RE: question about multiwindow mode and application icons

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

Hi again,

> > > >2. The window title setting is delayed for about a second. You can
> > > >verify this with xterm.

>I was able to get the "proper" way implemented, namely a 3rd thread that
>sleeps on a XNextEvent and which takes away the timeout in the main WM
>thread.  Now title changes are instantaneous, and no timeout polling is
>needed.  It turns out you just need to listen to the root window and
>there's no need to communicate from the WM->XNextEvt thread at all.  It
>also seems to not lose its mind when my screen saver kicks in, but I'll have
>to run it for a day or so to be sure.

I've tried it and got one problem described below:

1. start xterm
	setting window title works

2. start another application

3. switch to xterm -> setting window title does not works

4. kill another application

5. switch to xterm -> setting window title does still not works

6. kill xterm

7. start xterm -> setting window title does not works


>--------------------------------
>Ralf Habacker wrote:
>I'm already wondering about this, now it is clear.
>Let me ask one question: It is possible to get the executable name of an
>x-application on the server ?
>I'm asking because I have a working solutions using icon dlls for the
>application identifing the application by its window title. Using the
>application executable name would make this much easier. See the next mail
>to
>the list with a proposal for this.
>--------------------------------
>
>Try checking WM_CLASS properties.  A quick check would be to run xprop
>on the window you're interested in.  WM_CLASS is what .Xresources works
>off of IIRC.

got it.
>
>---------------------------------

>> For most of the X Consortium apps I don't think there are icons, alot of
>them
>> predate WM_HINTS I think!

>I don't have QT running, but since you do maybe you can write a quick
>app that makes a window and just SetIcon()s it over and over and see
>if the message ever gets thru to the procedure, maybe it's getting
>into the X callback procedure but I've made a mistake in the ATOM spec
>for the WM_HINT option?
>
I think, it goes easier, see below.

>---------------------------------
>In the meantime I've got some more details on how this feature (displaying
>different icons for x applications in the win32 window) could be implemented.
>I'm going to use a three level icon display scheme, choosen by the
>informations

>an x application will give.
>1. An x-application provides an application icon through the WM_HINTS events,
>which will be displayed as win32 window icon.
>2. In case point 1. doesn't work, users can provide a special icon dll, loaded
>at runtime into the server, which contains icons for specific applications
>like
>other window manager does through special icon files (for example icewm).
>Identifying the icons will be done through the application window title. There
>are more than one icon dll setup through an environment variable possible,
>which
>will be searched one by one. If no icon was found the xserver tries at last a
>default icon dll for general x applications.
>Current implementation status:
>1. not working yet due to problems getting the WM_HINTS event
>2. a working solution available (tested with some qt and kde applications)
>-----------------------
>That was fast!
>
I had this before I started the thread.
>----------------
>open issues:
>A. currently all win32 windows of the multi-window mode shares the same window
>class, which means, that changing a single windows icon will change *all*
>icons.
<snip>
>Instead of using the class icon, how about doing your own WM_NCPAINT
>handling?  You can set the class icon to NULL or a blank icon when you
>register the class, and in the WM_NCPAINT first call the default
>handler to draw the title/etc, and then DrawIcon(fn(x-class)) in the
>non client region, after getting the icon x/y from GetSysMetrics.
>
Seems to be complicate, see below


Because of the WM_HINTS problem I have simplified the icon strategy a little:

The easiest solution at now seems to me using *.ico files for any application
identified by the application name (using WM_CLASS). This makes it very easy to
support additional applications.

Implementing the WM_HINTS stuff could be done in a second step, which will come
later.

Implementation:

1. Setting the icon is only necessary in winCreateWindowsWindow() through a
LoadImage() call (see the function GetIcon() below) which loads the icon file
from the disk. To archieve the same icon for all windows of an application, each
application uses a uniq window class for its windows.

For that I need to retrieve the application executable name through WM_CLASS,
which works already on another place. Unfortunally in winCreateWindowsWindow()
there is only a WindowPtr available.

My question is now, how do i get some parameters from a WindowPtr ?

Display *pDisplay,
Window iWin,
WMInfoPtr pWMInfo

Any ideas ?

Cheers Ralf