Manual Hiding of Plasma Panel (desktop shell)

[Andrzej JR Hunt]

On Friday 05 March 2010 09:44:33 Emdek wrote:

>     there is a ToolButton class which is a subclass of QToolButton but
> which provides plasma stylings. i wonder if that might look nicer here?
> just #include "toolbutton.h" and then do new ToolButton. 
I've done that. Thanks for pointing it out. I was looking at the wrong 
toolbutton. Because the buttons have a different shape they don't quite fit 
in with the curved end of the panel, but that can still be worked out; 
otherwise I think they do look better.

>     also, is it necessary to have a separate unhidebutton rather than just
> use the hide buttons themselves to both hide and unhide? 
The reasoning behind having them separate is that the hide buttons are part of 
the panel view, the unhide button is a separate item that appears on the 
desktop, similarly to the glowbar that has also been written as a separate 
object. I.e. I don't have to remove the hide button from the panelview and 
place it onto the main desktop, and vice versa if the buttons are separate. 
An alternative would be to simply move the panel sufficiently off screen so 
that only the hiding button is still on screen,  but I'm not sure whether 
that's pos sible, and what workarounds that would need for multiple screens.

>     the hide button names are a but unfortunate as well; perhaps
> m_hideLeftTopButton and m_hideRightBottomButton? a bit more self
> documenting.
I'll do the names. I just wasn't sure which version would be better.

>     instead of setting the margins on the containment, set the contents
> margins on the PanelView itself. then position the button inside of the
> PanelView itself. this is guaranteed not to break, regardless of what the
> containment tries to do. 
>     i'd also position the buttons so they overlap the border of the svg.
> e.g. for the right-hand button in a horizontal panel, something like: 
>     qreal left, top, right, bottom;
>     containment()->getContentsMargins(&left, &top, &right, &bottom)
>     setContentsMargins(0, 0, m_hideButton.width() - int(right), 0);
>     m_hideButton->move(0, geometry().right() - m_hideButton.width());
>    
>     (obviously would need to be generalized for vertical panels and
> top/left/right/bottom buttons)
I'll try that once I have time to do some more real work on it.

> apart that ToolButton should be used instead, don't really like a fuction
> that does enabling -and- repositioning in one. positioning should be done
> by a layout, really

If you're talking about the unhide button: the repositioning can't be done 
earlier though since we don't know where the panel is going to be hidden to. 
With the hiding buttons: I'll try get a layout ready for the hiding buttons 
(i.e. in the panel view) though, I hadn't really thought of that before.

> Must it look so similar to old look from KDE3? ;-)
> In comments to that bug I've written how it could work:
> https://bugs.kde.org/show_bug.cgi?id=158556#c33
>
> Maybe at least these buttons could be shown when moving cursor to edge?
> Both, for hiding and at least showing panel (to not obscure windows).

Actually, I was myself thinking of making the unhiding button behave somewhat 
the way you described, or possibly just slightly transparent as to provide 
some visibility below it. However this could cause some usability issues: 
when you can see the unhide button (as in kde3), you just have to move the 
mouse over to that panel corner, click, and you're done: one fluid motion 
that takes me half a second. With an autohiding unhide button some more 
thinking is required (Where did I put that panel again?), making it's use 
inefficient --  i.e. I think the unhide button always has to be, at least 
partly, visible.  Having "touch" sensitive unhiding would be interesting to 
try out, I might do some experiments with it, but I think that should be a 
later option, since it is rather complicated (at least for me).

I'm not sure about the hiding of the button lengthwise though, since then the 
unhiding button/area has to cover the whole width, takes up more space, or if 
it's completely invisible until you're close by then you're getting the same 
problems as with autohiding, where buttons/panels appear/get in your way when 
you don't need them, and are hard to use when you do need them. I might 
experiment with that once I've got spare time, but at the moment I'm just 
trying to get working manual panel hiding that looks nice and works like it 
has before, without expending too much effort on it.

> But if the 'hide' buttons can be implemented so that they don't interfere
> with the current hot spots, I'm in to have them enabled by default. I liked
> the idea someone proposed to create those buttons as plasmoids so that each
> user can decide where to place them (either inside the panel or on the
> desktop). I'm concerned about the buttons taking the screen or panel edges,
> and/or displacing or overlapping the panel contents. If this is the
> behavior of this feature, I'd certainly ask to have an option to disable it
> completely.
Don't worry: the feature is completely optional: it is simply an additional 
panel visiblity mode, i.e. instead of selecting "Always Visible", "Windows 
Can Cover" and the like, you select "manually hideable", i.e. the feature 
only appears if the user specifically selects it, and the default panel 
visiblity modes, and their behaviousr, are still the same as ever.

-- 
Andrzej JR Hunt -- andrzej (at) ahunt.org