After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 151581 - menu unusable after switching screen resolution
menu unusable after switching screen resolution
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.4.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2004-09-01 08:29 UTC by Arjohn Kampman
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test GdkScreen::size-changed (949 bytes, application/octet-stream)
2004-09-02 04:33 UTC, Matthias Clasen
  Details
Suggested patch, untested yet (7.09 KB, patch)
2004-09-02 05:04 UTC, Tor Lillqvist
none Details | Review

Description Arjohn Kampman 2004-09-01 08:29:29 UTC
The following was reported by Gaim developers to be a GTK+ bug.

Whenever I switch to a lower resolution (when switching
from an external monitor to my notebook's lcd), the
menu that can be popped up by right-clicking the gaim
icon is unusable as most of invisible. Only the
top-most item ("New message...") is reachable, the rest
is rendered off-screen.

The original (Gaim-) bug report including a screen shot can be found here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1019022&group_id=235&atid=100235
Comment 1 Tor Lillqvist 2004-09-02 02:11:06 UTC
"Don't do that then" (http://www.catb.org/~esr/jargon/html/D/Don-t-do-that-then-
.html)

GTK doesn't handle switching screen resolution on the fly on X11, either. 
(Yeah, I know that in traditional X servers this isn't even possible. But isn't 
there nowadays some extension that makes it possible?) More importantly, 
neither does any GTK application.

Is it too harsh to resolve as NOTABUG? Or maybe there already is a more generic 
enhancement request that this could be duped on.
Comment 2 Matthias Clasen 2004-09-02 02:51:12 UTC
GTK+ does handle them since 2.2 at least in sofar as there is a
GdkScreen::size-changed signal, which gets emitted when the screen resolution
changes. Does the win32 backend not emit that signal ?
Comment 3 Tor Lillqvist 2004-09-02 03:11:36 UTC
Oops, hadn't noticed. No, gdk/win32 does not emit that. Will have to implement 
it. But would that help the original poster's problem, does gtk use that signal 
for anything? Or is it enough if GDK's idea of root window size is changed?
Comment 4 Matthias Clasen 2004-09-02 03:13:57 UTC
I haven't played around with RANDR on X, really. Thus I can't say if emitting
::size-changed will make the menus behave better, but I think getting that
signal would be the prerequisite to fixing the menu behaviour, if necessary.
Comment 5 Tor Lillqvist 2004-09-02 03:33:08 UTC
A further complication on Windows is that it's possible to switch screen depth, 
too, not just resolution. That's not possible with RANDR. But it probably is 
safe to just ignore that issue, a gtk/win32 application continues to work even 
if the screen depth changes.

Should there also be a monitors_changed (or whatever) signal, to indicate that 
the number and/or positioning of the monitors that the screen consists of has 
changed? Or does size_changed also cover that?
Comment 6 Matthias Clasen 2004-09-02 03:42:58 UTC
I think XRANDR (the spec) also allows to change depth, but that part of the spec
hasn't been implemented yet. Is it possible to change the number of monitors on
the fly on win32 ? Standard X doesn't provide for changing the number of screens
and Xinerama doesn't provide for changing the number of monitors, AFAIK. If this
is possible on win32, then a GdkScreen::monitors-changed signal would make a lot
of sense, I'd say. (Though handling that in gtk would mean catering for 
0.2 - 0.5 % of the GTK user base, I guess)
Comment 7 Tor Lillqvist 2004-09-02 03:54:52 UTC
> Is it possible to change the number of monitors on the fly on win32 ?

Yes, and their relative position.

Looking further at the X11 backend code, it does call init_xinerama_support() 
in _gdk_x11_screen_size_changed(), so I guess this means that size_changed is 
intended to cover also monitor positioning (or even number) changes.

Another thing: The X11 backend doesn't seem to set the width and height fields 
of it's per-screen root_window's GdkWindowImplX11 when it handles a screen size 
change? Should it?
Comment 8 Matthias Clasen 2004-09-02 04:15:45 UTC
Hmm, init_xinerama_support() is called from there to update the size information
for the monitors, I don't think it implies that ::size-changed was intended to
cover monitor geometry changes. But it certainly makes sense to reinterpret the
signal in this way.

You are right about the root_window size, though it may be that we get a
ConfigureNotify for the root window, and pick up the new size from that. I'll
experiment.
Comment 9 Matthias Clasen 2004-09-02 04:32:39 UTC
Yea, the root window seems to pick up the new size via a configure event.
I'm attaching a small test program.
Comment 10 Matthias Clasen 2004-09-02 04:33:32 UTC
Created attachment 31201 [details]
test GdkScreen::size-changed
Comment 11 Tor Lillqvist 2004-09-02 05:04:39 UTC
Created attachment 31202 [details] [review]
Suggested patch, untested yet
Comment 12 Tor Lillqvist 2004-09-03 01:30:32 UTC
The test program needs to actually create a window to receive any WM_* messages 
on Windows, just creating and showing an empty toplevel window is OK. There was 
a minor bug in the patch (forgot to use the "impl" field of GdkWindowObject), 
but otherwise it seems to work. Applied to HEAD and gtk-2-4.
Comment 13 Arjohn Kampman 2004-09-03 07:57:58 UTC
Thanks a lot. The response on my bug report has been incredible. Cheers to you all!