From: Arnout E. <no...@bz...> - 2011-02-19 03:41:40
|
Hi, Some applications show dialogs that are incorrectly placed - they might even position them off-screen. To move around transient popups, modifying the 'attrs' (for example at ioncore/clientwin.c:543) will affect where the window shows up. For 'non-transient dialogs', however, this does not appear to affect the window location - I hope I'm getting the terminology right here: I mean a dialog without its own titlebar whose location is constrained to be in its parents' frame (but which can be moved freely within the frame). An example program exhibiting the problem is attached - run it with 'java MisplacedDialogContainer2' (java 1.6). The popup is shown too far to the right and/or too far to the bottom when the container frame is not in the top-left frame of the screen. What would be the proper way to influence where this dialog is placed when mapped? Kind regards, Arnout |
From: Arnout E. <no...@bz...> - 2011-03-05 00:47:56
|
On Sat, Feb 19, 2011 at 04:41:28AM +0100, Arnout Engelen wrote: > Some applications show dialogs that are incorrectly placed - they might even > position them off-screen. > > To move around transient popups, modifying the 'attrs' (for example at > ioncore/clientwin.c:543) will affect where the window shows up. > > For 'non-transient dialogs', however, this does not appear to affect the > window location I was somewhat off-the-mark here: changing the 'attrs' for these popups does effect them. In this particular case, however, immediately after mapping the dialog, it would be moved again with a XConfigureRequestEvent. This XConfigureRequestEvent changes the window location (flags CWX and CWY) but not the dimensions (flags CWWidth and CWHeight). check_normal_cfgrq() in ioncore/clientwin.c interprets this as the new x/y coordinates being 'hard' and the current height/width being 'weak' suggestions. In this particular case, because the x coordinate is too high, moving the dialog off-screen, and the width was considered 'weak', the width got reduced to '0'. I'd say we should take into account the dimensions even when only the location is being specified. The following patch does that: diff --git a/ioncore/clientwin.c b/ioncore/clientwin.c index 9ec1b68..27bd85e 100644 --- a/ioncore/clientwin.c +++ b/ioncore/clientwin.c @@ -1231,10 +1231,12 @@ static bool check_normal_cfgrq(WClientWin *cwin, XConfigureRequestEvent *ev) if(ev->value_mask&CWX){ rq.geom.x=ev->x+gdx; rq.flags&=~REGION_RQGEOM_WEAK_X; + rq.flags&=~REGION_RQGEOM_WEAK_W; } if(ev->value_mask&CWY){ rq.geom.y=ev->y+gdy; rq.flags&=~REGION_RQGEOM_WEAK_Y; + rq.flags&=~REGION_RQGEOM_WEAK_H; } region_rqgeom((WRegion*)cwin, &rq, NULL); This seems to make sense and indeed it fixes the problems I previously encountered with applications misplacing their dialogs. I haven't noticed any negative side-effects yet. I'd appreciate it if anyone could comment/review/test ;). Kind regards, Arnout |
From: Arnout E. <no...@bz...> - 2011-03-11 23:41:11
|
On Sat, Mar 05, 2011 at 01:47:41AM +0100, Arnout Engelen wrote: > On Sat, Feb 19, 2011 at 04:41:28AM +0100, Arnout Engelen wrote: > > Some applications show dialogs that are incorrectly placed - they might even > > position them off-screen. > > immediately after mapping the dialog, it would be moved again with a > XConfigureRequestEvent. This XConfigureRequestEvent changes the window > location (flags CWX and CWY) but not the dimensions (flags CWWidth and > CWHeight). > > check_normal_cfgrq() in ioncore/clientwin.c interprets this as the new x/y > coordinates being 'hard' and the current height/width being 'weak' suggestions. > > In this particular case, because the x coordinate is too high, moving the > dialog off-screen, and the width was considered 'weak', the width got reduced > to '0'. > > I'd say we should take into account the dimensions even when only the location > is being specified. After some discussion on IRC we decided it would be good to, apart from taking into account the width and height to prevent the dialog from getting 'squashed', to ignore the value entirely when it is out-of-bounds. http://notion.git.sourceforge.net/git/gitweb.cgi?p=notion/notion;a=commit;h=0cd1e04960312d5c1c1a28efe5bc9f3453e33de2 Kind regards, Arnout > > diff --git a/ioncore/clientwin.c b/ioncore/clientwin.c > index 9ec1b68..27bd85e 100644 > --- a/ioncore/clientwin.c > +++ b/ioncore/clientwin.c > @@ -1231,10 +1231,12 @@ static bool check_normal_cfgrq(WClientWin *cwin, XConfigureRequestEvent *ev) > if(ev->value_mask&CWX){ > rq.geom.x=ev->x+gdx; > rq.flags&=~REGION_RQGEOM_WEAK_X; > + rq.flags&=~REGION_RQGEOM_WEAK_W; > } > if(ev->value_mask&CWY){ > rq.geom.y=ev->y+gdy; > rq.flags&=~REGION_RQGEOM_WEAK_Y; > + rq.flags&=~REGION_RQGEOM_WEAK_H; > } > > region_rqgeom((WRegion*)cwin, &rq, NULL); > > > This seems to make sense and indeed it fixes the problems I previously > encountered with applications misplacing their dialogs. I haven't noticed any > negative side-effects yet. > > I'd appreciate it if anyone could comment/review/test ;). > > > Kind regards, > > Arnout > > ------------------------------------------------------------------------------ > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > _______________________________________________ > Notion-devel mailing list > Not...@li... > https://lists.sourceforge.net/lists/listinfo/notion-devel |