Re: question about multiwindow mode and application icons

["Earle F. Philhower III" <earle at ziplabel dot com>]

Howdy,
At 10:00 AM 5/13/2003 +0200, you wrote:
> ...While working with the test server I recognized, that for all X 
> applications the
> same icon is used in the applications left top corner and the task panel 
> and I'm
> searching for a way to fix this limitation.
> ...PS: It may be that I'm are able to implement this, but currently I have 
> no idea
> how much work this would be, especially
> 1. the image conversation stuff
> 2. the server related XSetWMHints() stuff

I have been looking at this, not for the icons but for window titles.  The
image conversion part is trivial, as is the Windoze UI coding.  The hard
part is modifying the server to support XNextEvent grabbing.  The main
loops now sleep on a work queue and the Window message system, and nobody
is calling XNextEvents (in fact X events are being explicitly thrown out).

If I understand correctly, what you need to do is for each X window you map
you need to have the WM thread do an XSelectInput(PropertyChangeMask) to cause
the X server proper to notify it when a property is changed (WM_NAME = name,
WM_ICON = icon, WM_ICON_NAME = minimized title, etc.).  Then in a plain Jane
X window manager's main loop you'd do an XNextEvent() which would sleep
until a message came in, and if the event.type==PropertyNotice you then look
at it some more to see which window and which property and change the Windoze
icon or window name accordingly.

I've done an ugly hack on the multiwm to change the pthread_wait to a
pthread_timedwait() and if after 50ms there's no work to be done on the thread
it checks if any XPending(), and if so generates and pushes a synthetic 
WM_X_EVT
message on the work queue.  The main WM work loop then pops the queue and on a
WM_X_EVT it does a modified FlushXEvents() and if it finds any waiting
XPropertyEvts it then (eventually) will cross-ref the X window ID to a Windoze
HWND and grab the WM_NAME property and do a SetWindowText().  [Right now I
don't keep the Window<->HWND list, just print out the name changes to the log].
The WM_MAP does a XSelectInput() on every window it maps, and (eventually)
will keep track of the HWND<->WindowID map.  Unmapping would remove the Window
from the list...If there is a pre-existing way of mapping from a Window to
a WindowPtr I'd like to know about it, it would save one linked list.

Another way of doing this would be to spawn a 3rd thread that makes a 
notification
window and sleeps on a XNextEvent() loop.  The WM would send a custom 
message to
the hidden notification window each time a window is mapped, and that 3rd 
thread would
then do its own XSelectEvent() on that window.  If that 3rd thread gets a
PropertyChange event then it would just push a WM_X_NAMECHANGE or 
WM_X_ICONCHANGE
onto the main WM thread's work queue.  This feels more elegant, but for the 
life
of me I can't get XSelectInput() in the 3rd thread working properly, so the
main WM thread never received those new messages...

Maybe some of the big guys who orchestrated the multiWM would have a better 
idea
or suggestions?


-Earle F. Philhower, III
 earle@ziplabel.com
 cdrlabel - ZipLabel - FlpLabel
 http://www.cdrlabel.com