Future GUI

[Kai Kratz]

Hey guys,

nice to see you all work so hard and enthusiastically!

However there is something I am missing. In my opinion there should be some analysis of what is actually needed. For Example: It is nice to be able to position UI elements absolutely but do we need that feature? Is there nay pressing need for that feature? What I would love to see where that you take the current state of TS and come up with a list of features we currently use, then trim that list down to the absolutely minimum and use this trimmed list as core for whatever you build. If you feel a certain feature is needed come up with a good example to justify it and put it up for discussion.

The less features we need the better, feature creep is the death of every project especially open source. Please please don't get me wrong, I really like the work you guys are doing and this is by no means meant to reprimand any of you. It is a mere warning that things might get out of hand because you are having fun (When I'm having fun coding I build everything except the things I really need )

Please do not try to maximize features, please try to maximize expressiveness with minimal features. this is a very hard thing to do but very worthwhile!

Cheers,
Kai

 

[x3ro]

Kai Kratz: Totally agree with you. What properties we do or don't implement isn't that much of a problem once we have agreed on a general structure to use, and that is what I'm personally currently focusing on (besides getting to know the code base a little better and playing around with it a little bit).

 

[miniME89]

The first of all, SomeMenu is a modal window. The second, I think we should implement files with action in groovy. The result should be look like that:

Why to use groovy we should also think about modders and people like me who haven't used groovy before. Easiest way would be a normal java class. Or what would the advantage of groovy be? A big disadvantage is offcouse that most people know java but the dont know groovy.

Adeon:

class SomeMenuController implements UIButtonController, UIProgressbarController {
 
    public void buttonClick(...) {
        // Handle button click
    }
 
    public void progressbarUpdate(...) {
        // Handle progressbar update
    }
}

However, my solution also allows the definition of a class such as "NewGameButtonController", which could be re-used across menus (assuming, as an example, that there is more than one menu with such a button).

edit: x3ro your UIButtonController should be the IClickListener interface. We are talking from the same thing here.

I wrote some code how it could all fit together (in my opinion):

https://gist.github.com/3257909

The parser can of course be written in groofy. But i am probably already 1 step ahead, as I am thinking more and more about the implementation and how it fits together. But on the json files we all mostly agree.


Kai Kratz I also agree. But as x3ro alredy mentioned, we are just writing down the general structure of the new styling system, we need to write down the specific features for each element later on. And the current ideas of all the properties shouldn't be a problem at all. Most (all?) of the stuff is already there in code (as far as I can say that).

 

[Adeon]

Why to use groovy we should also think about modders and people like me who haven't used groovy before. Easiest way would be a normal java class. Or what would the advantage of groovy be? A big disadvantage is offcouse that most people know java but the dont know groovy.

Aha.
Java:
Modder write in Java. Modder compile in Java. Modder start terasology and test mod. #%#$%^#!! Mod's GUI is not correct. Modder fix in Java. Modder compil....

Groovy:
Modder write in Groovy. Modder start terasology and test mod. @#$@#$^!!!! GUI logic not correct. Modder fix in groovy and start terasology. Profit.

Ok. If you don't want groovy, leave it.

It would be better if any of you write a draft variant of issue. Because it will take eternity with my little knowledge of English.

 

[Cervator]

Groovy may sound scary, likewise Scala, but really they're like any other library jar file you just get a little bit of new syntax along with new methods

I integrated some code but not quite for develop yet - more details in the pull request: https://github.com/MovingBlocks/Terasology/pull/307

Adeon has said he'll look at changing the inventory to do the toolbar pull-out "shelf" thing rather than inventory/character placeholder screen. The two of you might want to hop on IRC when you're working so you can coordinate - keep up the good work!

 

[begla]

I think Adeon is right. Groovy has its down- and upsides. But we should decide wether we'll keep it or don't keep it. And overall Groovy is by far no bad language for not-so time-critical tasks like the GUI.

And getting into Groovy when you already know Java... Should be quite easy honestly. It's a bit more difficult to write good Groovy code!

Otherwise - great work so far. Can't wait to see a the whole inventory screen and GUI working.

 

[Immortius]

You can actually compile Java code from within Java. So we can set things up to skip the extra compile step, which addresses your main complaint (and of course is no different to how Groovy works, since Groovy has to be compiled too). And in both cases you could work on the code in an in-game editor ultimately.

That said I have no issue with having support for both Groovy and Java for mod code - including GUI stuff. I would probably use Java for my mods, for the same reasons I use C# when developing for Unity rather than Javascript. But other people have other preferences, and they both are JVM languages so it shouldn't be difficult. I personally will be working on the Java integration to start with.

 

[x3ro]

That said I have no issue with having support for both Groovy and Java for mod code - including GUI stuff.

While I see your point of being "friendly" to people who already know Java inside and out, I am a firm believer of the single point of control principle, i.e. if possible, there should be only one way to do a certain thing, in this case GUI configuration/modding/....

The downsides of having a Java and a Groovy way of doing stuff is that we'd have to write twice as much documentation, tutorials and do double maintenance if something changes. Also there might be bugs that make the Java part behave differently from the Groovy part, which makes things hard on both developers and modders.

PS: Compiling Java from within Java sounds like a _very_ bad idea. In that case you'd have to provide the modder with meaningful error reporting if compilation fails, etc. IMHO Java isn't meant for that kind of "dynamic" approach.

 

[x3ro]

I updated the prototype with visual states (e.g. hover). In my implementation, the visual states are triggered by the implementing UI element by calling, for example, setActiveVisualState("hover") on itself (which is implemented in the abstract base class). The syntax is based on CSS, as proposed by Adeon (IIRC).

 

[Immortius]

While I see your point of being "friendly" to people who already know Java inside and out, I am a firm believer of the single point of control principle, i.e. if possible, there should be only one way to do a certain thing, in this case GUI configuration/modding/....

The downsides of having a Java and a Groovy way of doing stuff is that we'd have to write twice as much documentation, tutorials and do double maintenance if something changes. Also there might be bugs that make the Java part behave differently from the Groovy part, which makes things hard on both developers and modders.

I'm not enthusiastic about supporting multiple languages, I am merely open to the idea. The one thing I am adamant about is supporting Java - everything is going to be doable in Java regardless because the project is open source and all the API is provided through Java. Any other language added on is fundamentally an additional point of control.

Actually, it is sort of a moot point. As long as our mod system uses jars or similar, then a modder can write in any JVM language - it all compiles to class files that are indistinguishable at runtime. Obviously this loses them dynamic compilation.

On documentation... Unity supports three languages. They simply document their API, which is common across all three, and a little information about some differences between the languages. We also don't need to maintain double the amount of stuff, because Groovy just uses the Java API.

PS: Compiling Java from within Java sounds like a _very_ bad idea. In that case you'd have to provide the modder with meaningful error reporting if compilation fails, etc. IMHO Java isn't meant for that kind of "dynamic" approach.

Is this so different from what happens with Groovy? Maybe the errors are slightly better, and maybe some of the errors are deferred until runtime, but at the end of the day the scripts are still compiled and you still need to deal with the errors and propagate them to the user. At any rate I'm just pointing out that it is feasible, and it isn't that arcane an art - it is used by such common Java technologies as JSP.

 

[Kai Kratz]

I think this discussion is derailed or i am stupid and therefore i require your help to decide

What has this discussion currently have to do with a gui framework? My current understanding is that: There is a java implementation that uses gui templates written in json to generate visible gui elements. Is that incorrect?

And the somewhat mixed in discussion of: What scripting language should be allowed for mods?
I think the second part needs to be discussed some place else

So please tell me if i missed something or this discussion derailed slightly.

 

[x3ro]

What has this discussion currently have to do with a gui framework? My current understanding is that: There is a java implementation that uses gui templates written in json to generate visible gui elements. Is that incorrect?

All frameworks currently in existence (i.e. found by us ) use XML and seem overkill for our use-case. Therefore, we have (sort of) decided to use a JSON based solution, whose syntax (and, in part, implementation details) we are discussing here. So it is pretty much all about that theming "mini-framework", but there are several sub-discussions which are a little "entangled"

 

[Cervator]

Yeah, JSON and Groovy parsing begets language discussions

Our current GUI framework is just a bunch of Java classes. I don't think the existing GUI setup has a config system yet, let alone one with JSON files parsed by Groovy or Java, nor a way to style things, etc.

If my understanding is correct (and it may not be) then round one of new stuff is adding the event focus (current stuff in "integrate") and round two (still to come) is about the JSON config and parsing. With fixing/enhancing the inventory stack movement in there somewhere.

 

[x3ro]

miniME89 I thought about the event-system some more, and I came to the conclusion that, given the current code base, your suggestion is probably the best approach. I updated http://gist.io/3252874 with some info on the controller mechanism, could you take a look at it and tell me what you think?

 

[miniME89]

x3ro I have taken a look at it. My solution would be one class file for one corresponding JSON layout file. Like this:

https://gist.github.com/3339906

Currently my solution would search for the click listeners inside a corresponding class file with the same name. So there would only be one class file where all the logic (behind the events) is implemented.

Could you achieve my solution by using the same Controller class for all elements within a JSON layout file? Is this correct? So your solotuion could reuse existing controllers and you could split up the listeners in multiple files? I see the advantages of this. But is splitting up into multiple classes really a good idea?

In my opinion we should avoid splitting logic into multiple files, as long as there are not dozens of event listener implementations. The goal would be, replace each class inside the gui.windows package by another "controller" class, which implements just the click listeners and will load the layout and style from a JSON file.

But now i can see how your solution would fit in. And i would approve this solution

Still a lot to talk about:

How would your controller class get access to other UI elements? (which where added through the same JSON layout file, or through others). Would the Controller class inherit from some parent class where the logic for accessing elements by id will be added? Or will we add this to the GUIManager?

Also, how would we for example allow mods to add stuff to the current UI? When does our JSON Parser know when to load a particular style file and where to add it in the UI? We would need some extension points. Some "extension-point" property inside the layout file. (equivalent to the eclipse plugin stuff, for example)

{
            "id" : "some-button",
            "class" : "UIButton",
            "title" : "Button1",
            "style-class" : "button",
            "controller" : "MyButtonController",
            "extension-point" : "ConfigMenu"      //This could also be the HUD (heads up display) for example
            "action" : {
                "onclick" : "ClickListenerImp",
            }
}

And would even our stuff be added this way? Should all GUI stuff be extensions? So we would have a MainMenu extension-point where we would add our stuff for example. The JSON parser then would know when to load particular layout files and parse and create there elements. Also currently all elements in the main menu state will be created on startup. In my opinion we should load and parse them if they are needed.

Just some points we should keep in mind

 

[x3ro]

Could you achieve my solution by using the same Controller class for all elements within a JSON layout file? Is this correct?

That is correct. If you look at the "Structural Definition" section of my gist, I mentioned that the "controller" specified at the root level is default for all UI elements, that is, you don't even need to re-specify the controller over and over.

x3ro
So your solotuion could reuse existing controllers and you could split up the listeners in multiple files?

Yep.

But is splitting up into multiple classes really a good idea?

In my opinion we should avoid splitting logic into multiple files, as long as there are not dozens of event listener implementations. The goal would be, replace each class inside the gui.windows package by another "controller" class, which implements just the click listeners and will load the layout and style from a JSON file.

I see why you don't like the idea of separating logic into multiple files. In this case though, I think it is a necessary sacrifice to avoid code duplications. Lets take the "Exit Game" button as an example. It is re-used across multiple menu screens, and therefore the logic is duplicated as well. This may not seem like much of a problem, but there might be buttons re-used across menus that are not as simple as the "Exit Game" button. Now consider that some modder might want that very button in his custom menu. If the logic is forcibly embedded into the menu controller, the modder has no choice but to copy the entire logic for the button to his mod. If there is a bugfix in the code he copied, the mod will still be affected by that bug. Of course this doesn't only apply to modders, it also applies to internal re-use of UI element logic

How would your controller class get access to other UI elements? (which where added through the same JSON layout file, or through others). Would the Controller class inherit from some parent class where the logic for accessing elements by id will be added? Or will we add this to the GUIManager?

Good question! I'd suggest that every controller inherits from the abstract class UIController which contains a field with a list of all UIElements in the current menu.

Also, how would we for example allow mods to add stuff to the current UI? When does our JSON Parser know when to load a particular style file and where to add it in the UI? We would need some extension points. Some "extension-point" property inside the layout file. (equivalent to the eclipse plugin stuff, for example)

I had thought of simply using the ID attribute to identify structural definitions pertaining to the same menu, and then loading them first-to-last until all UI elements have been added, that is, a modder would simply extend the main menu by using the root id "main-menu" and naming the JSON file accordingly.

I haven't yet understood how the "extension-point" stuff is supposed to work. Maybe you explain the mechanism you've thought of a little more?

 

[miniME89]

I had thought of simply using the ID attribute to identify structural definitions pertaining to the same menu, and then loading them first-to-last until all UI elements have been added, that is, a modder would simply extend the main menu by using the root id "main-menu" and naming the JSON file accordingly.

Currently we have no concept of how to add additional UI elements through another layout file. For example you write a mode and want to add a button to the video settings. So you are suggesting to write down the same nested structure in your mod layout file as it is in the actual video layout file (with the same, already existing IDs)?

Like this:

Our video config menu layout file:

{
    "id": "video-menu",
    "controller": "UIVideoMenu",
    "children": [
         //the actual video menu child elements (buttons, ...) here (maybe deeper nested)
    ]
}

The mod layout file:

{
    "id": "video-menu",
    //no additional properties needed, because the video config layout file defines this
    //but you could overwrite properties here
    "children": [
         {
             "id" : "modButtonID",
             "component": "UIButton",
             ...
         }
    ]
}

Yea, thats also a good idea, this way you could also overwrite styles of already existing elements.

My extension-point property was there to just identify a particular mod layout file as an extension to an existing one. you would for example achive the same thing above with the extension-point property like this:

{     
       "id" : "modButtonID",
       "extension-point" : "videoMenuExtension",
       "component": "UIButton",
       ...
}

You would just need to write down the elements you want to add within your mod layout file. The "extension-point" marks the element within this layout file to be a child of the video menu (in this case). This way you would have more control over the modder. He can than only add elements to specific points. Also you don't need to write down the nested structure in my approach.

On the other hand you can't modify exiting elements through the layout file, as in your approch. But you could probably still get the elements by ID and modify them.

But your idea would probably be the better solution.

 

[x3ro]

miniME89: "This way you would have more control over the modder." <- I think we can give the modders quite a lot of freedom, since we don't really gain anything by doing otherwise (or am I missing something?^^)

On a different topic: What do all of you think about giving the menu definitions the file extension ".menu.json". I've noticed that currently all JSON files only have a .json extension, and I think it would be neat if one could identify the type of the JSON file right away by looking at the name. Any thoughts Cervator Immortius Kai Kratz Adeon ? (Hope anyone I forgot isn't offended by it^^)

 

[Cervator]

Works for me, I don't see a drawback

Good stuff happening in here, so I'm just letting it progress on its own!

 

[miniME89]

On a different topic: What do all of you think about giving the menu definitions the file extension ".menu.json". I've noticed that currently all JSON files only have a .json extension, and I think it would be neat if one could identify the type of the JSON file right away by looking at the name. Any thoughts Cervator Immortius Kai Kratz Adeon ? (Hope anyone I forgot isn't offended by it^^)

I already started in my examples to give the JSON files different extensions:

Layout files: SomeMenu.layout

Style files: SomeMenu.style