Re: QPopupMenu should not use QApp::desktop()->availableGeometry()

[Havoc Pennington <hp redhat com>]

Hi,

Quoting your whole message for wm-spec-list gnome org which is really
the right list.

On Mon, Nov 11, 2002 at 09:24:26PM -0800, John Firebaugh wrote:
> Apparently Qt 3.1 now uses the desktop work area as defined by WM struts (if 
> supported by the windowmanager) for placing popup menus and tooltips. This is 
> probably wrong. At least it interacts very badly with the KDE panel:
> 
> http://bugs.kde.org/show_bug.cgi?id=50390
> http://bugs.kde.org/show_bug.cgi?id=49430
> http://www.halux2001.de/other/snapshot1.png
> http://www.halux2001.de/other/snapshot2.png
> 
> IMO, about the only thing the work area should be used for is deciding how to 
> maximize windows. Is there any sort of standard on this?
> 

My guess is that this is just a Qt bug and not intentional.

IMO the struts should be taken to mean that there's an always-on-top
panel on that side of the screen, more or less. This means e.g. you
don't want to maximize windows underneath the panel.

I'm not sure there's a point in clamping tooltips and menus to the
strut area, because tooltips and menus should be override redirect
windows and thus appear on top of any panels anyway, so if they
overlap the panel a bit, it's not really an issue. In fact you may as
well use the whole screen for menus to avoid scrolling.

But this isn't really something that is or should be in the spec or
standardized, it's just a judgment call that toolkit developers will
need to make.

One option if clamping is desirable in general might be for the
toolkit to support semantic types on toplevels (e.g. "dock" and
"splashscreen"), then have tooltips/popups from windows of type "dock"
ignore the struts. If the toolkit has semantic knowledge it can also
set the corresponding WM spec hints of course.

Havoc