Tasklist and mini-icons, second try

[Samuel Solon <ssolon usa net>]

A few months ago I posted the following email with patches to implement
small-icons in the tasklist. Apparently, nobody was interested.

With the release (pre-release?) of gnome-core-1.1.1 I had to make a minor
change to keep the patches working and decided that I would post them again.

I had hoped to at least start some discussion of how to properly display
mini-icons on the tasklist but instead got some handwaving that this will
be addressed in an unspecfied manner in a future version.

To me it was important to have something useful now so I wrote the code and
I'm "submitting patches".

Sam Solon
ssolon@usa.net

---------------------------------------------------------------


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 respond 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

small-icon3.tgz