Manual Hiding of Plasma Panel (desktop shell)

[Aaron J. Seigo]

On March 4, 2010, Andrew Hunt wrote:
> Hi all,
> 
> I'm currently working on adding manual panel hiding to the plasma dektop
> panel. ( https://bugs.kde.org/show_bug.cgi?id=158556 for more info.)
> 
> Progress has gone quite well, here are a few screens (cut and combined into
> one file):
> http://img697.imageshack.us/img697/5606/manualpanel2.png

it's getting there! :)

would you be able to upload a patch to reviewboard.kde.org so we can also try 
it and comment on it directly? (if you don't feel it's ready for that quite 
yet, that's cool; but when it is, please do so..)

my thinking on the positioning is this:

it probably shouldn't be in the containment itself. (though it's hard to know 
exactly where it currently is being placed without seeing the patch :) this is 
because the containment is completely free to do as it wants with items inside 
of it ... including removing, hiding or even deleting them!

the other problem i see there is fitts law: the buttons will not hit the edges 
of the screen and that can be annoying and certainly make them harder to use.

so what i suggest is this: don't put the item in the containment at all. 
instead, have PanelView make room for the button at the QWidget level; e.g. 
set a contentsMargin in the QGraphicsView and then manually place a ToolButton 
at the right position in the panel. this will allow us to slam the button 
right up to the edge of the screen.

to make it look good, we can perform a small trick: overlap the button with 
the left/right margin area of the containment. in the case where the panel 
hits the edge of screen, there is no overlap and the button and the 
containment will meet with a nice perfectly square join.

but in the case where the panel edge is floating, we may have a curved edge. 
what to do? easy! take the panel-background svg and paint the right/left 
border on top of the button with QPainter::CompositionMode_Source. this will 
create the illusion that the button is wrapped "around" the curvey edge of the 
panel and even with translucency it will look perfect (the button parts that 
"stick out" in the curved area will be visible, but the panel itself will be 
translucent). it might sound trickier than it is, but it's really straight-
forward, though a bit hard to explain. i can also provide an example 
implementation once you publish your patch.

but this approach ensures that there is not interefering with the panel 
containment itself. much simpler and won't end up with problems down the road.

> Also, I have built in an automatic system for determining where to
> place hiding buttons: If a panel is only connected to one side of the
> screen, then the hiding button will be displayed at that side, if it is
> connected to or neither, then I was thinking it should show two buttons,
> although Aaron Seigo suggested having only one (Do most people only use
> one side -- if so which? I use both, with more emphasis on the left...).
> Does anyone have further thoughts on this?

i think the only way to find out is to try it, test it and maybe even ship it 
and get feedback. as you are the one implementing it (and you seem to be 
really open to feedback, which is terrific), i'd say: make a decision, 
implement it, and let's see how it goes from there. worst case we change how 
it works later after we have some usage data :)

> Lastly, I have set up that when the panel height decreases below 25px, the
> buttons increase their width, giving a fat button, much like in Gnome. I
> have noticed that below a certain panel height, the applets bottom section
> gets pushed below the bottom edge of the screen (or top above the top of
> the screen when at the top etc.)

that would be a bug in individual applets, as they should freely resize all 
the way down to at least 16px.

> , however copying this for the hiding
> complicates button placement considerably (as well as making it look
> silly), so at the moment it just resizes with the panel. Would this be the
> best approach?

yes, the buttons should simply continue to scale down.

thanks for working on this.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks