On Mon, Jun 25, 2001 at 09:22:01PM -0600, Paul Koshevoy wrote:
> Hi,
>
> I've looked through HandleConfigureRequest() in fvwm-2.2.5/fvwm/events.c,
> and I found some code that I believe to be in error.
>
> At line 1450, the code reads:
> if (cre->value_mask & CWX)
> x = cre->x - Tmp_win->boundary_width - Tmp_win->bw;
> if (cre->value_mask & CWY)
> y = cre->y - Tmp_win->boundary_width - Tmp_win->title_height - Tmp_win->bw;
> if (cre->value_mask & CWWidth)
> width = cre->width + 2*Tmp_win->boundary_width;
> if (cre->value_mask & CWHeight)
> height = cre->height+Tmp_win->title_height+2*Tmp_win->boundary_width;
>
> I beleve it should read:
> if (cre->value_mask & CWX)
> x = cre->x;
> if (cre->value_mask & CWY)
> y = cre->y;
> if (cre->value_mask & CWWidth)
> width = cre->width;
> if (cre->value_mask & CWHeight)
> height = cre->height;
>
> I believe that the code is trying to account for the size of frame decorations.
> However, the event sender is supposed to include all the right information in
> the event already. Here is a comment from the code:
>
> /*
> * SetupWindow (x,y) are the location of the upper-left outer corner and
> * are passed directly to XMoveResizeWindow (frame). The (width,height)
> * are the inner size of the frame. The inner width is the same as the
> * requested client window width; the inner height is the same as the
> * requested client window height plus any title bar slop.
> */
>
> I am working on a small project where correct window placement is desireable.
If you want to write a client behaving well you should read
section 4 of the ICCCM2 which describes how window manager and
application interact properly. For your convenience I have
attached this section.
However, this will not help here. The ICCCM2 is too foggy about
window movement, and therefore there are applications that assume
either placement including or without the wm border. In other
words: whatever approch we chose, it will always be incorrect for
some applications. The pros and cons for your version are:
pro:
1) Reading the ICCCM2 carefully it seems this approach is
favoured.
2) It works better with Java applications.
cons:
3) Only few applications do it this way, so it would break more
applications than fix.
4) Some applications work like this: They ask the WM for a
specific position of their client window in root coordinates,
say (x, y). Now, with your approach the window manager would
place the client window at (x+bw, y+bw+th). The application
gets a ConfigureNotify event with the new position
(x+..., y+...). There are some applications that respond with
a new ConfigureRequest (triggered by XResizeMoveWindow()) now
requesting (x+bw, y+bw+th) as their new position. In response
they'll be placed at (x+2*bw, y+2*(bw+th)), and so on. The
windows finally wander off screen.
You see, (4) is the real reason why the approach implemented in
fvwm was chosen. This is not hypothetical, it really has happened
a lot in the past. Now, you could argue that an applications must
never respond to a ConfigurNotify with a ConfigureRequest (as
stated by the ICCCM2), but that does not help much. kwin will
suffer from the described problem, and will probably switch to the
approach in fvwm one day, so I recommend you switch to placement
method referring to client window coordinates, not frame
coordinates - even at the cost of having to calculate the WM frame
geometry yourself.
Anyway, it is almost always a very bad idea to let your
application move its own windows to absolute positions on the
screen. User will usually hate you for it. Most of the time it
is safe to assume that the window manager will do a much better
job in placing the windows than your application since it knows
about the other windows on screen too. Most of the applications
I saw trying that fail miserably anyway ;-)
> It's written using the Qt toolkit. The program behaves as expected under kwin,
> but misbehaves under FVWM2. When I tell the pogram to move itself to
> coordinates 0,0, fvwm2 puts it at -2,-18 (the size of the window
> decoration at that location).
>
> So, I have a fix in my local copy of fvwm2-2.2.5, but I would strongly prefer
> to see it in the official code. Actually, last night I was ready to fix
> every major window manager that did not agree with my program ;-), but I started
> with fvwm2 because I use it the most. Here is the reason why I think that in
> this fvwm2 is in error and not my program:
>
> http://doc.trolltech.com/geometry.html
>
> If you want, I can send you the source to my program to remove any doubts.
> It needs Qt 2.3.x to compile (RH 7.1 has 2.3.0, but I tested it under 2.3.1
> as well).
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: d.vogt_at_lifebits.de
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue Jun 26 2001 - 03:24:59 BST