GNOME Bugzilla – Bug 160977
Fix tasklist sizing behaviour (another one...)
Last modified: 2005-07-18 21:57:10 UTC
Since this recent changes in libwnck : 2004-12-03 Benjamin Kahn <xkahn@novell.com> * When a window title is too long to fit in the space provided, it should be shortened and ellipsizes should be shown. Fix for bug #155868 Buttons in the window list applet are always very small. It's like the window list applet did not use all the available space. It's very annoying as it makes it impossible to distinguish windows with similar icons.
See comment 11 and comment 12 in bug 155868 for a screenshot of this new problem.
The solution is here: http://bugzilla.gnome.org/attachment.cgi?id=32784&action=view from bug 155870 It simply needs to be approved by Havoc.
Well this patch would indeed fix this bug as a side-effect. And I agree that fixed-size buttons in the window list would be nice...
This gets even worse if you decide to group the windows when space is limited. Space is not limited, but the window list applet thinks it is, so it groups windows into very small buttons. The tasklist applet is basically unusable with libwnck 2.9.3 because of this bug.
*** Bug 164348 has been marked as a duplicate of this bug. ***
*** Bug 165084 has been marked as a duplicate of this bug. ***
How is this bug different from bug #125023 ?
I believe bug 125023, bug 155870, and this bug are all duplicates, but I'm not entirely certain. Part of the problem is that 125023 and 155870 have different patches, and we probably don't want to lose them... *shrug*
Elijah : do you think this could be set as a 2.10 showstopper ? The window list applet (which is very widely used) is unusable because of this bug.
(or at least set the "minimum size" of the button in the preference panel to something sensible, like 400 or 500 pixels...)
Sure, we _can_ do that. Though I'm thinking Luis or Andrew are going to thwack me for it. ;-)
*** Bug 165399 has been marked as a duplicate of this bug. ***
Moving to the right component. Sorry for the spam.
*** Bug 149804 has been marked as a duplicate of this bug. ***
Setting as NEW. We've confirmed this to death a long time ago :-)
*** Bug 166599 has been marked as a duplicate of this bug. ***
*** Bug 166858 has been marked as a duplicate of this bug. ***
Nope, this is totally a showstopper- after you've launched more than one application, it is the first bug you see in GNOME...
Created attachment 37823 [details] [review] preliminary fix to squished tasklist buttons My take on this bug: one function, wnck_tasklist_layout(), performs two different tasks, one called from wnck_tasklist_size_request() and the other from wnck_tasklist_size_allocate(). This patch simply splits wnck_tasklist_layout into two different functions, one to ask for a desired size, and one which allocates the given size (essentially what wnck_tasklist_layout() did previously). A couple issues, first wnck_tasklist_request_layout() could ask for a smaller size, see the comment in the code. Secondly, there seems to be a regression when grouping==WNCK_TASKLIST_AUTO_GROUP and there are apps which could be grouped together. It seems _request() groups them and thus asks for less space than needed, but _allocate() does not actually group them. Thus, we get squished buttons again. Once they are grouped, it displays correctly. I'm working on a patch to fix this, but it will be more complicated. Still, it acts nicer than before.
Let's finally look at this! Nathan: the reason we use only one function for the request and the allocation is because we want to request only what we need, and not more. And to see what we need, we try to find a layout. I can not try your patch right now, but it seems to me you're requesting too much space. I looked at the patch in bug #155870 and at my (old) patch in bug #125023... Havoc's comment in bug #155870 about font size is correct. My old patch needs some love and cruft removal. I'll try to update my old patch and see if it really solves the problem... I'm not sure it's the right approach, but at least I'll get to know the code again :-)
Created attachment 37934 [details] [review] patch number two gah it's early in the morning, and I've been playing with this entirely too long, so there are bits in the patch that can't be pretty. That said: o I discovered gtk_widget_get_size_request(), it actually had been used at one point then commented out. Solves the problem when the tasklist requests far too much space. (At least vertically, more on that later.) o I still believe that wnck_tasklist_layout() is used in two fundamentally different ways, thus it should be split into two functions (my code does this, there is some duplicate code that could be a procedure). o wnck_tasklist_size_request() needs to do different things depending upon grouping (ALWAYS vs AUTO). I did this by copying the while loop, changing it to an if block, and stripping any of the looping code. It's a kludge, it seems to work when everything else I tried didn't. I don't know why. o gtk_label_set_width_chars() is a beautiful function. By using it I believe it's possible to obsolete setting minimum/maximum widths entirely. Without it, max_button_width is far too small, which might have been the root of our problems to begin with. And now the bad news: because gtk_widget_get_size_request() returns -1 for the width, my tasklist does not limit it's width...at all. Which shows what might be a bug in the panel...my notification area, clock, etc. are pushed off the right side of the screen when there are sufficient open windows. If the requisition width is artifially limited then the panel returns to normal. Whose responsibility is it to crop the tasklist? Shouldn't the panel do this, and is this a bug to report?
I found a really stupid simple way to fix the bug without any big change of the code. Since 2.10 is due really soon, I'd favor this patch to anything else. Comments welcome.
Created attachment 37981 [details] [review] The stupide simple patche :-)
Note that I should probably s/MAX_CHAR_WIDTH/MAX_WIDTH_CHARS/ ;-)
It seems to destroy ellipsizing--if a title is too long, it is merely truncated instead of being ellipsized.
Good catch. /me returns to the code.
Created attachment 37997 [details] [review] Patch that works It seems to me the previous patch should work. It indicates there's a bug in the GtkTable allocation routines.
Ah, I found how to make it worl with a GtkTable: we just need to add GTK_SHRINK to the xoptions of the label. Anyway, I don't think we need a GtkTable here :-)
Sweet! Seems to work like a charm here. Well, there is the problem that the right bracket on minimized windows is missing (it gets ellipsized with everything else), but I believe that was a bug that existed before anyway...
I committed my patch. I'll leave the bug open, though, so we don't lose Nathan's patches. Maybe we should open a new bug and move the patches from this bug, bug #155870 and bug #125023 there? (this bug is not a 2.10 showstopper anymore)
*** Bug 169240 has been marked as a duplicate of this bug. ***
Vincent: yeah, I think it makes sense to open a new bug since there are two different issues anyway. (For those who are following this and other bugs, the issue fixed here was that taskbuttons would shrink themselves to be much shorter than the title length even when there was sufficient space; the remaining bug is that the length of all taskbuttons are dependent on the length of the longest title when there is sufficient space to display all titles)
*** Bug 169402 has been marked as a duplicate of this bug. ***
Consolidating as per comment 30; see bug 310809. Also, attachment 37394 [details] doesn't apply cleanly anymore so I'll update it's state while I'm at it, but please put any updates in 310809 since we're moving the remainder of this bug over there. Marking this bug as fixed, as Vincent fixed the buttons-are-always-super-tiny issue.