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.

Sign up for GitHub

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

Jump to bottom

Reimplement multi window logic #3510

Open
aadcg opened this issue Sep 19, 2024 · 2 comments
Open

Reimplement multi window logic #3510

aadcg opened this issue Sep 19, 2024 · 2 comments
Labels
4-series Related to releases whose major version is 4. ffi Renderer-specific quirks.

Comments

@aadcg
Copy link
Member

aadcg commented Sep 19, 2024 •
edited
Loading

As per the API of version 3, multi window support is broken by design. The root of the issue is that the same buffer can't be shown in multiple windows. There is no indication that WebKitGTK doesn't allow it, so it is unclear why this isn't implemented.

Find below 3 perspectives on the manifestation of the issue:

  1. Start Nyxt and call (ffi-window-set-buffer (window-make *browser*) (current-buffer)). Note that the new window is blank.
  2. What happens if the window count surpasses the buffer count?
  3. Take Nyxt with a single window and two buffers. Then create a window and call switch-buffer. Note that this results in swapping buffers across the windows. From a UI's perspective, this behavior is unsettling at best (not to mention that the window title is not properly handled).
output.mp4

For version 4, the root of the issue must be addressed for the WebKitGTK port.

Additionally, ffi-window-set-buffer should handle slots active-buffer, last-access and hook window-set-buffer-hook. It should be possible to drop window-set-buffer and rely exclusively on ffi-window-set-buffer-hook.
@aadcg aadcg added 4-series Related to releases whose major version is 4. ffi Renderer-specific quirks. labels Sep 19, 2024
@aadcg aadcg self-assigned this Sep 19, 2024
aadcg added a commit that referenced this issue Sep 19, 2024
@aadcg
Revert "buffer: Delete dummy-buffer-p."
c8f5f0e 
This reverts commit d027b31.

It turns out that the changes introduced in
d027b31 change the logic.

Indeed window-set-buffer is a sea of obscure incantations and bad design.

See #3510.
@aadcg aadcg changed the title ffi-window-set-buffer behaviour on multi window setting Reimplement multi window logic Sep 20, 2024
aadcg added a commit that referenced this issue Sep 20, 2024
@aadcg
Simplify ffi-window-set-buffer.
b68dbef 
Delete window-set-buffer indirection.

Delete dummy-buffer-p (breadcrumbs from ancient refactors).

Note that from this commit on, multi window support on WebKitGTK is unusable.
This is done on purpose.  The way is being paved to reimplement the feature, by
simplifying the API.

See #3510 for a detailed discussion.
@aadcg
Copy link
Member Author

aadcg commented Sep 20, 2024 •
edited
Loading

The core issue must still be solved, but something tells me that there are other issues regarding multi window support.

Regardless, this will become a priority later.

@aadcg aadcg removed their assignment Sep 20, 2024
@aadcg
Copy link
Member Author

aadcg commented Sep 20, 2024 •
edited
Loading

something tells me that there are other issues regarding multi window support

drawing

#3514

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
4-series Related to releases whose major version is 4. ffi Renderer-specific quirks.
Milestone
No milestone
Development

No branches or pull requests
1 participant
@aadcg