[Xquartz-dev] XQuartz 2.6.0_rc1 (for Leopard and Snow Leopard)

[doh123]

Thanks for the info!

I have screen capturing working right (for Wineskin anyways), and I'm able to use CMD+Opt+A to switch out of fullscreen to a unmovable window in Rootless, then I'm also able to press that same key combo in rootless to take it back to fullscreen at the last resolution if there was one.  Going back in was the problem and my solution was very hacky and very Wineskin specific, so its not really useful for Xquartz itself though...

I also add some other things, but its all Wineskin specific...

The last patch file I had attached though adds Display capturing exactly the same as its describes that Crossover does it, except the escape sequence is CMD+Opt+A (cuz it was already in there), and you cannot get back to fullscreen unless the Windows program tries to change resolutions again...  You may want to use the same method to add for an Xquartz update.  Its basically nearly exactly the same as the original capture patch, but changing the window levels for fullscreen.

now Cider seems to use CMD+Enter... and it never seems to be a problem, but I guess thats because they aren't really using X... so maybe they have more control?  I have Wineskin make Alt really be the Alt key, not CMD, so it might not be an issue either for me.

Would be nice to finally have a native quartz driver for Wine, but Xquartz is doing nicely right now  :-)  All the major shortcomings have been pretty much fixed... only the old extension for letting Wine control gamma appears to be missing, but I'd say wait for Wine to update to using RandR for gamma, then it might be easier to add in to quartzRandR...


On Jan 25, 2011, at 7:47 PM, Ken Thomases wrote:

> On Jan 24, 2011, at 12:32 PM, Jeremy Huddleston wrote:
> 
>> If we are to do something like this, I'd like to maintain consistency with what CodeWeavers does.  How have they addressed this problem with fullscreen games?  Do they have a key sequence to switch applications / hide / minimize while captured?  If so, we should adopt the same sequences.
> 
> We do not support those actions, currently.  We have an escape hatch if something leaves CrossOver stuck in full-screen mode (e.g. a game switches modes and then hangs or crashes).  That's Command-Option-R, the keyboard shortcut for our Window > Restore Display menu item.  It's one-way; it leaves full-screen mode (and CrossOver remains the active app).  There's no way to return to the full-screen mode that the game was using, unless the game itself re-sets the desired mode.
> 
> For us, since we focus on running Windows programs using Wine, I try to avoid most keyboard shortcuts that use Command as the only modifier.  We'd like to leave those available for issuing Alt-based menu shortcuts to the Windows program.  So, I'd avoid Command-H so a user can issue Alt-H to the Windows program, if necessary.  Combinations which use both Command and Option should be safe, since those avoid any analog that a Windows program might use.
> 
> Command-Tab is an exception to that guideline.  It would map to Alt-Tab which already has the same meaning on Windows as Command-Tab does on Mac OS X, so no Windows program would expect to receive it.  (We also make an exception for Command-Q, since it's an important escape hatch, too.)
> 
> Regards,
> Ken
> 
> 
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>