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.