plasma+nepomuk activities, take N

Chani chanika at gmail.com
Tue Oct 13 20:41:20 CEST 2009


On October 13, 2009 10:17:26 Aaron J. Seigo wrote:
> On October 13, 2009, Ivan Čukić wrote:
> > Since there are bound to be some changes in the concepts behind
> > activities, virtual desktops etc. I'll postpone the plasma+nepomuk
> > integration in order to introduce it alongside the new overview (I guess
> > we'll be able to do it for 4.5?).
> 
> i'll be getting some of the basics into 4.4, like using the Add Widgets
>  style interface instead of zooming. and we need the nepomuk integration
>  first.
> 
> > >From my point of view (that is from the implementation's point of view
> > > :) ),
> >
> > there exists the possibility for more than one containment to have the
> > same activity (something Chani mentioned some time ago) - that is, to
> > have more than one group of applets (what we now call activities) inside
> > one activity.
> >
> > Panels could share the current global context and wouldn't have their own
> > activities.
> 
> a Context could be shared by multiple Containments, yes. however, i think
>  we should be very careful in how we define when that is possible.
> 
> personally, i think a Context should be the combination of:
> 
> * Panel Containments
> * the active desktop Containment on each physical screen

I've only got the one screen... and... I'm having this sudden desire to have 
virtual desktops be my answer to running out of applet-space in the activity.
it might not be a good thing, though. I also like how my applets follow me 
around no matter what desktop I'm on. and I don't want to have (# desktops)*(# 
activities) desktop-containments.

most of the time, one desktop-ful of applets is enough. come to think of it, 
the only ones that feel crowded are the one covered in notes that I really 
should clean up, and the one that serves a dual purpose as both kde-related 
stuff and a place to test random plasmoids.

hmm.
no, I don't really want per-v-desktop activities, once I can associate windows 
with activities. once in a while I *might* want to have two desktop-
containments that are part of the same context. the more shiny plasmoids i 
want, the more likely that is; the larger my screen, the less likely that is.

panels help, but... sometimes I don't want things on a panel, I want them big.

originally I thought the activity's UID would just be its user-defined name 
("plasma", "math", etc) and any containment with that name would be associated 
with that activity. makes association easy... doesn't it? you might want to 
forbid unnamed desktop-containments, though, so that you're never not on an 
activity.
I guess the only problem is deciding which desktopcontainment to switch to 
when switching activity.

I'm not sure whether it's a good idea. I don't want to jump into this and then 
find out it's ugly and annoying. starting simple is good.
but what's the user going to think when they can have two different activities 
with the same name? or will we have code to prevent that?

> 
> while it is completely possible to get more fancy/complicated, this will
> likely be easiest to explain to someone using the system: everything they
>  see at any given time is part of the context. when they change what they
>  see, the context changes.

so long as they haven't heard of virtual desktops ;)

> 
> this keeps the door wide open for panels being associated with activities
>  (so when you change activities, the panel arrangement changes) while
>  keeping everything else very simple.
> 
> it does imply that we need to keep the activity name for desktop
>  containments in a multi-screen scenario syncronized.
> 
> when zoom out is removed, this should be a bit easier.

iirc, the only thing we absolutely need zoomout for right now is the "add 
activity" action. everything else is accessible through the desktop, mouse 
plugins or keyboard shortcuts.
it shouldn't be too much work to make "add activity" work while zoomed in and 
begin dismantling the zoom code... :)


..oh crap, plasma is just too much fun; I meant to work on my AI assignment. 
no more email! :P

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20091013/17bc2219/attachment.sig 


More information about the Plasma-devel mailing list