question about multiwindow mode and application icons

[Harold L Hunt II]

Earle,

Actually, I found a problem with the interaction between MultiWindow 
mode and Clipboard (-clipboard) that seems to have something to do with 
this patch.

I have been doing the following:

1) Launch XWin.exe -multiwindow -clipboard

2) Launch a local copy of xfig.  Observe that the title bar is being 
changed.

3) Close local xfig.

4) ssh to remote Debian Linux host.

5) Open xfig and/or mozilla on Linux host.

6) Observe that setting the title bar sometimes works, sometimes it doesn't.

7) When setting the title bar does not work, it is basically because the 
MultiWindow Window Manager thread has exited.

Checking /tmp/XWin.log indicates that winClipboardErrorHandler got 
called twice, which shouldn't happen because all paths through 
winClipboardErrorHandler lead to pthread_exit (NULL).  Thus, either 
pthread_exit (NULL) is not killing the calling thread (not your fault) 
as per the specification of what it is supposed to do, or somehow the 
MultiWindow window manager is calling winClipboardErrorHandler.  In any 
case, the window manager is being killed.

The interesting thing here is that running -multiwindow does not 
encounter the problem, nor does running -clipboard.  Only together do 
they cause this error.  This may have been a problem with the code 
before you started, but it may be related to your code.  For now I have 
removed the calls to pthread_exit () from winClipboardErrorHandler, as I 
really see no reason that we should bail out there when we have a 
problem.  This may have been a simple coding oversight on my part.

Let me know what you think.

Harold

Harold L Hunt II wrote:

> Earle,
> 
> In winmultiwindowwindow.c - WM_COMMAND, WM_SYSCOMMAND, and WM_INITMENU - 
>  These were all ending with a break.  I changed them to end with a 
> return 0, except when WM_SYSCOMMAND doesn't actually process anything. I 
> also changed WM_COMMAND to WM_INIT_SYS_MENU and I changed the menu 
> identifier to ID_APP_ALWAYS_ON_TOP, which is stored in resource.h.  It 
> was, in my opinion, a misuse of WM_COMMAND and WM_USER the way that it 
> was initializing.  Now it should be clear what is happening.
> 
> Other than that, looks good.
> 
> 
> Thanks for contributing,
> 
> Harold
> 
> Earle F. Philhower III wrote:
> 
>> Howdy again
>>
>>  >From: Harold L Hunt II <huntharo@msu.edu>
>> At 08:51 AM 5/16/2003 -0400, you wrote:
>>
>>> Earle,
>>> In the meantime, have you checked the size of /tmp/XWin.log when 
>>> running with this patch?  I just want to make sure that there are no 
>>> ErrorF's that should be #if'd out of the code.  We have had problems 
>>> where I miss the fact that someone is dumping tons of messages to 
>>> /tmp/XWin.log (think megabytes per minute) and I fail to remove those 
>>> messages before we make a release.  Could you double check for me 
>>> that this is not the case with this patch?  If it is the case, could 
>>> you please resubmit with the appropriate ErrorF's #if'd out?
>>
>>
>>
>> Sure, I checked and there's nothing new that I'm printing out in the 
>> changes,
>> but the winclipboard is still dumping every time it gets a new selection.
>>
>> Attached is the cleaned up change, it ran the whole day worth of heavy 
>> XWin
>> hacking for me at work.  It has the change I mentioned to Ralf 
>> earlier, so
>> the old diff with the bug he found should just be discarded.
>>
>> I also added something that I find VERY useful for things like xload 
>> and a console
>> window:  Always-On-Top.  Right-click on the titlebar of any X window 
>> and you can
>> make it float above other windows with the new menu item.
>>
>>
>> -Earle F. Philhower, III
>>  earle@ziplabel.com
>>  cdrlabel - ZipLabel - FlpLabel
>>  http://www.cdrlabel.com
>>
>>
>> ------------------------------------------------------------------------
>>
>>