On Tue, Jun 26, 2001 at 11:58:12AM -0600, Paul Koshevoy wrote:
> 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.
Right. Unfortunately, this has not happened up to date and with
all the applications that have already been written and that are
no longer maintained there is little chance of ever having a
standard.
> Like I said, I am ready to go rewrite every significant widnow
> manager out there.
You had better rewrite all applications to either scheme. The
window manager can't do it right in all cases without help from
the user. It took us roughly a year to tune the code so that it
produces acceptable results (i.e. the applications appears
roucghly in the correct spot and does not wander off screen under
any circumstances) with every application we encountered and I am
not willing to give that up to console some library authors who
do not care about the rest of the world.
> Which programs do you know of that would not place right with
> this change?
I can't remember any names, but almost any program that responds
to resizing with a new ConfigurRequest that includes the position.
Searching our mail archive from 1999 should surface some names.
> Do you really care about them? Do you
Yes, absolutely. If I have the choice to either misplace some
windows or to have some other windows wander off the screen I'll
chose the first.
> know of any other window manager that implements the same window
> placement scheme as FVWM2.
I guess any off the fvwm-offspring do it this way (scwm,
afterstep, ...). I didn't verify that, though.
> 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
What can I say? Trolltech and KDE have done the X world a
disservice with their method of forcing bugs to become a
"standard". While there is a slight chance that java on Unix will
one day revert to the placement behaviour described, I see little
chance that Qt will ever change. It's so buggy, we can hardly
make a patch for every little defect. Of course it would be
possible to make another Style option to cope with these windows,
but since Qt or Java windows don't announce the creating library
it is not possible to automatically chose the correct method.
> FVWM2 2.2.5. How long do you plan to keep FVWM2 backwards
> compatible with some old programs, while not benefiting any new
> programs?
Forever. Over time, fvwm accumulates options for each and every
problem there ever occurs (if it can not be solved in a general
way). However, I still have hope that these libraries revert to
the de-facto standard one day.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt_at_gmx.de
Reply-To: dominik.vogt_at_gmx.de
--
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 - 22:02:29 BST