Can't shrink window

[popey]

Somehow I have managed to make the pick window large and am unable to make it smaller again. It occupies a huge amount of my desktop (3 screens) and can't be made smaller.

[stuartlangridge]

This is a Pick bug, but it's caused because I don't know how to make a Gtk window be a certain size at my request but still allow it to be resized smaller.

The code currently uses set_size_request (https://github.com/stuartlangridge/ColourPicker/blob/app/pick/__main__.py#L379), specifically ourwindow.set_size_request(width in pixels, height in pixels). I will happily change this for something else which sets the size but doesn't set the minimum size, but I don't know what to change it to. So any suggestions or help are welcomed.

[johndrinkwater]

https://developer.gnome.org/pygtk/stable/class-gtkwindow.html#method-gtkwindow--set-default-size suggests changing from set_size_request to set_default_size would behave as wanted, allowing user to shrink below your saved state.
Gtk3 docs aren’t as useful, but they mention this function still exists. https://python-gtk-3-tutorial.readthedocs.io/en/latest/dialogs.html?highlight=set_default_size

[stuartlangridge]

Sadly, using set_default_size doesn't actually seem to set the size of the window, in Pick, and I don't understand why. Maybe things inside the window restrict its size or something?

[misterben]

Yeah - looks like set_size_request is the wrong thing. From the set_default_size info:

Unlike the gtk.Widget.set_size_request() method, which sets a size request for a widget and thus would keep users from shrinking the window, this method only sets the initial size, just as if the user had resized the window themselves. Users can still shrink the window again as they normally would. Setting a default size of -1 means to use the "natural" default size (the size request of the window). For more control over a window's initial size and how resizing works, investigate the set_geometry_hints() method.

For some uses, the resize() method is more appropriate as it changes the current size of the window, rather than the size to be used on initial display. The resize() method always affects the window itself, not the geometry widget. The default size of a window only affects the first time a window is shown; if a window is hidden and re-shown, it will remember the size it had prior to hiding, rather than using the default size. Windows can't actually be 0x0 in size, they must be at least 1x1, but passing 0 for width and height is OK, resulting in a 1x1 default size.

So you could maybe try using the resize() method?

[ralight]

If you remove the formatters combobox I bet you'll find it shrinks a lot more. That's the element that is setting the minimum width, even when it's hidden.

[ralight]

(obviously that's not a solution, but should help you figure out where the limiting factor is)

[stuartlangridge]

So you could maybe try using the resize() method?

You would think, wouldn't you? However, doing self.w.set_default_size(myw, myh) and self.w.resize(myw, myh) together still stubbornly fails to actually resize the window in the way that set_size_request does.

If you remove the formatters combobox I bet you'll find it shrinks a lot more.

It doesn't, I'm afraid. The formatters dropdown is a fixed size; it certainly enforces something of a minimum size on the window, but it does not grow with the window. If you increase the size of the Pick window, close Pick, and then re-open it, the size of the formatters dropdown doesn't change, and doesn't take up the full width of the window... and the window cannot be resized any smaller than it currently is. Using set_size_request to set the window's size is what causes that, certainly, but if I don't use set_size_request to set the window size then it doesn't actually resize to be the size I want. Hence puzzlement.

[ralight]

Hmm, you're right. I'm sure it was behaving differently yesterday.

Anyway, I think this exposes another bug. Pick saves window width and height as a proportion of the screen width/height to ~/.cache/colour-picker.json and attempts to restore them (so removing that file would've been a quick fix). @popey I wonder if you ran pick last time when your laptop wasn't docked, and so the screen size was small. After you docked, the screen size is much bigger, but pick was still using the same proportions for restoring so the window size became massive.

[stuartlangridge]

Pick saves window width and height as a proportion of the screen width/height

It does (and screen position, too). This is to avoid the issue where a saved position is off the edge of, or larger than, the screen it's being restored onto; it does have the problem you mention, where Pick saving its size on a small screen and then restoring onto a big one makes it large, but it's at least guaranteed to be within the screen, rather than being partially off it (which is very hard to fix unless you're the sort of power user who knows about alt+dragging to move a window, or alt+space to get at the window menu).

I'm not sure this is fixable -- as far as I'm aware, you either have one problem or the other -- and so I went for the one that causes fewer problems for non-expert users, but I'm happy to hear suggestions for alternate ways it should work. ("The desktop remembers for you and restores windows spatially to where they were last, for every application" is a better solution but that battle was lost many years ago, and I think that Pick always coming up in the same place for a user is valuable enough that I implemented it inside the app and plan to keep it doing that, somehow.)

[ralight]

You could save the old screen resolution and compare, then if they're different either try to be clever about it (likely to fail on non-rectangular composite screens like Popey's and mine), or just don't bother about restoring the size/position in that likely rare case.

[misterben]

Did you look any closer at set_geometry_hints() as a way of setting a sensible minimum first?

[stuartlangridge]

Did you look any closer at set_geometry_hints() as a way of setting a sensible minimum first?

I didn't, 'cos the above commit works -- I think what I was doing before was trying to resize too early, perhaps before the window was properly realised, so the actual fix here is to work out what I need to wait for and then set the size based on that. Maybe set_geometry_hints would help to set the size before then, although that's what set_size_request is for (it just has the awful side effect of setting a minimum size as well).