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

List:       kde-core-devel
Subject:    Re: Improving task manager interaction
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       2001-09-30 23:48:44
[Download RAW message or body]

Hi Mark,

I've done a lot of thinking and a bit of research about this so far.
I've coded a few prototypes (some hacks to kasbar, and a 1st cut
taskinfo class), but I haven't started coding the real thing yet. The
biggest challenge has been to figure out how to maximise the
compatibility of this with the existing standards.

So far I have come to a number of conclusion through this research:

1. There is no need for any extensions to support passive notification
dialogs. This can be handled by using the existing icon geometry hints,
and simply moving the notification popup to be aligned with the icon.
Making a self-positioning popup for this use is trivial (I already made
a prototype). Doing it this way makes it compatible with pretty much
any task manager or wm.

2. There is an existing X11 facility to allow an application to offer
a Window that should be used as it's icon. This was used in the past
to offer animated icons (eg. by an old X11 ftp client I used to use).
It may be that this can be used to allow apps to provide a custom
window as some sort of status popup window.

3. As a short-term hack, task progress info can be read from the
caption in the same way as the current modified document flag.

4. The ICCCM lets you specify a default icon size - we should be
using this, but I don't think we are.

5. A task must be able to contain a number of DocumentInfo
structures in order to support MDI.

6. Progress information should be represented as a range from
0 to a specified upper limit. For example, the upper limit will
often be 100, allowing the app to publish the percentage of the
task that has been performed.

7. If task/window thumbnails are to be supported, they should be
created/updated at need. Keeping them updated at all times, may
well require unnacceptible overhead.

8. The task info class should let tasks add overlays to their main
icon that reflect the current location, document or status. It should
also be possible to flash the main icon, or an overlay to indicate a
change in state.

9. I'm not sure that passive notification popups should be shown when
the window involed is active. In this case they could either be ignored
totally, or aligned to the geometry of the window instead of the icon.

10. The task info class needs to provide a simple way to find out the
DCOP id of the task window.

11. A document has (at least) the following state flags:
   - bool active	// The doc is being worked on by the user
   - bool modified	// The doc differs from the copy on disk
   - bool ready		// The document can be edited
   - bool busy		// The doc is currently busy performing an operation
   - bool progressInfo	// The doc can tell us how much of the op it's done
   - bool needsUser	// The doc is waiting for the user to talk to it
   - bool changedOutput	// The document has been changed by someone else

12. A task has (at least) the following state flags, and also
inherits those of a document:
   - bool hasMultipleDocuments	// This task contains >1 document
   - bool hasDCOP		// This task can provide a DCOP id

13. The concepts of the task and the document are somewhat confused
in this list. In general the document should be the core concept in
the design, with a task being an aggregation of documents. The task
should probably represent the most recent change in it's children.

14. Consideration needs to be paid to tasks that operate with groups
of files (such as KDevelop). Perhaps a 'Project' should be able to
publish information in the same way as a Document or Task.

15. We need to find a good way of grouping tasks.

16. The TaskManager API from kicker should be prepared for wider use:
	- Add d pointers
	- Move to a namespace
	- Add more kdoc comments
	- A virtual where needed
	- Better support for sub-task windows (eg. dialogs)
	- Install the headers to $prefix/include/ktaskmanager

17. It should be possible to wrap this in an API similar like QToolTip.

I'm very interested in working with a group of people on this because
to work, it needs to be pretty much universal. What do you think of the
above? Am I on the right track?

Cheers

Rich.
ps. I've cc'd this to kde-core-devel as other people might want to
chip in.

Mark Deneen wrote:
> 
> Well, my computer is back on a network, so i can finally get kde from cvs.
> I'd like to work on the task manager interaction you talked about on
> kde-devel. (http://lists.kde.org/?l=kde-devel&m=99849062631908&w=2)
> 
> I was just wondering if you had started work in this area, and how you had
> planned on doing the communication between the window manager, and the task
> bar.  (DCOP, WM_HINTS, etc).
> 
> Best Regards,
> Mark Deneen
> 
> 
> 
> --
> Sent through GMX FreeMail - http://www.gmx.net

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