Fork Shiny about oak HOT 6 CLOSED

It might be worth considering this before 2.0, actually, and tying it in with #13.

from oak.

I'm not sure if we should call the fork shiny or something else. That probably depends on whether we plan on making significant changes or not. If we do, we could continue with the tree theme.

from oak.

Sounds good. Shiny has not been getting the attention it deserves.

I am wondering where you want to take it ?

Personally i felt that the lack of Mobile & Desktop all in one was a big issue.
For Desktop, its all based on glfw, but then shiny for mobile.
There is a glfw for mobile but its also in a slow state of being worked on by one person.

Other than that i am really curious if you thinking about supporting Form based GUI's so golang programmers can say adios to Web based using Electron and Webviews. I am guessing its pretty low on your list since your really making a game engine.

Anyway, its nice that you and others are willing to give this a shot...

from oak.

Well, afaik shiny isn't using glfw and it's usable on desktop so that would resolve that first concern? I haven't actually used it on mobile myself, so I don't know much about shiny's support for it but I'll take your word that it works. Obviously there's the complete opposite approach of "all glfw" to consider, but our focus on this project has been to move away from non-Go dependencies as much as possible, and we see glfw as a non-Go dependency.

Right now I see shiny primarily as a window management tool and an input handler. I don't have experience with them, is there something about form based GUIs that would prevent them from being a library on top of shiny?

from oak.

The fork has happened in release/2.0.0.

from oak.

@200sc

Sorry i did not see your responses until now. Here goes:

Yes, shiny has no reliance on glfw.
i have used it on mobile. It works, but as ebiten has worked around there are issues, and so you need to build using "gomobile bind" and use a gl canvas at native (ios / android) and pump into that.

Regarding having no reliance on native (glfw, etc) i also think thats a smart move for many reasons:

• makes it easier to fix things as its golang
• make it more OS agnostic.
• Can fill in any native OS needs using the golang way (sys calls on windows, etc)

from oak.