Future GUI

[miniME89]

So, i read the thread and need to say that i also thought about something similar, seperate design from code, but not in this detail. I am glad that some has the same oppinon. But my secend thought was that it would take alot of time and effort.

But i am up for it to implement this, because placing elements in the GUI is currently a pain in the ass. (Check out the UIConfigMenuControls.java file). And also it would be easy for others to mod the GUI.

I would also prefer JSON, as i am familiar with (not that i am not familiar with xml ) but it is also faster than XML.

As i read the thread i took a (really) quick look at the GUI libraries out there. Nothing fits because they all rely on on xml and/or are inactive. But couldn't we just write the JSON parser for the GUI our self and use the widgets out of theses libraries? Because those widgets have possible more funcionallity than our current widgets =)

 

[Adeon]

Ok. so and what are your next steps?=)

 

[miniME89]

1. Check out the available libraries. See if its possible to use the widgets out these, without much effort, otherwise we will use our own widgets which are currently there. Also those widgets needs to be easy extandable. I would appreciate it if you could take a look at them today. I will take a look at them later (as i am at work currently =))

2. Analyse our code. Understand in detail how does the GUI works.

3. Create a remote branch where we can work on.

4. Integrate the widgets out of the library or redesign our widgets.

5. Write a JSON parser for the widgets

6. Redesign every GUI part.....all previously created UI can now be deleted =)

something like this.

Just send me a message or email if you found something out.

The impact will be huge.. Maybe we need to reconsider if we are just using one of the libraries and XML parsing.

 

[Cervator]

Woo for more GUI fanciness

I'd love to see us take advantage of some stuff out there (not reinventing the wheel, etc), even if none of the existing libraries are spot-on. XML isn't totally evil or anything, but I'd vastly prefer JSON myself.

Thanks miniME89 !

 

[miniME89]

Just checked out the TWL and nifty library.

First of all we should use one of those two libraries. Our current UI system and the widgets (UI components) is not suitable for writing our own parser (at least thats my opinion). It would work somehow, but would it be nice code? No. Secondly it will be hard to just integrate the widgets out of one library.

So the plan would be:

1. Integrate one of those libraries.

2. Replace the widgets used in the gui.menus package classes by the widgets of the library and set the layout with an xml file. This can be done step by step.

3. Delete the whole gui package except for the gui.menus package.

4. There is the possibility to write our own JSON parser later on. Because you can easy convert XML to JSON, this wouldn't result in a redesign.

At least thats a plan

I will take a deeper look at those two libraries. Also a few others should check out the libraries and write your opinion below. I will maybe try to integrate one of them later, just for testing how easy/hard they can be integrated. I hope the are easy to integrate, the better should be

 

[Adeon]

I dont see any difficulties to write "JSON parser" for our current code. And I dont really
see anything negative in the current code UI. Yes, it misses some elements, true. But the
terasology is an open source project. And what is wrong with further working on and improving the UI code?

Personally, I am set against of the idea to integrate the third-party library and
"to write JSON parser for it". Fact, any library might have bugs, and to repair them we'll have to
wait for the aside developers. Yes, we can definitely repair the bugs ourselves, but, first,
we will have to learn the third-party code back and forth. And second, when a bug is repaired,
we wont be able renew the library easily.

Once again, this is my personal opinion, not attitude. My opinion is based on the hard way of the company I work for. And my opinion might change when someoneshows me the facts and advantages of using the third-party library in Terasology.

 

[Cervator]

Both TWL and Nifty are using the BSD license, so if we really want we could fork either and apply our own fixes, tweaks, and a JSON parser if we'd like it. I figure that gets us the best of both worlds - we can tinker with it ourselves, fix bugs, pull updates from upstream, even offer up fixes ourselves.

Anything existing we prefer we can use instead, or merge in, etc. Or if the test shows too many issues with either of those libraries then oh well, experiment complete. Knowledge is power

 

[x3ro]

I just took a look at TWL (their example applet) and it has serious rending issues (constant flickering, for example). Can anyone verify this, or is it just a weird in-browser/mac issue? Because of that I currently haven't looked into TWL any further.

As for Nifty, I took a quick peek at it, and it is _huge_. The entire thing (master branch checked out) has 55k LOC, the nifty-core part accounting for around 25k LOC. I'm not saying that this is an indicator for good or bad quality, just saying that it is pretty big. The build on my local machine went smooth without any errors, and it has a maven repository too.

I tried to get this example to work, but apparently it is pretty outdated and after an hour or so I got annoyed and decided to postpone (because I have to get up in 4 hours or so ^^). The examples in the repository are apparently up-to-date, but they use some kind of LwjglInitHelper class (from the nifty example repo) which made it hard to quickly create a nice, self-contained example.

 

[miniME89]

I havn't had any problems with the applet.

I took a deeper look at TWL and in my opinion its a good solution if we can integrate this.

First I run the simple example in the wiki. No problem with that.

Then i tried to integrate it just by adding it in TerasologyEngine class. And thats the result:

yea, thats a button drawn by TWL from a template file at the position 0/0

That button should be grey with the text "Epic button", but after all its a result. I will investigate this strange layout tomorrow. But it should be possible to use TWL.

 

[Cervator]

Cool. I talked to x3ro some on IRC today as well, who has more ideas / tinkering for the topic, especially related to config in JSON.

Mainly I'm curious about how much more (if anything) we'd get out of adding in library "x" - any small proofs of concepts that are actually working in Terasology in a branch somewhere might give us an idea how it would compare to current state.

But we should keep in mind balancing effort in setting up and getting used to / integrating a library vs just adding that effort to the current system that works fine for our current needs. What might we need in the future that we can't do currently, and would it be easier to roll our own extras, replace, or (ideally) merge in existing stuff" Maybe there's a nice layout manager in one of the libraries we could use with our current components? A theming system for GUI skins? And most of all: how would we have mods interact with the GUI?

I really don't know what is the better option. Re-using existing content is great, but our needs are likely going to be very specific, and it may take more or the same effort to customize that in a library vs doing our own?

Anyway - bunch of stuff keeping in mind for reviewing our options. Very interested in what comes up

 

[Kai Kratz]

Hmm I want to voice my concern on this one.

I do not think we should use an external gui framework. To give you a reasoning for that:

• First we want the gui to have a certain look and feel which very likely will require customizing the external gui components to a certain extent.
• Secondly we do not intent to have a manager style game with the associated controls. For the most part simple text fields are enough, maybe combo boxes.

Given this I do not see us running the risk of reimplementing a whole full fledged gui framework making the possible integration effort a external framework requires highly cost ineffective in my opinion. The key is limiting the gui to the essentials.

 

[Cervator]

I do think we're in the right place this very moment - the GUI does what we need and works. Any sort of solid effort to bake in more than we need right now is too much, yeah.

Down the road tho one major thing is staring us in the face: mods

I'd like to for instance be able to take the snazzy GUI textures Janred (GitHub/IRC, not sure if he has a forum account) prepared and make them an option in-game, he's got multiple sets, even. Would we be able to grab a theming system like that? Or is that easy to implement from scratch real quick?

And that's just a set of textures for existing components, let alone adding new components.

I might also be involving a secondary desire here - the potential of externalizing the GUI bits anyway, even if we go with 100% homebrew. We are ending up with a lot of code, the LOC graph on GitHub is going nuts (60k 4 months ago, 90k today), tons of files, etc. Would it be helpful to be able to split out GUI code to stay better organized, or am I just being crazy? I might well just be crazy, not my expertise

Incidentally, as much as I'd love for us to make a kickass GUI lib by no means am I saying we actually should, now that would be crazy. I just want to have my cake and eat it too

(I'm really just talking and bringing up thoughts here - no intent to set direction. Easy for me to talk since I likely won't be coding it)

 

[x3ro]

I wrote a little prototype, which show what a very lightweight JSON based implementation of the customizable UI could look like. It basically creates instances of UIElement subclasses from a JSON configuration like the following:

[
    {
        "id": "title",
        "class": "UITextElement",
        "parameters": [
            {
                "method": "position",
                "value" : [100, 100]
            },
            {
                "method": "text",
                "value": "foobar"
            }
        ]
    }
]

The outer array contains all the elements' configurations, which accommodate some required properties, such as a unique ID for the UI element (so that we can talk to it from the code), the class the implements the UIElements behavior, and the parameters, which can be any property that is "settable" on the respective class.

You can run the example by simple executing "gradle run" in the root directory. It should yield a string like "Hello, I am the string 'foobar' at position 100,100" which shows that the values from the JSON string are passed on to the UITextElement class.

Note that this is simply a demonstration that this could be implemented in a lightweight manner (especially using Groovy) in case it was decided that a third party is too much bloat/complexity/... for Terasology.

Also please note that this was the first time I've ever touched Groovy/Gradle, so if I made any obvious beginner mistakes, please don't be too hard on me

 

[Cervator]

Nice, quick, and neat! Works fine

 

[miniME89]

ok, x3ro has now convinced everybody to use our current UI.

Yesterday I also checked out the changes which should be made if we implement an external library. It isn't that easy. But it would be possible and the result would be a highly customizable GUI.

On the other hand if we use our current UI we need to expand it more, add some styling options, make it more event-driven and offcurse write our own parser. And i really like the example of x3ro and I am up for this solution now.

So we need to update the current UI system a little bit, than set the layout for the JSON file and write the parser for it. Is this a plan which will be accepted?

Furthermore I don't have any experience with grrovy. (But i will be able to learn this)

x3ro, are you up for implementing a parser? I would tweak and expand the UI a little bit.

 

[x3ro]

miniME89 Yep, implementing the parser shouldn't be the problem. However, before we jump into implementing stuff, I'd stop to think about the big picture of this some more, so that we don't get it wrong and have do rewrite it later

Some additional thoughts on what I have already written:

• In my example, I'm using absolute positioning. This won't do most of the time, I guess. Therefore we need a way to relatively position an element.
• Element children/container
• How does the system decide which JSON file to load?
• How can a potential modder add new GUI element classes?
• How can a potential modder add new resources (e.g. images, sounds), and how are these referenced through JSON?
• Should these classes be Java-only, or may they be written in Groovy?
• Scriptable behavior: I just thought of this, and we might at least consider it for later implementation: Given that Groovy can be compiled at run-time, it would be possible to write UIElements with default behavior that can be altered by supplying Groovy code snippets in the JSON-file.
• ...

There is probably more (thus the "..."), so we really shouldn't rush this, IMO (given that the current UI is working just fine for our current needs, so we don't have much pressure either). Unfortunately I'm kind of in a hurry, so I'll leave it at that for now

 

[miniME89]

yea, i wouldn't rush it, i know there are a lot of things to consider. I just wrote down the basic plan. I would be up for some discussions in the IRC chat. I also have some ideas to the points you wrote down. I will be in IRC chat from ~4 pm (UTC+2).

 

[x3ro]

I can't say when exactly I'll be home today, probably around 9pm (UTC+2 as well). I'll take a look at the IRC too see if you're still there then

 

[Immortius]

We already have an asset system that can be used for images/sounds/etc. Assets are given a unique uri based on their type, providing mod/package and name (e.g. "sound:mymod:burp"), although when the type is know it can be shortened (e.g. "mymod:burp"). We could even drop the mod bit if the context is known. Anything in the terasology jar is put in an "engine" package. So when referring to an texture through JSON it would just be:

{
    "id": "title",
    "class": "UIDisplayElement",
    "parameters":
    {
        "position" : [100,100],
        "text" : "Ok",
        "image" : "mymod:button"
    }
}

I would suggest UI element definitions would be another asset, so they can be automatically detected and any code (or other UI elements) can reference them by uri too.

My general plan is for mods to either be directories, zip files or (if code is included) jars, containing a bunch of assets that automatically get detected by the asset manager (already working for some assets), and some classes that are automatically detected and invoked/used as necessary (not done yet), and then any other supported code the mod needs.

Where UI elements fit in... need to think about the use cases. I imagine gametype style mods would want to define a custom HUD and various custom menus - these could be specified and switched around by a controlling gametype class. Smaller mods may like to inject extra UI elements into the hud or menus - one idea may be some sort of extension point system where a HUD can declare some named areas where extra elements can be injected, perhaps automatically.

 

[Adeon]

I wrote a little prototype, which show what a very lightweight JSON based implementation of the customizable UI could look like. It basically creates instances of UIElement subclasses from a JSON configuration like the following:

[
    {
        "id": "title",
        "class": "UITextElement",
        "parameters": [
            {
                "method": "position",
                "value" : [100, 100]
            },
            {
                "method": "text",
                "value": "foobar"
            }
        ]
    }
]

...

Oh! Good! We may combine our efforts. What do you think about it?=)