Subject: FVWM: I might have a bug fix.

From: Paul Koshevoy <[email-masked]>
Date: Mon, 25 Jun 2001 21:22:01 -0600 (MDT)

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.
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).

Thank you,
	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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Paul Koshevoy <[email-masked]>
Date: Mon, 25 Jun 2001 22:08:06 -0600 (MDT)

>   if (cre->value_mask & CWHeight)

Actually, although this places the window at the right coordinates,
it screws up the size. Here is the revised fix:
  if (cre->value_mask & CWX)
    x = cre->x;
  if (cre->value_mask & CWY)
    y = cre->y;
  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;

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 26 Jun 2001 10:24:21 +0200

> 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 needs Qt 2.3.x to compile (RH 7.1 has 2.3.0, but I tested it under 2.3.1

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, email: [email-masked]
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Paul Koshevoy <[email-masked]>
Date: Tue, 26 Jun 2001 11:58:12 -0600 (MDT)

Hi Dominik.

> 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?

---

From: Paul Koshevoy <[email-masked]>
Date: Thu, 28 Jun 2001 20:59:00 -0600 (MDT)

<snip>

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.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 27 Jun 2001 02:23:09 +0200

On Tue, Jun 26, 2001 at 11:58:12AM -0600, Paul Koshevoy wrote:
> 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

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, [email-masked]
Reply-To: [email-masked]
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Rene Huber <[email-masked]>
Date: Fri, 29 Jun 2001 11:13:23 +0200

> On Tue, 26 Jun 2001, Dominik Vogt wrote:
[..]
> standard window manager (I am one of the few running FVWM2 at work, everyone

Why not do it the way mwm has done it:  make it configurable.  From
the mwm manual page:

positionIsFrame (class  PositionIsFrame)
                 This resource indicates how client window  posi-
                 tion information (from the WM_NORMAL_HINTS prop-
                 erty and from configuration requests) is  to  be
                 interpreted.  If the resource value is True, the
                 information is interpreted as  the  position  of
                 the  mwm  client  window  frame. If the value is
                 False, it is interpreted as being  the  position
                 of  the  client  area of the window. The default
                 value of this resource is True.

In fvwm, it might even be a Style, seeing that not all applications
behave the same.

	RH
-- 
#   Rene Huber - Software Engineer  \ / Pallas Athena B.V., The Netherlands #
#   Email:  [email-masked]   \     PO box 747, 7300 AS Apeldoorn    #
#     Phone/Fax:  +31 55 5760881    / \     http://www.pallas-athena.com    #
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Paul Koshevoy <[email-masked]>
Date: Fri, 29 Jun 2001 23:51:04 -0600 (MDT)

On Fri, 29 Jun 2001, Rene Huber wrote:

<snip>

> In fvwm, it might even be a Style, seeing that not all applications

A configuration option for configurable window placement behavior would be an
acceptable solution. I would be even happier if FVWM2 followed MWMs example,
and made the placement by frame the default, while maintaining the current
placement behavior as a backwards compatibility configuration option.

Paul.