[Xquartz-dev] Fully self contained Xquartz.app?

[doh123]

I doubt it... no iCal for sure... stripped down accounts running hardly anything... and it doesn't switch away from Xquartz... its only the X11 active window that lose focus... and if its in fullscreen, the whole fullscreen hides, but its still Xquartz as the active app.

On Jul 15, 2010, at 5:03 PM, Jeremy Huddleston wrote:

> This sounds like it may be this issue:
> 
> http://xquartz.macosforge.org/trac/ticket/58
> 
> 
> On Jul 15, 2010, at 12:03, Bob wrote:
> 
>> Yes, I usually work in fullscreen mode on my laptop and this is a huge
>> annoyance.  It happens intermittently about once an hour for me and
>> this is using quartzwm with terms and emacs (so I don't think your
>> lack of a WM is the issue).  I seem to remember a long time ago there
>> was some discussion of this and it was stated that it is caused by
>> things outside of X11 and thus hard (seemingly impossible?) to fix.
>> Also, I think it is related to the momentary loss of focus seen in
>> rootless mode but it is far more jarring in fullscreen mode (and seems
>> to last much longer).
>> 
>> I do think that if the developers worked in fullscreen mode for a few
>> weeks this would annoy them enough to take action.
>> 
>> Bob
>> 
>> 
>> On Thu, Jul 15, 2010 at 8:12 AM, doh123 <doh123 at doh123.com> wrote:
>>> I notice a very similar issue, but I only recently was able to reproduce it using normal Xquartz.app... but its completely random, sometimes It wont happen for a long time, then sometimes it'll happen often.
>>> 
>>> Basically, when in fullscreen mode, with no window manager running (playing games in Wine), all of a sudden for no reason (even if I'm not touching the machine) it'll just switch from the fullscreen back to the desktop... Xquartz will still be the active app.  When it does do this, sometimes a second later it automatically switches back to the fullscreen, sometimes it doesn't.  Sometimes it doesn't because I was in middle of clicking or typing and when it switches back, I click at the wrong time and it makes me click on the desktop, then I have to click back on Xquartz to get back to fullscreen.
>>> 
>>> I haven't tested it while running any window managers, because fullscreen games on a fullscreen Xquartz look and run normal with no window manager running.  I'm not sure I've ever noticed and issue when running rootless, but I'm in fullscreen most of the time.
>>> 
>>> On Jul 15, 2010, at 4:44 AM, Eeri Kask wrote:
>>> 
>>>> Am 07/15/2010 12:42 AM, Jeremy Huddleston <jeremyhu at apple.com> schrieb:
>>>>> On Jul 14, 2010, at 02:45, Eeri Kask wrote:
>>>>>> (Because of the latter (window entry/exit and focus events most
>>>>>> troublesome) it is hard to use Xquartz for own X11-applications
>>>>>> development because nobody knows where to look for problems.  In
>>>>>> this context xcb can be questioned too of course.)  :-(
>>>>> 
>>>>> I don't think I have an open bug report about these entry/exit/focus event issues...
>>>> 
>>>> 
>>>> No, definitely not by me.
>>>> 
>>>> I haven't yet managed to gather sufficient information about some
>>>> regular pattern how these enter/leave/focus issues can be triggered
>>>> deterministically willfully.  Currently it looks like it is kind of
>>>> understanding some stochastic process by observation...  :-)
>>>> 
>>>> The most I can say today, it seems window stacking order changes or
>>>> unmap/map requests result in effects which can be explained like the
>>>> misordered delivery or dropping of some enter/leave events, which
>>>> then understandably often results in a mess in focus management; let
>>>> it be focus by PointerRoot by the X-server or by assigning by some
>>>> window manager implementing sloppy-focus-follows mouse.
>>>> 
>>>> If enforcing stacking order change by some special client
>>>> application tied to some "passive-grab/passive-release-grab" hotkey
>>>> then it looks like the execution of lowering the affected window
>>>> sometimes (i.e. again randomly; not always) finishes first and then
>>>> PointerRoot focus (or even enter-window) assignment by the X-server
>>>> still uses the stacking order of the pre-lowering screen state or
>>>> something... resulting in focus falling into a window which is not
>>>> ontop.  (In few cases the server even has reported the pointer being
>>>> in a window which is perceptually verifiably covered by some other
>>>> window.)
>>>> 
>>>> Therefore all in all now I am only able to complain but still keep
>>>> observing and try creating a reproducible deterministic triggering
>>>> of some of these situations... prior to reporting a bug.
>>>> 
>>>> 
>>>> E.g. exposure events cause trouble too, esp. in connection with the
>>>> XShape- and AppleWM extensions; but this results only in wrongly
>>>> painted screen content, not ending up typing into a wrong window.
>>>> 
>>>> (P.S.  If it is relevant, I run X in fullscreen mode all day (not
>>>> using click-to-point focusing), returning into Aqua only on logout;
>>>> so how far might possible Aqua involvement go in these problems is
>>>> uncertain...)
>>>> 
>>>> Greetings,
>>>> 
>>>>   Eeri Kask
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xquartz-dev mailing list
>>>> Xquartz-dev at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xquartz-dev mailing list
>>> Xquartz-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>> 
>> 
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
> 
> 
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>