multiple plasma-desktops

[Chani]

> > ok, cool.
> > right now the view actually sets its screen to be the containment's
> > screen, which seems a little odd.
>
> i've actually fixed that in the patch i posted for review today. it now
> just returns the current containment's screen. one less thing to
> synchronize

yay :)

> > > > we have a concept of 'active containment':
> > >
> > > and likely always will.
> >
> > good. you disagreed with this a while ago, which was confusing me, but I
> > think you'd just misinterpreted what I'd said.
>
> perhaps. iirc, you were asking if there was an "active containment" in on
> Corona (or at least that's what i thought you were asking?) and the answer
> to that is "no". a _view_ has an active containment, but there is no
> meaning to the question of "which is the active containment in plasma?"

it's not what I meant, but I didn't explain very well the first time and 
didn't get a chance to explain again.

>
> > > > their signals
> > > > need to be connected somewhere. if we connect them to our view, we
> > > > also need to modify the signals to say which containment they're
> > > > coming from (at
> > >
> > > not necessarily it could well be possible for all non-claimed (e.g. all
> > > screen() == -1) containments to handle their own zoomed status and
> > > switch their screen() to the screen of the view the click came from.
> >
> > I didn't think of doing it this way.
> > that would mean putting code into Containment that understands zoom
> > stuff, I guess...
>
> already available in the paintInterface method really.

ok... I'll have to spend some time wrapping my head around this stuff.

> > 
> > > > there are some minor glitches with
> > > > accidental view-moving and dragging things between containments, and
> > > > figuring out a decent ui will take more thought, but it looks like
> > > > things won't be too hard. for now I'll just stick an add button on
> > > > some blank part of the canvas.
> > >
> > > perhaps this even belongs in the toolbox.
> >
> > originally I wanted that. but, well, when you're zoomed out there's more
> > than one toolbox... and why not make use of that blank canvas space? :)
>
> yes; i think we can actually do both tbh. maybe if we go the GridLayout
> route, then we can have an "empty" entry (at the end?) that is a button
> that says "Create a new activity"?

sounds good to me :)
someday I'll want a button that lets me add a non-default containment too, but 
I'll try to just focus on basic things for now

>
> > > > regardless of whether we get it to stay in the corner someday
> > > > (you've kinda scared everyone away from trying to work on that
> > > > anyways).
> > >
> > > erm. how exactly? it's not the easiest thing to do, but i haven't
> > > discouraged anyone from working on this. in fact, i've helped people
> > > with questions who have tried working on this in the past. =/
> >
> > me and gamma were talking to you about toolbox plans and you suddenly
> > started contradicting things you'd said before, telling us not to do
> > things the way we thought we were supposed to. when we asked you to
> > explain, you said it'd be easier if you just wrote the code yourself. :(
>
> the latter is because the former was what i'd repeated several times: the
> toolbox shouldn't shrink, but then you need to move it. so you have to pay
> attention to the transformation matrix, but you have to set transforms off
> which means you have to do all the positioning manually. after saying it a
> few times over i became exasperated. i'm really not good at repetition. ;)

and I'm really not good at handling seemingly contradictory statements :)

for the record: it turns out that when aaron said "move" he meant "move to the 
corner of the containment" but we were hearing "move to the corner of the 
view".

>
> > > > should I be able to zoom into a containment that comes from a
> > > > different screen?
> > >
> > > i think no, only non-associated containments.
> >
> > ok. we still need to be able to have two views on different desktops show
> > the same containment, btw.
>
> that's fine. because the associated-ness is by screen(). desktop() should
> not be used to decide if a Containment is associated, but rather with which
> View(s) it is associated.

great.

>
> > I have a feeling people with multiple screens might get confused when
> > they zoom out and see containments they can't zoom into, but that can be
> > dealt with later if it turns out to be a problem.
>
> i thought about that. what i think we will do is paint over these
> containments with a translucent grey (which will only change the
> background; neat!) or some such to show that they are manipulatable but not
> selectable and perhaps even change the toolbox options available.

ooh, sounds nice :)

-- 
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/20080222/68c258cd/attachment.pgp