On Tue, 26 Jun 2001, Dominik Vogt wrote:
<snip>
> 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 ;-)
Hi,
I have taken some time at home and work, and did some more research, here
are my findings.
1. Problem Setup:
Start application, move it to 0,0 coordinates of the root window, Ctrl-C it.
2. Problem Evaluation:
Replay the trail recorded in step 1. Trail replay is considered successful
if the upper left corner of the window manager decoration ends up at
coordiantes (0,0), as was during trail recording.
CDE (HP-UX 10.20) - OK
CDE (OSF1, dec alpha) - OK
CDE (Solaris 2.6) - OK
OLWM (Solaris 2.6) - OK
4Dwm (IRIX 6.5) - OK
KDE 2.1.2 kwin - OK
GNOME Sawfish - OK
WindowMaker - OK
FVWM2 - failed
blackbox - failed
AfterStep - failed
Enligntenment - failed
I did not test MWM, because I do not have access to it at home or at work.
As you can see, when an application requests to be placed at particular
coordinates, most popular window managers and industry standard window
manager CDE do not expect the application to account for the size of the
window decoration frame. However, FVWM2, blackbox, AfterStep and
Enlightenment all expect the application to account for the decoration size.
The end result is that there is no way to write an application using the Qt
toolkit and expect it to work correctly under CDE and FVWM2 - it's either
one or the other.
I would like to point out again, it is very important for future application
development on Unix/X11, that the window managers follow the same convention.
So far, CDE, OLWM, 4Dwm, KDE, GNOME and WindowMaker all follow the same
convention. FVWM2, blackbox, AfterStep and Enlightenment follow a different
convention. FVWM2 is in the minority.
So, have I convinced the FVWM2 maintainers to make the changes I requested
earlier? All I want is that all major window managers follow the same
convention (since ICCCM has not made it a standard). Personally, I think the
convention implemented by CDE should be followed, because CDE is the industry
standard window manager (I am one of the few running FVWM2 at work, everyone
else runs CDE 2.0).
Will you do it?
Paul.
--
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 Thu Jun 28 2001 - 21:58:13 BST