-
Notifications
You must be signed in to change notification settings - Fork 257
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
Separation of Core and UI #262
Comments
@martanne I'm ready to work on this during the coming June. What are your thoughts? If you don't have any plans to separate the UI out, then do mention and close this issue... |
Although I'd say that before attempting this, a proper test suite have to be ready. |
I think the current code base is already mostly structured that way, I certainly tried to keep separate things separate. There certainly exist some warts. A general ui should not directly have to depend on libtermkey (as is currently the case). Also the rendering code in Feel free to improve it. While I personally don't have an interest in alternative GUIs, trying to add an EFL (or GTK) based UI would surely highlight some more deficits of the current architecture. Also the necessary integration into a proper main loop could prove to be useful for async I/O related activities. Also the most interesting section of your post, the "Core API" is marked as TODO ... |
Great!! 👍
Neither do I, but that may be because I haven't found one that integrates with terminals the way I would like.
That needs a lot of thinking. I'm getting a few ideas but it doesn't seem general enough (considering that it should work across languages). For single-file single-view part may not be that hard, but we'll have to support multiple files & windows at some level. If the design fundamentally cannot accommodate inter-widow interactions (same-file-multi-views, diff-mode, locked-scrolling etc.), then it would be a lot of pain to change it in future. One major thing I noticed is that the pieces are presented as a linked list. I loved the design, but linked lists are not a great choice when you consider sharing access. I've been thinking about writing a CoW Binary tree with some specific properties to keep track of line numbers. But I would be a madman to try making it in C (it would literally take years to make it memory&thread-safe). I'm referring to Rust, of course. And thinking further, I'm actually interested in rewriting this in Rust (which would actually make me a madman!)... |
OK, what is this ticket good for? Does anybody work towards it? |
Assumptions: Single window, single file
Concerns of Core
Concerns of UI
Inputs to Core
Outputs from Core
:
or/
) (optionally overridable by UI)Unresolved
Low-level details
Core API
TODO
The text was updated successfully, but these errors were encountered: