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 659246 - [GTK3] Cannot shrink window
[GTK3] Cannot shrink window
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: GUI
git master
Other All
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2011-09-16 13:59 UTC by Morten Welinder
Modified: 2011-09-24 15:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (343 bytes, patch)
2011-09-16 20:26 UTC, Jean Bréfort
committed Details | Review

Description Morten Welinder 2011-09-16 13:59:38 UTC
When a file is loaded from the command line, the resulting window
cannot be shrunk in either direction to a size less than the initial.
Comment 1 Jean Bréfort 2011-09-16 14:28:03 UTC
I suppose that we request the size when loading, and with gtk3, widgets can't shrink under the requested size.
Comment 2 Andreas J. Guelzow 2011-09-16 17:19:00 UTC
This is not restricted to the command line but applies to any file other than the one loaded into the initial window.
Comment 3 Jean Bréfort 2011-09-16 20:26:46 UTC
Created attachment 196772 [details] [review]
Proposed patch

Seems this work, apparently we need to calls to gtk_widget_set_size_request, the first to force the wanted intial size, and the second to allow shrinking.
Comment 4 Morten Welinder 2011-09-17 21:10:44 UTC
Hmm...

This behaviour is according to docs, i.e., it shouldn't have worked for
gtk2 either.

I wonder why we use gtk_widget_set_size_request at all.   Why isn't
gtk_window_set_default_size enough?
Comment 5 Jean Bréfort 2011-09-18 05:05:36 UTC
I suppose it's because we set the size of the notebook, not the GtkWindow size.
Comment 6 Andreas J. Guelzow 2011-09-23 20:53:46 UTC
And there is a problem with us setting the size of the notebook rather than the size of the window. As user I would expect the size of the window to be rebuild:

Example:

new Gnumeric
make sure no toolbars are shown.
A1: a
size the window to be 15 pixels or so less tall than your screen (and pick some arbitrary width about half your screen width)
save
switch on at least two horizontal toolbars
quit

restart Gnumeric
A1: b
now open the previously saved file. 
Note that the window is too tall! At least it is taller than the user probably expect.
Comment 7 Morten Welinder 2011-09-23 21:31:03 UTC
Well, there are two reasons for setting size:

1. To make the entire window take up the same screen real estate.
2. To make the same part of the sheet visible.

Our current code achieves #2 and fails at number #1 in your case.

Damned if you do, and damned if you don't.
Comment 8 Andreas J. Guelzow 2011-09-23 21:42:03 UTC
Perhaps we should try harder to do 1 _and_ 2, ie. save the status of the toolbars. Of course themes etc. may still cause our windows to vary with size slightly but hopefully not as extreme as with changes in the toolbars.
Comment 9 Morten Welinder 2011-09-24 14:36:52 UTC
Themes and file formats will get in the way.

Anyway, I don't think this is an issue that users lose a lot of sleep over.

Jean: please apply the patch.  That gets us going.
Comment 10 Jean Bréfort 2011-09-24 15:50:34 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.