Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
aadcg opened this issue Jul 15, 2022 · 5 comments
Open

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

aadcg opened this issue Jul 15, 2022 · 5 comments
Labels

Comments

@aadcg
Copy link
Member

aadcg commented Jul 15, 2022

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 aadcg added the low label Jul 15, 2022
@Ambrevar
Copy link
Member

Ambrevar commented Jul 18, 2022

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.

@aadcg
Copy link
Member Author

aadcg commented Jul 18, 2022

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.

@lansingthomas
Copy link
Contributor

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.)

@aartaka
Copy link
Contributor

aartaka commented Jan 10, 2023

Yes, makes total sense!

@aadcg
Copy link
Member Author

aadcg commented Jan 10, 2023

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

4 participants