KDE/kdebase/workspace/plasma/containments/panel

[Chani]

> +        //FIXME I think these tests may always return true
> +        //but it won't really be tested until we have non-fullwidth panels
> +        //FIXME! yes, it *is* broken. just not visibly so, yet.
> +        if (geometry().x() <= r.x()) {
> +            bFlags ^= SvgPanel::DrawLeftBorder;
> +            leftWidth = 0;
> +        }
> +        if (geometry().right() >= r.right()) {
> +            bFlags ^= SvgPanel::DrawRightBorder;
> +            rightWidth = 0;
> +        }

so I committed even though this part is really kinda fucked up.
once we start having multiple panels, floating panels, or non-full-width 
panels several things in the code are going to need fixing. mostly it 
revolves around one question: how do we position panel-containments on the 
canvas?
the view and containment classes meddle with things enough already, so I 
stopped the panelcontainment from also trying to manage its position, but 
that's only good enough for the current ui.

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).

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.

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!)

so how should the geometry be managed?

since Containment uses translate() the panelcontainment thinks that it's 
drawing at 0,0 when it's really drawing somewhere out in negative space. 
I could have the panelcontainment pretend that this area is the screen and 
place itself where it would appear - similar to the old behaviour, except I'd 
update the border calculation code to actually work... the x,y of the 
screenrect is what's throwing us off, because the panel isn't positioned 
relative to that, so I'd just base my comparisons off the width and height, 
and use 0,0 instead of the screen's x,y.
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.

another option would be to have the translatey code in Containment take over 
placement of panels entirely, putting each panel off somewhere in its own 
space, and then have the panelcontainment just keep itself at 0,0. we 
wouldn't have to reposition the panel when its location changes, but we would 
have a harder time knowing where it really is in order to choose which 
borders to draw (or in order to save the positioning for floating panels in 
the future, I think).

the second option seems kinda cool to me, but the first may be more practical. 
opinions?

-- 
This message brought to you by evyl bananas, and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080302/1dbd1162/attachment.pgp