question about multiwindow mode and application icons

[Harold L Hunt II]

Earle,

Earle F. Philhower III wrote:
> 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.
> 

Wow!  You have certainly done your homework here.  This is way more 
complicated than I thought it would have to be.

As for going from and HWND to a WindowPtr, it seems to me that you can 
either use the existing WIN_WID_PROP property, which is set in 
winmultiwindowwindow.c/winCreateWindowsWindow () and contains the XID of 
the X window, or you could add another property that contains a pointer 
either to the privates structure or the WindowPtr.  Does that solve your 
problem?  I like the window properties because they eliminate searches 
through linked lists and they eliminate the need to even have a linked 
list structure in our code base.

> 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...
> 

Hmm... I would have to see the code in order to have some suggestions.

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

Kensuke Matsuzaki (the originaly author of the MultiWindow mode) might 
have some ideas, but I have not seem him on the list in quite some time. 
  Even if the code doesn't work I would like to see it... I might be 
able to help get it working.  Shoot me any code that you would like me 
to look over and I will see what I can do.  [Feel free to post a `diff 
-U3 -N' to the list for all to see and I will pick it up there.]


Thanks for contributing,

Harold