GNOME Bugzilla – Bug 96343
no clear behavioral policy for size conflicts between applet and panel
Last modified: 2007-06-29 12:20:35 UTC
If you have a panel set to a size smaller than one of it's applets, the panel won't shrink. But then you get a weird panel like the following: http://bugzilla.gnome.org/showattachment.cgi?attach_id=11717 Usability Problems: 1) There's no way to tell which applet is preventing the panel from shrinking, other than removing the panel applets 1-by-1 until the panel shrinks. Can you tell, in the screenshot, where the problem is? When I originally saw this, I thought it was a problem with the window-list (and almost filed a bug). But it's the clock! 2) Some applets expand to fill the width of the actual panel (like the window-list), while other applets don't get wider than the panel's specified width (like the menu, drawer, mixer, and workspace-switcher). There should be a policy one way or the other, and all applets should behave consistently. I think that these two issues are probably the result of some higher-up hole in the design. Has anyone come up with a design and specification for how applets should behave with respect to different panel sizes? Also see bug 83686 and bug 96341.
Also see bug 75189.
Michael: For point 1, we already have bugs bug 83686 and bug 96341. So, the issues left in this bug would be point 2 excluding the clock applet. Guess, we should be raising bugs against the respective applets which are causing the problem. But we could leave this one for the discussions to take place and finally raise bugs if required against the respective applets. Hope it is fine. Also some discussion did take place in bug 94152 on issue.
Yes, maybe I wasn't too clear: this bug is that there isn't a general policy saying what to do. Bug 83686 and bug 96341 don't actually discuss point 1. Point 1 is that it's impossible for the user to figure out which applet is preventing his panel from being small when he tries to make it small. Those bugs just discuss the problem of one particular applet (the clock applet) that keeps the panel from being small. For some applets, it might be desirable for them not to shrink (I don't know). But you should still be able to tell *why* it is that your panel doesn't shrink -- thus the usability problem of point 1. For point 2: Before filing bugs with individual applets, we need to determine what the applets should be doing in the first place! Should they expand to fill a panel's width, even if the panel is set to a smaller width than it can go, or should they be at the width the the user set the panel to? I can think of arguments for both options. For instance, if all applets shrunk to the user's specified panel size, we'd have a partial solution for point 1: it would be much clearer which applet is preventing the panel from shrinking. It's hard to file bugs against all applets without knowing what behavior is "buggy". That's why I filed this bug -- I don't think anybody's really thought about a policy to figure out this general problem.
My personal feeling is that all applets should be responsible for shrinking to however small the panel asks them to go. If it is waaay smaller than they can go, they could opt to display text or something informing the user of that. Expanding the panel can be, as Michael points out, very annoying.
That's my personal feeling too. One option might be to modify the applet framework, in particular the canvas, such that any applet that paints itself through the canvas can by dynamically shrunk (or stretched for big panels) in order to fit on the panel at a good size. However, I don't know *anything* about the actual gnome applet framework code, and have no idea about whether this would be possible or desirable. And not too many applets use a canvas. But I think the ones that have the most trouble rescaling are either A) the ones that DO use a canvas (like wanda-the-fish) or B) the ones with wide text strings on vertical panels, like the clock (and window-list to some extent). Both of these components seem to be good candidates to apply an "applet resizing framework" to, since they are fairly straightforward to resize. This would, at least, make it easier for applets to conform to ackward panel sizes, so that we wouldn't have to worry about applets that don't fit on the panel as much.
Is this still an issue? Panels (even a new empty one) in 2.8 don't seem to shrink less than 23 pixels (although they allow for the pixel width to be decreased all the way to 12 with no discernable effect).
I think this got fixed with the new toplevels in 2.4.