[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [Panel-devel] Task management in plasma
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2007-05-27 8:13:36
Message-ID: 200705270213.36530.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 26 May 2007, Richard Moore wrote:
> - No separation of properties of the document from the properties of the
>   task. In fact there is little or no support for storing the properties of
>   the document at all. Things like parsing '[modified]' from the window
> title are hardly good enough!
>
> - No real support for MDI

these go hand-in-hand with your NETWM vs DBUS item below...

> - Support for task grouping is only skin deep - a function that says
> 'should these tasks be grouped together'. This function only supports a
> single policy and has no mechanism for extending it.

well, there are actually a few different policies in there, but yes.. it's 
pretty static. the question is what is missing? it would be nice if the 
grouping was done in libtaskmanager rather than also relying on cooperation 
with the visualization.

> The user should be 
> able to define their own groups (though grouping similar windows should
> remain one of the available policies).

i'm very hestitant about this. it is an occasionally requested feature, but 
i'm really not sure it's a useful feature and will certainly complicate the 
code by adding yet another grouping system and require the addition of user 
interface to manage it.

> - The interface provided by NET specification is the only means of
>   communicating with a task manager. There is no DCOP or DBUS interface
> that users or tools could use to control higher level facilities.

i'm really on the fence whether we should fix NET or add another layer of IPC 
to it all. and if we do add DBUS to the mix, where does the line get drawn 
between what should be in NETWM and what should be on the bus?

> - No way to associate addional information with tasks. For example we
> should be able to associate KIO::Jobs with tasks to provide overlays of
> download progress etc.

yes...

> - Window state information is incomplete (we can see if a window is
> maximised, but can't tell if it is only maxed for width for example).

yes...

> - Support for transients is weak. I don't know if this really matters
> though.

i think we're ok with this right now.

> - Support for multiple screens is weak.

in which way(s)?

> - Integration of the LMB and RMB menus is weak, these should be obtained
> from the task. This can't be done right now however as the task manager API
> has no understanding of which tasks are grouped.

well, that and we can't easily get a menu from a task in any case due to lack 
of communication between task observers (e.g. the taskmanager, pager, etc) 
and the windows themselves.

> - Taskmanager
> - Task Group
> - Task
> - Startup

these were always painful; perhaps we could have a special place in the 
taskbar for them so they can be treated separately and specially.

> - Document

the real power of Document representation is that it would allow things like 
web apps to potentially be displayed as first class citizens in addition to 
the obvious MDI improvements.

> If we define DBUS interfaces to these concepts then we gain the ability to

at least some of this probably could and even should be done using window 
manager hints. i'm still thinking about which ones should be which =) 
essentially, most of the problems we run into are the incredibly unuseful 
body of NETWM information. there is a policy right now that says that windows 
can only talk about themselves and only as it pertains to window management; 
so window relationships are not supported (and there has historically been 
push back on changing that) and there is little in the way of window state 
information.

perhaps if we go to the window manager people of the world with a cogent "this 
is what we need and why" we can get them to bend.

this may meant that much of this would slide off until 4.1.

> provide facilities for richer integration. For example UIServer could tell
> the task manager to overlay progress data, applications could request
> particular groupings (eg. group the kwallet dialog with the application
> that caused it to be launched).

these are very nice ideas. i'd like to see something similar for many of the 
systray icon usages.

> So, any comments?

honestly, i'm still digesting =)

as for implementation, i'd like to see if we can manage this as a DataEngine; 
i purposefully added the ability to add DataSource* directly rather than only 
have the setData method so that we could stand a chance of doing this 
efficiently. we may also need/want to override the DataSoruce::data() method, 
but i'm not sure yet.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)

[Attachment #5 (application/pgp-signature)]

_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel


[prev in list] [next in list] [prev in thread] [next in thread]