Imagine if you will ... (ah, such a classic start! =) You are working on a work project involving Sarah and John and Marmaduke; you switch to working on your MySpace profile ... Let's call each state (the work project, MySpace fiddling) a "context" and changing between them a "context switch". What happens with the rest of the software running on your computer when you switch contexts? Answer: pretty much nothing. At least not automatically.
Compare with network connectivity. When you lose network connectivity, KMail stops fetching your mail, Kopete closes it's connections .. and when the network connectivity comes back, it all fires up again automatically. This is great because now the software is reacting to the environment it "lives" in.
Virtual desktops help somewhat as people can use them to aggregate related windows into contexts. But let's face it, there's only one Kopete window. Wouldn't it be great if you could tag Sarah, John and Marmaduke in your Jabber buddy's list with the "Workmates" tag? That way, when you switch back to the work project after you're done MySpacing, Kopete could re-arrange your buddy list to put those workmates at the top of your buddy list. The contacts widget in your panel or on your desktop could also switch the people they are showing.
To make software react to the user context in the environment they live in, we need a way to publish the user context and for the user to communicate "I am now doing $FOO" and "I am physically located in $BAR". This is similar to how Solid broadcasts changes in network status to KDE applications, but for user context.
In Plasma we have the idea of Activities. In 4.2 you can give your Activities names and Plasmoids can ask what the current Context is and do whatever they might want to do given that Context. Plasmoids are also notified via a Constraints update when the context changes.
For this to really fly, though, this contextual information needs to be accessible by software outside of Plasma itself. Nepomuk will be filling this role, and today a few of us huddled together on IRC for a quick meeting to wrap up a week's worth of discussion on the Nepomuk KDE mailing list about user context. Trüg, Hari and myself managed to align our schedules with one goal to achieve: come up with the initial ontology (fancy way of saying "organization definition", more or less) for context.
Over the next couple of days we'll be coding the start of a Nepomuk service for publishing and collecting information on the current context and I'll be hooking Plasma into it. This will allow other applications to see the various known Contexts and either automagically tag data with appropriate Contexts and/or let the user manually tag data. Going back to the Kopete and contacts widget example, once we can associated (or "tag") contacts in Akonadi with Contexts then Kopete and the contacts Plasmoid will be able to adapt in concert with Plasma.
We aren't going for auto-context switching yet, though we will be automating location changes and eventually hopefully be putting in some intelligence for detecting the user's current activity.
Fortunately for us, there's a lot of really good science that's already been done in this field for us to reflect upon and base our efforts on. We're also starting simple, though we intend to build as far as it makes sense to, as defined by real world user benefit. Which is to say that our odds of success are extremely high.
Once 4.2 is out, I'll be poking and prodding application developers to start making their applications context aware. (Application developers: you've been warned! ;) This won't make applications dependent on either Plasma or Nepomuk, they'll just work better when they are around. All that will be required is D-Bus, which is already a requirement for KDE 4 applications. But if Nepomuk is around then applications will be able to rifle through and get information on Contexts. Likewise, if Plasma is around then the user will be able to interact rather directly with the Context using their desktop shell.
As we develop the application API further, I'll blog more about it. Plasmoid developers can start having fun right now, though! =)
Subscribe to:
Post Comments (Atom)
22 comments:
If this is implemented correctly, the KDE4 desktop will simply become the absolute best desktop on earth. Software that is aware of what the user is doing, and adapting for it would be software to beat all competitors.
I only worry about people not using it, or thinking that it's a bug. When Joe adds a new contact, he may not know to associate it with his Plasma Context, and all this work goes down the drain. If it associates automatically (assuming it doesn't make a mistake), Joe will just wonder why his contacts keep moving around, possibly thinking it's a bug.
You know what Seigo? Since the first moment I heard about Nepomuk, I knew it was THE pillar that would set KDE apart from the other Desktop Environments.
And I really mean something that would show in the future's computing books as "from here on, the next generation of the desktops started".
If ever you find yourself asking "What can I do with this data", just ask Nepomuk for the actions associated with this data's mime-or-something type, and then ask for the services/applications available to deal with this object-action pair.
Nepomuk is the super-glue for everything.
Wonderful! (I am the PowerDevil Developer)
I think I'll integrate this in powerdevil since that reminded me about one thing... For example, sometimes I leave the PC on just for downloading stuff, and I set a powersaving profile for it.
Now imagine if I have a context-based profile manager: by now profiles kick in when a battery event or an adaptor event happens, but what about letting people define $context -> $profile matches? I think this would be great and would improve usability a lot, what do you think? :)
In addition to agreeing with notriddle about the "KDE4 with contexts is going to be the absolute best desktop on earth" thing, I think the killer application of this functionality is filtering mail folders in KMail and feeds in Akregator.
That way, I'd actually be able to get my mails/feeds and *not* see all the neat stuff that is going on in kde-commits & Co., so that I can rather focus on the Real Work that needs to be done.
For notriddle worrying about the difficulties of association, I think it's absolutely necessary to have items associated with all contexts by default. That solves the situation for users who don't (want to) know about this thing.
Very cool.
What I would like to see are project/context sensitive/centered virtual desktops.
So that I can have a desktop for each project I am working on and I can attach a context to that desktop.
That would make single tasking so much easier.
Great progress! Thanks!
So is the Nepomuk coming on 4.2 or is it going to come 4.3 or 4.4?
I mean a) the file search possibilities b) search boxes on open/save/dolphin/x-y-z?
The desktop what is aware what user is doing, is going to be great.
KDE4 brought us great great (great!) technologies, but for me it seems that problem is that all developers are tweaking those (still KDE4 is young, just a 4.1.1) technologies but feel that applications does not have time to follow.
I hope that KDE4 developers would write some documents/list (easy to understand by normal users too!) of what you can gain with these technologies if you implent support for them in your application.
What I am trying to say is that I see someway the current KDE "world" too slow to adapt these technologies. It is always slower to adapt new ideas if users does not know them and does not know that they can wish them by using BKO. I think that we need to bring littlebit more "human related" stuff for these technologies so normal users can talk about them, get ideas and deliver them to developers and other users.
Reason for this is we are talking so extremely great technologies what users have not seen on other desktops, only a "tip of the iceberg" like desktop search and virtualfolders.
So now we have the "hammer" and "nails". We need to present them to users so they can give us more ideas how and where to use these tools and what kind cool stuff we could get done with them. (And I dont mean now nailing your foots to floor so you cant do nothing more than sit on your computer and write us more cool technologies!)
I agree with notriddle. This is awesome stuff, but one has to be careful with "intelligent" behaviour. How many people have you heard hurling abuse at Microsoft Word for it's myriad of autocorrect features that they don't know hoe to turn off (or turn to real use)?
Software design is just getting to the stage, led by data-wealthy web design I think, where this sort of thing can be helpful, but it has to be very well designed.
Clarity, discoverability... you know all this stuff waaaaaay more than I ever will of course.
And solid flexible design of course, which I know is also a passion of yours. This is a new paradigm, there are going to be lessons learned and we will want to tweak the behaviour, but we want the code to last.
To the Kopete tags: Wouldnt it be enough if you just use groups that you can create with Kopete? Sure every user would have to create a group and assign people to it but imho its nothing else than tagging everyone
I'm usually not a guy who submits everything to digg but that's so cool I had to:
http://digg.com/linux_unix/Plasma_Context_and_Nepomuk_in_KDE_4
So if you want to let the world know about it, digg it. :-)
Thats exactly what I had envisioned in my mind when I came to Academy 2006. Originally I had planned to propose something like that to Aaron, but we did not have the time to talk about it.
When Trueg talked about the possiblities of Nepomuk this year it became clear that Nepomuk would be the right way to go, and I talked with Trueg about my ideas. Seems to be that you two are now just implementing it in a way that I envisioned already in 2006, but had not the required time/standing to populate back then. - Great to see that something like this finally comes to KDE4!
I do think that Nepomuk has the potential of being really, really great. But there's still a part of me that is somewhat afraid that if we combine all of this together, we will end up with a paperclip-shaped plasmoid that tells me "Hey, it seems that you are writing an email to XXX....".
For love of $DEITY Aaron, make sure that doesn't happen!
@notriddle: agreed; i'm very intent on keeping it simple, straightforward, communicative and based in real world challenges (versus the academic stuff i see too often in this area). hopefully we'll succeed =)
@zeroum: we can, of course, do a lot more than that example with Nepomuk. i mean, we already do that without Nepomuk =)
as for Nepomuk being THE pillar, it's really hard to single out any of them like that because it is really through their interaction with each other that things get interesting. on its own Nepomuk is pretty dry and academic; add in Akonadi and it gets interesting; mix in geographical awareness (i foresee something that uses parts of Solid + some optional gizmos like GPS data) and it gets more interesting; tie it into the desktop shell and ... you get the picture.
on their own any of these pillars are interesting but not anywhere near what they are together. sum is greater type of things. or, put another way, try propping up a house on just one stick; it's easier if you have a whole bunch of them spread out evenly.
when people ask if there is design that goes into kde 4 i look at the pillars and wonder what part of it they are missing =)
@drfav: i think that could be quite interesting, actually ... i'm not sure exactly what sort of contextul information or states would work best as triggers, but if we experiment with it, we'll be sure to find out.
@jakob: "I think the killer application of this functionality is filtering mail folders in KMail and feeds in Akregator."
it's definitely going to be one of the great applications, yes, but i think we can come up with many other interesting applications as well. for the mail/news centric user, though, you're probably right.
"I think it's absolutely necessary to have items associated with all contexts by default."
actually, that would make the entire system useless. the idea is to create meaningful connections only and allow interfaces to adapt to context on user request.
the contacts plasmoid, for instance, should probably have three modes of behaviour: a "show everything" mode, a "context aware" mode and a "show only what i explictly define (e.g. by d'n'd)" mode. these can generally be chosen based on the user's actions correctly much or even most of the time.
@kragil: that will be achieved by turning on per-virtual-desktop-containments, something that should get done for 4.2
@Mikko: Nepomuk is already in KDE 4.0 and 4.1, it's really just a matter of more KDE applications using it.
"I hope that KDE4 developers would write some documents/list (easy to understand by normal users too!) "
why should developers write this stuff? most of us developers write so horribly that you really wouldn't want us to in the first place, but even more importantly documentation is something that non-developers can contribute leaving developers to continue doing their specialty: writing code.
"We need to present them to users so they can give us more ideas how and where to use these tools and what kind cool stuff we could get done with them."
this i completely agree with.
"And I dont mean now nailing your foots to floor so you cant do nothing more than sit on your computer and write us more cool technologies!"
hehehe ...
@PepperJohnny: you could certainly tag entire groups with a context, or even tag other tags with a context. there's no limit to the generality (or specificity) of what can get tagged/associated.
the examples in the blog entry were simply examples. =)
Janne: of course not. it'll be shaped like a cashew. duh! ;)
Hi! I just wanted to say that I have been using kde4.1 (from kubuntu hardy) + compiz for a few days and I really like the work you've managed to do on it. I think it needs to be worked on a few details, but overall it ROCKS! I think the post from SJVN asking for kde to be forked no longer holds water.
Great job! Keep it up!
This has some resemblance to what reiser4/winfs/apple newton tried to do...instead of having different apps reading handling their own data and trying to imitate some sort of integration via some process-communication mechanism (OLE, dbus, etc), which works but makes your concept of "context sharing between apps" somewhat hard, they tried to implement a "central" piece of software which handles all the data - contacts, emails, etc. So, theorically, an IM would just request to this central piece of software: "Give me a list of all contacts". The email program would also request that list, and would ask for notifications of new contacts added. Then, the IM program would add a contact for some reason, and instead of storing it in a file which only him uses, and whose format only he understands, he would store it in the central piece of software: "Add this contact to the list of contacts". And any other application which requested notification of new contacts, like the email program, would get notified.
@Edmundo: "and I really like the work you've managed to do on it."
thanks
"I think it needs to be worked on a few details,"
yep, still work to be done; 4.2 is going to be as much an improvement over 4.1 as 4.1 was for 4.0 i think.
"but overall it ROCKS!"
=)
"I think the post from SJVN asking for kde to be forked no longer holds water."
it never did hold water. it was a crank post written without understanding of what was being written about. given the quality of SJVN's other pieces, it was surprising, and i had hoped he'd own up to it. *shrug*
@Diego Calleja: "they tried to implement a "central" piece of software which handles all the data"
this is where our approach and the reiser/winfs/newton/etc approaches diverge.
we don't actually have one central location for information; what we have are things like Akonadi which are central points of coordination for specific types of data. an email app could still keep the email in a local store and publish it or even just augment it via Akonadi, though Akonadi does work better when operating on a 100% shared cache. point is that Akonadi is really just a cache and it is specific to groupware.
there are other such data pools, if you will, (Solid, Decibel, Plasma, the traditional file system, images mnaged or viewed in digikam/showphoto/gwenview..).
Nepomuk connects all these pieces together; again, it doesn't actually store any of the actual data itself, just the connections. it then allows applications to ask how things relate.
the critical feature is, as you can see, that it is all decentralized. unlike the all-in-the-file-system-approach as seen in reiser or winfs, it isn't required that everyone works with the same interfaces or store everything in the same place and the same way.
the end result can be quite similar (assuming one added an rdf-style layer on top of reiser or winfs; nepomuk is more than just an indexer, that's strigi's job =) but the means to get there is different ... and that is critical.
i don't think we'll ever realistically see a real-world-useful winfs or reiserfs approach because it is too centralized and requires all the app devs to get "on the same page". it also means that those features of your apps aren't portable outside of that filesystem! nepomuk travels nicely wherever the app might.
with Akonadi, as an example, all data that gets passed through it ends up Nepomuked (well, assuming the user doesn't disable that feature =) ... and anything that speaks imap can use Akonadi as a basic mailer without additional code.
this makes it much more approachable for app develoepers. and since such a relationship and metadata store is really only as valuable as the amount of data it gets to work with and the number of applications that expose the results in their own interface, i think the KDE 4 approach has a real chance of succeeding where others have fallen flat.
Will all of this be able to be controlled through dbus though. I think KDE 4 is still crippled in the fact you can't do simple tasks that you could do with KDE 3 and dcop. I thought dbus would be a key component to plasmoid creation as dcop was with some SuperKaramba themes. You've always talked about how you want to make things simple for artists, programmers, and users. However right now it's not and you have to compile the decent plasmoids and now we're stuck in limbo as a lot of SuperKaramba themes require dcop and it's not offered. It would be great to port those to KDE 4 but most of the calls required in to do it in dbus aren't there. You would think that would have been a priority early on as the easier it is to create Plasmoids and SuperKaramba Widgets the better Plasma looks and the more tempting it becomes, the more interest you have. Instead we're stuck with few working SuperKaramba themes, most Plamsoids being from KDE developers and a dbus system that was supposed to be so much better then dcop but still comes no where near. Don't get me wrong I know there are other things more important, but I think dbus is key to this whole desktop experience and kde applications working with other applications. A great example would be Lancelot working with KMail and Kopete. I'm just scared by snive comments on mailinglists to users about features that aren't their yet (but are there and don't work) that dbus is being overlooked and while all these features are great they don't stand in comparison to what dbus would be capable of.
@JMiahMan: let's start by sorting out the different parts of your comment.
dbus vs dcop: they are just IPC implementations and as such it isn't the IPC itself (e.g. dbus itself or dcop itself) so much as it is what the application expose. so dbus vs dcop is a bit of a red herring.
so will "all of this" be controllable by dbus? i'm going to assume by "all of this" you mean the nepomuk stored contexts; and the answer is yes. it will be coordinated via a nepomuk service which plasma (or whatever else) speaks to via dbus.
as for plasma itself and dbus, it's on the 4.2 TODO to put together some nice D-Bus interfaces that do at least what kicker/kdesktop provided (which is "not much": wallpaper settings, applet creation).
as for other porting SuperKaramba themes, you really will have to be specific because D-Bus interfaces don't happen magically, right? they are there because applications export those interfaces.
you bring up KMail .. well, the future there is Akonadi and there's actually an Akonadi DataEngine already in existence. for sending mail, those interfaces still existin KMail.
many interfaces still exist, in fact: the standard KMainWindow interface or the media player interfaces, for two examples.
so .. if you could describe exactly what D-Bus interface you are looking for that could help.
the idea that there are fewer D-Bus than DCOP interfaces isn't really accurate however; the only place we have less IPC interface right now is in Plasma, and that's like that for two reasons:
* it didn't make sense to expose certain things until they were reasonably complete (wallpapers, for example)
* people may quietly stew but do they step up to do the work? D-Bus/DCOP APIs are really one of the easiest kinds of thing to do as it's just exposing what is already in existence ...
d-bus in Plasma, is what I'm waiting for. Thanks for the explanation. It's just frustrating, I'm pretty sure by your explanantion it's a little frustrating to you also. THanks for your explanantion and explaining what's up.
This sounds great but please do not forget to make at least one decent tutorial that explains a bit. If there are a few smallish images too that would be awesome :D
Plasma is the thing I was looking for most of KDE 4.x
The fancy graphic does not interest me much - I want to use my computer to do work better and faster, not to enjoy visual effects (these are just a bonus, but not my main reason for using a computer to do work, and btw this is why i also think that koffice is extremely important, and it is good that we do not have to rely on the sluggish openoffice)
@notriddle: there are ways to handle "intelligent" systems that don't have the Clippy effect; research (yeah, old-fashioned science) has advanced in that area. I'm sure the usability girls/guys will keep an eye on the problem.
My preferred reading on the subject is the recent article Exploring the Design Space for Adaptive Graphical User Interfaces.
It shows that people do like an adaptive interface given that its predictions are accurate.
next, you will try to guest what am I doing by checking which dns request I am doing. and then you will be able to build up stats for me. about how many hours I spend doing actual work, surfing porn, etc.
that's just awesome
thanks
Post a Comment