Re: FVWM: I might have a bug fix.

From: Rene Huber <rene_at_pallas-athena.com>
Date: Fri, 29 Jun 2001 11:13:23 +0200

On Thursday Jun 28 2001 at 08:59:00PM -0600, Paul Koshevoy wrote:
> On Tue, 26 Jun 2001, Dominik Vogt wrote:
>
> <snip>
>
[..]
>
> 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).
>


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:  rene_at_pallas-athena.com   \     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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Fri Jun 29 2001 - 04:13:22 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:51 BST