emacs-devel
[Top][All Lists]
Advanced

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

Re: "Final" version of tty child frames


From: Gerd Möllmann
Subject: Re: "Final" version of tty child frames
Date: Sun, 12 Jan 2025 09:57:02 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Jared Finder <jared@finder.org>,  Eli Zaretskii <eliz@gnu.org>,
>>   emacs-devel@gnu.org
>> Date: Sun, 12 Jan 2025 08:36:16 +0100
>> 
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> 
>> > So the child is invisible after the last C-l. Whether or not it becoming
>> > visible again is something else to consider later, I think.
>> 
>> Just has the thought that this might be the wrong angle to look at the
>> problem because I think there is something missing on ttys which GUIs
>> have: proper focus management.
>> 
>> I imagine that on a GUI we get events as needed from the window manager
>> to change the focus frame to what the window manager wants. I think that
>> part is missing on ttys.
>
> I think on TTYs, change of focus should be triggered by either a mouse
> click (if there is a mouse) or by explicitly selecting a frame (or
> maybe by raising it).
>
>> Or is select-frame-set-input-focus a complete replacement for that?
>
> In that function, we have this:
>
>   (select-frame frame norecord)
>   (raise-frame frame)
>   ;; Ensure, if possible, that FRAME gets input focus.
>   (when (display-multi-frame-p frame)
>     (x-focus-frame frame))
>
> Does raise-frame change input focus to the frame we raise on TTYs?

That should land in tty_raise_lower_frame which only changes the
z-order. It does nothing concerning the focus. raise-frame itself
doesn't do much more than call that hook function.

> display-multi-frame-p currently reports nil on TTY -- is that correct?

Its doc says "Return non-nil if DISPLAY is a graphic display", so I
think we shoudn't change that for ttys, for compatibility reasons.

> What does x-focus-frame does on GUI frames, and does that make sense
> on TTY?

Hm, on NS I think this is 

static void
ns_focus_frame (struct frame *f, bool noactivate)
/* --------------------------------------------------------------------------
     External (hook)
   -------------------------------------------------------------------------- */
{
  struct ns_display_info *dpyinfo = FRAME_DISPLAY_INFO (f);

  if (dpyinfo->ns_focus_frame != f)
    {
      EmacsView *view = FRAME_NS_VIEW (f);
      block_input ();
      [NSApp activateIgnoringOtherApps: YES];
      [[view window] makeKeyAndOrderFront: view];
      unblock_input ();
    }
}

static void
ns_raise_frame (struct frame *f, BOOL make_key)
/* --------------------------------------------------------------------------
     Bring window to foreground and if make_key is YES, give it focus.
   -------------------------------------------------------------------------- */
{
  NSView *view;

  check_window_system (f);
  view = FRAME_NS_VIEW (f);
  block_input ();
  if (FRAME_VISIBLE_P (f))
    {
      if (make_key && !f->no_accept_focus)
        [[view window] makeKeyAndOrderFront: NSApp];
      else
        [[view window] orderFront: NSApp];
    }
  unblock_input ();
}

What that does exactly I don't know, but it reads like it could do
something (makeKeyAndOrderFront) that changes both input focus and
z-order (?).



reply via email to

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