Replies: 2 comments 12 replies
|
@dezza What do you think? You seem to be well versed in this #12671 (comment) |
|
Yes I would not recommend using GtkApplication, from my experience it results in long startup times. However, how would this make the Vim GTK GUI testable? Also are you working on something similar to what I said, I don't want to stomp on your progress. |
|
No worries. I just tried to solve it I like a good rabbithole - I did use LLM/agent here just to prove to myself it did not explode in complexity. To my surprise it did not. There is 1 missing aspect to GUI testable is just a headless wayland (weston headless, iirc). But all non-GUI code gets way more testable of course, the main code change is rewiring GUI to event core in remaining GUIs. |
So something like comparing an existing image of the GUI to the current snapshot of the GUI being tested?
So what you are saying is to refactor the entire common GUI code into something like a server (Vim) and client (GUI interface) design? How would that work for the Win32 GUI? Also what do you mean by event core? Thanks |
Xvfb(X11) is currently only tested headless gui code and its very minimally tested. Weston headless is the (missing) Wayland counterpart to that. Its trivial.
Not exactly like NeoVim - still "native" GUI so to say, with less architectural complexity. (Yes Win32 is part of that) The main thing is keys! Input, terminal ansi esc codes - all this background state which is part of event-core. You understand? (... + jobs,ch,autocmd etc) |
|
Essentially something similar to Neovim's architecture (UI's communicate to the Neovim instance via RPC), however instead everything is internal and in the same process?
If I understand, doesn't Vim already do this via What would the event core interface look like, maybe we can take notes from Neovim. I will take a shot at prototying a working refactor maybe. |
|
It is similar in that it simply(caveman) explained is a transport belt for events. But the similarities stop there cuz NeoVim has server! Vim has struct. NeoVim adopts libuv, but Vim retains the existing platform-handling code. I was extremely surprised (and happy) to see that the complexity did not escalate while refactoring. Basically what I did was tag multiple refs:
The thing is I was pleased to see that the PRs could keep modularity, they did not get interwined deeply.. The modular PRs are reviewable and not even slightly convoluted, its merely an abstraction. All mentioned above keys,term-esc,jobs/ch,autocmd remains functionally during conversion. So you keep adding PR's on top integrating each new part (eventually each GUI, which can be proven easy first). I have spent a lot of time on that rabbithole and I'm just about Gtk, which takes more time. But non-GUI vim seems straightforward. Whats great about that, is that the core gets more testable, I think it should start being polished like that and tag the refs. It would be nice if a vim10 branch/target was a common goal, because its an anniversary. The goal would be to progress and prove the most advanced endgoal transitions to gtk ASAP - so the thesis is proven. However, the most important thing is keeping that boundary of logical change refs one thing converted to event-core at a time and confirm no breakage. This is what I'm most positive about, because it really doesn't seem that complex - its basic wrapping around existing entrypoints and highly modular and not intertwined at all. There is no long period of next-branch is "broken" without feedback. The contributors should daily drive it to test it thoroughly between the iterations. The immediate benefit to a testable core and what possibilities it opens now with less risk of breakage is whats comforting given how quickly that is achieved. |
|
Okay I will leave this restructuring up to you for now. It seems like you want to consolidate a bunch of functions into a set of well defined entry points? |
|
I can show you the concept once I get some sleep, as long as you take it for what it is, then I think it would also be easier for you to understand. I've experimented with both
The easiest is SDL3 GUI. However, it does not make core Vim more robust or testable.
The smallest architecture is by far the event-core - it avoids the dual-abstraction and server implementation. If it was ever wanted, it was better implemented as subsystem on top of the minimal event-core so not to pollute the minimal core. The recent issue with terminal leaks in ghostty due to the ingrained timing nature of term.c is also another thing that benefits vastly of event-core as prerequisite. If a thing such as FDs for term resp would be implemented it needs a transport. Instead of re-inventing these concepts in every subsystem its better with a common interface. Everywhere in Vim there are syncronous shortcomings from completion, autocmd and even the popup key/hit-message input race iirc.. The more PRs everyday its just a tug of war.. You add stuff, you break stuff.. |
|
@64-bitman mby u could elaborate on the challenge ure facing? I did try to incorporate the same GDK_REDRAW_PRIORITY fix from gtk3 over your gtk4, but recently also discovered that cursor blinking (gtk3) had a lot of redraws simultaneously when screen was redrawing - thats another clue to look for. gtk4 has also changed some since I last tried, maybe its better now, although I did try that priority peek hack on gtksnapshot/hwaccel I'm sure! |
|
I'm not facing any challenges as of now for this. I just want a clear idea on what should be done first |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Currently the way the GTK GUI is implemented in Vim causes a bunch of issues/bugs. This is because Vim runs GTK, and GTK is designed so that it is the one running everything. I think it may be possible to refactor so that we run the GTK4 interface code on one thread, then communicate both ways between the Vim thread, like a weird terminal emulator.
One issue is that it would not be possible to use some of the existing code fully (e.g. menus). There would have to be a way to synchronize the GTK internal view of menus and Vim's view of menus. I am guessing this is a big blocker to this. However some existing things will be made simpler, for example the channel feature uses GIO IO channels for the GTK GUI, if we separate the GTK code into a different thread, then that is unecessary (just use Vim's existing common channel code).
An internal socketpair could be used to communicate special escape sequences (for simple stuff, e.g. drawing, showing the tabline/scrollbar). Then for more complex things (menus, print dialog, ...), something like a
GAsyncQueuefrom GLib could be used to pass around objects/data structures in a thread safe manner.Performance will probably not be any different, however it may be easier to maintain in the future. I think if this is done, the GTK4 GUI should be ported first, then the GTK3/2 GUI after separately.
All reactions