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

Weird tab bar behavior #3417

Open
JoeKar opened this issue Aug 4, 2024 · 1 comment
Open

Weird tab bar behavior #3417

JoeKar opened this issue Aug 4, 2024 · 1 comment

Comments

@JoeKar
Copy link
Collaborator

JoeKar commented Aug 4, 2024

The interaction between the tab bar and buffer window/pane seems to be seamless, which creates some cases where the user could be confused:

  • mark a text section with the mouse while still pressing the left mouse button to move the selection up and reach a tab != the active one
    • the inactive will become the active one
      • my expectation is, that the tab bar should ignore these "triggers"
      • "easy to fix" (ignore while the active tab still keeps the press), but could be just half of the truth since there are other strange cases
  • press the left mouse button over one tab and move the mouse while still pressing the button
    • the next hovered tab becomes active
      • intended?
    • when the tab bar is left into the buffered text within the same action then the buffered text will be selected till the mouse button is released
      • I don't expect that to happen, because the press was done within the tab bar

Version: 2.0.14-dev.245
Commit hash: 2259fd1
OS: Debian testing (trixie)
Terminal: GNOME Console aka KGX 46.0

@glupi-borna
Copy link
Contributor

I have been bitten by this so many times! I think the simplest solution would probably be to track if the mouse press was initiated within the bounds of the tab, and only handle the release event if it happens on that same tab. The trouble is, from what I can tell, that tcell's event reporting is pretty minimal, and we would need to implement our own mouse press-release tracking.

At first blush, I thought we could just do the same handling in TabList that we do in BufPane, but I'm now pretty certain that it wouldn't work, because the state would not be shared between those two structs, unless we did the legwork to synchronize it, but that would likely open up a whole slew of new edge cases that we would have to consider.

The other solution would be to rework event handling to track the receiving Tab/BufPane for press events, and then only dispatch the next release event to that same Tab/BufPane. This would likely be a larger rewrite, but we could use it to greatly simplify mouse handling in bufpane.go, and generally make mouse handling more robust.

Is there a simpler/more robust solution that I'm not seeing here?

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

No branches or pull requests

2 participants