GNOME Bugzilla – Bug 649520
Window doesn't resize to fit the width of its contents widgets
Last modified: 2012-02-21 17:45:48 UTC
Created attachment 187327 [details] screenshot See attached screenshot.
Yeah, sometimes I see this sometimes I dont. gtk+-3 bug I think, not sure what do do. what gtk version are you running?
Running gtk3. Your comment made me want to try to investigate it myself, but it turns out to be a heisenbug... now that I'm trying to test it, it behaves correctly. Question though: why do you have like 7-10 levels of widgets in the glade file's hierarchy? Seems quite complex, are they all really in use?
(In reply to comment #2) > Running gtk3. Your comment made me want to try to investigate it myself, but it > turns out to be a heisenbug... now that I'm trying to test it, it behaves > correctly. > > Question though: why do you have like 7-10 levels of widgets in the glade > file's hierarchy? Seems quite complex, are they all really in use? When I started this gtk3 was still a little rough around the edges (and IIRC) in order to get the packing and expansion correct I came up with the rather complex h/v/h/v box hierarchy you see in the main window... so some of that might be unnecessary. Other than that, the use of a notebook to hide the start page is necessary (and is the same trick that gnome-control-center uses)
(In reply to comment #2) > Running gtk3. Your comment made me want to try to investigate it myself, but it > turns out to be a heisenbug... now that I'm trying to test it, it behaves > correctly. > The reason for that is that while testing you're opening the "Shell" tab directly, which causes the window to get resized. Click on some other tab, and then click on the "Shell" tab and the bug will be visible.
(In reply to comment #4) > (In reply to comment #2) > > Running gtk3. Your comment made me want to try to investigate it myself, but it > > turns out to be a heisenbug... now that I'm trying to test it, it behaves > > correctly. > > > > The reason for that is that while testing you're opening the "Shell" tab > directly, which causes the window to get resized. Click on some other tab, and > then click on the "Shell" tab and the bug will be visible. Nope, I dont see it.
*** Bug 649532 has been marked as a duplicate of this bug. ***
*** Bug 649533 has been marked as a duplicate of this bug. ***
Same here, I use Lithuanian language and some strings are longer than english, so widgets are invisible... I think, that making this window resizeable fix'es this bug. Attaching patch.
Created attachment 188216 [details] [review] Meakes gnome-tweak-tool window resizable.
*** Bug 651334 has been marked as a duplicate of this bug. ***
I Have the same issue here. At least make the window resizeable.
(In reply to comment #11) > I Have the same issue here. At least make the window resizeable. Pay me. Joking. Maybe. Seriously though, Im pretty certain this is a gtk bug, and on that presumption I am not going to work around it. It is transient, random and goes away if you search. A minimal reproducible test case might motivate me to work on it.
All languages has different label lengths, in some languages some labels takes way more space than in english, that's why some controls moves to right and is not visible. Some people like bigger fonts, this is yet another reason, why labels takes more space... Each time I install or update gnome-tweak-tool I need to go to /usr/share/gnome-tweak-tool/shell.ui and edit this line: <property name="resizable">False</property> changing it to this: <property name="resizable">True</property>
Created attachment 190014 [details] Translated labels takes more space...
(In reply to comment #13) > All languages has different label lengths, in some languages some labels takes > way more space than in english, that's why some controls moves to right and is > not visible. Some people like bigger fonts, this is yet another reason, why > labels takes more space... > I understand your point. But the gtk widget should request the size it needs based on the Lenght it requires to show text without truncating it. Like it does in the other 99% of cases. A minimal test case showing which single widget is not requesting space correctly would help locate the underlying bug
(In reply to comment #12) > (In reply to comment #11) > > I Have the same issue here. At least make the window resizeable. > > Pay me. Joking. Maybe. Only if you pay me for beta testing ;P. > Seriously though, Im pretty certain this is a gtk bug, and on that presumption > I am not going to work around it. It is transient, random and goes away if you > search. I do think it has something to do with the font setting on gnome 3. > A minimal reproducible test case might motivate me to work on it. I see a workaround that works in the comment 13: "Each time I install or update gnome-tweak-tool I need to go to /usr/share/gnome-tweak-tool/shell.ui and edit this line: <property name="resizable">False</property> changing it to this: <property name="resizable">True</property>" It worked well for me.
(In reply to comment #13) > All languages has different label lengths, in some languages some labels takes > way more space than in english, that's why some controls moves to right and is > not visible. Some people like bigger fonts, this is yet another reason, why > labels takes more space... > > Each time I install or update gnome-tweak-tool I need to go to > /usr/share/gnome-tweak-tool/shell.ui and edit this line: > > <property name="resizable">False</property> > > changing it to this: > > <property name="resizable">True</property> It worked well for me.
I repeat. I'm not commiting this work around. Searching causes the window to resize too.
I'm suspecting this might only happen when the gnome shell "user theme" extension is not installed. Could it be that infobar widget that shows when user themes are not available? Did you use the "get content area" method (if available)?
(In reply to comment #19) > I'm suspecting this might only happen when the gnome shell "user theme" > extension is not installed. Could it be that infobar widget that shows when > user themes are not available? Did you use the "get content area" method (if > available)? I suspect you might be correct. However, in the last days I replaced the infobar widget with a nicer and more consistent error reporting UI used throughout gnome-tweak-tool. So if the infobar was the culprit then can those that saw the bug please try to reproduce it using git HEAD?
Oh, and I just checked that I was using get_content_area prior to this change; I was.
Here's some additional confirmation. I can CONFIRM that this happens on a new install of Fedora 15, English language display, using its gnome-tweak-tool version 3.0.5. Basically, the window size for the "shell" side-tab doesn't resize properly. I can also CONFIRM that this is fixed if I edit /usr/share/gnome-tweak-tool/shell.ui and change this line: <property name="resizable">False</property> to: <property name="resizable">True</property>" Good luck!
(In reply to comment #22) > Here's some additional confirmation. Did you read the other comments in this bug? I am not working around a gtk bug by making the window resizable. I suspect the bug was in GtkInfoBar, which is no longer used in master. If you want to help please test with master and see if the bug is there.
(In reply to comment #23) Yes, I read the other comments, but the status of this bug is still "unconfirmed". I'm hoping that my report will justify making this "confirmed". I don't expect that you'll make the window resizable.
(In reply to comment #24) > (In reply to comment #23) > > Yes, I read the other comments, but the status of this bug is still > "unconfirmed". I'm hoping that my report will justify making this "confirmed". > I don't expect that you'll make the window resizable. It is unconfirmed because 1) no-one has determined this is a g-t-t bug and not a gtk one 2) no-one has confirmed it is still present in master (now that the widget hierarchy has been sympathised and the infobar removed.
Created attachment 192879 [details] The window issue.
I am using the master (downloaded 20 minutes ago) and still getting the windows size issue.
*** Bug 656038 has been marked as a duplicate of this bug. ***
I've been able to fix this just by opening, with Glade, the file /usr/share/gnome-tweak-tool/shell.ui , selecting "main_window" and setting "resizable" to "yes".
*** Bug 662305 has been marked as a duplicate of this bug. ***
screw it, lets just ellipsize long strings. 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.
*** Bug 663958 has been marked as a duplicate of this bug. ***
*** Bug 664623 has been marked as a duplicate of this bug. ***
*** Bug 665037 has been marked as a duplicate of this bug. ***
*** Bug 665107 has been marked as a duplicate of this bug. ***
*** Bug 666428 has been marked as a duplicate of this bug. ***
This has been marked as resolved/fixed, but it is still doing it for me. It should be reclassified as unresolved. For a fairly novice user (I'm not a novice, btw), the temporary fix would be to resize the window, but I see the strong resistance to making that the default. Is it customary for developers not to create workaround for upstream problems (gtk or not) when there are problems rather than waiting for the upstream (gtk) problem to be fixed (which may be a long time away)? I know in the programs that I have written (I am NOT a professional developer, I admit), I have many times had to work around issues such as this, esp with graphical interfaces. Why the strong resistance to simply allow the user to resize the window? I prefer to have windows resizable anyway (and it is how I write all my GUIs).
I did work around it in master (and the latest 3.2.x release). My work around was to ellipsize labels, and not resize the window. You didn't mention which version (of g-t-t) you were running so I assume it is an old one. If it is >= 3.2.1 then it is a different bug. Since 3.2.1 I have not received any new complaints of graphical window size glitches.
(In reply to comment #37) > This has been marked as resolved/fixed, but it is still doing it for me. Please ALWAYS mention your exact version and distribution.
Sorry, came over from bug https://bugzilla.gnome.org/show_bug.cgi?id=666428 where I was the reporter so had all that info. My current gtt is 3.0.4-2. I'm using Linux Mint Debian edition tracking Debian testing (just think of me on a debian testing box). Don't know when deb testing will upgrade to gnome 3.2, and other distros will need a fix for 3.0 versions that aren't a rolling release distro so I hope there is a fix in both the 3.0 and 3.1 versions. Not sure how far behind deb testing is on gtt. I'm thinking testing will be switching to gnome 3.2 as many of the gnome components are 3.2 now (including gnome-session), but not gnome-shell nor gtt. I'm crossing my fingers for a soon release. I'm eager for the 3.2 goodness.
(In reply to comment #40) > Sorry, came over from bug https://bugzilla.gnome.org/show_bug.cgi?id=666428 > where I was the reporter so had all that info. My current gtt is 3.0.4-2. I'm > using Linux Mint Debian edition tracking Debian testing (just think of me on a > debian testing box). > > Don't know when deb testing will upgrade to gnome 3.2, and other distros will > need a fix for 3.0 versions that aren't a rolling release distro so I hope > there is a fix in both the 3.0 and 3.1 versions. Not sure how far behind deb > testing is on gtt. I'm thinking testing will be switching to gnome 3.2 as many > of the gnome components are 3.2 now (including gnome-session), but not > gnome-shell nor gtt. I'm crossing my fingers for a soon release. I'm eager for > the 3.2 goodness. There is very little point in me making a 3.0.x version with the fix. Even if I do so it is my experience that the 3.0.x release will not be pulled into distros in good time anyway. The 3.2.x experiencing the same bug was a case in point - there were many duplicates, it was well reported, I fixed it, and it took weeks to get into distros. I suggest emailing the debian maintainer of gtt and asking him to cherry pick the single commit to fix your problem. It is less work in total for both of us and more likely to result in a fix getting to the repos.
I understand the point. Sadly, debian maintainers email addresses are mailing lists from which historically I have not gotten anywhere in endeavours such as this. I think you have to be more a member of the "in crowd" to get anywhere or you are ignored. I guess I'll just have to wait until 3.2 from sid (I'm duel tracking sid and testing with testing as primary as of earlier today) into testing. I could upgrade gnome 3.2 from sid (unstable) but am hesitant to do so for fear of breaking something. I'm willing to wait. It is good to know there is a fix that I will be able to have down the road (my wife and kids will find it much easier that way as they are novices).
Since you decided to go with a workaround in the end, why on earth did you not pick the workaround (resizable window) that actually makes the strings actually useful, rather than just make them more prettily unreadable?
(In reply to comment #43) > Since you decided to go with a workaround in the end, why on earth did you not > pick the workaround (resizable window) that actually makes the strings actually > useful, rather than just make them more prettily unreadable? To mock you?