RE: Custom icons per window class/name patch
On Wed, 28 May 2003, Colin Harrison wrote: File should open in WordPad etc. What about posting the images as gif, png or jpg or even better, just posting a link to the image? bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
RE: Custom icons per window class/name patch
Howdy Colin, At 03:21 PM 5/28/2003 +0100, you wrote: ...It shows the task switcher icons with:- 3) ghostview (!) 3) konqueror (showing transparency fault) 4) xeyes and xclock (ok) Are you sure you have all the patches in? #4 xclock is actually a watch icon, with a black strap at the top and bottom whenever I run under 16 or 32 bit mode #3 gv looks more like ghostview has a 50% grey dither around the icon, no? In that case because of the scaling artifacts from xxx-32 you'll get that kind of effect, especially at 1-bit deep. I'll see if I can find anything since it's common between 32 and 16 bit modes. Icons larger than 16x16 seem to have OK 1-bit masks, it's pretty odd! -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: Custom icons per window class/name patch
Howdy Colin et. al, There is a quick, easy fix for the 16x16 bitmask icon problem. At winmultiwindowwindow.c, line 1961 there's an if statement: if (iconPtr-drawable.width 16 || iconPtr-drawable.height 16) iconSize = 32; else iconSize = 16; Replace it completely with just iconSize = 32 and all your problems are solved. There are assumptions that are made in the scaler that aren't valid for sub 32-bit wide icons or masks, and since the scaler can increase as well as decrease the image, it all works just fine. -- Original Message - Subject: RE: Custom icons per window class/name patch From: Colin Harrison [EMAIL PROTECTED] .. I don't get the xclock watch icon on my remote linux boxes either, (RedHat 8.0 and 7.3, KDE) using XFree86-4.2.0-72 and XFree86-4.2.0-8 which are RH's latest released rpms for these disto versions! Cygwin is at 4.2.0-1. Looks like a red herring anyway, I can't fault any 'normal' (as in longstanding) X app icon handling through XWin! Could be, it's not too big of a deal anyway since the masks seem to be OK (OTW you would have a non-white clock face...) -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
RE: Custom icons per window class/name patch
Hi Earle, Just about to try your patch. I'm going cross-eyed starring at these icon! I think that there is a black outline to xeyes and xclock icons that maybe gets lost in the wash! KDE show them with an outline (maybe it's an add-on effect?) Also think xclock has a watch icon now, after all, not a clock (I'm seeing 4 eyes now!)!! I need a new big widescreen monitor and a new pair of specs! I'll maybe try it on a friend's machine, he always has the most expensive kit, being a graphics designer. Colin
RE: Custom icons per window class/name patch
Hi Earle, Your fix is good. No more transparent background problems on ethereal or konqueror icons. I'm off to get my eyes tested! Thanks Colin
RE: Custom icons per window class/name patch
Hi Earle et al, Just some (final?) results to show how good icon handling now is. Notice the xclock and xeyes now have their correct border and woopee it is a watch not a clock! (It's a tiny attached file, 20K...honest Alexander!) Captured at 16 bit colour 1280x1024 display. Attached is a compressed .rtf file containing a capture of icons I get at 16 bits colour via XWin. It shows the task switcher icons with:- 1) A putty session (not via XWin!) 2) Six remote apps via XWin listed 'x ' in putty session. File should open in WordPad etc. Colin IconsFromXWin.rtf.bz2 Description: Binary data
RE: Custom icons per window class/name patch
I just did some runs with the commercial apps I use at work, and can see that many do *not* create custom classes or window_roles for each type of window. I think the best thing to do for the class naming is to just use an incrementing number and make each window its own class. Then when the window is deleted we will just UnregisterClass(GetClassName(hwnd)) and NOT have any GDI leaks. We have a GDI leak now because of this, so it will kill two birds with one stone. Under NT or later this leak shouldn't be a problem, but 95 based OSes share a common 16-bit pool amongst all apps, and may run out causing really bad things to happen if the server is running for a long time. We also have a GDI leak on the HICONs which need to be properly disposed of before they're lost completely. With a separate class per window this will be easier, since no window will share a HICON with another. The class, name, and role can still be used for the 2nd chance iconification of windows (the LoadImage() call referencing xwin.ini). I'll throw a patch together tonight for this unless someone beats me to it. -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
RE: Custom icons per window class/name patch
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Earle F. Philhower III Sent: Monday, May 26, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: RE: Custom icons per window class/name patch Howdy Ralf, At 09:39 AM 5/26/2003 +0200, you wrote: while testing some KDE3 applications, I recognized that the application window class distinction by WM_CLASS isn't enough, because kde applications uses different icons for different windows of an application. This applications uses the WM_WINDOW_ROLE property to distingh for example message box windows from basic windows. Currently the icons of the main window are overwritten, because all the windows of an application share the same window class. The appended patch fix this. (Additional this patch fixes one segfault in GetClassHint, I have recognized causes by a null WindowPtr) I'm not a KDE user so I can't test this directly, but are you sure that the window role name is unique between applications? Would it make sense to use the Windows class name a function of both the res_role, res_name and res_class? Or is there only one KDE file open box that all apps would share? The first. 1. I've done some research relating to this stuff and found some specification of this in the Inter-Client Communication Conventions Manual (ICCCM) for example on http://tronche.com/gui/x/icccm/sec-5.html: It is necessary that other clients be able to uniquely identify a window (across sessions) among all windows related to the same client-ID. For example, a window manager can require this unique ID to restore geometry information from a previous session, or a workspace manager could use it to restore information about which windows are in which workspace. A client may optionally provide a WM_WINDOW_ROLE property to uniquely identify a window within the scope specified above. The combination of SM_CLIENT_ID and WM_WINDOW_ROLE can be used by other clients to uniquely identify a window across sessions. If the WM_WINDOW_ROLE property is not specified on a top level window, a client that needs to uniquely identify that window will try to use instead the values of WM_CLASS and WM_NAME. If a client has multiple windows with identical WM_CLASS and WM_NAME properties, then it should provide a WM_WINDOW_ROLE property. The client must set the WM_WINDOW_ROLE property to a string that uniquely identifies that window among all windows that have the same client leader window. The the spec. A practical hint one can find in http://mail.gnome.org/archives/wm-spec-list/2003-January/msg00010.html, where one of the kde core developer suggests the following: WM_CLASS+WM_WINDOW_ROLE are supposed to uniquely identify every window in an application (+PID if needed). PID might be necessary in multi monitor environments to distingh different sessions like starting the same xapp on two several servers, which might be have different window setting options based on the specific machine x or gui settings. 2. I have asked several kde apps for their implementation and recognized that this isn't implemented very straight. Some applications defines WM_WINDOW_ROLE application wide uniq and some does not so. Your suggestion WM_CLASS+WM_WINDOW_ROLE appended by [+PID] will be the best for all cases, i think. kate: WM_CLASS(STRING) = kate, kate WM_WINDOW_ROLE(STRING) = kate-mainwindow#1 khelpcenter: WM_CLASS(STRING) = khelpcenter, khelpcenter WM_WINDOW_ROLE(STRING) = MainWindow konsole: WM_CLASS(STRING) = konsole, konsole main window - WM_WINDOW_ROLE(STRING) = konsole-mainwindow#1 tip of the day - WM_WINDOW_ROLE(STRING) = unnamed about dialog- WM_WINDOW_ROLE(STRING) = aboutkde settings dialog - WM_WINDOW_ROLE(STRING) = unnamed keditbookmarks main window - WM_WINDOW_ROLE(STRING) = keditbookmarks-mainwindow#1 kicker WM_CLASS(STRING) = kicker, kicker WM_WINDOW_ROLE(STRING) = Panel ... 2. KDE uses 16x16x16 sized icons for modal dialogs (48x48x16 for regular icons), which seems to be not designed for displaying un the task bar or ALT-TAB process switching window. Currently this type of icons are displayed wrongly. CreateIcon() seems to stretch this icon so this result in displaying black horizontal stripes. This problem would be solved, when issue 1. would be implemented. Can you check the raw bits that are being passed to the CreateBitmap for this icon? I've run several 16x16 icon apps (ethereal and konqueror) and they all work fine. The icon_pixmap seems to be displayed fine in the window and taskbar, only in the task switcher the result is very bad. (Of course windows will pixel double the 16x16 icon to 32x32 for the task switcher...). CreateIcon does work for 16x16 bitmaps, but if there was a 32x32 icon registered for the window class before, maybe Windoze doesn't like swapping it for a 16x16 with the GCL_HICON... The problem is kde and gnome specific. The kde3 window manager (kwin) taks switcher displays two
RE: Custom icons per window class/name patch
Hi Ralf, Huh, where was the problem ? I've build it after applying all recent patches from Earle. When I applied Earle's and your patches in sequence, clean, from Harold's test86 sources I got some minor hiccups on the last .dif. I've noticed that KDE icons have problems in their transparent backgrounds(e.g. konqueror). I suspect that the colour mask (xor) algorithm's from Earle may have a minor weakness with some pixmap sources (png's or KDE types?). I'm no expert in bit mangling graphics formats, and Earl's algorithms look tricky to me, so I'll put my hands up here. Mind you, the icon handling is pretty impressive as it stands! I'll try and capture hicons/CreateBitmap data that goes wrong (I'm displaying 16 bit 1280x1024 incase this is device dependent?) Colin
RE: Custom icons per window class/name patch
Erle wrote: I just did some runs with the commercial apps I use at work, and can see that many do *not* create custom classes or window_roles for each type of window. KDE and gnome apps does. I think the best thing to do for the class naming is to just use an incrementing number and make each window its own class. This was my first attempt. Then when the window is deleted we will just UnregisterClass(GetClassName(hwnd)) and NOT have any GDI leaks. ... because of not freeing the Window Class after destroying a window ? There is no need for this. MSDN says, you can call UnregisterClass() after every window destroying. If the class could not be found or if a window still exists that was created with the class, the return value is zero. To get extended error information, call GetLastError. Before calling this function, an application must destroy all windows created with the specified class. All window classes that an application registers are unregistered when it terminates. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/Win dowsUserInterface/Windowing/WindowClasses/WindowClassReference/WindowClassFuncti ons/UnregisterClass.asp We have a GDI leak now because of this, so it will kill two birds with one stone. Under NT or later this leak shouldn't be a problem, but 95 based OSes share a common 16-bit pool amongst all apps, and may run out causing really bad things to happen if the server is running for a long time. We also have a GDI leak on the HICONs which need to be properly disposed of before they're lost completely. With a separate class per window this will be easier, since no window will share a HICON with another. ... but there are many more windows with the default x icon and not with the icon of the basic application window. Fixing this means adding some stuff to deal the stuff, the Window Class concept does. I have some questions about this: 1. Does UnregisterClass() frees the assigned ICON or has it to be free'd manually ? 2. The CreateIcon() and LoadImage() stuff does not frees the previous icon. Could this not be fixed ? Does this not fix mostly GDI leaks ? 3. Every time a WMhints message comes in a new icon will be created. What about checking if this icon was already created and avoid every time recreating ? The pixmap id could be stored in the private window area. The class, name, and role can still be used for the 2nd chance iconification of windows (the LoadImage() call referencing xwin.ini). You mean canceling the wm-hints pixmap features ? That means excluding all x apps, which does provide such informations. I'll throw a patch together tonight for this unless someone beats me to it. Any comments ? Cheers Ralf
RE: Custom icons per window class/name patch
Hi Ralf, Huh, where was the problem ? I've build it after applying all recent patches from Earle. When I applied Earle's and your patches in sequence, clean, from Harold's test86 sources I got some minor hiccups on the last .dif. I have seen, that you have got already this problems. Thanks. I've noticed that KDE icons have problems in their transparent backgrounds(e.g. konqueror). I suspect that the colour mask (xor) algorithm's from Earle may have a minor weakness with some pixmap sources (png's or KDE types?). probably caused by 16x16x16 pixmaps. I'm no expert in bit mangling graphics formats, and Earl's algorithms look tricky to me, so I'll put my hands up here. Mind you, the icon handling is pretty impressive as it stands! I'll try and capture hicons/CreateBitmap data that goes wrong (I'm displaying 16 bit 1280x1024 incase this is device dependent?) I don*t know, what*'s was going wrong, but anyway, streching the 16x16 bit images the 32x32 for the task switcher will not give good results. KDE apps uses the _NET_WM_ICON property to provide a higher sized image. See my other mail for more informations. Is there anyone there who has a linux machine with KDE 3 running, which could be accessed through the internet, so that Erle could connect to this machine and try by himself ? BTW: One could use the KDE 3.1.1 release from the kde-cygwin port, but I don't know I this would be to heavy ? I'm using this for testing this icon stuff. It need some more time for starting a kde application, but with a fast machine it would be possible.
RE: Custom icons per window class/name patch
Howdy, it's probably bad form to reply to your own posts but here goes: Attached is a patch from the clean test 86 release (xwin-20030518-1426.tar.bz2) The changes are as follows: * Colin's key un-sticker for when you unfocus an X window with a key depressed * Custom icons on a per-window basis - Each window created in its own class (to allow custom icon) - Class name = fn(res_name, res_class, res_role, incrementing counter) - Icon is created on-the-fly using the routines I sent before - On destroy of a window free the icon (if not x default) and class - Also still have XWIN.INI support, but seems silly to me at this point, I would just remove it completely and wait for a real ~/.xwinrc file parser and PNG files... * Set XIconSizes() to the Windows approved 16, 32, and 48. It doesn't seem to be looked at by anything, but it is in the XLib documents as something a WM should set. * Removed several misc compile warnings and turned off debug messages for GetWindowName (probably leftover from local debugging?) TBD: * KDE's proprietary icon format (it should be pretty easy to hack the present code to support it, all the real work is already done...) * Handle icon customization better, through ~/.xinitrc and PNG/JPG/etc. * Small icon bitmask problem? -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com from_86.diff.bz2 Description: Binary data
Re: Custom icons per window class/name patch
Earle, Thanks. I will work on merging the remaining changes in this patch into my tree tomorrow. I hope to make a test release tomorrow so that we can all get back into synch. Thanks for your great contributions, Harold Earle F. Philhower III wrote: Howdy, it's probably bad form to reply to your own posts but here goes: Attached is a patch from the clean test 86 release (xwin-20030518-1426.tar.bz2) The changes are as follows: * Colin's key un-sticker for when you unfocus an X window with a key depressed * Custom icons on a per-window basis - Each window created in its own class (to allow custom icon) - Class name = fn(res_name, res_class, res_role, incrementing counter) - Icon is created on-the-fly using the routines I sent before - On destroy of a window free the icon (if not x default) and class - Also still have XWIN.INI support, but seems silly to me at this point, I would just remove it completely and wait for a real ~/.xwinrc file parser and PNG files... * Set XIconSizes() to the Windows approved 16, 32, and 48. It doesn't seem to be looked at by anything, but it is in the XLib documents as something a WM should set. * Removed several misc compile warnings and turned off debug messages for GetWindowName (probably leftover from local debugging?) TBD: * KDE's proprietary icon format (it should be pretty easy to hack the present code to support it, all the real work is already done...) * Handle icon customization better, through ~/.xinitrc and PNG/JPG/etc. * Small icon bitmask problem? -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: Custom icons per window class/name patch
Howdy Colin, At 10:52 PM 5/27/2003 +0100, you wrote: I've noticed that KDE icons have problems in their transparent backgrounds(e.g. konqueror). I suspect that the colour mask (xor) algorithm's from Earle may have a minor weakness with some pixmap sources (png's or KDE types?). I'm no expert in bit mangling graphics formats, and Earl's algorithms look tricky to me, so I'll put my hands up here. They're pretty standard and unoptimized, but since they are only called a very few times during a heavy-weight process, and for 32x32 images it's not a big deal. It just steps over the destination image, figures out which pixel in the source image that pixel maps to, and then does any color space conversions. A nicer way would be to promote all images to 32 bits and then do some 2d bilinear filtering. 8) It's sure nice to have a 1BOPS machine for under 1K$. Mind you, the icon handling is pretty impressive as it stands! I'll try and capture hicons/CreateBitmap data that goes wrong (I'm displaying 16 bit 1280x1024 incase this is device dependent?) Can you try again at 32bpp and see if things are munged? I didn't notice any problems with the quickie konqueror runs I did (over a 56k modem, you don't wanna do a long konqueror remote run, trust me) at 32bpp with the 16x16 icons. That would narrow down where to look by a lot. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: Custom icons per window class/name patch
Howdy Ralf, I'm condensing a bunch of your messages into one longer one... At 11:30 PM 5/27/2003 +0200, you wrote: 1. I've done some research relating to this stuff and found some specification of this in the Inter-Client Communication Conventions Manual (ICCCM) for example on http://tronche.com/gui/x/icccm/sec-5.html: ... The the spec. A practical hint one can find in http://mail.gnome.org/archives/wm-spec-list/2003-January/msg00010.html, where one of the kde core developer suggests the following: WM_CLASS+WM_WINDOW_ROLE are supposed to uniquely identify every window in an application (+PID if needed). PID might be necessary in multi monitor environments to distingh different sessions like starting the same xapp on two several servers, which might be have different window setting options based on the specific machine x or gui settings. What's I think connection ID would be better than PID, they're not guaranteed unique across different machines. FWIW I just used the incrementing counter like you tried before, and seems hunkey dorey as long as you clean up after yourself in the destroy... 2. I have asked several kde apps for their implementation and recognized that this isn't implemented very straight. Some applications defines WM_WINDOW_ROLE application wide uniq and some does not so. Your suggestion WM_CLASS+WM_WINDOW_ROLE appended by [+PID] will be the best for all cases, i think. kate: WM_CLASS(STRING) = kate, kate WM_WINDOW_ROLE(STRING) = kate-mainwindow#1 khelpcenter: WM_CLASS(STRING) = khelpcenter, khelpcenter WM_WINDOW_ROLE(STRING) = MainWindow konsole: WM_CLASS(STRING) = konsole, konsole main window - WM_WINDOW_ROLE(STRING) = konsole-mainwindow#1 tip of the day - WM_WINDOW_ROLE(STRING) = unnamed about dialog- WM_WINDOW_ROLE(STRING) = aboutkde settings dialog - WM_WINDOW_ROLE(STRING) = unnamed keditbookmarks main window - WM_WINDOW_ROLE(STRING) = keditbookmarks-mainwindow#1 kicker WM_CLASS(STRING) = kicker, kicker WM_WINDOW_ROLE(STRING) = Panel I think the only thing consistent is the inconsistency. :) And as far as I've seen in the commercial and non-KDE apps is that nobody but KDE sets that role, even to unnamed Can you check the raw bits that are being passed to the CreateBitmap for this icon? I've run several 16x16 icon apps (ethereal and konqueror) and they all work fine. The icon_pixmap seems to be displayed fine in the window and taskbar, only in the task switcher the result is very bad. Are you sure about this? Windoze will expand 16x16 icons and their masks, maybe the 16x16 icon is bad too but it's too small to see? A windows magnifier app might be handy here... The problem is kde and gnome specific. The kde3 window manager (kwin) taks switcher displays two kind of icons: 1. a list of 16x16 pixel icons like the windows task switcher does and 2. a higher resolution icon for the current selected application. The 16x16 pixel icon is provided through the regular WMHints property, the bigger one by the _NET_WM_ICON(CARDINAL) property, which is part of the Extended Window Manager Hints found in http://www.freedesktop.org/standards/wm-spec.html Ahhh, another window manager standard. So many to choose from! In detail from http://www.freedesktop.org/standards/wm-spec/1.3/html/x231.html _NET_WM_ICON _NET_WM_ICON CARDINAL[][2+n]/32 This is an array of possible icons for the client This is an array of 32bit packed CARDINAL ARGB [alpha,red,green,blue] with high byte being A, low byte being B. The first two cardinals are width, height. Data is in rows, left to right and top to bottom. ... I've appended an xprop dump for the KDE3 kate application. May be you can use this. Looks like about a 30 minute job to parse this guy into separate icon sizes and choose the largest one and feed that into the resize routine. It makes it easier that they're all 32-bit quantities, no format conversions necessary, and there is no reason not to write a nice 2d bilinear or quadratic scaler to give some really sharp icons! ... I just did some runs with the commercial apps I use at work, and can see that many do *not* create custom classes or window_roles for each type of window. KDE and gnome apps does. Yup, seems to be neither rhyme nor reason about it. The apps I'm using have been ported using some Tk, some MainFrame(tm) Windoze porting layers, and maybe some über-hacks... I think the best thing to do for the class naming is to just use an incrementing number and make each window its own class. This was my first attempt. It's in the patch I sent a few mins ago, it seems to work OK and not leave things dangling if you clean up the HICONs and WNDCLASSes... Then when the window is deleted we will just UnregisterClass(GetClassName(hwnd)) and NOT have any GDI leaks. ... because of not freeing the Window Class after destroying a window ? There is no need for this. MSDN says, you can call UnregisterClass() after every window destroying. If the class could not be found or if
