This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Custom icons per window class/name patch


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]