Re: [opensuse] KDE3-4 did teams change?

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 spread***, 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
Loading