Re: Tokamak IV breakout groups
On Friday, 5. February 2010. 21.02.37 Aaron J. Seigo wrote: > On February 5, 2010, Lukas Appelhans wrote: > > I think we should have a working group (only for a few hours maybe) about > > how we manage application menus... (especially interesting for Ivan, > > ruphy, Nuno et moi) > > sounds good; let's call it a half-day session? can you add it to the wiki > with you as facilitator? thanks :) +1 with a note that this is related to the activities :) -- You know, there are many people in the country today who, through no fault of their own, are sane. Some of them were born sane. Some of them became sane later in their lives... -- Monty Python's Flying Circus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma activities and Nepomuk
> > the big requirements we have in plasma is the ability to have a named > "context" that can be associated with locations, people, documents ... > > context+location will likely end up being a pretty important pairing to at > least some of our users since if i'm doing work related activities, what > that looks like when i'm in the office vs in an airport is pretty > different (e.g. vpn access, NDA'd documents, etc). > damnit aaron, stop being right! ;P ...okay, so what me and some others have been calling Activities for months was actually your Context from back in august. :) -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities
On February 5, 2010 09:44:14 Aaron J. Seigo wrote: > On February 4, 2010, Chani wrote: > > We seem to have two or three definitions of the word "activity" in > > kdebase now. Oops. > > we have precisely one definition. *you* have precisely one definition, in your head. not so in mine. :) and I guess I've spread the confusion a bit because of that. > > > We have activities "the group of widgets on your desktop" and activities > > "the windows/files/whatever for your current project". Can someone come > > up with a different name for one? I'd take Context but aaron's already > > defined that to mean activity+geolocation. > > Context is precisely what it's supposed to be. last time you were talking about context, you made it sound like it was all about the user's location, not what they were working on. perhaps I misinterpreted, though. so: the Context holds associations that define what the user's working on: files, windows, etc. plus one or more Activities. the set of Activities that is tied to that Context gives the user an anchor to build the Context around. does that sound right? > Context is specific to the person in that it is the person's current > internal state which defines which Context (if any) is applicable. it has > nothing to do with the computer. in fact, Context is a way to make the > computer reflect the person. you're suggesting we make the computer define > the Context through a visual representation, when really it's something > that should be global to the computer at any given moment. yes, because I get the impression people have trouble grasping abstract, global things that have no visual representation. I just want a way to get people using it easily, that's all. at one point I considered having rows of desktops and each row being a different Context, but that was full of problems too. having a spatial representation for *both* vd's and context certainly won't work (no, not even if we go 3d, diego :) > > > So while in theory it makes sense to be able to merge vdesktops with > > > > activities, > > it doesn't make any sense in theory. does too! :P > > > how can we make activities simple and non-threatening to the new user? > > by making them easy to define and switch between. the defining bit is > actually going to be the hardest. if we wish to tackle an interesting set > of unanswered problems, that's probably where to head. mm, the UI for this is going to be important to get right. (part of the reason I haven't tried doing it myself ;) > > > what do we do about a dual-monitor computer having two activities > > (desktopcontainments) for each activity (in nepomuk)? > > Context can be shared between Containments. > > what needs to be done in this case is to make it so that: > > * Context objects are able to be managed by the appliction (e.g. plasma- > desktop). right now they are a detail hidden in libplasma (which gives us > flexibility going forward since they aren't really exposed in any > meaningful way) I wasn't aware there was any code for this in libplasma; I thought all we had was ivan's nepomuk stuff in playground (that's going to kdereview soon, riiight? ;) > > * plasma-desktop ensures that one and only one Context object is active at > a time and is associated with all visible Containments > > * separate out the Activity Name setting from the containment type switcher > in the config UI; it does not make sense to have there as long as we have > PVDA and multi-screen support. while PVDA could be turfed, we'll never get > away from multi-screen support separate out, as in give the Context a name instead of giving the Activity a name? or something else? -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak IV breakout groups
Am Freitag 05 Februar 2010 21:02:37 schrieb Aaron J. Seigo: > On February 5, 2010, Lukas Appelhans wrote: > > I think we should have a working group (only for a few hours maybe) about > > how we manage application menus... (especially interesting for Ivan, > > ruphy, Nuno et moi) > > sounds good; let's call it a half-day session? can you add it to the wiki > with you as facilitator? thanks :) Done... I also just added the other guys to the Participants... hope that's ok for you :) Lukas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities
> > So while in theory it makes sense to be able to merge vdesktops with > > > > activities, in reality it'd end up feeling awkward and hacky. :( > > And not really possible. For example, one might want to have more virtual > desktops in one activity (when I say 'one' in this case I mean 'at least > me' and me, and aaron, and several people at my school... I want to keep that use- case too :) I'm just not sure it's suitable for everyone. > > The second problem in using vdesktops and accompanying kwin effects to > represent activities is that we'd have to have all activities 'in memory' > at the same time to be able to show them which is *wrong*. > > I'd rather have a list of activities with 'activate this one' than to have > the /live/ previews of them. And this would be a rather simple approach > for the implementation - when the activity is changed, the applications > that care about it would listen to the signal. > > - session manager would load apropriate applications > - kwin would activate the desired virtual desktops (if we want different > number of vds per activity) > - plasma would change the widgets > - menus would change the favourite apps > - dolphin would change /places/... > > Mind that I'm working with the presumption of having only one activity > dubbed 'current' at a time like discussed before (at T3). one activity will be "current", yes, but you can have more than one open at a time. you don't quit an application when you hit alt-tab, after all. :) there'll be the current activity, the other running activites, and the other closed actvities. I figure the UI will probably show the closed activities separately... although if someone wants to play with a widget that lists all of them together and does some sort of automagical opening & closing, feel free :) ...remember, though, that the session support will take time, and will never be 100% (think proprietary niche applications). so, closing an activity might be a potentially destructive action. -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak IV breakout groups
On February 5, 2010, Lukas Appelhans wrote: > I think we should have a working group (only for a few hours maybe) about > how we manage application menus... (especially interesting for Ivan, > ruphy, Nuno et moi) sounds good; let's call it a half-day session? can you add it to the wiki with you as facilitator? thanks :) -- 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak IV breakout groups
On February 5, 2010, Marco Martin wrote: > On Friday 05 February 2010, Aaron J. Seigo wrote: > > hi all ... > > > > we need to collect a listing of all the breakout groups for Tokamak IV. > > you > > > > can see a start to this on the Tokamak IV organization page here: > > http://techbase.kde.org/Projects/Plasma/Tokamak4#Breakout_Groups > > > > to add a new group, please propose it here in this thread and if we agree > > that it's on topic and that we will have the right people at Tokamak IV > > to cover the topic then we can add it. > > > > note that there are breakout groups already there fore Oxygen and KWin, > > but that they need some details added. > > > > each breakout group will have a facilitator assigned. this person will be > > responsible for organizing the schedule for the talks and helping us to > > get reports back from that group. the facilitator does not need to do > > all that work themselves, they just need to ensure it gets done. :) > > facilitators are free to wander between break out groups, of course, but > > it would be good if they were around their break-out group as much as > > possible or is needed. > > > > break-out groups may last for the entirety of Tokamak IV, or they may > > only last for a day or two. this is up to the people in the breakout > > group. please note. > > > > if you would like to participate, in whole or in part, a break out group, > > please add your name to the attendees list for that group(s). > > > > if you would like to give a presentation, add it to the list as well. > > > > i will try to work out some scheduling that will work for as many people > > as possible based on the input you provide on that page. > > > > thanks :) > > oh, god, i should really be in all of them, can we make tokamak 4 weeks? :p hehe. i know the feeling ;) > jokes aside, we have 4 groups, and we could easily end up with more. > the ideal thing would be to have "work sessions" that don't last all day > (half? a bit more?) so we'll have a schedule with two in the morning and > two in the afternoon, maybe with some hours of overlapping but letting > people to attend to more than one. this will really depend on who is attending, how long the breakout groups need/want for their topic, how many presentations, etc. which is why we need to get that information in there, so we can start dealing with exactly the logistics issues you note. > even if the kwin one will make sense probably to be a day ot two, since > martin will be here only for a short time and /all/ of the "core" people > (well, everybody that even remotely touched either libplasma or a shell) > should - really- attend. i don't know if we need everyone there for the window management break out, but it will need to revolve around Martin's schedule as you note. and as we just discussed on irc, it may make sense to suspend the mobile breakout for .5-1 day and hold the kwin breakout then. again, i really need to know who wants to attend which breakouts :) > also, depending from how many presentations there will be, they should be > sequential, so everybody listens to all, and then back to work :) good point; that's also part of the scheduling that needs to happen. we also have some other constraints such as with the mobile break out group presentations: the SDK presentations really must happen right at the start otherwise people won't have the tools they need to get working. -- 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak IV breakout groups
Hey! I think we should have a working group (only for a few hours maybe) about how we manage application menus... (especially interesting for Ivan, ruphy, Nuno et moi) We may want to integrate it with Nepomuk, get some thoughts about sharing as most code as possible and get some enlightenment on the concept of TOM... Lukas PS: Except that I'd maybe like to get into some brainstorm sessions of activities =) Am Freitag 05 Februar 2010 20:09:05 schrieb Aaron J. Seigo: > hi all ... > > we need to collect a listing of all the breakout groups for Tokamak IV. you > can see a start to this on the Tokamak IV organization page here: > > http://techbase.kde.org/Projects/Plasma/Tokamak4#Breakout_Groups > > to add a new group, please propose it here in this thread and if we agree > that it's on topic and that we will have the right people at Tokamak IV to > cover the topic then we can add it. > > note that there are breakout groups already there fore Oxygen and KWin, but > that they need some details added. > > each breakout group will have a facilitator assigned. this person will be > responsible for organizing the schedule for the talks and helping us to get > reports back from that group. the facilitator does not need to do all that > work themselves, they just need to ensure it gets done. :) facilitators are > free to wander between break out groups, of course, but it would be good if > they were around their break-out group as much as possible or is needed. > > break-out groups may last for the entirety of Tokamak IV, or they may only > last for a day or two. this is up to the people in the breakout group. > please note. > > if you would like to participate, in whole or in part, a break out group, > please add your name to the attendees list for that group(s). > > if you would like to give a presentation, add it to the list as well. > > i will try to work out some scheduling that will work for as many people as > possible based on the input you provide on that page. > > thanks :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tokamak IV breakout groups
On Friday 05 February 2010, Aaron J. Seigo wrote: > hi all ... > > we need to collect a listing of all the breakout groups for Tokamak IV. you > can see a start to this on the Tokamak IV organization page here: > > http://techbase.kde.org/Projects/Plasma/Tokamak4#Breakout_Groups > > to add a new group, please propose it here in this thread and if we agree > that it's on topic and that we will have the right people at Tokamak IV to > cover the topic then we can add it. > > note that there are breakout groups already there fore Oxygen and KWin, but > that they need some details added. > > each breakout group will have a facilitator assigned. this person will be > responsible for organizing the schedule for the talks and helping us to get > reports back from that group. the facilitator does not need to do all that > work themselves, they just need to ensure it gets done. :) facilitators are > free to wander between break out groups, of course, but it would be good if > they were around their break-out group as much as possible or is needed. > > break-out groups may last for the entirety of Tokamak IV, or they may only > last for a day or two. this is up to the people in the breakout group. > please note. > > if you would like to participate, in whole or in part, a break out group, > please add your name to the attendees list for that group(s). > > if you would like to give a presentation, add it to the list as well. > > i will try to work out some scheduling that will work for as many people as > possible based on the input you provide on that page. > > thanks :) oh, god, i should really be in all of them, can we make tokamak 4 weeks? :p jokes aside, we have 4 groups, the ideal thing would be to have "work sessions" that don't last all day (half? a bit more?) so we'll have a schedule with two in the morning and two in the afternoon, maybe with some hours of overlapping but letting people to attend to more than one. even if the kwin one will make sense probably to be a day ot two, since martin will be here only for a short time and /all/ of the "core" people (well, everybody that even remotely touched either libplasma or a shell) should - really- attend. also, depending from how many presentations there will be, they should be sequential, so everybody listens to all, and then back to work :) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Tokamak IV breakout groups
hi all ... we need to collect a listing of all the breakout groups for Tokamak IV. you can see a start to this on the Tokamak IV organization page here: http://techbase.kde.org/Projects/Plasma/Tokamak4#Breakout_Groups to add a new group, please propose it here in this thread and if we agree that it's on topic and that we will have the right people at Tokamak IV to cover the topic then we can add it. note that there are breakout groups already there fore Oxygen and KWin, but that they need some details added. each breakout group will have a facilitator assigned. this person will be responsible for organizing the schedule for the talks and helping us to get reports back from that group. the facilitator does not need to do all that work themselves, they just need to ensure it gets done. :) facilitators are free to wander between break out groups, of course, but it would be good if they were around their break-out group as much as possible or is needed. break-out groups may last for the entirety of Tokamak IV, or they may only last for a day or two. this is up to the people in the breakout group. please note. if you would like to participate, in whole or in part, a break out group, please add your name to the attendees list for that group(s). if you would like to give a presentation, add it to the list as well. i will try to work out some scheduling that will work for as many people as possible based on the input you provide on that page. thanks :) -- 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: TokamakIV update
On February 5, 2010, Sandro Andrade wrote: > Hi all, > > Has the arrangement for working groups in T4 already begun ? Or is this we need to start this. i'll begin a new thread for it. -- 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: TokamakIV update
Hi all, Has the arrangement for working groups in T4 already begun ? Or is this going to be defined in the beginning of sprint ? I'm trying the make a plan for my contribution during T4 ... See you, Sandro On Wed, Feb 3, 2010 at 11:06 PM, Lukas Appelhans wrote: > Am Mittwoch 03 Februar 2010 23:50:55 schrieb Ivan Čukić: > > On Wednesday, 3. February 2010. 23.22.20 Lukas Appelhans wrote: > > > Hey! > > > > > > Just to give an update from my side... I will arrive at 18:24 on Friday > > > and will depart at 17:33 on sunday... anyone got the same times (and > > > maybe the same train, it's some ICE)? > > > > You should fill that info to T4 page on techbase so that we all can > > organize in groups. > Done, thanks for hinting... > > Lukas > > > > Cheerio > > > > -- > > There are no such things as applied sciences, only applications of > science. > > -- Louis Pasteur > > ___ > > Plasma-devel mailing list > > Plasma-devel@kde.org > > https://mail.kde.org/mailman/listinfo/plasma-devel > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities
On February 4, 2010, Chani wrote: > We seem to have two or three definitions of the word "activity" in kdebase > now. Oops. we have precisely one definition. > First, there's the original: desktop containments. > Second, there's the nepomuk activities: they're UIDs that can have an > associated name, and then other arbitrary things can be associated with > them. these are the same thing. there is the idea of Context. Context includes the concept of an Activity which is primarily a temporal concept. a desktop view in plasma-desktop is intended to reflect the Activity that is current in Context. > Third, there's my "everything you need for what you're working on" > plan, which will pull in kwin and new session stuff and applications, and > *probably* will be tied to a set of containments (one containment, for > those of us with one screen). Hopefully this will merge with nepomuk's > activity stuff, so we can count only two definitions of "activity" in kde. no hopefully about it: obviously this would merge with the Context. there's no point in doing it otherwise. which means we have one meaning, one implementation and one place of storage. the only "multiple" here is that it gets reflected in multiple places and that we will end up needing a way to coordinate these multiple reflections. > The first thing that comes to mind is, can we rename one of these concepts? this is unnecessary due to the above. > We have activities "the group of widgets on your desktop" and activities > "the windows/files/whatever for your current project". Can someone come up > with a different name for one? I'd take Context but aaron's already > defined that to mean activity+geolocation. Context is precisely what it's supposed to be. > For the rest of this i'll just say "containment" instead of > plasma-activity, and when i say "activity" i mean the nepomuk/kwin/etc > thing. please don't confuse matters even further. there's a reason they are called Containment in the code, that Context is a separate class and that we only refer to Activity in the UI. > quick review for anyone who's forgotten: I want to be able to associate > windows with activities so that they're only shown on those activities > (yes, plural, not like virtual desktops where it's all or one). later I > want applications to adapt to the current activity (example: filedialog > showing special Places for that activity), I want to be able to > save/restore the whole activity - both containment(s) and windows - and > then someday I want to start automatically associating new windows with > activities based on stuff like nepomuk tags on the file that's being > opened. right, this has been the goal for the last ~3 years. > Anyways, to help people get it, I think it will be beneficial to tie the > activity to N containments, where N is the number of physical screens. this is a requirement, actually. and why Containments can share Contexts. > Having this activity-containment tie gives users an anchor. The activity > isn't a completely abstract concept then; it's got a more physical > representation. And if users are smart they'll give each activity its own > wallpaper; having a pretty picture makes it far easier to tell them apart > and remember where you are. right. > Now the part aaron's not going to like . ;) I think that the spatial layout > of virtual desktops, and the pretty composite effects showing that layout, > really help users grasp the concept better. I think that for most people, > it makes sense to start out with the same spatial stuff to help people not > feel lost. sure. > I'm not talking about something added on here - that'd be confusing, the > way the zui and desktopgrid are confusing. I'm talking about a merge. > Tying activities to virtual desktops, a strict 1:1 relationship. I'd at which point you may as well just stop considering tying applications into Context or anything else that isn't strictly spatial. my guess is that people will be rather confused as to why when they go to check their email everything else changes (due to the Activity/Context being changed) or why they can't check their email after the Context changes unless they add EMail to every Activity. Context is specific to the person in that it is the person's current internal state which defines which Context (if any) is applicable. it has nothing to do with the computer. in fact, Context is a way to make the computer reflect the person. you're suggesting we make the computer define the Context through a visual representation, when really it's something that should be global to the computer at any given moment. > effects. But how do we avoid it when apps like kmail start adapting their > content to the current activity? but not trying to tie it to the concept of virtual desktops. > So while in theory it makes sense to be able to merge vdesktops with > activities, it doesn't make any sense in theory. > in reality it'd end up feeling a
Re: [kde-promo] Javascript Jam Session
Hi Aaron, Yes, this is definitely exciting...contests are fun to promote :) I read through all the info below and don't really have much in the way of feedback as this looks very well thought out already. I did notice one typo, but that's about it: * Each contestant may submit one, and only one, Plasmoid for judging. Contestants may work in teams (an artist and a programmer is a common pairing in Plasmoid development, for instance) but only one prize per submission will be offered regardless of team size and constants may not be a member of more than one submitting team. constant -> contestant in that last line Otherwise, this looks kickass and I will be happy to help you all spread the word come Feb 9! - Justin On Thu, Feb 4, 2010 at 8:06 PM, Aaron J. Seigo wrote: > hi everyone ... > > i have some exciting news to share with you! > > below is a first draft of the text i'm working on for the announcement of a > javascript plasmoid competition. supporting artwork is underway and some > details (some prize specifics, judges, etc) are still being filled in. > feedback is welcome and wanted. > > obligatory statement of the obvious: i'm happy to do the planning for this > "in > public" here on the promo and plasma lists with all of you so that it can > be > as great as possible, please don't blog/tweet/dent/etc about this quite yet > > == > > Plasma Javascript Jam Session > > > KDE is pleased to announce the Plasma Javascript Jam Session. This > (friendly) > competition will reward the creators of the most original, interesting and > beautiful Plasma widgets written in Javascript with some great prizes and > community recognition. > > Anyone, except members of the judging panel, may participate in this open > challenge that starts immediately after the release of the KDE Software > Compilation v4.4.0. The rules are simple: > > * Only Plasmoids written using the Simplified Javascript Plasmoid API > (documented here: > http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API ) will > qualify. > > * All submissions must be released under a Free software license in > compliance > with the KDE Licensing Policy: > http://techbase.kde.org/Policies/Licensing_Policy > > * All submissions must be the original work of the contestants. Third party > Javascript libraries, DataEngines, etc. may be used, but the actual > Plasmoid > itself must be the work of the contestant. > > * Each contestant may submit one, and only one, Plasmoid for judging. > Contestants may work in teams (an artist and a programmer is a common > pairing > in Plasmoid development, for instance) but only one prize per submission > will > be offered regardless of team size and constants may not be a member of > more > than one submitting team. > > * Final submissions must be in the form of an installable .plasmoid file > submitted to by March 31st 2010. > > > Plasmoids will be judged based on the following criteria this: pie chart showing category break out>: > > * Usefulness / Entertainment Quality (40%): accounting for a full 40% of > the > final score, this metric reflects how indispensable, fun and "recommend it > to > my friends"-worthy the Plasmoid is. > > * Originality (20%): the more unique the Plasmoid, the better it will do in > this category. > > * Beauty (20%): for Plasmoids that inspire desire, these points go higher! > > * Technical (20%): code poetry and Plasmoids that expose the full power of > Plasma will rack up technical proficiency points. > > The prizes up for grabs are truly exciting: > > * Grand Prize: a brand new Nokia N900 (pre-loaded with your winning > Plasmoid?) and an invitation to Akademy or Camp KDE > > * 1st Runner Up Prize: and an invitation to Akademy or Camp KDE > > * 3 Honorable Mention Prizes: > > > In addition to these over-all prizes, three bragging-rights titles are up > for > grabs: > > * Beauty Queen: this crown is reserved for the most stunning Plasmoid in > form > and function > > * Technical Giant: the Plasmoid that embodies the peak of technical > excellence > will walk away with this badge of honor > > * Creative Genius: the Plasmoid with the most interesting and original > concept > will claim this title > > Additionally, everyone who submits a working Javascript Plasmoid that meets > the contest requirements will receive a personalized certificate of > participation by email. All submissions will be published for download on > kde- > look.org after the results are announced on April 9th. > > Contestants won't be left entirely on their own, however. Training sessions > will be held on Friday the 12th, Saturday the 13th and Sunday the 14th of > February at 16:00 UTC on irc.freenode.net in #plasma ( channel?>). > Each session, led by Plasma developers, will cover the Simplified > Javascript > Plasmoid API in detail along with Plasmoid development tips and tricks. > > In addition, contestants are welcome to ask questions and solicit > development > advice on #plasma on ir
Re: activities
On February 5, 2010, Diego Moya wrote: > The current problem with VDs and activities is, they are conflicting > spatial metaphors. They both are using the plane surface in two > different inconsistent ways. If I'm working with a set of windows and > go to the right (either with the "rotating cube" or "viewport > horizontal shift" effect), it will change windows as I enter in a new > virtual desktop. But if I zoom out and zoom in to the right of the > initial workspace, it will change activity instead - same windows but > different background. plasma-desktop's zooming is already gone in trunk. > See how it doesn't make sense? The zooming interface is not the one to > blame for confusion - several popular implementations (the iPhone, for > example) show that the general public is not confused by it. But the > same relative movement arriving to different places? That's a no-no. it's not just that. it's also the fact that zooming performance of QGraphicsView as we were using it is very poor on x11, meaning we weren't able to do nice transitions. we were also doing it without any cooperation with the window manager, which didn't help anything. add to this things like PVDA and syncronizing activities across all of them while zooming, etc, etc. anyways, moot point, because we won't be using zooming for the plasma-desktop desktop containments. > What I think should be done is moving the activities to the Z axis. > This is a proven metaphor - windows already behave this way (a window > is the 70's portrayal of an activity - a set of tools designed to work > together). Since activities have a strong linkage to the desktop, I > suggest a metaphor of activities as a pile of desktops along the 3rd > dimension, one of top of the other. i don't see how this would make anything clearer, tbh. -- 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities
On February 5, 2010, Marco Martin wrote: > what i see as the "real" one is the nepomuk one, the plasma ones i see more > as "placeholders" or "visual representations" of activities > (i would even tempted to ditch that at all and make widgets in the same > containment behave differently when the activity chnges but that would add > even more complexity if the current containment was not tied to activities) widgets are intended to behave differently depending on the active context, but it is assumed that we would keep the context and the containment consistent with each other. what you are suggesting is being able to change the context without changing the containment itself. this is only useful if the user wants the exact same set of widgets. it would also mean we'd have some abstract concept of activities (see the Concentrate video Ivan linked to for an example of that) and i just don't think that's very approachable. yes, we could make containment<->context paring exceptionally powerful and flexible. the question is whether that would end up being used by more or less of our users as a result. > soo, the containment would be the perfect thing to visualize an activity, > there is only the multimonitor and the pervirtualmonstruosity that breaks > this perfect paradigm :/ so indeed an activity must become a -set- > of containments. Context already does this; for PVDA one solution might be to link all the containments together. with the ZUI gone, this becomes less problematic, but it does mean that changing the desktop containment on one virtual desktop would change them on all virtual desktops unless we offered some "just change this one containment, but not the context" method. not sure that's worth it. > note that the pervirtualmonstruosity wouldn't be a problem anymore if we > take the route of an activity is a virtual desktop right. we'd just end up with a different set of warts. -- 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasmate alpha1 release
On February 5, 2010, Yuen Hoe Lim wrote: > Anyway, so if I read the conversation right, we have decided to a) release > alpha1 on the 10th as planned and b) "keep" themes for now? :) correct. > Just fixed this btw: > > I tried creating a new project "Hello" and changed it to "Hello1" in the > > > metadata. Now, when I again tried to create a project "Hello", it > > overwrites the older "Hello" awesome :) -- 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities
Short reply: Move activities to the third dimension - they should be a generalization of the plasma dashboard to N layers. Open windows should adapt to the current selected layer (dashboard = all windows autohide; other layers = show new background + show attached plasmoids + change Nepomuk-enabled parts in applications) Long reply: On 5 February 2010 01:54, Chani wrote: > One thing that is *very* important to me is that people must be able to > understand activities enough to use them. A lot of people really don't get > virtual desktops. I don't want to hold back those of us who do, but neither do > i want to make a complex beast that scares off all but the geeks. The current problem with VDs and activities is, they are conflicting spatial metaphors. They both are using the plane surface in two different inconsistent ways. If I'm working with a set of windows and go to the right (either with the "rotating cube" or "viewport horizontal shift" effect), it will change windows as I enter in a new virtual desktop. But if I zoom out and zoom in to the right of the initial workspace, it will change activity instead - same windows but different background. See how it doesn't make sense? The zooming interface is not the one to blame for confusion - several popular implementations (the iPhone, for example) show that the general public is not confused by it. But the same relative movement arriving to different places? That's a no-no. We should decide which service (VDs or activities) keeps the plane metaphor, and move the other competing service to use a different one. I first supported merging "virtual desktop" and "activity" in a 1:1 relation, but this can be too limiting - and I think I have now a better idea. On 5 February 2010 10:43, Marco Martin wrote: > there were so much ideas in the past, > - a desktop grid like, did with or without virtual desktops: problem of > windows not showing their real content and other virtual desktop limitations. > also been pointed out that this approach is inherently modal. is a problem? > maybe not since if i want to change what i'm doing is a modal action per se. > > - a strip that looks like the widget explorer, not modal and we don't have > virtual desktop problems. thumbnails becomes very little however and is an > advantage because one can not worry about wrong contents anymore, but a > disadvantage because they're so little that they could become almost > meaningless (they should just show the containment probably, and different > wallpaper for each contaiment shoud be almost enforced) None of these solve the conflict bewteen the two usages of the plane. How do you explain to the user where windows go when you switch virtual desktops? > > - or we could go barebone, just text, with an activitybar, a popup menu, a > secondary taskbar, whatever. it will probably be the first prototype anyways > and could be the "faster" to use in the end, but it will have a big problem of > learnability.. This *would* solve the problem, as it removes any physical metaphor for the activities. But it makes them abstract, again. What I think should be done is moving the activities to the Z axis. This is a proven metaphor - windows already behave this way (a window is the 70's portrayal of an activity - a set of tools designed to work together). Since activities have a strong linkage to the desktop, I suggest a metaphor of activities as a pile of desktops along the 3rd dimension, one of top of the other. How does this solve the conflict between desktops and activities? The VDs can keep the horizontal plane layout, being a big table with boxes in a grid - each box having a different group of windows. Camera panning = switching VDs. Activities then can be like the tablecloth on the table. We have several layered tablecloths, and we can change the extended tablecloth to support one activity or the other. The transition effect could be a movement in depth, like a tickler file or a Rolodex. This is compatible with whatever spatial effect used for the VD change (cube, infinite strip, big plane), as activities would be layers parallel to the VD plane. You could use the opposite change instead and put activities in the plane while virtual desktops are layers parallel to the activity desktop. I don't mind, except that the plane has been used as the standard metaphor for VDs for many years now. Now go and make the different code snippets match to the chosen metaphor. ;-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasmate alpha1 release
> the backtrace wasn't very specific, but i may have fixed it anyways. can > you > svn up libplasma and repeat to see if it works better now? > > Agh! I'm still persuading the latest pykde to build :( The crash is trivial to reproduce though, so if someone has the latest builds at hand maybe you could give it a quick try? * create a new python plasmoid in plasmate * change "self.setHasConfigurationInterface(False)" to "self.setHasConfigurationInterface(True)" in the init method. * refresh the plasmoid, right click the plasmoid > settings * crash happens. Btw, I've started some documenting of "what's possible" as well as a quick todo list here: http://techbase.kde.org/Projects/Plasma/PlasMate. Feel free to add-on, amend! Anyway, so if I read the conversation right, we have decided to a) release alpha1 on the 10th as planned and b) "keep" themes for now? :) Just fixed this btw: I tried creating a new project "Hello" and changed it to "Hello1" in the > metadata. Now, when I again tried to create a project "Hello", it overwrites > the older "Hello" > :) Jason "moofang" Lim Yuen Hoe http://yuenhoe.co.cc/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities
On Friday 05 February 2010, 06:43 Marco Martin wrote: > what i see as the "real" one is the nepomuk one, the plasma ones i see more > as "placeholders" or "visual representations" of activities +1 > in the end the more clear name it could have i think is just "widget set" +1 again hehe. though it's not a "beautiful" name :P -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Javascript Jam Session
On Thursday 04 February 2010, 22:06 Aaron J. Seigo wrote: > below is a first draft of the text i'm working on for the announcement of a > javascript plasmoid competition. supporting artwork is underway and some > details (some prize specifics, judges, etc) are still being filled in. > feedback is welcome and wanted. Great idea! I hope it makes the development of JS plasmoids more "popular" :) Cheers! -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities
On Friday 05 February 2010, Chani wrote: > hey guys :) this is a bit of a pre-emptive email... ramblurr was saying > he'd email some questions, and yagami was having ideas in #kwin, and > there's some possible confusion I'd like to address, so... well, here I > am. > > We seem to have two or three definitions of the word "activity" in kdebase > now. Oops. > First, there's the original: desktop containments. > Second, there's the nepomuk activities: they're UIDs that can have an > associated name, and then other arbitrary things can be associated with > them. Third, there's my "everything you need for what you're working on" > plan, which will pull in kwin and new session stuff and applications, and > *probably* will be tied to a set of containments (one containment, for > those of us with one screen). Hopefully this will merge with nepomuk's > activity stuff, so we can count only two definitions of "activity" in kde. what i see as the "real" one is the nepomuk one, the plasma ones i see more as "placeholders" or "visual representations" of activities (i would even tempted to ditch that at all and make widgets in the same containment behave differently when the activity chnges but that would add even more complexity if the current containment was not tied to activities) soo, the containment would be the perfect thing to visualize an activity, there is only the multimonitor and the pervirtualmonstruosity that breaks this perfect paradigm :/ so indeed an activity must become a -set- of containments. note that the pervirtualmonstruosity wouldn't be a problem anymore if we take the route of an activity is a virtual desktop > And so, confusion abounds! Oh joy :/ > The first thing that comes to mind is, can we rename one of these concepts? > We have activities "the group of widgets on your desktop" and activities > "the windows/files/whatever for your current project". Can someone come up > with a different name for one? I'd take Context but aaron's already > defined that to mean activity+geolocation. in the end the more clear name it could have i think is just "widget set" > [...] > > Here's where I run up against cruel reality, though. Virtual desktops have > a lot of limitations most people don't notice. Some of them can be fixed, > some miight be fixable or could be worked around, and some are just evil. > > I think it's *possible* to fake removing a virtual desktop that isn't the > last one. I worry about small things like applications assuming they're on > exactly one desktop. I don't think it's possible to beat the composite > monster, though. what about showing the window greyed out with a loading spinner on it? (and if the app has been in that activity before, maybe show an old screenshot of it instead of the actual app?) also, in a grid effect most of the times probably the window will be so small to not b able to distinguish what's inside anyways... those things just mask the problem but i think is the only thing we can do... > [...] > so, yeah, two open issues I'd like feedback on: > how can we make activities simple and non-threatening to the new user? > what do we do about a dual-monitor computer having two activities > (desktopcontainments) for each activity (in nepomuk)? - it should be something really prominent, that doesn't get forgotten - it should be really flashy (heck, the desktop cube made my sister grasp the virtual desktop concept, and she is really the type "I'm forced to use computers but i don't want to learn because they are a tool of satan and they should burn in hell") - so someting with less text possible and more images and drag and drop as possible (even activity, context, whatever is too jargon, really) there were so much ideas in the past, - a desktop grid like, did with or without virtual desktops: problem of windows not showing their real content and other virtual desktop limitations. also been pointed out that this approach is inherently modal. is a problem? maybe not since if i want to change what i'm doing is a modal action per se. - a strip that looks like the widget explorer, not modal and we don't have virtual desktop problems. thumbnails becomes very little however and is an advantage because one can not worry about wrong contents anymore, but a disadvantage because they're so little that they could become almost meaningless (they should just show the containment probably, and different wallpaper for each contaiment shoud be almost enforced) - or we could go barebone, just text, with an activitybar, a popup menu, a secondary taskbar, whatever. it will probably be the first prototype anyways and could be the "faster" to use in the end, but it will have a big problem of learnability.. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities
> We seem to have two or three definitions of the word "activity" in kdebase > now. Oops. > First, there's the original: desktop containments. > Second, there's the nepomuk activities: they're UIDs that can have an > associated name, and then other arbitrary things can be associated with > them. Third, there's my "everything you need for what you're working on" The Nepomuk activities - as in UIDs/nepomuk-resources-provided-by-the- activities-service - are the base for the "everything you need for what you're working on", so those two terms are not really colliding - they do represent the same thing. (the activities service is developed for use in kwin/plasma/apps/...) Plasma Containments, on the other hand, don't. /Fortunately/, the term Activity is a user-space term, so we don't have it in the code and it is replaceable. > So while in theory it makes sense to be able to merge vdesktops with > activities, in reality it'd end up feeling awkward and hacky. :( And not really possible. For example, one might want to have more virtual desktops in one activity (when I say 'one' in this case I mean 'at least me' :) ). The second problem in using vdesktops and accompanying kwin effects to represent activities is that we'd have to have all activities 'in memory' at the same time to be able to show them which is *wrong*. I'd rather have a list of activities with 'activate this one' than to have the /live/ previews of them. And this would be a rather simple approach for the implementation - when the activity is changed, the applications that care about it would listen to the signal. - session manager would load apropriate applications - kwin would activate the desired virtual desktops (if we want different number of vds per activity) - plasma would change the widgets - menus would change the favourite apps - dolphin would change /places/... Mind that I'm working with the presumption of having only one activity dubbed 'current' at a time like discussed before (at T3). > so, yeah, two open issues I'd like feedback on: > how can we make activities simple and non-threatening to the new user? > what do we do about a dual-monitor computer having two activities > (desktopcontainments) for each activity (in nepomuk)? Code-wise, it is possible for multiple containments to share the same Context, as panels will share the global-currently-active-activity-context. I've received a link to an application called Concentrate, that aims to do for Mac what we are doing here. I'm not really satisfied by its ui and configuration dialogue, but it is worth taking a look at it: http://www.youtube.com/watch?v=q-ojXcMJTIk&feature=related -- There are no such things as applied sciences, only applications of science. -- Louis Pasteur ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
