RE: question about multiwindow mode and application icons

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

> Howdy Ralf...
>
> >Subject: RE: question about multiwindow mode and application icons
> ..
> >I've checked your patch and it works mostly as expected.
> >I've recognized only two problems:
> >1. THE WM_HINTS stub is never reached. I've added a test application
> >2. The window title setting is delayed for about a second. You can
> >verify this with xterm.
>
> For #1 you need to make sure the app is updating the WM_HINTS, or
> even setting it in the first place.  I'd say 90% of apps do not set
> this property, that's why most WMs have big config files that
> specify a mapping between a window class and a custom .jpg icon.

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.

> If you're sure the app is setting the propery, it may be setting it
> before the window is mapped.  In that case you'd need to query
> for the property in the WM_WM_MAP case: statement.

I will give it a try.

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

When I starting thinking about this feature, I took a look into the qt library
source (see for example
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kde-cygwin/qt-3/src/kernel/qwidge
t_x11.cpp?rev=1.1.1.6&only_with_tag=QT_IMPORT&content-type=text/vnd.viewcvs-mark
up) and I recognized that for qt and kde applications it should do so.  (May be
you can find more. Search for "SetIcon". )

>
> #2 you have a point, I've never had it be more than just noticable
> but then again I do most of my work on remote systems and my local
> CPU is just handling the window manager (and maybe IE).  If it's
> really bad what you can do is change the timeout delay in the PopMessage
> function from (now.mullitm+50) to (now.mullitm+5) at the cost of
> slightly more CPU utilization at idle.

I will try.

> Like I said, the best way
> would probably be to have a 3rd thread working on a XNextEvent()
> loop, but that's kinda hairy to get working properly, and due to
> CPU scheduling in pthreads() you might still have some delay between
> when the XNextEvent() thread goes to sleep after pushing a value to
> when the PopMessage() thread notices and wakes up...

Hmmh, this seems to be a job for the real xfree gurus.

> One other thing I have seen after having it running for a 36 hours
> is that when my screensaver grabs and releases the GDI it seems
> all the X-Window windows are reset somehow.  I do a xprop on a window
> and see the cyg_privmap_rl in the window prior to the screensaver
> and after I come back that property is gone.  Very odd, I'll have to
> look at it and maybe the XChangeProperty() call should be done in
> the winmultiwindowwindow.c function.  If worse comes to worst a
> list of top level windows can be put back in to keep track of these
> things.  There shouldn't be that many top level windows to worry about,
> after about 100 or so even Windoze itself gets funky!

Identifing the top level window is also a must be for displaying different
icons. See the next mail.

Cheers
Ralf