akiyosi
commented
2 years ago @yatli Hi, Thanks for this issue. Looks good regarding the direction of gui_widgets.nvim.
My major interest in this plugin is to integrate the display of images better with Neovim's buffers. For example, I believe one item would be to improve the markdown file decoration that gui_widgets.nvim supports by default. That is, the current markdown decorations are rather rough sketches, and it would be better if, for example, empty virtual lines were inserted according to the height of the image, as well as text labels, with respect to the display of images.
Now we have the core ingredients, the display mechanism is upstreamed to neovim,
fvimandgoneovimare onboard, we can move on to the next stage.The current widget generation code in lua is just a demo showcase of what's possible. All the widgets are invalidated and re-created on content change, which is very inefficient. We may seek inspiration from other plugins, especially those dealing with conceal and coloring -- they tend to work on fragments without looking at the full document.
Treesitter is also a promising source for tracking widget-generation patterns. However, it requires mixing the syntax tree for the filetype, and our "custom overlay" for tracking GUI elements.
There's also a distinction between auto-generated widgets, and user-created ones. Here the user refers to another plugin, or the frontend. While auto-generated widgets are mostly for document visualization purpose, user-created ones are not based on the content of the document, and are mostly geared towards building an interactive UI.
Although it is possible that the user maintains its own state representation for widgets, a more transparent approach is preferable because it allows composition from a 3rd party plugin, without the frontend knowing about the states. I have tried to implement a "pushbutton" from the backend and the result is somewhat not convincing: it uses two images to represent the button, one for normal, one for clicked, and uses the mouse event callback mechanism to swap between the two. It's laggy, and the 3rd party plugin will have to manage the widget states if there are more complex ones, such as checkbox, tabs and tables etc.
We can formally define a set of such UI elements, as done in GUI frameworks, and manage an abstract model for these elements. Then, gui-widgets.nvim negotiates with the frontend and query if the frontend supports a native counterpart for it. States can be maintained from gui-widgets.nvim, and synchronized with the frontend through the protocol.
These are examples of UI elements: