Roadmap : non-buffer widgets and communication

[gagbo]

Hello,

First of all, thanks for making this, I've been using this gui as my main GUI (n)vim implementation and it's really been helpful 👍

I have a lot of newcomer questions about the direction of the project, and how it might evolve. I am going to have a little time to delve a little into C++ programming and Qt, and I think I'll just try to make a small explorer widget which could communicate with the NeovimConnector to have a file explorer using as many Qt features as possible.

I don't think it's going to be merged anyway, but I wondered if you ever planned to create widgets/applications which would try to do what Onivim does : enhance the feature set of Neovim using "native" (or at least non-vimscript) code.If so, do you have an idea already of the architecture such a project would need ? Sorry if it's too vague now, but if you have any question I would be happy to answer them.

Basically I'm thinking :

• File explorer widget
• Implement a tooltip/ballon feature
• Have floating windows

These are some features we could add in a C++/Qt app which could then just use nvim-qt as an editor widget.

[justinmk]

It's a good idea to review existing issues and PRs before proposing potential duplicates.

• File explorer widget Project tree #254
• Implement a tooltip/ballon feature.
  • this will be provided by Nvim core in the near future.
• floating windows
  • this will be provided by Nvim core in the near future. [RFC] Floating windows in TUI and Remote UI neovim/neovim#6619

[gagbo]

I tried to look for older issues but basically my only keywords were 'Qt widgets'.

I provided these examples just on the top of my head while writing the issue, but I guess the main point I want to get at is that I'd like to know if @equalsraf plans to integrate these kind of features to nvim-qt or to concentrate on this core widget and provide an API to use in "bigger" projects.

Another thing I don't totally understand, since you're here :) : if nvim core provides UI features, does that mean that the nvim process will pass calls through msgpack and UI projects will have to correctly answer the calls ? Or does it mean that it's implemented in TUI and the same renderer for the TUI buffer and the GUI one will automatically get picked up to process the popup/floating window ? Or both maybe ?

[equalsraf]

Hi @gagbo. This will run a bit long I'm afraid, bear with me

I don't think it's going to be merged anyway, but I wondered if you ever planned to create widgets/applications which would try to do what Onivim does

My "original" plan was never to go as far as Oni, Oni has a very clear idea of where it wants to go in terms of UX and what type of IDE it wants to be. Honestly I dont. My main goal was to provide a library people could use to build other components, or a bare bones UI that adheres closely to the Vi way of doing things.

As a rule of thumb, if a feature would be generally applicable to any neovim UI, I prefer to push it upstream. I might use this project to test or bootstrap the idea but if it is a good idea the best method to ensure it is well supported is to discuss it and contribute upstream even if at times it delays its arrival here.

the main point I want to get at is that I'd like to know if @equalsraf plans to integrate these kind of features to nvim-qt or to concentrate on this core widget and provide an API to use in "bigger" projects.

I have nothing against doing this, I would like to point out a couple of things first:

• neovim-qt is both a library that can be used externally and a standalone UI. For example just because the library provides a certain component/widget that does not mean the UI has to use them
• I have no clear notion on what happens when some types of native/Qt widgets get mixed up with the neovim widget (more on this bellow) e.g. how does the focus in Qt widgets interact with neovim, or who handles input between the two.
• I certainly don't mind including widgets as part of the library that are not used by the stock UI

And now for a more practical answers to your questions 😄

if nvim core provides UI features, does that mean that the nvim process will pass calls through msgpack and UI projects will have to correctly answer the calls ?

This already happens. Either because neovim does this as part of its UI protocol, or because neovim-qt uses it to provide additional features - check the src/gui/runtime/ folder for a neovim plugin whose purpose is to support features in the UI.

Or does it mean that it's implemented in TUI and the same renderer for the TUI buffer and the GUI one will automatically get picked up to process the popup/floating window ?

The later is a topic of significant debate in neovim/neovim. So both.

I tried to look for older issues but basically my only keywords were 'Qt widgets'.

For figuring out future directions you should check the neovim issue tracker (example). In fairness neovim-qt has not been keeping up to date with all the features in the UI protocol - we are missing multiple of the externalized widgets (search for ext_ in neovim) not to mention the new protocol for drawing optimisations and floating windows.

You listed some features, allow me to extend that list along with some comments

• We could have stock Qt models for neovim data e.g. a list of buffers/tabs/etc - the kind of stuff that would be easy to embed in an application that uses nvim.
• the balloon/tooltip needs to be worked upstream - historically Vim had support for extending balloon (see :h ballooneval in Vim) and it even had properties unique to the GUI (i think they could render special content - but I may be confused about this point)
• file explorer - this one is tricky, because I can think of multiple uses
  1. as a side pane - common in IDE - problems here are how do you interact between your side pane widget and neovim. Who handles the input, how do you switch back? I dont expect to be a clear answer to this one.
  2. As a modal popup - Vim had the browse command to do this, neovim does not
• Vim had the set guifont=* form to call a font selection GUI. vim-qt had its own custom font picker for this.
• Don't get me started talking about attaching to multiple nvim instances, sessions and resume. My favourite feature of nvim is its architecture the UI could actually drive multiple nvim instances in multiple machines.

I just realised I have not addressed the main title of the issue which is Roadmap sadly I've ran out of time for today :)

I hope this helps to provide some context. Feel free to ask more questions.

[gagbo]

I'll give a few of my thoughts here, and even if my style sounds a little definitive at times, I'm really just exposing my point of view for you to correct the way I see things

I have no clear notion on what happens when some types of native/Qt widgets get mixed up with the neovim widget (more on this bellow) e.g. how does the focus in Qt widgets interact with neovim, or who handles input between the two.

As far as I understand, if an Event (KeyPress, KeyRelease, or Mouse) happens in a child widget and this widget does not ack it, the event gets passed to the parent. I am not a Qt wizard, so I don't know if this is practical at all, but we could imagine a widget architecture where :

• Either the current bare neovim widget is a parent to everything we add in the library for later use
• or there is one 'super' widget which holds all widgets including the current bare neovim widget. This MainWindow would then be responsible of dispatching events correctly.

Another solution would be to have all widgets catch every event, but have the widgets communicate through signals/slots. This is probably the cleanest way in my opinion, since it does not lock us for multiple instances of nvim at first sight.

We could have stock Qt models for neovim data e.g. a list of buffers/tabs/etc - the kind of stuff that would be easy to embed in an application that uses nvim.

With Qt6 coming in a not too distant future and seeing the tone of this Qt contributor presentation, it may be wiser to try to use Qt models sparingly (They don't seem to believe too much in using Q variants as much as possible anymore), but I suppose this kind of issues may come later

For figuring out future directions you should check the neovim issue tracker (example). In fairness neovim-qt has not been keeping up to date with all the features in the UI protocol - we are missing multiple of the externalized widgets (search for ext_ in neovim) not to mention the new protocol for drawing optimisations and floating windows.

I'll try to see if there's something not too big I can bring to the table

as a side pane - common in IDE - problems here are how do you interact between your side pane widget and neovim. Who handles the input, how do you switch back? I dont expect to be a clear answer to this one.

Since we're in a Qt application, maybe we could use the Super key to change focus between panels ? In #254 at least, it seems that the only missing thing is changing between panes with the keyboard (meaning each panel updates the other accordingly, and that using the mouse works as expected)

Thanks for this answer, it helps a lot :)

[equalsraf]

I'll give a few of my thoughts here, and even if my style sounds a little definitive at times

There are only two things in life which are definitive :)

As far as I understand, if an Event (KeyPress, KeyRelease, or Mouse) happens in a child widget and this widget does not ack it, the event gets passed to the parent.

That is the gist of it. There are alternatives but for most cases this works well - even here I dont think we gain anything by doing it differently.

What makes the neovim case particularly hard is that the user may have created a mapping in neovim to do something else (using nmap, imap, etc) and if you start handling that input differently you might be breaking his expectations.

With Qt6 coming in a not too distant future and seeing the tone of this Qt contributor presentation, it may be wiser to try to use Qt models sparingly

This is news to me. I actually like the models/views framework.

I'll try to see if there's something not too big I can bring to the table

Quick suggestions

• In this repo, ext_cmdline (I actually started this in WIP - GUI: Implement external cmdline #351, but never finished 😞) basically requires looking at the protocol in (:h ui-protocol and ui-cmdline) and implement a command line widget for the UI
• in neovim/neovim some the issues that involve the word "externalize",

Since we're in a Qt application, maybe we could use the Super key

Or we can just let the user decide. you can have gui specific settings being set in ginit.vim as well as rpc requests that operate on the panel (e.g. open/close)

[gagbo]

This is news to me. I actually like the models/views framework.

It's mostly the containers, I've been thinking this since I saw this talk from 2017 CppCon

Or we can just let the user decide. you can have gui specific settings being set in ginit.vim as well as rpc requests that operate on the panel (e.g. open/close)

I'm not totally finished looking at the code in #484 but it looks like it actually provides (neo)vim commands to send the correct messages to the widgets to interact (These lines). Maybe the better style would be to make it a Plug mapping but I also think leaving the choice to the user is the better and easier way to deal with mappings