I'd like to propose "Neovim No-Nonsence Protocol" as the working name for this project to help our discussion. It can also be used as the official name when releasing it if no nice names are found.
- image preview
- inline preview of latex expression in a markdown file
- minimap.
- color picker.
- showing icons without Nerd Fonts.
- pets
- Not specific to a GUI application like Neovide
- We cannot assume how a GUI renders things, like Qt, winit, or Electron.
- But specific to Neovim
- We should not reinvented Qt or something.
- We should keep this protocol simple and small.
- Ease of implementation across many GUI applications
- Easy and Kind APIs that provided to plugins
We can use Neovim's built-in windows, buffers, and extmarks as the primitive of NNNP.
- to indicate the position, width, height, and z-index of the widget.
- to draw the background color (that might be transparent).
- to represent the lifetime of the widget.
- to tell a GUI what it should be rendered by a special filetype,
nnnpwidget
. - to receive keyboard events.
The flow of the widget system:
- GUI sets a global variable to tell plugins that NNNP is available.
- A plugin creates a (floating) window with a buffer with the special file type,
nnnpwidget
. - The plugin can ask for the dimension (logical size and scale factor) of one character in the grid to the GUI.
- The plugin provides image data to UI through the buffer content.
- UI renders the image and updates it when the buffer content has been updated.
- The plugin can receive keyboard and mouse events through a window.
- What kind of image data should be supported? I think supporting only the bitmap is nice for simple implementation and API.
- bitmap image
- vector image
- tessellated triangles
- or other
- How to plug between a GUI to a plugin? (RPC, buffer content, lua function, temp file, or compound of them)
- image content (I prefer base64 encoded in a buffer content)
- triggering of rendering from plugin
- triggering plugins for each frame of rendering
- provide dimension data in DIP to plugins
- Implementation details of the extmark-based API
- Is it suitable, the current direction of the protocol design?
- The name of the protocol