[Goodies-dev] Panel plugins HIG

[Landry Breuil]

On Tue, May 29, 2012 at 6:12 AM, Mike Massonnet <mmassonnet at xfce.org> wrote:
> 2012/5/28 Harald Judt <h.judt at gmx.at>:
>> Most plugins don't have padding around the progress bars. This is intended, because some people like to string together the meters, without any free space between them.
>> So, in most cases there is only padding around the plugin container box.

There's plugin container box _border_ set with
container_set_border_width which takes care of the space 'outside' of
the box,
and then there's the spacing between the childs 'inside' the box. Two
different variables, so many things to disagree on.. So far, what
we've seen is :
- buttons/images dont specifically need spacing, because the icon
usually dont span the whole width of the button
- labels look good with a 2px spacing, otherwise with a 0px spacing
they're 'stuck' to their neighbour
- progressbar themselves dont need spacing, because usually theres a
label or button/image besides them which comes with its own spacing
- some progressbars dont size the same - i agree we should have a
#define progressbar_width (set to 8 ?), but which height ? Imo, the
gtk_widget_set_size_request() call should ONLY take care of the width
and let -1 for the other dimension, so that the size comes from the
parent widget. For example systemload does (BORDER, size - BORDER),
that looks wrong to me.

Because screenshots are always better than words, here's shots of a
panel in various size/mode/nrows, with from left to right (last
releases, not what's in git) :
battery cpugraph diskperf fsguard mpc netload systemload timeout wavelan
http://rhaalovely.net/~landry/shared/xfce/

I've set the panel background to colored to show the plugins which
dont have 'transparent' event boxs (some of them are fixed since them
in git)

It clearly shows :
- that's there's zero consistency (thank you captain obvious)
- that the progressbars are too small on small panels (ie too much box
border width ?). On large panels its less visible, but still some
space wasted. On the contrary, i find the battery progressbar too high
(not enough border ?)
- imo , 20px panels are unusable (font too small, icons squeezed,
progressbar ridiculous...) 25 or 26 should be a 'minimum' if one wants
to show monitors..
- Some plugins dont set 'small' property and look awful on 2 rows
panels  (fsguard, timeout) we still have to decide whats the guideline
for setting small or not. Personally, i think small should have been
set as defaulting to true. Most plugins look ugly by default on
multiple-rows panels
- 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.
- to me, either vertical or deskbar mode should orient the progressbar
as vertical... i'd say deskbar mode. Others might disagree of course
:) But then, which size should it be ?

>> I've uploaded several patches to the bug tracker for demonstration purposes
>> which do for the padding something very similar to what you proposed (you
>> can quickly find them by using the search terms "use better border sizes").
>> These solutions are certainly not ideal, though; Landry Breuil thinks a
>> function replicated in every plugin is not the way to go, as this might lead
>> to another copy-and-paste orgy. I agree with him in that such a function
>> would be better located in a central place, or a better solution can be
>> found.
>
> Indeed it makes the code redundant, but it's the case with signals
> handling like size-changed or orientation-changed, they almost all do
> the same. I don't see an issue with the patches. Of course it could be
> addressed directly inside libxfce4panel, but there is nothing settled
> yet.

Addressed in the panel -> api change -> not going to happen in 4.10 :)
Or then we also want a panel-wide setting for
- label padding
- plugin border
- progressbar size
- progressbar orientation
- etc etc...

> 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..

> And since all of this is a style issue, it might be addressed
> differently... style properties can work.

Style properties through gtkrc files ? That's not accessible to john
doe users :)

Landry