[Xquartz-dev] Apple-WM usage

[Jeremy Huddleston]

> True = 1, False = 0
> XAppleWMSetCanQuit(dpy, False): 1
> XAppleWMSetFrontProcess(dpy): 1
> XAppleWMSetWindowLevel(dpy, window, 0): 1
> XAppleWMSetFrontProcess(dpy): 1
> XAppleWMSetWindowLevel(dpy, window, 0): 1
>
> Even though all those are returning 'True' XAppleWMSetCanQuit,  
> XAppleWMSetFrontProcess, and XAppleWMSetWindowLevel appear to nat  
> have any effect.

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.

Just as a note, are you running this in Terminal.app or in an xterm?   
What version of X11?

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.

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

> 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

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

> Possibly quartx-wm is not doing the XAppleWMSetWindowLevel stuff  
> correctly itself.
>
> What I was planning on doing was patching blackbox so that it would  
> work better in rootless mode on OS X. For example the aforementioned  
> XAppleWMSetCanQuit. Also behavior such as this:
>
> When I click on an X11 window in the background it gets focus and  
> comes to the foreground.
>
> When I hold down a modifier and drag an X11 window in the background  
> it gets focus and moves around but does not come to the forground.

Actually, that isn't working with quartz-wm either.  command-dragging  
should not move the window to the foreground, but it incorrectly does  
with 2.2.0_rc3's server and quartz-wm.

> etc...
>
> I was hoping to ge this to work with the aid of Apple-WM but am  
> having trouble getting it to do anything at all at this point and  
> would really appreciate any helpful ideas.

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

--Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3221 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20080408/b6e5220f/smime.bin