On Wednesday 10 December 2008 04:35:12 Rodney Baker wrote:
On Wednesday 10 December 2008 11:13:08 Rajko M. wrote:
On Tuesday 09 December 2008 03:19:08 pm Rodney Baker wrote:
This was great if you had specific documents or files that you worked with on a regular basis e.g. a spreadsheet, database, text files, word processor documents etc. Rather than finding and opening each file or application individually, you just opened the workspace folder and everything in it opened up to where you left of last time you used them.
If you leave documents in KDE applications opened, they will be opened next time you start computer.
Yes, but that is only part of the functionality that workspace folders provided.
Lets say, for instance, that I have 3 specific tasks to do, each of which has a specific and unique set of applications and documents associated with it.
I could create a workspace folder for each task. When I open the folder, the documents and applications associated with that folder open up in the correct state. When I close the folder, the applications and documents close down again, ready for next time I open the folder. I could then move onto the next task in the next workspace folder etc.
Now, I could so this by having multiple different logons for different tasks and remembering each session, but that would mean logging on and off several times. The workspace folders were a much more elegant way of achieving the same thing.
Anyway, no point in reminiscing. Maybe I'll raise an enhancement suggestion when I get a moment or three to put it into developer-friendly terms ;-).
This 'pipe dream' is already part of KDE 4's infrastructure. Nepomuk, a close second for the most obscurely named Pillar of KDE, is a system for the storage and querying of semantic relations. It is a specialised database and set of APIs for accessing that data. One use of it is to implement a task-oriented view of your data that crosses the vertical type-oriented silos it currently sits in. For each of your tasks you could <define a project> in Nepomuk[1], then specify a set of files and 'objects'[2] 'in Nepomuk' as being part of that project; for example, an email from a customer defining the requirements, some photos of whiteboards exploring a solution, <a Contact representing the customer>, and a Kate session (comprising 5 files). You would put this task on the desktop by (broadly) adding a Folder View applet there pointing at the URL "nepomuksearch://<projects/tenders/JonesM>". Then you get icons for all these in that folder, and can open individual items, or the whole lot from the Folder View, or even <right click the Contact and IM him>. Bits in <> are stuff that is currently not yet implemented. The hard and mostly invisible work in KDE 4 has been reorganising what we already had so that new things are possible without onerous overhead, and working on basic things like the nepomuk APIs and storage systems, besides working on the bling. [1] There is not yet a 'KDE Project Management Tool' to do this, but the relations can be added to the store using the APIs, and specific apps are starting to use them, eg digikam. [2] Things that don't, in the current KDE implementation at least, have a physical presence on the filesystem like a group of contacts or a web browsing session. Coming back to the example, most of it can be done with KDE trunk now. The usable user interfaces, for example, a way to define projects, and broad support for projects in applications (the KDE file dialog, for example) is still to be done. You can have a Folder View showing a nepomuk search, and you can have desktops dedicated to particular tasks, with their own constellations of Folder Views and other applets representing the task's state. There is an activity switcher applet to change your context. The Kate session support is mature, even if the session files always live in .kde4/share/apps/kate/sessions and must be accessed on Kate startup or via the Sessions menu. Generally though, it's not coherently integrated yet. I expect that this will blossom in KDE 4.3. Of course, this could be implemented using today's filesystem; task-specific folders, jpegs, saved copies of emails, vcards, another folder for the text documents. I know a prominent YaST developer who manages a large photo collection in this way using symlinks and scripts. It gets messy (updating links, out of date copies) quickly when objects are in more than one task, or there is no physical file you can place in a folder. Will