Vertical panel mode(s)

[Andrzej]

On 10/27/2011 04:41 PM, Nick Schermer wrote:
>
>> 1. Acknowledge that there are two very distinct use cases for vertical
>> panel mode and add an option to panel preferences.
>>    Specifically, "Orientation" panel property could have three values:
>>      - Vertical,
>>      - Horizontal,
>>      - Vertical (dock).     (The name is not very good, I know. Please
>> propose something better)
>>    In "Vertical (dock)" mode all items should arrange themselves horizontally.
>
> This can also be simulated by send a horizontal orientation to the
> plugins. I think I prefer a checkbox to enable this behaviour.

Do you mean such option already exists and it just isn't exposed in the 
GUI? I must admit I didn't spend much time searching for alternative 
solutions.

> My idea was to add a packing/container plugin to add for example 3
> launchers in a vertical row. Is still on the 4.10 roadmap, but I'm not
> sure if I can complete it mostly because I doubt it's a solution for
> the problem and might be complicated to work with.

For launchers I'm currently using a Quicklauncher plugin (I got this tip 
on #xfce, thanks killermoehre). Yes, it would be nice to have something 
better (like a list of launcher icons displayed as an automatically 
wrapped array) but for the time being quicklauncher does the job.

Note that this works only for launchers, other plugins cannot be grouped 
this way, and perhaps they shouldn't be, as they often display a menu so 
they may need "access" to the edge of the panel.

Other issues I've spotted with plugins in a vertical pager/dock.:
- application menu:
   button title is vertical
   icon is scaled to the width of pager (I'm OK having this particular 
icon a bit larger than others)
- workspace switcher:
   workspaces are "transposed". Instead of:
     1  2  3
     4  5  6     (where number of rows is 2)
   I'm using:
     1  3  5
     2  4  6     (where number of rows is 3)
- window buttons - works OK (which is *a lot better* than its Gnome's 
counterpart) but the option for changing the orientation could be moved 
to the panel itself
- battery monitor:
   icon is scaled to the width of pager but luckily displaying icon can 
be disabled.
- /most of other other plugins displaying icons, such as "show desktop"/
   large icon which cannot be disabled.
- notification area:
   icons are big and positioned vertically - this can be fixed by 
changing the "maximum icon size" option (again, this could instead be 
taken from the panel settings - point 2 in my previous email).

> They are not used in the panel, but for plugins only. Not many plugins
> inside the panel use these, but for example the menu positioning does.
> Adding the dock mode here is a bad idea, because the place on the
> screen does not change, I even not completely agree with the _H and _V
> in there; floating and the cardinal directions would've been better;
> but that's a leftover of previous versions.

OK, it was just my misunderstanding of purpose of these enums.

> Personally I love the Haiku deskbar and wouldn't mind if Xfce4-panel
> could behave in the same way. It's not that complicated, because a lot
> of plugins are already capable of this in some extend, but it requires
> a lot of testing and tiny adjustments.

Indeed, the Haiku deskbar is very close to what I'd like to have.

Making all the plugins aware of the "vertical dock mode" (or should we 
call it a deskbar?) is good but I'd prefer to have one switch in the 
panel rather than 10 in each plugin separately. Occasionally I may want 
to move the panel back to the top or bottom of the screen.

Also, making the vertical panel and then configuring orientation or icon 
size of each plugin seems like working around a mismatch between the 
design of the panel and the user's "mental model". This is really a 
property of the panel not the plugins.

As for the complexity and testing overhead - I think the the *long term* 
burden would actually be lower with a single switch (+ icon size) 
instead of N separate tweaks in each of the affected plugins. Of course, 
this would still had to be implemented and tested - no magic here.

Andrzej