KDE/kdebase/workspace/plasma/containments/panel

[Aaron J. Seigo]

On Saturday 01 March 2008, Chani wrote:
> what Containment does is translate each panel to somewhere up in negative
> co-ordinates; it should move them such that each screen has its own area in
> negative space (although I think here might be a minor bug in that code).

i don't really think it matters, tbh, as long as they are stacked so they 
don't run into each other. this can be done by giving them their own full 
screen area size (but then you have recalculate that whenever screen size 
changes.. ugh) or just stack them next to each other, horizontals and 
verticals.

the placement code does need to be fixed to take this into consideration, and 
i think there's even a fixme in the code there.

> what PanelView does is show the panelcontainment (regardless of where it
> is) and move the view itself to whatever edge of the screen it needs to
> appear at.

right.. which how it should remain. think of autohiding panels -> the view 
moves away, if the containment is in literal coords you can see it on the 
desktop now. =)

> with the code I committed, the panel just sits at 0,0 in the negative area.
> obviously this isn't going to work for multiple panels, but I decided to
> leave it that way until I fix it properly. (nobody's using multiple panels
> yet, right? if you are, then I'm sorry!)

yes, people are. we have the bug reports to prove it. =)

> since Containment uses translate() the panelcontainment thinks that it's
> drawing at 0,0 when it's really drawing somewhere out in negative space.

which is really the beauty of the translation. the panel can do internal 
calculations as if it were actually on screen.

> this would probably work pretty well, and be easy, and so long as panels
> don't overlap on the screen they wouldn't overlap on the canvas either.

the only remaining challenge will be auto-hide panels on the same side of the 
screen. those probably will be able to overlap. =/

my thoughts on how to solve this problem completely have been to stack 
horizontal applets in one space, verticals in another. for horizontal panels, 
only the x position would matter and we'd calculate the y position based on 
the screen edge. this would let us ignore panel overlap issues on canvas 
completely, have an easy way of keeping track of (and letting the user 
interact with) panel x position (or y pos for verticals) and keep the other 
calculations simple.

i think this makes the least amount of work since for horizontal panels all we 
really care about is the x() and width() (y() and height() for verticals) as 
the rest is dependant on their Plasma::Position which we already know. this 
prevents the whole "where do i put this panel?" question since the answer is: 
we stack them ;)

-- 
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 Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080301/923de476/attachment.pgp