GNOME Bugzilla – Bug 100110
text not visible on cdplayer applet
Last modified: 2004-12-22 21:47:04 UTC
On a horizontal panel, the text which displays the track no and display time is cut (or half visible) when the panel size is XX Small, Small & Medium.
*** Bug 100107 has been marked as a duplicate of this bug. ***
The problem here is that the labels don't expand (in gnome1 they expand and the cdplayer makes the panel larger). By not expanding the text gets squished
This seems to happen to other applets as well. Try the clock applet on a small panel. Something must have changed recently in gnome-panel. I'm moving it there temporarily.
Mark: any idea on this one?
Yes, its caused by this: 2002-10-17 Mark McLoughlin <mark@skynet.ie> * panel-applet-frame.c: (panel_applet_frame_constrain_size): impl to constrain an applets position to not be larger than the the panel width. (panel_applet_frame_size_request): use it. Applets are supposed to respect their size allocation. I know, this is hard when the allocation is smaller than the text size ... I don't really know what to do about it. Hmm .... There's some other bugs around for applets doing this.
oh yes, infact a min-commander would be unusable on a vertical panel now . Although it should not be put on a vertical panel in the first palce. Still it looks bad. Probably we have to come up with a list of applets that a vertical panel can ever have.
That seems to be an easy way out. You may want to discuss this on the usability list before taking it forward.
Calum, seth: thoughts, comments ? :)
Mark: I think even the clock gets constrained right now. Is there a reason we should keep this change to the panel? Maybe we can change it after 2.2 and then change all the applets to behave properly?
Several reasons really ... applets *shouldn't* make the panel expand. Doing that takes up valuable screen space on the user. Applets should respect the size allocated to them - I made the fish do a few days ago instead of using the size_changed signal .... I'll say again - with a large font, there isn't a whole lot the applet can do, so we need to figure out something. The reality is that the panel needs to be bigger so I think jumping up to the next size setting is what should happen instead of increasing the panel size. i.e. change the preference rather than the panel size. I dunno, I'm prolly talking crap.
Same problem as in bug #97409. Not sure if this should be marked as duplicate, though.
I think Mark's assessment is basically correct, although I don't completely agree that an applet should *never* make a panel expand-- if the user has specified minimum font and icon sizes in their theme, an applet ought to respect those, and a panel ought to grow to the smallest size necessary to meet that demand if required. Which is almost what Mark said, except he only mentioned text, not icons :) (I realise that most applets, not to mention launchers etc., aren't currently engineered to shrink their icons no smaller than the gtk theme's icon sizes anyway, but that's not to say they shouldn't in the future.) Ensuring 'the smallest size necessary' for the panel is one of the sizes in the preferences dialog sounds like a reasonable solution given the way panels currently work... although of course it would be much nicer if you could just grab panel edges and make them any damn size you wanted :)
The "solution" I thought of long time ago was: when an applet is too large, only display part of it (as it is now I suppose), but when the mouse gets over it (or it gets focus), grab the applet, stuff it into an override redirect window above the panel of the proper size. So when you would run the mouse over such an applet it would sort of "break out" of the panel so that you can fully use it.
Interesting idea, I guess it wouldn't work so well for monitoring-type applets where the idea is to be able to just glance down at the panel for information rather than having to interact with it, though. We really need to work pretty hard at figuring out a consistent model for how the panel and its contents resize, it's pretty wild up to 2.2 at least... it must be the only desktop window in the world that's designed to hold less information when you make it bigger :)
How about defining a panel size as a certain multiple of the application font size?
See #94026. The minimum panel size is now relative to the font size: min_size = font_ascent + font_descent + 2 * (focus_pad + focus_width + thickness) I think this should fix this cdplayer issue, especially if Kevin has done the expanding work on the cdplayer ... bouncing it back to gnome-applets for now.
Yep fixed now.