> -----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 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 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 specification does not stipulate what size these icons should be, but individual desktop environments or toolkits may do so. The Window Manager MAY scale any of these icons to an appropriate size. 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. Cheers Ralf
xprop.log
Description: Binary data