[Xquartz-dev] Full-screen vs. Spaces

[Zulli, Louis P]

I've noticed the following behavior; not sure what "standard" behavior should be. 


I use three Spaces, 1--2--3. With X11 set for full-screen mode but not open, I start xeyes from Terminal.app. (For me, Terminal.app windows open in Space 3 by default.) This starts X11, and I see an xeyes window on my root window. This xeyes window inherits a "binding" to Space 3 from Terminal.app. (It's "bound" to the Space of the Terminal.app that invoked it.) By "bound to" I mean the following: I drag the xeyes window off the left edge of my root screen and Spaces switches to Space 2. I see my Desktop but no Apple menu-bar; xeyes is still active. If I click on that Desktop, the xeyes window vanishes and I'm in Space 2. If I activate X11 by clicking on its dock icon, I get the xeyes window on the root window again. This xeyes window is still bound to Space 2, and can now be dragged off either the left edge or the right edge of the root screen. 


Anyway, I guess I was surprised that I could do this. Perhaps it's only me, but I like to think of that X11 root screen as being "isolated" from the OS X environment, so that it should require a "cmd-opt-a" to escape from it. Maybe we need a preference for X11 that "disables" Spaces from acting from the root window? I guess the larger issue is: How should X11 fullscreen and Spaces interact? 


----- Original Message ----- 
From: "Jeremy Huddleston" <jeremyhu at apple.com> 
To: "Developer talk about Xquartz" <xquartz-dev at lists.macosforge.org> 
Sent: Sunday, December 28, 2008 11:13:25 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [Xquartz-dev] 2.3.2-rc4 full screen oddities 


On Dec 28, 2008, at 16:27, Viv Kendon wrote: 

>>>> Well, you'd have to switch to space 6... 
>>> Exactly...only once I'm in full screen I can't find a way to do   
>>> that: is there something I'm missing? 
>> 
>> I think the only way is the menubar control.  In System Preferences- 
>> >Spaces, click the option to add a control to the menu bar... 
> 
> I already have that.  In X11 preferences I checked the auto-show   
> menu-bar in full screen mode box (I didn't do that in my previous   
> testing).  And now I can get to different screens while in full   
> screen mode, with a brief flash back into Aqua on the way. 

Have you tried: 

defaults write org.x.X11 fullscreen_hotkeys -boolean YES 

>>> If I go to screen 6 first then cmd-opt-a into full screen, well,   
>>> things just get worse, with the effects mentioned below.  In the   
>>> Spaces preferences I have unchecked the option to have Spaces   
>>> switch to a screen with active windows when selecting an app, but   
>>> this sort of switching still happens, 
>> 
>> Are you using 2.3.1 or 2.3.2_rc4?  2.3.2_rc4 should support that   
>> spaces checkbox. 
> 
> I meant in the Expose+Spaces preferences, at the bottom, the option   
> to have Spaces switch to a Space with open windows for an   
> application if you select that application.  I have that unchecked,   
> I don't want Spaces to do that.  But it still does quite of lot of   
> that sort of switching between Spaces when I didn't ask it to.   
> Especially around X11 windows.  For example... 

Yeah, that's actually hard to do right with Fullscreen X11 since with   
fullscreen, we need to "unhide" the windows... and "unhiding" the   
windows actually causes us to switch to that Desktop since it's   
different than just activating the Application.  I'm not really sure   
that we can support that in a trivial manner (and I'm not sure a   
complicated solution is really worth the cost of implementation) 

<snip/> 

> I even managed at one point to get both the Finder menu bar and the   
> X11 menu bar superimposed, but I don't have a reliable way to   
> reproduce that (yet).  And I just lost focus from X11 entirely while   
> typing 

This has been reported before... and actually, I've seen it happen   
with applications other than X11, (I've lost focus from Mail.app and   
Terminal.app as well while typing) 

<snip/> 

> Another reliable way to get out of full-screen using the menu bar   
> only is to click on the menu bar to drop focus from the X11 window,   
> run the mouse along to the Spaces control so the drop-down appears,   
> then, without selecting anything, run the mouse back to the left so   
> the drop-down goes away.  That lands you back in Aqua-land but with   
> X11 still having focus. 

Can you get back to "X11-land" with a cmd-opt-a there? 

> I think I'm going to stop testing with quartz-wm and set up full   
> screen with a different window manager.  I don't think how X11 full   
> screen works with Spaces is a high priority. But I do care a lot   
> about the focus stealing and would really like that fixed so it   
> doesn't happen except for drastic events like system shutdown.  It   
> is much more intrusive when working in full-screen, especially when   
> it flips you back to Aqua without warning. 

Yeah, I agree with you on that, and I'll buy a case of beer for anyone   
who figures out that bug or comes up with the reproducible test case   
that leads to that bug being squashed once and for all. 

>>>>> (How did I get into this state in the first place?  well, I was   
>>>>> trying to test the cmd-opt-a thing in another app, and   
>>>>> RetroOffice (X11 build of NeoOffice) was open on Space 6...it's   
>>>>> an app bundle so it is natural to start it in a different space.   
>>>>> and yes, it does react to cmd-opt-a, by doing "select all".) 
>>>> Well if it's an X11 application with an app bundle... then it's   
>>>> either got its own X11 server or its using ours... which is the   
>>>> case? 
>>> It uses xquartz, it doesn't bundle its own: 
>>> http://neowiki.neooffice.org/index.php/RetroOffice 
>> 
>> Ans meta-alt-a is a key-sequence in RetroOffice for select-all? 
> 
> Both ctl-a and cmd-a appear to do select all.  I think RetroOffice   
> has some Aqua key bindings as well as traditional X11 key bindings. 

Right, but in X11-land, OSX's cmd is mapped to X11's meta... but as   
you said, it's not getting this key sequence any more, so this issue   
is really moot now. 

>>>>> Finally, something also appears to have changed with the cut and   
>>>>> paste in relation to RetroOffice, I can't find a combination of   
>>>>> pasteboard options that allows the ctr-c and ctl-v that should   
>>>>> work within the app to function properly. 
>>>> How so? 
>>> ctl-c on a selection followed by ctl-v pastes something previously   
>>> copied from elsewhere in X11 land, or whatever cmd-c last copied.   
>>> I have the X11 preferences window open and the only pasteboard   
>>> option I have checked is "enable syncing.  So RetroOffice is not   
>>> copying (or cutting) into the buffer it then pastes from.  But   
>>> I'll have to get back to you after I've had a chance to revert to   
>>> the previous RetroOffice version and test in a more vanilla   
>>> account, log out, reboot, etc., etc.. 
>> 
>> Well, file this bug with Retrooffice then.  If all you have   
>> selected is the 'enable syncing' option and no sub option, that's   
>> the same as it being completely disabled =/ 
> 
> RetroOffice doesn't do bugs, it only exists for debugging   
> NeoOffice.  I'm testing with it because I can't test at work using   
> the Ooo on linux I first had cut+paste problems with, until we are   
> back in the New Year on 5th Jan.  I'll come back on this one once   
> I've reverted to the previous RetroOffice version...it may be it has   
> picked up some NeoOffice code that interacts with the Aqua   
> Pasteboard independently of X11, because cmd-v works to paste in   
> it...hmmm. 

Oh, yeah... interesting point.  It's probably using NSPasteboard   
directly since it's NeoOffice under the hood. 


_______________________________________________ 
Xquartz-dev mailing list 
Xquartz-dev at lists.macosforge.org 
http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20081229/0c5016d4/attachment-0001.html>