[Goodies-dev] Panel plugins HIG

[Mike Massonnet]

Le mercredi 30 mai 2012 à 11:44 +0200, Harald Judt a écrit :
> Am 29.05.2012 21:47, schrieb Landry Breuil:
> > - when in vertical mode, labels should be angled vertically to display
> > fine (but keep them horizontal to please people still using 4.8
> > orientation-changed mode..). I assume if people wants labels
> > horizontal, they'll use deskbar mode with a wide enough panel or with
> > 2 or 3 rows.
> 
> That's right about the labels, 

I'm all OK for using rotated labels at the time in vertical mode, I
updated the Wiki page in that regard. One question is still open, what
angle should be used for the labels? Is it always 90°? Or rather 270°
when the panel is on the left side of the screen, and 90° for the other
side?

Currently plugins (clock, and menu plugin) seem to set an angle of 90°
despit the position of the panel.

> [...]
> 
> > Addressed in the panel ->  api change ->  not going to happen in 4.10 :)
> 
> Also it won't help as the external plugins are supposed to support older 
> versions of the panel. That would be another bunch of #ifdefs, and I 
> can't see them anymore.

It's better to avoid the #ifdef hell. Distributions that aren't
upgrading to 4.10, aren't going to upgrade plugins either. Since 4.10 is
out now, there is no good reason to publish new plugin releases with
#ifdefs.

> > Or then we also want a panel-wide setting for
> > - label padding
> > - plugin border
> > - progressbar size
> > - progressbar orientation
> > - etc etc...
> 
> In fact that would be fine as it , though you wouldn't need "progressbar 
> orientation". That makes me think if we shouldn't consider xfconf some time.

I can list the following settings that are most common.

optional frame / 1px border around the plugin
 - clock
 - notification area
 => it will be useful to know when/for which plugins this can be
included

2/4px padding around the plugin
 - progressbars
 - labels

button
 - no padding
 - no relief

progress bar
 - 8px width

I don't see anything else for the moment, so nothing really new there :)

> >> In fact I'm not all thrilled by the idea of having small/medium/big
> >> paddings. What will be missing next is the size of the composite
> >> widgets (labels and progressbars).
> >
> > There are improvements to do, and making the border size variable
> > is a good idea, i'm just not sure we need 3 or 4 different sizes..
> > We need to settle on something, test it with all plugins and see how
> > it looks. Screenshots are always better than words thrown around..

+1

> If we do not care about smaller panels than 20 pixel, then my test cases 
> would be met with BORDER = (panel_size > 26 ? 2 : 1). That's still an 
> improvement over no border. Otherwise, we need to use some formula to 
> calculate the value. I guess we'd be the first to use polynomial 
> interpolation in panel plugins? ;-)

Sounds good. The Wiki page has also been updated with this information.

One open question is the size of the labels. When the panel size is too
small, for example < 18px, the font size may be reduced because it tends
to be unreadable. But that's hard to tell, since it depends on the
system font size.

> Similarly, we won't need to deal with extremely big panel sizes (show me 
> one user who chooses the maximum of 128). Currently, we don't have 
> screens with 400 dpi or extremely high resolutions, though that might 
> perhaps become an issue in the future.

Maximilien Noal:
> Well, with xfce4-embed-plugin you can hit that limit pretty fast:
> http://pix.toile-libre.org/?img=1338394462.png
> 
> But that's the only "sane" use case I can think of. ;-)

The embed plugin is one of those plugins that simply don't need a
padding ;)

Mike