Create abstract input feeder, instead of using glfw directly.

[stavenko]

Hello. I wanted to use your gui library in my project, but it seems, that it' impossible right now to use existing GLFWWindow with your library. Screen class initializes window and GL context itself, and it owns rendering context, which is not acceptable for software I'm working on. It would to very good, If we could use your library in passive way. When application decides what input to give to nanovg and when (and in which framebuffer) to render gui.

Do you have such a plans in nanovg, or, would you like to improve your library in this way? I have a choice right now to implement my own library, or to extend functionality of yours. And I don't really know which way would be faster for me. Also I don't know your vision of this library development.

[svenevs]

I don't think you can control the order in which the event queue / items are rendered very easily, but the main method for displaying your own OpenGL application is the Screen::drawContents method. The rest of the calls that wrap that are controlling / displaying any widgets you may create.

However, if you've done all of your own initialization of GLFW then you can use the Screen::Screen() constructor and call void initialize(GLFWwindow *window, bool shutdownGLFWOnDestruct); with your already created window.

[svenevs]

(initialize is a member method of Screen, the other constructor ends up calling that at the end as well and it should only ever be called once)

[stavenko]

Screen::drawContents is not fully acceptable. In my application there are a lot of renderings in framebuffers, which then combined with the final shader, or on final step - using blending. Best way - to render it to separate texture, rerendering it on demand.

I believe It's possible to create some special PassiveScreen class, which accepts some input provider as parameter and initialized GLFWWindow and GL context. I suppose I could contribute this class with some examples.

It could be templated class e.g.:

template<typename InputFeeder>
class PassiveScreen: public InputFeeder, public Widget {
   void onMouseMove(...) override{}
   void onMouseKey(...) override {}
   void draw() {}
};

Users could inherit there's own InputListeners interfaces like this:

 struct UserOwnInputClass{
     virtual void VeryComplicatatedInputThatIsHardToProcess() = 0 ;
     virtual ~UserOwnInputClass(); 
 };

class InputFeeder: public UserOwnInputClass{
    void VeryComplicatatedInputThatIsHardToProcess() {
       if(someCondition) onMouseMove(...);
       else onMouseKey(...);
   };
   virtual void  onMouseMove(...) = 0;
   virtual void onMouseKey(...) = 0;
};

Is it worthing to be in library, or I better to to this in my own application, without contributing it to you?

[stavenko]

Well. I just tried to built in nanogui as is. And succeded perfectly. Didn't see at first sight those public functions within screen class, which allow others to give input to library.

And, in my rendering loop I use Screen::drawWidgets, It renders only windows without background - that's what I need.

PS: I had a small problem, while implementing this. Somehow when Screen is initialized before glfw and glew, there's could be perfomance problems. Changed nanogui::Screen nanoguiScreen to std::unique_ptr<nanogui::Screen> nanoguiScreen in my class declaration;