GNOME Bugzilla – Bug 324254
Realizing a top-level window widget early positions it at 0,0
Last modified: 2011-11-10 18:17:23 UTC
Version details: 2.8.9 Distribution/Version: XP sp2 I'm currently testing some monitors at work, and I connected all 3 at once to my computer. Left and right monitors use 1024x768 resolution, center monitor (which is primary) uses 1280x1024. Left monitor's origin is -1024,120, right monitor is at 1280,72. GIMP user installation (both in 2.3.5 and 2.2.9) opens it's window on the left monitor, however part of it is hidden above the monitor boundary (the window's top left coordinate seems to be at -1280,0). After the user installation is complete, GIMP's own windows are also partially hidden above the upper edge of the monitor. X-Chat 2 shows similar problems, though they aren't immediatelly visible, since it starts maximized by default.
I also just ran into this problem. Two monitors. Same symptoms: windows being created off-the-screen of the smaller window. Gimp 2.2.10 win GTK 2.8.9 for win2k ++ Both fresh off your website with no additional gimp patches/features/plugins/etc loaded. Just a pristine new install. Dell Inspiron 2650 with built-in LCD and 17" external iiYama VM-510 22" external CRT monitor. CRT is primary (display 1), Laptop is display 2. LCD is 1024x768, CRT is 1280x1024. OS Name Microsoft Windows XP Professional Version 5.1.2600 Service Pack 2 Build 2600 OS Manufacturer Microsoft Corporation System Name GKETELL System Manufacturer Dell Computer Corporation System Model Inspiron 2650 System Type X86-based PC Processor x86 Family 15 Model 2 Stepping 7 GenuineIntel ~1894 Mhz BIOS Version/Date PHOENIX TECHNOLOGIES LTD. A05, 9/10/2002 SMBIOS Version 2.3 Windows Directory C:\WINDOWS System Directory C:\WINDOWS\system32 Boot Device \Device\HarddiskVolume1 Locale United States Hardware Abstraction Layer Version = "5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)" User Name ADARANET\gketell Time Zone Pacific Standard Time Total Physical Memory 512.00 MB Available Physical Memory 102.25 MB Total Virtual Memory 2.00 GB Available Virtual Memory 1.96 GB Page File Space 1.22 GB Page File C:\pagefile.sys
Are you sure this isn't caused by windows being opened at positions saved from earlier when you had just one monitor connected to the machine? Maybe GIMP should also save the monitor geometries and avoid restoring window positions in case the geometries have changed? Once you have moved the windows so that they are completely visible, quit and restart GIMP, do they open in the same locations? Anyway, this bug report is a bit too vague to be useful. We need a minimal sample program using GTK functionality only that shows what the problem in GTK is. I do notice that GTK seem to be very careful in positioning menus, for instance, not to cross monitor boundaries. I have two monitors, the left in portrait (1024x1280), the right in landscape (1280x1024) orientation. If I position GIMP's toolbox window so that its menu bar is partially in the "hole" above the landscape monitor, the pop-down menus are carefully positioned to be completely visible on one monitor.
I see this behavior too when my app restores windows to saved positions. My question is whether it's the app's responsibility to constrain positions to the visible areas of monitors or if gtk should do it. I suspect that under X11, it's under the window manager's control. A related issue is when the monitor geometry changes while the app is running. I just tested on my setup and it looks like open (both gtk and native) windows are repositioned so they remain visible if the display area shrinks. This might argue for gtk to constrain initial display of windows to the visible area.
Do you mean you see it when your app restores windows and the monitor geomety has changed inbetween? Or does it happen always when you have multiple monitors and "holes" in the screen? > This might argue for gtk to constrain initial display of > windows to the visible area. Ah, but how can GTK know whether the application for some reason really *does* want a window to be partially or completely outside the monitors? It wouldn't surprise me if that happens, too, in some applications. They would then break if GTK started repositioning the windows against the applications requests. Or maybe I'm being too careful here...
My bug report was about GTK+ windows whose titlebars were way above the monitor boundary on a fresh GIMP install (I mentioned the user installation wizard), making it hard to move them for somebody who doesn't know Alt+Space shortcut. There were no saved window positions from before.
Ah, sorry, I need to read more carefully... Still, could you be bothered with distilling out a minimal test program that just calls the same GTK functions that GIMP does when it opens the fresh install windows?
Just tested a gnome install and it does seem to let windows be positions so they are only partially visible initially. I don't have a setup where I can easily change the monitor geometry under linux. I think it's the application's responsibility to detect and deal with geometry changes. In the gimp case, does the monitor in question have a non 0 top y value? My wild guess is that gimp is assuming the monitor has a top left of 0, 0.
In the specific case of GIMP's user installation dialog, it seems that it is the call to gtk_widget_realize() in user_install_dialog_run() that causes the dialog to get positioned at 0,0 (in GDK coordinates) which might be outside the visible monitors if you have "gaps" in your multi-monitor setup. The whole mechanism behind this is not entirely clear to me, but if the dialog widget is already realized when passed to gtk_window_show(), that will call gdk_window_move_resize() causing the window to be truly positioned at 0,0. Presumably there is some bug in gdk/win32 as this doesn't happen on X11. A trivial workaround is to remove the call to gtk_widget_realize(). Then the window will be positioned "normally" in an automatically chosen location by Windows. Sven says removing the call to gtk_widget_realize() doesn't seem to do any harm on X11, either, so once that is done this problem hopefully will be gone at least for gimp's user installation dialog... I'll keep this bug open, though, as there real problem presumably is in gdk/win32. A minimal test program would be nice... Or examples of other gimp or gtk-demo dialogs that get positioned off-screen.
Created attachment 63903 [details] test program This is simply the "simple.c" test program from GTK+ with a call to gtk_widget_realize() added. It exhibits the problem.
Don't forget that my original complaint was also that GIMP's toolbox opened partially off-screen (the titlebar, menu and first line of tools weren't visible), and not just the user installation.
That seems to be caused by the default sessionrc positioning the toolbox at (48, 48) in gdk coordinates. GIMP apparently doesn't check whether the toolbox is completely visible if positioned there. Prolly should open a separate bug on GIMP for this.
See bug #339099 for the GIMP issue.
Fixed in 2.24.8