emacs-devel
[Top][All Lists]
Advanced

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

Re: mouse-autoselect-window


From: martin rudalics
Subject: Re: mouse-autoselect-window
Date: Fri, 07 Sep 2007 20:56:31 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

We do x_make_frame_invisible in this case.  Would that fail?


I'm not sure what you mean by the reference to x_make_frame_invisible.

Sorry.  I meant x_make_frame_visible.

I am referring to the following issue: Emacs wants to switch focus to a
particular frame e.g. because the user ran the command (next-error) and
the relevant file is already being shown in another frame (the "new
frame").  If the new frame is already visible (i.e. mapped), then one of
the hacks used by (select-frame-set-input-focus) may or may not succeed,
depending on the window manager.  (There is also the issue that
select-frame-set-input-focus is not used in all of the cases that is
should be.)

Which cases do you mean here?

If, however, the new frame is unmapped and iconified, then
select-frame-set-input-focus definitely will not work.

That's what x_make_frame_visible is supposed to achieve.

Note that once a client offers a top-level window to the window manager
to be managed (bringing it out of the Withdrawn state),

How differs the "withdrawn" from the "iconified" state"?

it will remain
managed by the window manager until the client explicitly moves it to
the withdrawn state.  While it is managed, it will either be in the
visible state, meaning it is mapped (and presumably at least partially
visible), or it will be in the iconic state, and unmapped.  It is the
window manager that decides at all times in which of these two states a
window will be, although a client can request a transition from visible
to iconic or from iconic to visible.  The window manager should mark a
window as iconified whenever it will not be visible for any reason, so
that the client knows that it need not waste any resources redrawing it;
a window should be marked iconified, therefore, when it is
shaded/"rolled up" or not part of the current workspace, or on an
unselected tab, in addition to when the user explicitly "iconifies" it.

In my tiling window manager, for instance, if a new window is opened or
selected, if there is not enough space, the least recently used window
will be automatically shaded/"rolled up", and therefore iconified.  I
would still like it to be possible, though, for emacs to focus an
iconified frame (and cause it to become visible).

But it should not make any difference for the client whether the window
was iconified explicitly or just "shaded".





reply via email to

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