(Real) Task Orientation in KDE 4.0 using KParts

[Renato Machado de Sousa]

Disclaimer: I am only an user, and I don't know if this is already planned
and I am stating the obvious. Actually, I really hope I am stating the
obvious here.

Also, I am not in these lists. Please cc me if possible. I will try to
check the list archives in the web, but response may be slow...

KDE/KParts is turning into a very beautiful architecture. It could 
become a new paradigm in desktop environments, using some rearrangements 
in the way things are seen by the user.

In Kontact, all we have are tasks, that are all handled by the
appropriate parts. We (user) don't give a damn if it is Kmail that sends
mail, or Kaddressbook that manages contacts. We click "Notify someone of
something" and the thing notifies this someone. Konqueror also has some
of this (basically, it shows whatever I click, be it by openning a
separate app or by using a Kpart).

This task-orientation should be taken to the desktop itself. No concept
of openning an application, but of realizing a task. This has been
already claimed to be the future of User Interfaces (and some systems
(cough, winxp, cough) claim to implement it, but are a bit far from real
T.O. architecturally). Now we have KParts, which is becoming a very
elegant way of putting this concept to practice. With Kparts we don't
need standalone applications, all we need is KParts and a generic
Kpartcontainer app (ok, ok, and the panel, and the desktop, and applets
(which are Ktinyparts anyway :)). You want to "create a new presentation",
and Kpartcontainer pops up with a Kpresentationpart.

One problem I can think of this kind of concept is tabs. What tasks
should be grouped under the same window (i. e. tabs)? (PDFs, PSs and
DVIs are very alike, but I could also want to group the DVI with the
corresponding TeX file). One alternative is to have a default strategy 
(task based... I may want every picture in a different window, but 
tabbed browsing by default), but clean drag n' drop interaction to 
group/detach tabs (like in fluxbox).

Another problem is non-KDE apps. Just ignore them, maybe they'll go away 
(or turn into a Kpart and be assimilated) :)). Seriously, just call the 
appropriate app instead of Kpartcontainer if they're the best for the 
job (e.g., call OO.org for "new presentation")

Let me try a list of tasks that are already possible in the current
state (or near future, already planned features) of KDE. Note that there 
are many possible tasks, so some kind of hierarchic grouping is still 
desired...

*View File (maybe filetype selection, then open dialog, then views file)
	(This task covers Kview/Kuickshow, Kpdf, Kghostview, Kdvi,
	Kaboodle. Actually, for the first four, I think it is really
	urgent that we get rid of them as separate apps, as there is no
	sense in having "viewer" apps in a clean architecture like
	Kparts. Separate apps just call for usability incoerences and
	duplicate effort. They should all be implemented as parts, and
	these parts ran on a common "Viewer Container")

*Create File (select filetype dialog/submenu, opens empty file) 
*Edit File (open dialog, opens file)
	(These two tasks should cover all of Koffice, Kdevelop, Kate)
*Browse (files, the web, audiocd, lan, whatever... read Konqueror)
*Inbox (Join KMail/Knode)
*Compose Message (select IM, Mail, News)
*View Calendar (Korganizer)
*New Appointment (Korganizer, Kaddressbook if group task)
*New Contact (Kaddressbook, Kopete's new contact)
*Browse Contacts (Kaddressbook, but including IMing capabilities of kopete)
	(The 6 tasks above stand for Kontact)
*Play Media (JuK)
*Games (a group with entries for each one)
*Connect to the Internet (configured at control panel)
*Burn a CD-ROM (K3b)
*Communicate with portable device (Camera, Palm, Phone, MP3)
*Manage downloads (KMLdonkey, Kget, maybe even Kopete and KSirc)
*Shares (KMLdonkey, SMB, NFS)
*Control Panel

Now I humbly get under the desk and prepare for the bashing...

Renato Machado de Sousa