[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-10-01 22:54:17
[Download RAW message or body]



Martijn Klingens wrote:
> 
> On Mon, 1 Oct 2001, Richard Moore wrote:
> > 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:
> > -- snip --
> 
> > 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 is 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
> 
> An idea that Rob Kaper came up with and that I think is pretty nice is to
> have next to the modified flag a 'status' icon. Then it would be possible
> in a game to show a set of dice next to the app's icon if it's your turn.
> For many other apps it would also be quite useful to have such a thing.
> KMail can show an icon if there is new mail. Konq can show a progress bar
> showing how much of a page is loaded, etc...

I think the overlay stuff I refered to should be able to handle this,
the idea is that you should be able to blend additional information
into the basic icon.

> 
> Might be worth implementing?
> 
> And something that I would like is to remove the distinction between
> documents and tasks, though I understood from your mail that you are
> planning that already.

I don't want to remove the concept of a task entirely, but I do want to
make things document-centric. A task would become an aggregation of docs
in my view, but would also be able to define properties of its own.

Without retaining some concept of a task, I don't see how the API could
correctly report things like application-modal dialogs. Note that the
presence of tasks in the API does not mean that there would be any
requirement that a given task manager should display them - it may choose
to be 100% document-based.

Ultimately, I'd also like to see the somewhat more advanced concept of a
'project'. The project would represent a user-defined group of documents,
instead of an artifact of the implementation like the task.

> 
> What I would like is to have all my konsole sessions still use a single
> window as they do now, but not have their own "task bar", but instead add
> an entry to the normal task bar for each session.
> 
> Since I sometimes have multiple konsole windows and sometimes multiple
> sessions I often find myself pressing alt-tab when shift-arrow is needed
> and vice versa. Not quite intuitive IMO :-) But again, I think you already
> planned this, I just wanted to mention it in case you didn't.

This is possible within the framework I describe, though it will require
a task manager that understands the extra set of hints.

> 
> > -- more snip --
> > > 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?
> 
> For what I could actually understand it looks good. But there are some
> pretty low-level parts that I didn't completely understand yet ;-)

Feel free to ask about them - if nothing else, you'll be forcing me to
write the documentation/specification. ;-)

Cheers

Rich.

> 
> Martijn

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