Tasklist icons

[Michael ROGERS <M Rogers cs ucl ac uk>]

I'm forwarding this to the wm-spec-list from gnome-devel-list because of the
recent discussion about icon formats. If a new standard for tasklist icons is 
introduced, it should probably be portable between Gnome and KDE (and 
mentioned in the spec). I think the .desktop format is shared by Gnome and 
KDE?

Michael

>At 10:47 PM 11/17/99 +0100, Anders Carlsson wrote:
>>Samuel Solon wrote:
>>> 
>>> I've gotten to really like the task list applet but without "meaningful"
>>> mini-icons it's much less useful. I notice that the mini-icons can be set
>>> from properties on the windows but it doesn't appear that any Gnome
>>> programs do this and we're left with the problem of legacy programs which
>>> will probably never handle the mini-icons in the required way.
>>> 
>>> There is already a mechanism in gnome for associating an icon with an
>>> application, the .desktop file, so it would make sense to use the Icon
>>> entry of a desktop file if the application doesn't indicate an icon in some
>>> other way.
>>> 
>>> Most applications set the WM_CLASS property of a window and this can be
>>> used to find a <class>.desktop file somewhere in the
>>> $(DATADIR)/share/gnome/apps hierarchy.
>>> 
>>> This means that the .desktop file associated with an application should be
>>> named the same as the WM_CLASS property but that shouldn't be too much of a
>>> problem.
>>> 
>>> Legacy apps can be handled by creating a .desktop file for them. If the
>>> executable isn't found the file won't have an entry in the menus created,
>>> so there isn't any negative impact.
>>> 
>>> The attached tar file contains patches to add this capability (diffs
>>> against gnome-core-1.0.53). It's a little messier than I'd like but I
>>> wanted to keep the icon lookup separated from the rest of gwmh. Also making
>>> this messier is that the code to lookup the icon (and other desk handling)
>>> is in applet desk-guide, which is #include from tasklist.
>>> 
>>> Untar the file at the applets level of a source tree to create the new
>>> classicon.[ch] files in the desk-guide directory along with a diff file in
>>> desk-guide/ and tasklist/ which can be used as the input to patch.
>>> 
>>> This has certainly made my life much better. ;-)
>>> 
>>> --
>>> Sam Solon
>>> ssolon@usa.net
>>> 
>>
>
>Anders,
>
>I'm not really sure how to responsd to this message.
>
>>Hi Sam,
>>
>>the tasklist that is in gnome-core 1.0.5[34] is only there as a form of
>>technology preview, it's slick and people like it. The "new" one that
>>will be in the next major release of GNOME will have more functionality,
>>along with an API in gnome-libs to set the mini icon.
>>
>
>Does this mean that patches are *not* being accepted for this applet? Are
>there other pieces of gnome that people shouldn't bother working on?
>
>>Personally I don't think having the mini icon references in .desktop
>>files is good, because you may want to have different icons for
>>different windows.
>>
>
>Well, you talk about adding an API to gnome-libs to set the mini icon, but
>that's only a small part of the issue. Are we now going to give control of
>the iconic version of a window to the application itself? What if someone
>wants to change the icon to match a particular theme that they've developed.
>
>If each app has to handle it's own icons then a method of specifying them
>will have to be developed. Perhaps something similar to the (transparent)
>way that accelerator keys are added to apps.
>
>Adding an API also fails to address legacy apps. I run lots of non-Gnome
>apps and I'd like for them to have an icon in the tasklist.
>
>X has a way of identifying windows, the WM_CLASS property and we should
>make some use of it since many existing apps will set it.
>
>Looking over the patches I've submitted I've found that it doesn't work the
>way that I wanted it to, so I've spent a little time rethinking the matter
>resulting in another attempt the results of which are attached.
>
>I had several goals with this:
>
>1. Make as compatible as possible with existing practices so most things
>just work (app with a single top-level window).
>
>2. Allow legacy (non-Gnome) apps to be easily accomodated.
>
>3. Support multiple top level windows in both Gnome apps and legacy apps.
>
>4. Don't break anything (backward and forwards). Any changes to the desktop
>file should be backward compatible.
>
>What I came up with:
>
>In the following res_name and res_class are both values from XGetWMHints.
>In the following I use <app_name> to refer to the res_name value from
>XGetWMHints and <app_class> to refer to the res_class value from the same.
>
>Start at $(datadir)/gnome/apps
>
>1. Look for a desktop file with the name "<app_class>.desktop". 
>
>2. If found look for "<app_name>.Icon" entry in the desktop file and if
>found use that icon.
>
>3. If "<app_name>.Icon" isn't found, remember the "Icon" entry.
>
>4. If "<app_name>.Icon" hadn't been found, look for a file
>"<app_name>.desktop".
>
>5. If "<app_name>.desktop" is found use the icon in an "Icon" entry.
>
>6. If there is a remembered "Icon" from step 3 use that.
>
>7. Apply same tests to all subdirectories until we find something.
>
>Some examples might make this clearer.
>
>Netscape Navigator's main window has <app_name>="Navigator" and
><app_class>="Netscape". Looking for "Netscape.desktop" finds a file with an
>"Icon" entry, but no "Navigator.Icon" entry. There is no file
>"Navigator.desktop" so the "Icon" entry from "Netscape.desktop" will be used.
>
>The message center in Navigator has <app_name>="MailFolder" and
><app_class>="Netscape". Looking in "Netscape.desktop" finds an "Icon"
>entry, but no "MailFolder.Icon" entry. There is no file
>"MailFolder.desktop" so the "Icon" entry from "Netscape.desktop" will be
>used and the two Navigator windows will have the same mini-icon.
>
>If we wanted the message center to have a separate icon we could add the
>following to "Netscape.desktop"
>
>MailFolder.Icon=mailfolder.png
>
>and the message center would get it's own mini-icon. This entry should be
>ignored by any other software that uses desktop files.
>
>If we created a (bogus) "MailFolder.desktop" file with an "Icon" entry, any
>app that had an <app_name> of "MailFolder" would use this as an icon. This
>is, unfortunately, subject to search order. Currently placing
>"MailFolder.desktop" at the top level $(datadir)/gnome/apps it would be
>found before any more specific definition of "MailFolder" (such as one in a
>"Netscape.desktop") file that was further down in the heirarchy. Perhaps a
>search for "<class_name>.desktop" should be done first.
>
>In any case, the attached tar file contains the new classicon.* files and
>patches to desk-guide and tasklist (code from desk-guide is #included into
>tasklist). Untar at the "apps" level and apply desk-guide/desk-guide2.diff
>and tasklist/tasklist2.diff.
>
>The diffs were created against CVS versions, but I have tested them with
>October Gnome and they seem to work.
>
>I'm sorry this has gotten so long (and involved) but this is one of those
>issues that always seems to be involved.
>
>Sam Solon
>ssolon@usa.net