KDE/kdebase/workspace/plasma/containments/panel
Aaron J. Seigo
aseigo at kde.org
Sun Mar 2 07:22:44 CET 2008
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
More information about the Panel-devel
mailing list