Custom icons per window class/name patch

[Earle F. Philhower III]

Howdy Ralf!
At 09:33 PM 5/19/2003 +0200, you wrote:
>...> can then check for it in the winCreateWindow section and also in the 
>WM_HINTS
> > property handler if it's changed later.  Others don't and then it's up 
> to the
> > WM to give them one, either from a config file or some built-in defaults.
>... or this has to be provided by the client application (maintainer).
>Because currently I have not idea how to deal with the pixmap files 
>provided by
>WM_HINTS (I have searched several hours to find an exact spec how to 
>access the
>pixmaps, unfortunally without any success, [does noone has used this 
>before ?])
>I'm going to provide a set of icon files for kde/qt with the next kde release.
>Applying my patch (icon_base_filename=application_name [1]) and the 
>LoadImage()
>feature of searching all the pathes of the PATH environment var takes the 
>burden
>from the xserver maintainer to the application maintainer (like me).
>The maintainer only have to release a set of icons for example in their client
>bin directory (in my cases /opt/kde3/bin), which will be added to the PATH env
>var before starting the xserver.
>The xserver will search this files in case of starting applications, while 
>basic
>application without any icon would use the default 'x' icon.

I have to admit that I agree with Harold on this, that the whole idea of cygwin
is to make Windoze look like any other Unix system.  As I'm looking at more
of the commercial apps I use and the newer freeware ones I see that the 
majority
do provide bitmap icons in the WM_HINTS, just the really old ones like xterm
don't.  Even xload has one.  [I was able to patch the XC distribution to get
a local working copy of xload, one that shows your Windoze CPU utilization.
If I get the time I'll submit it to the xfree-devel list and see what they 
think
of including it in the next full release...]

IMHO the odds of you getting any SW group to make a special Windoze .ico
patch and files for cygwin is pretty small.  There's extra work and most
folks using X11 are using Linux or other unix systems anyway so they aren't
going to have any tools to make .icos even if they wanted to.  If it's your
own app, then sure. ;)

The pixmap format's not that bad, and if you defer the icon generation until
later you can do it in the WM thread, which is a valid X client so all the
nice X*() functions are available.  Since you can now make a unique window
class from the WM_CLASS res_name and res_class, changing the icon in one
won't affect other apps.  You might even get X to scale and change the depth
of the image to the standard Windoze formats by rendering the Pixmap into a
drawable, and then using the raw bits.  That'd be SW reuse at its best!

Oh yeah, I think there's a tiny memory leak in the patch I sent before.
You need to free() the res_name and res_class after their use, I don't
think I did that, mybad!

...
>KDE/qt for example uses png images by default, so there may be more 
>formats. My
>suggestion is to start with this basic implementation and to see if other 
>people
>have some ideas and knowledge to enhance this.

Eating PNG and JPEG files is not that bad, if you check out the sample
code in their SDKs they each have about a 30 statement main() that
decompresses an image into a RGB buffer.  That would definitely be more
friendly to the Unix folks than .ICO, and if you link dynamically you won't
blow the server size up at all.

I can see your point, but it seems like the code is just a few steps away
from being a real standard window manager.  If we get that, then the only
thing the commercial X servers have on xwin is speed, and I'll trade
reliability for speed any day when doing real work.


-Earle F. Philhower, III
  earle@ziplabel.com
  cdrlabel - ZipLabel - FlpLabel
  http://www.cdrlabel.com