GLFW Host

[riri]

Hi

I saw in the features list (#229) the integration of GLFW was planned (low priority), also @jpcima started working on a PUGL integration (#111).

I would like to make the GLFW host integration (mostly to get rid of the gtk3 dependency), but I lake some understanding on how windows and views are articulated. GLFW only hosts windows, and do not manage at all the content except the GL context if asked to (but it's optional). So in this case, should the view and the window be kinda merged (or more precisely actions to the view forwarded to the window) ?

In this regard, then I don't have any reference to the destination of the cairo surface. I suppose I could put it on the platform specific native window.

Considering @jpcima work, is the best practice to just set a custom host and develop it as a separate library or to add it to the Elements code base (aka glfw aside of linux, macos and windows) ?

I'm just discovering Elements, but it's the one matching the most my idea of a GUI toolkit after long researches, and I like a lot the philosophy. Great job :-)

[djowel]

The basic idea here is to use the Artist port as the backend (using Skia). GLFW can be easily ported that way. See https://github.com/cycfi/elements/tree/artist_port

Considering @jpcima work, is the best practice to just set a custom host and develop it as a separate library or to add it to the Elements code base (aka glfw aside of linux, macos and windows) ?

There's no "best practice" yet. Although we've been discussing this on and off for quite some time now. Yes, glfw can very well sit alongside linux, macos and windows. But "linux" should probably be renamed as glfw. I know "linux" works on Windows, for example (I haven't tried MacOS, but I see no reason why glfw can't work on MacOS as well).

Many thanks!

[djowel]

Let's ping @redtide :-)

[redtide]

I was tempted to suggest the same about using artist because opengl but I wasn't the right person 😛 I'm just thinking if it could be possible to keep the hosts outside the library, it could make less "obligations" for maintenance; for example if someone contributes his work and then not working on it later for some reason, or having so much code and/or submodules to carry on.
About "linux" host I think it simply doesn't exists, so the current one could be just renamed to "gtk3". AFAICS glfw is cross-platform.

[riri]

So far, so good. Host is completely decoupled from elements base, so I suppose it's a matter of cmake configuration to enable a new host type from an outside project. In this case, inside/outside of the project does not seem to be that important. Btw, I agree with @redtide about the gtk3 naming instead of linux.

For the Artist port, I see the only implementation is with Skia for now. That looks much heavier in terms of dependencies, and as far as I understood, this is a work in progress. Is it temporary, and a canvas abstraction without exposed dependencies like for host is planned? Yes, I know, I am digressing from the initial subject :-p

[djowel]

Artist is the future of Elements. Cairo is old and no longer in active development. It lacks a lot of the modern 2D capabilities. I've considered maintaining a cairo port, but I decided against it due to lack of time. If anyone wants to maintain the cairo port, then I'm willing to give it another consideration.