UI idea: Turn the status bar into a docker (or several dockers)

[Thomas Pfeiffer]

On 23.08.2012 15:02, Jaroslaw Staniek wrote:
> On 23 August 2012 14:45, Thomas Pfeiffer <colomar at autistici.org> wrote:
>> On 23.08.2012 14:40, Jaroslaw Staniek wrote:
>>>
>>> On 23 August 2012 14:31, Thomas Pfeiffer <colomar at autistici.org> wrote:
>>>>
>>>> Hi everyone,
>>>> while discussing the best way to implement the word count in the Author
>>>> UI,
>>>> I had an idea for the Calligra UI in general.
>>>> Flexibility is one of the key advantages of the Calligra UI. One of the
>>>> few
>>>> UI parts that are currently not flexible is the status bar. That's why I
>>>> asked myself:
>>>> "Why not put the the things currently displayed in the status bar in one
>>>> or
>>>> several docker(s), put these dockers at the bottom by default (or maybe
>>>> someplace else if that works better for a particular application) and
>>>> remove
>>>> the standard status bar?"
>>>> This would allow to keep the current layout as default while preserving
>>>> maximum flexibility. To me, this is the logical consequence of the
>>>> "Flexible
>>>> UI" paradigm of Calligra.
>>>> So, what do you think about it? Did I miss any problems/downsides?
>>>
>>>
>>> This is good idea observed in dynamically configured apps, e.g.
>>> Firefox and generally XUL allows the plugins to inject ui bits in such
>>> places too.
>>> I plan to have view-related actions (dependent on context/plugin used)
>>> in Kexi's statusbar for example.
>>
>>
>> Well technically it wouldn't be a statusbar anymore, then ;) But if you can
>> inject stuff into a standard statusbar, you can shot it in a statusbar
>> docker as well, correct?
>
> Correct. And we know that too much uncontrolled flexibility could result e.g.:
> - in what we've seen in KDE 3 toolbars: buttons that cannot fit on
> screen horizontally, and thus display annoying arrow button on the
> very right hand,
> - in misaligned UI elements (sometimes a problem with nested
> QWidgets/QGroupBoxes/QLayouts).
>
> As usual it would be ideal to forget technical limitations and make
> sure with the UI and interaction is superb and by default; and take
> enough care so the user cannot 'break' the UI's usability by just drag
> & dropping.
>
> PS: Example of adaptability when an UI element is dragged onto a
> limited area is plasmoid - when dragged onto panel it changes its
> geometry and sometimes even the way how the content is presented.

Absolutely. We need dockers to realign themselves based on position anyway, 
because dockers placed on top need to be aligned differently than those placed 
on the sides as well.
In an ideal world, I think a docker should have a specific layout for: Top, 
side, bottom and free-floating (detached). And if a docker doesn't have a layout 
set for a certain position, it should not be possible to place it there.