RE: Custom icons per window class/name patch

["Ralf Habacker" <Ralf dot Habacker at freenet dot de>]

> -----Original Message-----
> From: cygwin-xfree-owner@cygwin.com
> [mailto:cygwin-xfree-owner@cygwin.com]On Behalf Of Earle F. Philhower
> III
> Sent: Monday, May 26, 2003 7:28 PM
> To: cygwin-xfree@cygwin.com
> 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

Attachment: xprop.log
Description: Binary data