Jump to content

Leadwerks UI reloaded


codeape
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

System:

Linux Mint 17 ( = Ubuntu 14.04 with cinnamon desktop ) Ubuntu 14.04, AMD HD 6850, i5 2500k

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

PC : Win 10 Pro 64 Bit , 4x cores ~2 GHz , 8 GB RAM , AMD R7 265

2D : Photoline , Zooner Photo Studio 13 , Art Rage Studio 3.5.4 , Ashampoo Snap 7 , ...

3D : Shade 15 Basic , Carrara 8.5 & DAZ Studio 4.8 , Cheetah 3D 6.3.2 , Via Cad 8

Music : Samplitude Music Studio , Music Creator 7

IDE : Leadwerks Engine 3.x , Unity 5.x , (Unreal 4.8.x) , AGK v2.x , Construct 2 , (Clickteam Fusion 2.5) , ShiVa 1.9 , Game Maker Studio , MS Visual Studio .Net , Android Studio , Monkey , ...

Link to comment
Share on other sites

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.

  • Upvote 1

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

  • Upvote 1

System:

Linux Mint 17 ( = Ubuntu 14.04 with cinnamon desktop ) Ubuntu 14.04, AMD HD 6850, i5 2500k

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...