[GH-ISSUE #872] DoubleClickInterval could be improved by taking into account last click position #636

Closed
opened 2026-03-04 01:06:39 +03:00 by kerem · 3 comments
Owner

Originally created by @carpii on GitHub (Aug 26, 2023).
Original GitHub issue: https://github.com/rivo/tview/issues/872

I have a table and click different rows with the mouse, but it does not always select the clicked row

This appears to be due to tview.DoubleClickInterval which will interpret any two clicks within 500ms to be a double-click
I can reduce this value, to make clicks more responsive, but then it makes it more difficult to intentionally double-click

Im wondering if its possible for tview to record the position of the first click, and then only consider a second click to be a double-click if its within a certain proximity to the first click?

This would allow us to keep tview.DoubleClickInterval interval at 500ms, but if you click in a different area it would always be interpreted as a click?

Originally created by @carpii on GitHub (Aug 26, 2023). Original GitHub issue: https://github.com/rivo/tview/issues/872 I have a table and click different rows with the mouse, but it does not always select the clicked row This appears to be due to `tview.DoubleClickInterval` which will interpret any two clicks within 500ms to be a double-click I can reduce this value, to make clicks more responsive, but then it makes it more difficult to intentionally double-click Im wondering if its possible for tview to record the position of the first click, and then only consider a second click to be a double-click if its within a certain proximity to the first click? This would allow us to keep `tview.DoubleClickInterval` interval at 500ms, but if you click in a different area it would always be interpreted as a click?
kerem closed this issue 2026-03-04 01:06:39 +03:00
Author
Owner

@carpii commented on GitHub (Aug 27, 2023):

Thanks @digitallyserviced

I appreciate mouse in terminal is never going to be ideal, but tview does a reasonable job of it so far.
My app is making use of lots of dynamically created pages, frames and controls, so the mouse is very convenient whilst developing. I do plan to add full keyboard support eventually, although haven't yet thought this through fully

Regarding your branch, you seem to have made a bunch of useful additions.
I wonder if you have considered isolating these changes and suggesting them as a PR?

Cheers

<!-- gh-comment-id:1694766799 --> @carpii commented on GitHub (Aug 27, 2023): Thanks @digitallyserviced I appreciate mouse in terminal is never going to be ideal, but tview does a reasonable job of it so far. My app is making use of lots of dynamically created pages, frames and controls, so the mouse is very convenient whilst developing. I do plan to add full keyboard support eventually, although haven't yet thought this through fully Regarding your branch, you seem to have made a bunch of useful additions. I wonder if you have considered isolating these changes and suggesting them as a PR? Cheers
Author
Owner

@carpii commented on GitHub (Aug 30, 2023):

Hiya @digitallyserviced

Thanks for the help so far.
Looks like you've done some awesome work on your fork, with lots of new features

I do have plans to dig through your fork, but the project I'm working on right now is fairly long-term, and likely to become a mature project over time.
I'm a little reluctant to switch to an undocumented fork right now, at least until I find some major show-stoppers where I have no other choice (or @rivo decides to stop maintaining the official repo).

So, to be honest, the fork that I have actually pushed to a public repo is a mess and lacking any sort of proper public release In many ways...

No probs. I appreciate it probably developed over time for your own needs, and was never intended to be a public fork

Perhaps I'll end up cherry picking some isolated parts of your fork, so they can be pushed as a PR. I'll let you know if I do this though, so you can submit it from your fork and be credited for it

Sadly any chance of submitting a PR into rivo's tview, I do not see happening... there are tons of PR's that just sit there, which would add great stuff. I just dont want to sit there...

Yeah I understand. It's unclear whether rivo is not interested in PR's, or whether he disagrees with them (or maybe just doesn't have time to dig into them)

Cheers

<!-- gh-comment-id:1699861143 --> @carpii commented on GitHub (Aug 30, 2023): Hiya @digitallyserviced Thanks for the help so far. Looks like you've done some awesome work on your fork, with lots of new features I do have plans to dig through your fork, but the project I'm working on right now is fairly long-term, and likely to become a mature project over time. I'm a little reluctant to switch to an undocumented fork right now, at least until I find some major show-stoppers where I have no other choice (or @rivo decides to stop maintaining the official repo). > So, to be honest, the fork that I have actually pushed to a public repo is a mess and lacking any sort of proper public release In many ways... No probs. I appreciate it probably developed over time for your own needs, and was never intended to be a public fork Perhaps I'll end up cherry picking some isolated parts of your fork, so they can be pushed as a PR. I'll let you know if I do this though, so you can submit it from your fork and be credited for it > Sadly any chance of submitting a PR into rivo's tview, I do not see happening... there are tons of PR's that just sit there, which would add great stuff. I just dont want to sit there... Yeah I understand. It's unclear whether rivo is not interested in PR's, or whether he disagrees with them (or maybe just doesn't have time to dig into them) Cheers
Author
Owner

@carpii commented on GitHub (Sep 1, 2023):

Thanks for the reply. I'll close this ticket, as clearly DoubleClickInterval is not the elegant solution I initially thought it was

So my reason for wanting to stick with the official fork (for now) is mostly due to risk management.
@rivo has a long history of maintaining tview, and whilst there's lots of forks, many of them end up abandoned (the cview fork you mentioned seems to have been abandoned a couple of years ago, unless I'm mistaken).

So I'd prefer not to build an app on top of a more feature-rich fork, if it means I'm painting myself into an unmaintained corner a few years down the line. I've learnt this lesson many times in my long career as a software eng!

I may end up creating my own fork eventually, but I'd prefer to be familiar with each downstream change, rather than just switch to a heavily modified fork, and be left troubleshooting every problem myself

I am interested to hear more about your project, and if I could help at all.

It's primarily an accounting app, aimed at personal, freelancers, and SOHO usage.
MySQL backed, but with an emphasis on automated rule-based OFX/QIF/CV imports for its transaction source, plus a JSON-based CLI interface for batch processing, categorising, reporting etc.

Later versions may include a REST API and web frontend using the same backend JSON API, plus investment tracking.
I need this software for my own use, but whether it evolves beyond what I need, we'll see :-)

<!-- gh-comment-id:1703445528 --> @carpii commented on GitHub (Sep 1, 2023): Thanks for the reply. I'll close this ticket, as clearly `DoubleClickInterval` is not the elegant solution I initially thought it was So my reason for wanting to stick with the official fork (for now) is mostly due to risk management. @rivo has a long history of maintaining tview, and whilst there's lots of forks, many of them end up abandoned (the `cview` fork you mentioned seems to have been abandoned a couple of years ago, unless I'm mistaken). So I'd prefer not to build an app on top of a more feature-rich fork, if it means I'm painting myself into an unmaintained corner a few years down the line. I've learnt this lesson many times in my long career as a software eng! I may end up creating my own fork eventually, but I'd prefer to be familiar with each downstream change, rather than just switch to a heavily modified fork, and be left troubleshooting every problem myself > I am interested to hear more about your project, and if I could help at all. It's primarily an accounting app, aimed at personal, freelancers, and SOHO usage. MySQL backed, but with an emphasis on automated rule-based OFX/QIF/CV imports for its transaction source, plus a JSON-based CLI interface for batch processing, categorising, reporting etc. Later versions may include a REST API and web frontend using the same backend JSON API, plus investment tracking. I need this software for my own use, but whether it evolves beyond what I need, we'll see :-)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/tview#636
No description provided.