[Top][All Lists]

[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]