bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5985: 23.1.96; Mac OS X: Frames in other spaces erroneously thought


From: Alan Third
Subject: bug#5985: 23.1.96; Mac OS X: Frames in other spaces erroneously thought visible
Date: Tue, 17 May 2016 20:05:20 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.93 (darwin)

Hagmonk <address@hidden> writes:

>> On OS X, enable Spaces. (Note to those who don't use Macs: Spaces are
>> a bit like virtual desktops in many X11 window managers.) Run emacs
>> and create two or more frames. Move some frames to different spaces.
>> 
>> Evaluate (visible-frame-list).
>> 
>> Expected result: Only frames in the current space should be listed.
>> Actual result: All non-iconified frames are listed.
>> 
>> As a side effect, C-x 5 o (other-frame) can select a frame in a
>> different space. Also, (frame-visible-p) evaluated in a frame in a
>> different space will return t.
>
> It’s not clear to me what the desired behavior should be here. From the 
> documentation:
>
> ---
> (frame-visible-p FRAME)
>
> Return t if FRAME is "visible" (actually in use for display).
> Return the symbol ‘icon’ if FRAME is iconified or "minimized".
> Return nil if FRAME was made invisible, via ‘make-frame-invisible’.
> On graphical displays, invisible frames are not updated and are
> usually not displayed at all, even in a window system’s "taskbar".
> ---
>
> Minimizing a window does result in the symbol “icon” being returned.
> However, OS X doesn’t have the notion of making an individual window
> invisible. Command-H will hide all windows for an application. And
> although there is no “taskbar” if you invoke mission control to see
> available windows, the window remains “displayed" in that sense. In
> fact while mission control is active, the app’s thumbnail is a live
> representation of the app’s window state (try playing a movie and then
> invoke mission control from another space)
>
> It seems if OS X had the notion of hiding an individual window, frame
> visibility could be keyed off that window state. Without that, it’s
> not clear how this would be supported without changing the definition
> of visibility used by frame-visible-p.
>
> I’m inclined to suggest this behaves as intended. 

And I'm inclined to agree. However, if someone with access to an X
system with virtual desktops (or similar) could test how it behaves,
that would be helpful in determining exactly what the correct behaviour
should be.

Unless someone happens to just know?

-- 
Alan Third





reply via email to

[Prev in Thread] Current Thread [Next in Thread]