Geometry Problems -- *Negative* screen placement of windows

[Robert Heller]

At Wed, 29 Nov 2006 14:35:24 -0500 David Hampton <hampton-gnucash at rainbolthampton.net> wrote:

> 
> On Wed, 2006-11-29 at 13:59 -0500, Robert Heller wrote:
> > GnuCash (2.0.1-4.rhel4) sometimes gets it into its mind to pop up
> > windows and dialogs with a *negative* y placement.  This makes it
> > difficult to move to the window, since the window manager title bar is
> > off the top of the display. Is there some way to fix this?  Or is this a
> > known bug.
> > 
> > I am NOT using a Gnome or KDE desktop -- I am using fvwm2 in mwm
> > compatibility mode.
> 
> That sounds like a bug in fvwm2.  Gnucash does nothing more than ask the
> window manager for the coordinates, store them in a file, load them from
> a file, and pass them back to the window manager.  If the window manager
> get/set routines don't agree on whether the coordinates include the
> window border then this problem could occur.  E.G. The get routine
> returns the coordinates of the window border, and when gnucash hands the
> numbers back the set routine takes them as the coordinates of the window
> content, and then subtracts a bit to get the coordinates of the border.
> 
> Do the windows creep upwards every time you close and reopen them?

I just started and restarted GnuCash and yes the main window does open
higher the second time than it did the first time, so I guess they do. 
I've never really noticed this before...

*None* of my other applications have this behaviour, at least as far as
I can tell.  I do have explicit  geometry settings for almost all of the
applications a regularly open, especially those I start at login time
(started from my .xinitrc script). Other applications never have the
problems that GnuCash has though.  I'm guessing that they don't bother
to ask and save window geometry fetched from fvwm2 or else if they do
the make sure the origin is never negative.

The man pages for XAllocSizeHints, XSetWMNormalHints, XGetWMNormalHints,
XSetWMSizeHints, XGetWMSizeHints, and XSizeHints (all on the same page)
include this statement:

"The x, y, width, and height members are now obsolete and are left
solely for compatibility reasons."  Which is suggestive...

Yes, it does seem that fvwm2 has a problem.  I just did a little
experiment with wish (Tcl/Tk):

% toplevel .foo
.foo
% wm geometry .foo [wm geometry .]

The toplevel foo was moved on top of the main toplevel and displaced up
and to the left by the size of the WM decorations!

Maybe I need to download the sources to fvwm2 and figure out what is
going on (there is another pesky bug -- the Icon box module crashes when
the title of a window get too long and sometimes people go totally off
the deepend with web page <title> tags.).

> 
> David
> 
> 
>                                                                                                        

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Linux Installation and Administration
http://www.deepsoft.com/  -- Web Hosting, with CGI and Database
heller at deepsoft.com       -- Contract Programming: C/C++, Tcl/Tk