[Xquartz-dev] Apple-WM usage

[Jeremy Huddleston]

>> Just as a note, are you running this in Terminal.app or in an  
>> xterm?  What version of X11?
>
> From Terminal.app, the version I used yesterday was 2.2.0_rc2, I  
> also tried it with 2.2.0_rc3 today with the same bad results. I  
> tried it today from both Terminal.app and and xterm, again failure.

Ok, sorry for delaying... I'll get to this as soon as 2.2.0 is out the  
door.

>> XAppleWMSetFrontProcess(dpy) should cause X11 to move to the  
>> foreground as of 2.2.0_rc1 or rc2... there was a bug in 2.1.4 and  
>> not sure which rc fixed it.
>
> For me I remember that with 2.2.0_rc1 expose would bring all X11  
> windows forward, with rc2 expose brought none forward. Maybe some  
> patch was lost from rc1 to rc2?

not quite... This is actually partially intentional.  F9 expose should  
just bring the selected window forward.  In the old style,  
SetFrontProcess caused all the windows to come forward.  This is  
"wrong"... I just need to figure out where to hook in to cause cmd-tab  
and clicking on the dock to move all the windows forward.

>> I agree...  but I also want to cut down on Apple-WM a bit where it  
>> is feasible to more functionality into the server itself thereby  
>> making it even easier to use other WMs...
>>
>> One of the main issues with using other WMs is dock integration...  
>> this is also one of the biggest reasons quartz-wm isn't open- 
>> sourced.  Much of the way quartz-wm integrats with the dock is  
>> proprietary, and we'll need to break out that functionality into  
>> libXplugin in a way that other WMs can easily use.
>
> Personally I'm torn as to the right thing to do here. On one hand  
> you want the wm to be able to have this control. On the other no wm  
> other than the OroborosX someone else pointed out before in the x11- 
> users list did any of that. But it did it with a hacked Xserver. Was  
> it that AppleWM never worked for anyone outside Apple or because of  
> lack of interest?

Almost certainly lack of interest.  Blackbox, gnome, kde, xfce...  
those are all developed by people running X11 on a unix box.  They're  
not going to add AppleWM support "just cause"... they probably can't  
even test it reliably.

> Personally I would like the Xserver to do little so the wm can do  
> more if it wishes.

Right, but there are some things that the Xserver *SHOULD* do... like  
managing the clipboard proxying for example...

> Then you could have behavior like in the venerable twm about  
> clicking on windows and the window will have focus but may not come  
> to the front, or it may go to the back, etc - all customizable.

*that* is definitely a WM issue.  I'm more focusing on the "other"  
stuff like clipboard, "Dock Issues" (minimizing causing an icon in the  
dock, for example), etc... things you might not realize are actually  
done by quartz-wm at first glance.

> Also personally I am not too keen any more on having the dock be my  
> icon manager for X11. I like the separation, and the Dock is pretty  
> crummy as an icon manager anyway.

I don't know what you mean by icon manager

> But the one thing I do know for a fact is that you and Ben will do  
> most of the work on anything Apple has not opensourced, so I don't  
> get to decide ;)

Sure you do!  Apple is a part of this community.  Granted we more or  
less have the final say as to what gets included in Apple's releases,  
but where x.org goes, we follow.  We're not driving X.org... we're  
along for the ride just like everyone else.  We're all in this  
together.  I'm tired of listening to my own ideas.  Throw some at us,  
send some patches.  That's what this list is for ;)

>>> Oh I am currently running the more recent release candidate (rc2)  
>>> and there is that bug in this one where the Windows do not come  
>>> forward until the dock icon is clicked twice.
>>
>> Yeah... I noticed that... not quite sure why that is.  I need to  
>> find out what event is sent to us by clicking on the icon in the  
>> dock and have it send a kXquartzBringAllToFront X event.  In 2.1.4  
>> kXquartzBringAllToFront was triggered on SetFrontProcess which  
>> caused 'F9' exposé to not behave correctly (selecting a window  
>> moved all X11 windows to the front rather than just the selected  
>> one).
>
> Maybe the broken behavior of bringing all the windows to the front  
> is better than the broken one of bringing none for now?

F9 is bringing forward one (the selected one).  So it's a matter of  
which do we want to break... Exposé or cmd-tab.  Voting for breaking  
exposé in favor of cmd-tab puts in a kludge to get it to work.  Voting  
for a broken cmd-tab (for now) leaves us with correct code rather than  
a kludge... just need to find the right place to put in more correct  
code.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3040 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20080411/13fde292/smime-0001.bin