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 643138 - Can't show dialog near parent window and guarantee its not off screen
Can't show dialog near parent window and guarantee its not off screen
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.22.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2011-02-23 22:20 UTC by Steven T. Snyder
Modified: 2018-02-10 03:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Steven T. Snyder 2011-02-23 22:20:34 UTC
Note: I have not confirmed if this is a cross-platform issue or just an issue with GTK+ on Windows.

With *PyGTK* 2.22.0 running on *Windows 7*, I want to have a new window pop up near a parent window, but never off-screen. 

I observed the behavior I want in *Microsoft Wordpad* in both *Windows 7* and *Windows XP*. If you make the window very small and move it to the bottom right of the desktop, right click in the text field, and open the *Paragraph* menu, the dialog pops up fully visible. This happens even if the *Wordpad* window is partially off-screen. The child dialog does not pop up in a fixed position relative to the main window. It just pops up close, and fully visible.

My application consists of a main screen which spawns child windows that block the rest of the application until the user is finished using them. The user may have to open and close many child windows in sequence, so I want them to appear near where they click on the button, so the user doesn't have to move the mouse all over the screen.

I tried using *gtk.WIN_POS_MOUSE*, but when the main menu is near an edge of the screen; the child window that spawns often ends up partially off-screen. 

I would expect that a call to *set_transient_for(main_menu)* on a child window should inform *Windows* that I want my window to be near its parent. However, *Windows* just places it at the top left of the desktop -- not even necessarily on the same screen as the main menu.

The following Python code for PyGTK will demonstrate the problem by popping up a window at the bottom left of your screen that contains a button which spawns a subwindow when clicked:

 class MyWindow(gtk.Window):
     def __init__(self):
         gtk.Window.__init__(self)
         self.connect("delete-event",self.on_delete_event)
         button = gtk.Button("Open Subwindow")
         button.connect("clicked",self.open_sub_window)
         self.add(button)
         self.set_gravity(gtk.gdk.GRAVITY_SOUTH_EAST)
         self.show_all()
         width, height = self.get_size()
         self.move(gtk.gdk.screen_width() - width, gtk.gdk.screen_height() \
                                                                    - height)
 
     def on_delete_event(self, widget=None, data=None):
         gtk.main_quit() 
 
     def open_sub_window(self, widget=None, data=None):
         w = gtk.Window()
         w.set_size_request(200,200)
         w.set_transient_for(self)
         w.set_position(gtk.WIN_POS_CENTER_ON_PARENT)
         w.show()
 
 if __name__=="__main__":
     MyWindow()
     gtk.main() 


As you can see, the sub_window shows up partially off-screen.
If you comment out the line *w.set_position(gtk.WIN_POS_CENTER_ON_PARENT)* you will see that the *Windows* window manager just places the subwindow at the very top left of the desktop. Not very useful!
Comment 1 Martin Renold 2011-07-24 12:14:18 UTC
I can confirm this bug, and also that it is Windows specific.

MyPaint users on Windows frequently report problems with windows appearing offscreen: https://gna.org/bugs/index.php?15239
This does not happen on Linux.
Comment 2 Matthias Clasen 2018-02-10 03:37:47 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.