[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
bug#5985: 23.1.96; Mac OS X: Frames in other spaces erroneously thought visible
Tue, 17 May 2016 20:05:20 +0100
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
> (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
Unless someone happens to just know?
|[Prev in Thread]
||[Next in Thread]|
- bug#5985: 23.1.96; Mac OS X: Frames in other spaces erroneously thought visible,
Alan Third <=