Hi Dominik.
On Tue, 26 Jun 2001, Dominik Vogt wrote:
> 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 ;-)
My application is replaying an event trail file. The trail file contrains a
list of user generated events - mouse clicks, keyboard input, window move and
resize events, focus change events, show, hide, repaint, etc.... When the
trail is replayed, the application reassembles events in the trail file into
actual events, and sends them to the event dispatcher, therefore faking user
input. So, if I record a trail where I drag my window to coordinates 0,0 on
the root window, I want the trail replay to put the window in the right spot.
However, under current fvwm2 2.2.5, the window is being placed at -2,-18.
My argument for changing fvwm2:
The application can be run under any window manager, or without a window manager
at all. Therefore, application cannot assume anything about the size of the
decoration frame. When application decides that it should be placed at a
particular location, it specifies where the decoration frame upper left corner
should be, and the dimensions of the inner frame, and does not need to know
anything about the size of decorations the window manager will put on the
window (since those can vary wildly from window manager to window manager, from
theme to theme). With this scheme, I can record my trail under one window
manager, and replay it under another window manager, and expect the window
frame upper left corner to be a 0,0.
The largest problem with what you suggested (to account for frame size inside
the application), is that my application does not know which scheme the window
manager is implementing for window placement. The only real solution to this
problem is to standardise on one scheme. Like I said, I am ready to go rewrite
every significant widnow manager out there. Which programs do you know of that
would not place right with this change? Do you really care about them? Do you
know of any other window manager that implements the same window placement
scheme as FVWM2.
Paul.
PS.
The Qt toolkit is very significant, there is a large number of new projects
being ported to Qt or written in Qt from scratch. These new programs rely on
the window placement behavior advertised by Qt, which will work under kwin,
but will fail under FVWM2 2.2.5. How long do you plan to keep FVWM2 backwards
compatible with some old programs, while not benefiting any new programs?
--
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 - 12:56:47 BST