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

List:       kde-devel
Subject:    RE: I'd like it, but...
From:       David Faure <David.Faure () cramersystems ! com>
Date:       2000-03-02 15:08:21
[Download RAW message or body]

> > On the technical side, this means... adding those states, the
> > corresponding icon, and the command line for the status check
> > to the definition of the mimetype, and using all of those
> > in KMimeType::icon. Sounds feasible.
> 
> 	Couldn't you get by with the following:
               ^^^
me ? :-)
I thought _you_ would do it.
(This is a development list, not a wishlist) :}

> 	o A way to set the events that trigger a status check.

- wanting to display an icon triggers a status check,
- a new sycoca database (i.e. a mimetype change) triggers it as well 
  because all icons are recalculated
- notifying of a change on the file using KDirWatch 'manual' notification
method triggers a status check (e.g. this happens after 'OK' in the
properties dialog for any .desktop file whose icon changed,
or when mounting/unmouting an icon).

That takes care of most cases already.

What's missing is... that a change of status in the printer 
triggers a status check, for instance. That's a lot more difficult,
since no program is notified of this, and we for sure don't 
want kdesktop.konqueror to poll any printer...

And yes, if you manually remove all files in ~/tmp/*,
you can't expect the icon for ~/tmp to change in the
view listing ~/. That will only work if you go into ~/tmp,
delete everything, go up, and then the icon appears correctly...
(Otherwise konqueror would have to 'dir-watch' every directory
icon it shows, and that would turn it into a resource killer).

> 	o A way to specify the means of determining which icon to use.
> 
> 	The "means of determining which icon to use" could include
> predefined options (ie, mounted vs. unmounted) and a way to run an
> arbitrary program that simply writes a state value or icon name to
> stdout. Wouldn't this generalize the behavior of the trashcan and
> device links? Couldn't it even let us make the printer icon change
> according to the printer status?

That's what we already said isn't it ? Specifying a script or 
program that prints the status - rather than the icon, so that 
you can change the 'mounted' and unmounted' icons for instance.
The mimetype file (or the device .desktop file itself, or the
.directory file) tells you which icon to choose for each status,
which is a lot more flexible (you don't expect users to write
the scripts themselves).

But running an external program each time you want to display
the trash icon or any .desktop file might slow everything down a bit...
Well, it would configurable and off by default, like very
resource-killer feature :-)

David.

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