nyxt icon indicating copy to clipboard operation
nyxt copied to clipboard

`focus` is a concept that only applies to `window` and `input-area`

Open aadcg opened this issue 1 year ago • 2 comments

With respect to buffers, it makes little sense to say which one has the focus.

There are buffers and, at any moment, there's a single current-buffer (which may not correspond to the displayed one).

To stress the fact that buffers can also be switched to, i.e. bring them to display, it would be better to use concepts such as background/foreground.

I suggest switching from:

(define-ffi-generic ffi-window-set-buffer (window buffer &key focus))

to:

(define-ffi-generic ffi-window-set-buffer (window buffer &key foreground))

If you're wondering about set-current-buffer,

(defun set-current-buffer (buffer &key (focus t)) ...)

, there are only three of the following calls (set-current-buffer buffer :focus nil), which should probably be replaced by (with-current-buffer ...).

In other words, I'm saying that the focus key of set-current-buffer should be deprecated.

aadcg avatar Jul 15 '22 15:07 aadcg

Note however that :focus nil is actually a GTK-implementation detail. It's not about displaying the buffer in the foreground or not, but whether the widget is "grabbed". So yes, focus applies to buffer in the sense that if they have a selected HTML input, then this is where the user is going to type.

In buffer-source, we have

   (prompter:selection-actions #'(lambda (buffer)
                                   (set-current-buffer buffer :focus nil)))

which is meant to effectively display the buffer in the foreground, but without focusing the GTK widget so that the user keeps typing in the prompt-buffer.

All that said, the naming and the API is confusing. It could be improved, but with-current-buffer won't work here because it does not display the buffer.

Ambrevar avatar Jul 18 '22 12:07 Ambrevar

Oh I see!

The issue is that we use the word buffer, but it's actually a GTK object that behaves mostly like what we'd call a window.

aadcg avatar Jul 18 '22 17:07 aadcg

This came up in my ongoing exploration of rethinking the prompt area UI (#2687) and I think it belongs here.

Issue PA 1 - inconsistent buffer focus selectors

I see this as an issue because the interaction:

  1. is not consistent with the expectation users bring from other apps
  2. does not have a visible status
  3. causes errors in other places when users type things in random websites intending to type in the Prompter of our Prompt Area

Make sense? (I tried to explain this in the recently closed #2706, but I was not really getting the issue yet.)

lansingthomas avatar Jan 09 '23 22:01 lansingthomas

Yes, makes total sense!

aartaka avatar Jan 10 '23 08:01 aartaka

@lansingthomas I've moved your valuable comment here (see Problem 3).

The purpose of this issue is slightly different so, with your authorization, I'd like to remove your comment from here so that we keep discussions focused.

aadcg avatar Jan 10 '23 10:01 aadcg