Added extra configuration options to the dock and the panel

[AKArien]

• Dock and panel :
  • Changed « Autohide duration » to « Animation duration »
  • Added options to control the delay before doing the showing/hiding animations
  • Added options to place them on the left or right edge of the screen
    • This also includes an « orientation », that allows to override how certain elements might want to change depending on the position. For the dock, this can show the icons with their « base » oriented to an edge of the screen. For the panel, most widgets now have a layout optimised for a vertical bar.
      • this is not the case for window-list, command-output and network widgets
• Dock :
  • Added maximum entries per line. When this number is exceeded, a new line is created for the next icons.
• Panel :
  • Renamed « Widgets left » and « Widgets right » to left/top and right/bottom to go with new option to have panel on the sides
  • Added minimal width option
  • Added option to let the panel not span the full edge
    • Option to force the panel to be centered by the middle box instead of the total width. This will lead to more spaced out elements in the side that takes less space

Breaking stuff :

• out_box for panel is supressed, so no more style using it.
• dock/dock_height is repcaled by dock/minimal_height

Adresses #259

[eaglgenes101]

I'm interested in some of the features in this PR, is this suitable for trying out at this moment?

[AKArien]

@eaglgenes101 hi, thanks for your interest !
While some of the code is on the "never let this see the light of day" list, i'm pretty sure most of the features should behave correctly for the user. Of course, please report back if you have any issues or improvements !

Exception is the "orientation" (pivoting) feature : options for rotated icons in the dock don't look and feel great, because the icons are not perfect squares and the widgets are still laid out as per their original dimensions, leading to a bit of overlap. I also meant to let panel widgets be oriented similarly, but it's even more of a problem there.
I'm thinking of just giving up on this pivoting ordeal, as it's probably not such great eye candy anyway.

[eaglgenes101]

In the end, I decided that this functionality isn't exactly what I wanted. That said, having icons on the side dock works well, and I don't recall any bugs I ran into.

[AKArien]

Probably not perfect as is, but i’m hoping it won’t be a waste of your time to review :)

[AKArien]

@trigg hey there, taking the liberty to ping you to ask how much breaking is ok.
notably, this is currently breaking dock_height to unify minimal sizes between panel and dock. With it introducing a vertical panel, i currently changed the description of widgets_left and right to indicate wether it becomes the top or bottom. Soreau also suggested to rename them as start/end, which i do see the value in, although it’s a bit unclear at a first reading which is which.
And hey, if we are breaking things… i am once again asking to change launchers_size into launchers_icon_size :)
He also suggested splitting this pr in a few smaller ones, which i will let you be the arbiter of soundness of.
Finally, if you have any idea on how to make the reflowing dock look good on the bottom, i’d like to hear :)
And, ofc, comment on the code problems ! Notably reloading the layout of widgets for a vertical panel currently has a lot of copypaste, but i’m not sure what is the best way to cut down on it.

[trigg]

After a quick read through, this looks well thought out.

As to the questions:

• I'd only use the terminology 'Start'/'End' instead of top/left bottom/right if it's also respecting the users reading direction. I don't think we are but could be wrong.
• I'd welcome creating a launchers_icon_size option, provided we also check for an existing value in launcher_size first. We can phase the older out but we'll need a cross-over time period
• Same with dock height, check existing config-name first, switch to newer name if unset.
• Splitting this PR looks, to me, like it would just make a bunch of PRs that all require one another to work. Possibly reorder and title commits to individual tasks, but I'd be happy to squash merge otherwise.

I've not had a chance yet to run this and see it in action, I intend to soon