Backend functionality for easier integration into existing applications

[VisenDev]

The idea is to add functionality to the backends to separate dvui specific initialization - and general window / rendering initialization.

Existing applications will already have functionality for opening up a window, rendering a frame, etc... with a given backend.

The dvui user interface code will work the same whether the window was created by dvui or by a user application. So it would be nice to accommodate the use case of desiring this.

This proposal would allow an end user to use dvui only for adding widgets - the end user still manually creates a window and handles rendering frames and so on...

Possible implementation strategy -

• Separate backend functions that manage the window into two separate functions. For example, init becomes initWindow and initDvuiState. initWindow creates the window, and initDvuiState initializes backend data fields.

• Other functions like begin and end would also need to be split up in a similar way

• Thus, users that also want dvui to create a window can call both functions, users that only want to use ui widgets can only initialize the dvui state

• This differentiation could also be accomplished by giving all of the aformentioned functions another parameter to specify which behavior is desired.

[david-vanderson]

I agree! In fact, this is the idea behind having a separate "-ontop" example. Let's add a "raylib-ontop" example and use that to figure out how this should work (looking at "sdl-ontop" shows a possible way, but it's not great).

I'm pretty sure that only initWindow needs a split - begin and end work on a dvui.Window no matter how it was made. But I could be wrong.

[david-vanderson]

Sorry - I should have said. Can you please add a "raylib-ontop" example (can crib most of it from the sdl-ontop) with your best guess as to the right way to do this?

[VisenDev]

Sorry - I should have said. Can you please add a "raylib-ontop" example (can crib most of it from the sdl-ontop) with your best guess as to the right way to do this?

yes, I'll start experimenting with this

[david-vanderson]

Thanks again for working on this. Sorry - I didn't quite realize how different raylib would be from SDL. Doesn't look like there is a way to wait with event interrupts.

I've done a pass over it with my own opinions, so what do you think? I was trying to see how it would work to require more of the underlying raylib API instead of the backend handling that complexity. If you think that looks okay, I will rework the sdl backend similarly (init vs initWindow like you suggested).

You are the primary driver and user here, so your opinion matters most. Better or worse?

[VisenDev]

Thanks again for working on this. Sorry - I didn't quite realize how different raylib would be from SDL. Doesn't look like there is a way to wait with event interrupts.

Raylib desktop uses glfw, so maybe glfwWaitEvents would work?

glfw headers are bundled with raylib in src/external/glfw/include/GLFW

I've done a pass over it with my own opinions, so what do you think? I was trying to see how it would work to require more of the underlying raylib API instead of the backend handling that complexity. If you think that looks okay, I will rework the sdl backend similarly (init vs initWindow like you suggested).

You are the primary driver and user here, so your opinion matters most. Better or worse?

Looks fine to me, this approach still fulfills my usecase. The same functionality is achieved either way.

I guess the only point I may have from a library philosophy point of view is whether or not dvui expects users to understand the underlying backend they are using.

Eg, is dvui primarily a self contained ui and windowing library (like gtk)? Or is dvui primarily a UI toolkit that can be used ontop of another windowing/rendering library (like raygui)?

Are dvui users expected to call non-dvui backend functions? If dvui is a generic UI toolkit used in combination with another window/rendering library, thats perfectly fine. If dvui is meant to be viewed in a standalone manner divorced from the underlying backend - then that might be less desirable.

It just depends on what your intentions are with dvui

[david-vanderson]

Good. I view dvui as more of a generic UI toolkit - it's more limited in scope (hopefully easier to integrate). At least that's my current thinking.

I'll look into whether we can call glfw stuff. Thanks!

[VisenDev]

In light of the init initWindow split, this issue can be closed