Leadwerks UI reloaded

[codeape]

So I really like Leadwerks. However, I see that a lot of problems tracked back to GTK and capabilities of different UI toolkits.

 

So why not doing things the Blender way? Create your own OpenGL UI toolkit with a event system and/or a message system and create an editor that uses the same UI toolkit for all platforms.

 

OK, I am not stupid ... this is not a small thing and maybe not the most fun thing to do. However it could be a long time goal and a nice evolution of Leadwerks.

 

There are many pros:

+ Same UI code for all platforms.

+ The UI could be used by both the editor and in the games we make with Leadwerks.

+ You will be using your own UI that you have 100% control over.

+ UI is a feature people want

+ No more OS dependent UI bugs.

 

The con:

- More things to do.

- It will take a loooooooooooooong time to accomplish.

[Guppy]

Blender went this route, but they have a paid team and (contrary to the kickstarter page's promise of " our team has a lot of experience with multi-platform development" ) Leadwerks does not.

 

I've before suggested that He hire an experienced consultant to code the UI in GTK+ (or Qt, wx, etc ) a complete recode is not necessary - between glade and gtkbuilder a reworked UI should be done in no time flat and the consultant could focus on helping josh tie in the code bits that responds to the evens ( showing images/opengl contexts/altering states, etc ).

 

ofcourse this rests on the silly notion that the editor components is written in C, C++, python or one of the myriad languages that actually have gtkbuilder bindings.

[YouGroove]

- It will take a loooooooooooooong time to accomplish.

You mean years, and this would mean LE3 progressing even more slowly.

No thanks.

[Rick]

and (contrary to the kickstarter page's promise of " our team has a lot of experience with multi-platform development" ) Leadwerks does not.

 

If I recall correctly Josh leaned on a contractor heavily for Linux stuff who did have a lot of experience. I could be wrong but I recall him talking about a contractor for that stuff.

 

Personally it would be interesting if Josh could write the editor with node-webkit using WebGL for the 3D viewport. This would give a consistent look on all platforms. I know he likes the idea of the editor looking like the platform it's running on but I think that's overrated. It would be better to have the editor loot exactly the same on all platforms and only require 1 codebase that node-webkit could possibly give him. Perhaps the issue is WebGL doesn't support OpenGL 4.

[YouGroove]

No way, it would take ages, even hiring someone.

The only solution would be put LE3 GUI open source for all people to contribute and choose a system than make it together, otherwise forget the idea.

But i like the idea indeed.

[MarkusR]

hmm, creating a own gui need more than a month work and much fine tuning after that.

using a opensource gui often do not do what u need or is buggy or u not understand, too complicated etc.

replacing a gui i the current state of editor waste much time.

[Josh]

I relied a lot on Aria and Bruce for the Linux stuff. Previously three different people worked on the various platform implementations for Leadwerks on mobile and Mac.

 

Most of the problems I ran into with the Linux GUI stuff came down to a fundamental design mistake the GTK guys made. The system is asynchronous, which means you can set a value, immediately query the value, and it's not the value you just set. This required a lot of workarounds and caused the delay of the project. X is designed the same way, and according to Canonical, X causes more bugs than anything else in Linux, and that's why they're replacing it with Mir. I do not know if GTK is designed that way out of necessity or just because they were following the X design philosophy.

[marchingcubes]

The 'asynchronous' implementation of X11 isnt really responsible for any issues in end-user UIs except for difficulty to sync application redraw with X11 server repaints, but this is never a problem for the applications themselves which just send x protocol messages whenever they like. It is just a huge problem for the x server to identify a 'ok this app is done updating so i'll copy its buffer to the screen' barrier.

 

X11 is being replaced for many reasons, and this is definitely one of them, but i'm not sure the 'GTK is asynchronous' issue w/regard to updating widgets etc. is any more of a problem here than in any other event-loop-driven UI.

 

I don't do any GTK these days, but I don't recall having to architect my GTK applications for an asychronous widget model.. The only situation I can think of that matches the description is if you are dispatching events, and expecting those events to be received and processed before the glib event loop has run.

 

I am not aware of any UI system anywhere that processes UI events without relying on this type of 'asynchronous' queue mechanism. However, as far as I am aware, direct function calls to GTK widgets e.g. gtk_button_set_label() or whatever are entirely synchronous.

 

Can you be more specific about what is problematic?

[Guppy]

Not sure why one would fault GTK for being asynchronous - aren't all modern GUI API's multithreaded/event driven these days?

 

Also setting a input and then immediately reading it is not a use case that would ever happen, and goes against the intended use because you'd spend a lot of time in idle wait polling a input box instead of simply subscribing to the event ( changed signal in gtk speak ).

 

The simple truth is that any unfamiliar API is going to seem idiotic until you become familiar enough with it to use if comfortable - for instance I still curse every time I come across the Leadwerks input API. My solution here has been to do a hacky api wrapper to make it behave event style - this predictably is horribly unstable because I'm using it in an unintended way.