[Xquartz-dev] Apple-WM usage

[xquartz-dev.5.mzs at spamgourmet.com]

Hi,

On Tue, 8 Apr 2008, Jeremy Huddleston - jeremyhu at apple.com wrote:

> Hmm... I'm going to look into this a little more tomorrow to help you out... 
> I'm X11'd out for the night... 2.2.0_rc3... phew.

Thanks on both counts.

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

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

>> An example of the rationale for doing this is so:
>> 
>> For example you would like X11.app to pop-up a dialog box asking you to 
>> verify that you indeed wish to quit. So when you start-up your X11 session 
>> would like to do the XAppleWMSetCanQuit function.
>> 
>> There are lots of other places the window manager would like to do other 
>> Apple-WM specific things.
>
> 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?

Personally I would like the Xserver to do little so the wm can do more if 
it wishes. 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.

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.

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 ;)

>> I have also tried to compile aw.c with -framework AppKit with no difference 
>> in behavior. Is there something I am doing wrong? Does it have to be the 
>> actual window manager that calls these? What is the future of Apple-WM?
>
> Again, too tired

Please don't forget...

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

> Helpful ideas to come at a later point... sorry I'm not much use now...

I'll keep waiting patiently.

Thanks,
mzs