Replies: 11 comments 12 replies
-
|
Ok, then for version 3.0 https://go.dev/blog/module-compatibility ;) |
Beta Was this translation helpful? Give feedback.
-
|
The whole point of version 3 is that you can do breaking changes. |
Beta Was this translation helpful? Give feedback.
-
|
The whole point of Go is to be as compatible as possible that's all I'm saying. Here another interesting piece. |
Beta Was this translation helpful? Give feedback.
-
|
May I ask why you are planning to remove Regarding all the breaking changes. I'd say go for it! If people need this backwards compatibility, the README could simply link the features that are removed with v3, so people know which version to use. Given go uses tags for versions, changes can easily be backported via a separate branch anyway, in case any heavy bugs occur. |
Beta Was this translation helpful? Give feedback.
-
|
PostEvent is brittle. There are non-blocking forms, but the blocking API winds up creating a potential application deadlock. I'd really prefer that users get this via channel, and then they can make a clear decision about whether or not to block, or to multiplex on a select statement as they need. |
Beta Was this translation helpful? Give feedback.
-
|
If I switch to a version 3, I will probably relegate maintenance for version 2 to critical fixes only. I have zero interest in doing feature work for multiple versions at once. Even non-critical bug fixes probably won't get backported. |
Beta Was this translation helpful? Give feedback.
-
|
Ah yeah ... right, the channel could be used for both posting and reading, this way tcell wouldn't even have to know about the simulated events. I didn't think that far. Regarding not backporting, that's absolutely fair :D |
Beta Was this translation helpful? Give feedback.
-
Would it be possible to expose the Events channel directly? Are there any disadvantages to doing so? This is a read-only channel because we probably don't want the user closing this channel. We use
We should consider using a |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. This API evolved before go Contexts existed. :-) |
Beta Was this translation helpful? Give feedback.
-
|
I suspect we could expose the Events channel.... although I need to refresh my brain to ensure that there were no compelling reasons for not doing so. One key thing is that if a legacy user is using the PollEvent api, then that might be confused by another consumer pulling from the Events channel. I'm half inclined to just expose the channel and insist that users consume from that. It's nicer that way. We do need a way for the application to signal a graceful shut down for us. I guess a context would do. |
Beta Was this translation helpful? Give feedback.
-
|
In v3 we exposed the channel directly, screen.EventQ(). |
Beta Was this translation helpful? Give feedback.
-
|
Is there a roadmap? Any idea how long it will take until 3.0 comes out? I've read that the author of Vaxis would like to help with kitty/sixel/ modern TUI stuff. |
Beta Was this translation helpful? Give feedback.
-
|
3.0 already is out. No special things for sixels but the kitty keyboard protocol is included. |
Beta Was this translation helpful? Give feedback.
-
|
It would be very easy to reduce tcell's memory consumpition by changing these types: type Color uint32 and reordering fields in Style so that ulStyle would be after ulColor. After this change Style would be 48 instead of 72 bytes and cell 144 instead of 192 bytes. This would reduce the memory consumption of a fullscreen window from 4 MB to 3 MB for me. I also think that url and urlId don't belong to Style (not very useful in themes). These could be parameters to Screen.PutUrl or something like that. |
Beta Was this translation helpful? Give feedback.
-
|
We shrunk memory quite a bit by making this sort of change. But the url and urld are still part of the style. The alternative would have been to make them a separate field on the cell. |
Beta Was this translation helpful? Give feedback.
-
|
Now that Style.Decompose is gone I noticed my color picker (just a toy for testing) can't be updated to v3. I can use screen.Get to get style but can't inspect it. Other problem I had was with a listview where selected item has same attributes as unselected items but different fg/bg colors. I fixed this by replacing the selected style with selected fg and bg colors. It is quite weird that there are GetUnderlineStyle and GetUnderlineColor but no getters for other fields. :) Btw Style.Normal doesn't just clear attributes but url and underline style/color too. |
Beta Was this translation helpful? Give feedback.
-
|
I need to look at this because clearly we need some of these capabilities. |
Beta Was this translation helpful? Give feedback.
-
|
What would be the alternative to |
Beta Was this translation helpful? Give feedback.
-
|
Attributes() gives some of it. We need GetColors() or something like that, and maybe others. |
Beta Was this translation helpful? Give feedback.
-
|
#880 - this adds a individual accessors for the parts of style. |
Beta Was this translation helpful? Give feedback.
-
|
The views package is still present, as is the character set support. For now. |
Beta Was this translation helpful? Give feedback.
-
|
I also kept KeyCtrlA through KeyCtrlZ -- it was too painful to remove them (for now.). Maybe in tcell v4. |
Beta Was this translation helpful? Give feedback.
-
|
In tcell v2, I created and used https://github.com/noborus/tcellansi to reproduce the tcell screen after exiting. However, this package is not very efficient and is insufficient. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I think it's time to start thinking about what tcell 3.0 might look like.
There are many changes I'd like to make, which require potentially breaking changes. It's time to discuss what those would be, and solicit feedback.
Key Encoding Changes
First off, we need to remove definitions for
KeyCtrl[A-Z]etc. Those won't work well going forward because they overlap with other key definitions, and were based on compatibility of the ASCII encodings. These already don't work that way on Windows, but we have a serious problem where e.g. KeyCtrlH occupies the same encoding as KeyBackspace (these are aliases for each other). This happens with a few of these, and is a throw back to old style TTYs.I would discard the
KeyCtrlXXXsymbols altogether. Modified keys would be presented as such. For the times when we have an overlap of e.g. Ctrl-I is TAB, we would just report as TAB. On most modern terminals these would be unambiguously handled by the CSI-u encoding scheme proposed in #671. (This is already the case on Windows.)Retiring Termbox compatibility
The termbox compatibility layer is abandonware. People who want to convert to tcell gradually would be able to use version 2.x, but moving to 3.x they would need to actually update their code. I don't think many (if any) projects are actually using the termbox layer anyway. There are semantic shortcomings that would be difficult to overcome if we tried to keep this compatibility, and I don't think it's worth doing for termbox.
Retiring support for the legacy Windows console API
At least for output (not sure about input), the VT mode on Windows is vastly superior. This might hurt Windows versions before Windows 10. But Windows 8 is EOL.
Adopting modern Go.
We would move to probably Go 1.20 or newer. This could allow using generics for example, or possibly other things. We can't support the old versions of Go forever.
Removing the PollEvent based API.
This is probably controversial, and would require many (most) applications to change. The
PollEventAPI is awkward and not very idiomatic for Go. TheChannelEvents()API (possibly with some refinement) would become "standard".PostEventandPostEventWaitespecially need to be removed.Retire support for ancient terminals
I'm specifically talking about the ancient Wyse, TVI925, and similar. We simply don't see them in the wild, and we can't test them. While the idea of having good fallbacks and a rich terminal database was a worthy ideal, in practice it hasn't been useful, and keeping this support means we have bloated terminfo databases that nobody can use. Probably there are some other outliers, like beterm, that could be removed without much of anyone noticing.
Revisiting the API around SetContent, GetContent
Today these are use a single rune, and optional array of combining rules. It would be simpler by far to just make this a string. The rule is that the first fully composed glyph from the string would be displayed. Possibly we could actually give a feedback about how many bytes were consumed from the string.
Remove views framework
The "views" package was an early effort at building a widget set on top of tcell. It sort of works, but it's also sort of abandonware. There are others that have done a better job here. And maybe even views could move into its own package and be expanded separately.
Combining HideCursor, ShowCursor, SetCursorStyle somehow...
This API feels like it evolved organically -- it did -- and could probably be revisited in some way.
Retiring CharacterSet API
Nobody has ever used this I think. It does nobody any good. We need to remove it.
Summary
This is a lot of potential breaking change. But we could do it if we had a major release boundary. We'd need a migration guide of course. But I don't think that would be too hard to do.
Beta Was this translation helpful? Give feedback.
All reactions