Skip to content
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

Next steps: early designs #1

Open
yatli opened this issue May 31, 2022 · 1 comment
Open

Next steps: early designs #1

yatli opened this issue May 31, 2022 · 1 comment

Comments

@yatli
Copy link
Owner

yatli commented May 31, 2022

Now we have the core ingredients, the display mechanism is upstreamed to neovim, fvim and goneovim are 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:

  • Button, checkbox, radiobox (two state and tri-state)
  • TextBox, read-only or read-write(input fields)
  • Slider
  • Layout container (hstack, vstack, grid, tabbed view etc.)
  • Scrollbar
  • Listview, Treeview, Tableview
  • Color indicator/picker
@yatli yatli changed the title Next steps Next steps: early designs May 31, 2022
@akiyosi
Copy link

akiyosi commented Jun 4, 2022

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants