Future GUI

[Adeon]

Hi! I need some help with the GUI design.

To create a window we need to:
1) Create a new class that extends UIDisplayWindow
2) Inside a constructor add interface elements along with their size, disposition and action they perform
3) Create an instance of this class and add in to the GUIManager.

I think it's wrong. My suggestion is:

Windows generation will rely on three files.
1) UI<WindowName>Window.xml contains window description along with ui
elements descriptions, e.g. id, disposition and size. If we need to attach an action to the particular element, we just add "on" attributes such as onMouseClick, onMouseOver, OnKeyUp, etc. Attribute names here are names of corresponding methods.
2) UI<WindowName>Window.css contains styles (background, position, size, text color, background color, borders, etc)
3) UI<WindowName>Window.groovy contains a class UI<WindowName>WindowAction which methods are actions for the ui elements in this window. Once the game starts, GUIWindowsBuilder relying on this files generates UIDisplayWindows and add them into the GUIManager.
What do u think?

UPD 1. JSON might be replacing XML files

 

[Cervator]

Moved out from Core to Dev for more help potential!

Maybe related thread: viewtopic.php?f=4&t=247
Maybe related issue: https://github.com/MovingBlocks/Terasology/issues/190

I think rolling in more event-based stuff would be good. Anything XML makes me hesitant, while I'm beginning to accept moving from Groovy to JSON for data and what not. I suspect there'll be better feedback out here than from me!

 

[ironchefpython]

Windows generation will rely on three files.
1) UI<WindowName>Window.xml contains window description along with ui
elements descriptions, e.g. id, disposition and size. If we need to attach an action to the particular element, we just add "on" attributes such as onMouseClick, onMouseOver, OnKeyUp, etc. Attribute names here are names of corresponding methods.
2) UI<WindowName>Window.css contains styles (background, position, size, text color, background color, borders, etc)
3) UI<WindowName>Window.groovy contains a class

tl;dr: Either use an existing HTML DOM layout library to render your UI, or use a primitive layout engine derived from the existing model. It would take way too much effort to reinvent the HTML wheel with a slightly different syntax and scripting mechanism.

There's a clear isomorphism between a hierarchical structure of UI elements, and the structure of an XML file; this is not coincidental, as the XML data format was derived from HTML, which started as a simple markup language but quickly became a way to represent document layout as well (which later degenerated into a de facto window layout). It seems like a no-brainer to use a custom XML format to represent your UI, and then use some kind of stylesheet for formatting. I mean it works in the browser, right?

But here's the problem. HTML sucks. XML sucks. CSS sucks. They are better than any other similar approach that standardizes on document rendering, but they still suck. Smarter people than I have spent decades trying to make them not suck, and they suck.

The amount of man-years that went into Gecko and Webkit and Trident to make a sucktastic ball of suck like HTML/CSS behave in a decent fashion is staggering. I would not recommend trying to build your own layout engine with a similar design and flexibility of HTML/CSS that uses your own custom XML tags and custom CSS syntax. It will suck.

If you can find a good HTML layout engine that works with the Terasology window, use it. Absolutely. Someone else has wasted their life reinventing the HTML wheel, no reason you can't ride it. And everyone knows HTML, it will be easy for mod writers to create custom interfaces for their mods.

Failing that, if you can find any good UI layout engine that doesn't totally suck, use it. Great programmers steal.

If you can't find any existing library that isn't impossible to integrate or completely unsuitable, then write your own. Write a minimal, featureless, basic UI system that uses function calls to add elements to a GUI, and expose that to the modding API, and let people make a bunch of method calls to create their custom interfaces. It's going to take 20 seconds for someone to realize that JSON is also isomorphic with XML, and by association, a hierarchical structure of UI elements, and another 40 seconds to whip up a function that recursively descends a JSON data structure and invokes the API calls to make a UI. However, the good news is you won't have a bunch of XML parsing and CSS parsing garbage in your UI code.

But that's just... uh... like my opinion, man.

 

[Adeon]

Sucks, sucks, sucks...oh.
I just want to separate the view apart from the model. Action and view in the class UIWindow are not correct. Html and xml do not suck, you just need to know how to use them

 

[Adeon]

>Failing that, if you can find any good UI layout engine that doesn't totally suck, use it. Great programmers steal.

And get dependant on this library's developers?

 

[ironchefpython]

And get dependant on this library's developers?

Aren't you already dependent on everyone from Oracle to the OpenAL developers?

You stand on the shoulders of giants, no reason to piss on 'em.

Sucks, sucks, sucks...oh.
I just want to separate the view from the model. Action, view in the class UIWindow is not correct.

I completely agree with separating the model from the view. Interaction with the UI (view) should trigger events that can be listened for by event handlers (controller) that can update the game state (model). However doing so doesn't require putting an XML parser in your UI code.

Html and xml is not suck, just need to know how to use it.

I know a little bit about HTML and XML. But hey, write the code the way you like. The goal is to have fun after all, and not necessarily to maximize efficiency.

 

[Cervator]

The older thread had some discussion in it about GUI packages, but most got disqualified for not working directly with OpenGL. At the bottom we were down to two suggestions by ironchefpython: TWL http://twl.l33tlabs.org/ and FengGUI http://www.fenggui.org/

Both sound like they still use XML tho, which is so pointy

I wonder if there's anything out there defining stuff in JSON?

As for getting dependent on a library - well, with the right library you can always fork and just settle with your own flavor, or bring in part of the library, mixing with your own stuff

I do think it sounds like we all agree on something very event-centric?

 

[ironchefpython]

we were down to two suggestions by ironchefpython

"Suggestions" is too strong a word. FengGui hasn't been touched in 2 years, and while TWL is under active development, I have no hands-on experience with that library myself. I was merely... identifying alternatives.

I still stand by my original assertion, that while writing your own library from scratch might be more fun, if you leverage an existing library you'll get a playable game faster, and you'll likely have a more polished and less buggy UI.

I do think it sounds like we all agree on something very event-centric?

The last 20 years of UI development have all pointed us in this direction, yes.

 

[Cervator]

Well, beyond events, really

Haven't had time to deeply investigate, but it sounds like we're going deeper than mere events, also thanks to how event-based it sounds like our overall architecture will be

And yeah, "identifying alternatives" has a nice sound to it

Still leaves us sort of afloat on whether we can use an existing library, in whole or to supplement our internal stuff.

If we just had to throw some quick GUI component definitions together in JSON to be read by the existing engine with events tied in nicely, how would you do it?

 

[ironchefpython]

If we just had to throw some quick GUI component definitions together in JSON to be read by the existing engine with events tied in nicely, how would you do it?

The existing code creates UI elements by instantiating java objects and calling methods to configure and style them. So I'd either expose a modding API that allows instantiating/configuring/styling and write a simple javascript function that recursively reads a JSON structure, or I would whip something up in Java using Jackson (but only because that is the JSON processor I use most often in Java).

I would keep that code decoupled from the UI code itself however. I don't like tight couplings between UI API and serialization formats. (just a personal preference)

 

[Immortius]

Not that I'm fussed, but since we already have GSON in the library set, may as well just use that for JSON serialization needs.

On styles, may be worth having a look at Unity's GUISkin system for some inspiration. Basically it is a set of named element types, each of which has some common information on textures/fonts/offsets for that element. Each GUIElement then associates with one or more of those elements - e.g. a button would uses the "Button" information, a scroll bar may use "ScrollBarUpButton" "ScrollBarDownButton" "ScrollBar", "ScrollBackground" elements - but these can be overridden, so you could have a "SmallButton" varient.

 

[ironchefpython]

Not that I'm fussed, but since we already have GSON in the library set, may as well just use that for JSON serialization needs.

Yup.

On styles, may be worth having a look at Unity's GUISkin system for some inspiration. Basically it is a set of named element types, each of which has some common information on textures/fonts/offsets for that element. Each GUIElement then associates with one or more of those elements - e.g. a button would uses the "Button" information, a scroll bar may use "ScrollBarUpButton" "ScrollBarDownButton" "ScrollBar", "ScrollBackground" elements - but these can be overridden, so you could have a "SmallButton" varient.

There are some great ideas out there, but I'd rather use a shitty library we can smash in with a wee'k's worth of work, than write an elegant, powerful library that takes 8 months to write the 90% of the functionality, and the remaining 10% of the functionality (and the 90% of the tedious work) is never done, leaving another GUI library on the open-source trash heap of history.

 

[Immortius]

There are some great ideas out there, but I'd rather use a shitty library we can smash in with a wee'k's worth of work, than write an elegant, powerful library that takes 8 months to write the 90% of the functionality, and the remaining 10% of the functionality (and the 90% of the tedious work) is never done, leaving another GUI library on the open-source trash heap of history.

Sure. I don't disagree with that. If someone wants they can always spend some time working on something better later after all, but it would be good to have something functional now. There are a couple of other GUI libraries listed here that haven't been mentioned: http://www.lwjgl.org/wiki/index.php?tit ... sing_LWJGL, are any of those reasonable? Nifty or Gooei?

 

[Cervator]

Looks like Gooei hasn't been touched since 2007

Feng not for two years (as noted earlier). Last news item three years ago.

TWL and Nifty appear active, but none of us appear to really have any exposure to them, and all of them do XML. Which was "meh" back when we were looking at GUI stuff initially a few months ago.

There's no perfect solution. As much as I'd like to have one that's all frameworky and nice, backed by JSON, I don't think we'll find one. I think it might just come down to whomever is willing to put in the effect to work GUI, and whatever preference that person has.

If that's Anton solo (I sure suck at UI), and he is happy to tinker with GUI long-term (do say if not!), I say he picks, tho the more feedback we can provide on design and inspiration from other libs the better

If somebody else (also) wants to really badly do GUI, well, join in! Maybe we can look at the options more closely. I wonder if any of the libs, dead or not, are useful enough to fork.

 

[ironchefpython]

I think it might just come down to whomever is willing to put in the effect to work GUI, and whatever preference that person has.

Yup

 

[Adeon]

If that's Anton solo (I sure suck at UI), and he is happy to tinker with GUI long-term (do say if not!), I say he picks, tho the more feedback we can provide on design and inspiration from other libs the better

Mmm, yes I want tinker with GUI long-term, becouse it's very interesting. That'd be nice if somebody would guide me somehow, cause, indeed, I'm not that good in UI design and development, but I'm really willing to learn.

 

[woodspeople]

I'm experienced at GUI design having built several well received interfaces. However, I have only little bits of time to contribute. Anyone who does the GUI work is welcome to consider me available for advice and feedback, if that's worth anything at all. Also, we looked at TWL, and the child says he is interested in contributing some theme-supporting background images (ie steam boiler GUI), if that's useful.

 

[Adeon]

I'm experienced at GUI design having built several well received interfaces. However, I have only little bits of time to contribute. Anyone who does the GUI work is welcome to consider me available for advice and feedback, if that's worth anything at all. Also, we looked at TWL, and the child says he is interested in contributing some theme-supporting background images (ie steam boiler GUI), if that's useful.

Oh! Good! Check your private messages=)

 

[Adeon]

Hi, miniME89! I've noticed that you are making GUI. Marcel, maybe we can do it together? What is your nearest future plan? What about to share this task for you and for me?=)

 

[Adeon]

I want create a Combo Box and a Progress Bar.
What do you think about it?