GNOME Bugzilla – Bug 695989
set_geometry_hints max_width/max_height not honoured on win32
Last modified: 2018-04-15 00:35:04 UTC
Here is the code: import gtk x=gtk.Window() x.set_geometry_hints(max_width=600, max_height=400) x.show() gtk.main() This works as expected on Linux (bar any window manager overrides you may have), but it does not do anything at all on win32. One can resize the window beyond the maximum dimensions specified, though the maximize button is greyed out. How can I get the max dimensions to be honoured on win32?
Actually, it does do something. If you set max_width and/or max_height (not exactly sure about the combinations) your window will stop responding to resize() requests when a user resizes it above the max dimensions you specified. And not even always, at one point it did work for me and then it stopped working again, and I couldn't figure it out. Then it dawned on me, I removed the max_width and max_height from set_geometry_hints and now my resize code does work. Meaning, once a user has resized the window above max_width or max_height, you can no longer programmatically resize it back. From my hack attempts at getting around this limitation, there are two ways to get some form of max size: 1) In the "configure-event" for your gtk.Window, execute window.hide(), window.resize() and window.show(). This will blink the window and make the user lose his resize 'grasp' on the window border. So: # def handler(widget, event): # if event.width > MY_MAX_WIDTH: # widget.hide() # widget.resize(MY_MAX_WIDTH, event.height) # widget.show() 2) In the "configure-event" for your gtk.Window: - create a tuple (True, MY_MAX_WIDTH, event.height) and make sure you can access it elsewhere - call widget.queue_draw_area(0,0, event.width, event.height) 2b) In the "expose-event" for your visible gtk.Window/Container/Widget: - check your tuple and call window.resize() on its values - replace your tuple with (False, 0, 0) or something of the kind This will fire a LOT of events but as soon as the user releases the resize border the window will get resized back to your required dimension(s). But I'm sure there is a more native Windows method for this, although there is scarcely any documenation for PyWin32.
This is still broken with GTK3 on win32, tested with the semi-official pygobject32 3.8 builds (but works on Linux): from gi.repository import Gtk, Gdk #@UnresolvedImport window = Gtk.Window(Gtk.WindowType.TOPLEVEL) window.set_size_request(300, 200) window.connect("delete_event", Gtk.main_quit) geom = Gdk.Geometry() geom.max_width = 600 geom.max_height = 400 hints = Gdk.WindowHints.MAX_SIZE window.set_geometry_hints(window, geom, hints) window.show_all() Gtk.main()
Right. I was reporting this for/on the latest pygtk for gtk2, which would have been... pygtk 2.24 with pygobject 2.28.
I was just hoping GTK3 would fare better. Never mind. I have implemented a workaround using pywin32 instead. The problem is that apart from a few GTK developers who manage to build from source on MS Windows, everyone else uses a version from one the released binaries on gnome.org, all of which have the broken max-size... and many many other known bugs. The last pygtk2 version on the ftp server is 2.5 years old (and is so full of critical security issues it's not funny).
When I was on the GTK+ forums some while ago when this was current for me, my impression was that it was a group of people who were accustomed to using extremely poor tools. In Dutch there is a word that resembles it called "pover" and it is used only for things that are lacking. When you say "this and that is not functioning very well" the answers you get are very despondent and defeated. They basically suggest you'll just have to live with it, by offering suggestions that are completely unsatisfactory workarounds. My feeling current is that wxWidgets is actually much betterly maintained ... ;-). The python bindings wxPython (classic) 3.0.1.1 was just released a few days ago. From what I can see (I have no experience with it whatsoever) wxWidgets doesn't even USE wxGTK on Windows systems (but it does so on Linux/Unix). Personally, I don't like the "gobject" (Gnome Object) abstraction that GTK3 uses. GObject is something huge. It provides access to an entire set of Gnome libraries. That is not something an ordinary GTK user should need or want to use. In PyGTK2, it was abstracted, or hidden, by actual functional meaningful libraries, but from what I understood, this normal access method was removed and now you have to use that GObject thing directly, which is a horror to me. With wxWidgets you probably would not need to care about such things as you only have to work with the common interface(?). But the reason (and only reason) I chose to experiment with GTK2 first is because I want or wanted the thing to turn into a GIMP plugin eventually ;-).
I meant "my feeling currently".
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new