Search results

You can always let the controller know about the context after it is created, so that it can respond to context-specific events: UIWindow window = guiManager.createUI("engine:inventory"); window.controller.setContext(this); If you're loading a certain layout, you're bound to having many...

It's probably about time I got back to this :) Firstly, I do think that going from Java-Code to a JSON based layout system is a big advantage. It might not be revolutionary, but I know that I wouldn't like to create website styles using Java code, as opposed to CSS (which I'd argue to be...

I'll look into that. You make it sound like you don't really think that the entire change is worth it in the first place, which I find a little discouraging, considering the work I've already put into it. Probably because I didn't know better. Will fix. This doesn't make sense to me. The...

I basically used Scala's Tuple2 and "ported" it to Java. I find it strange that such a generic class could be considered bad practice, because what you suggest seems to be to create a class "AssetManagerAndGuiManager", and if I'd need to return two values somewhere else, "FooAndBar" (please...

I think you might want to run ./gradlew run Note the "./" in front, because "gradlew" is a file that lives in the Terasology repository (a wrapper around the gradle executable).

So, at last I've reached a "presentable" state for the GUI system modifications. It is currently possible to define UIWindows via JSON defintions, including its child widgets as well as the default styles. It is also possible to specify a controller for a menu, which is in charge of registering...

Thanks Skaldarnar - And sorry to everyone I might have forgotten to ping :whistle:

Thanks for your feedback Immortius. I agree that the UI should not use LWJGL directly. If I understand you correctly, what you propose would require a ground-up rewrite of the entire UI though, and I think that the UI customization "framework" can be implemented first. Bottom-line, the only...

This is the continuation of the "Future GUI" (http://forum.movingblocks.net/threads/future-gui.248/) Thread, which has gotten quite long and mazy, and hasn't been updated for a while. A rewrite of the current GUI system is our main goal, mainly in order to make the GUI more "moddable", i.e...

Perdemot: Why would you recommend him to use Eclipse when the projects "official" IDE is IntelliJ?

While (and because) my knowledge on Java performance implications is limited, wouldn't it be feasible to code up an actual "benchmark" comparing different chunk storage forms. For this to work we'd need to gather information on how the data is actually used (i.e. how it is accessed...

Immortius: Groovy does just that by default, i.e. assigning a string to a property that takes an enum and automatically converting, but that is case-sensitive as well. How do you propose making it case insensitive with GSON?

I see your point, however doing all the conversion in the unserializer would entail an ass-load (sorry) of "problems". The problem is that the JSON file has no clue about types. The only thing it knows are Strings, Numbers, Arrays and Maps, nothing else. Because of this, if we'd want to put the...

So I've been working on this some more, and I'm currently trying to "re-build" the main menu using a JSON definition. This is what I've got so far: By using the following menu definition: { "id": "main-menu", "controller": "UIMainMenu", "children": [ {...

http://openbook.galileocomputing.de/javainsel/ :)

IMHO anything beyond 90 characters is not readable. I'm not saying that it can't be displayed, monitor resolution obviously allow for far more than 90 characters (except on my laptop), but I just hate reading long lines and then jumping back to short lines. Imagine a book where 20% of the lines...

Sure, I could just reconstruct what I did and just add it as a single commit on top of develop, but I'd really like to preserve my commit history because it turns out commit history can be really useful.

I'd say submit a pull request on GitHub, like that it can be directly tested and discussed and eventually merged, if it is liked :)

miniME89 While rebasing I noticed that you made many class renames, which are okay ("UIDisplayWindow" -> "UIWindow", "UIGraphicsElement" -> "UIImage") but they make my work of rebasing my changes on top of yours much harder. Changes like naming, which are pretty much no-brainers (but introduce...

Ah, I hadn't seen that #339 had been merged in :) I will try to adapt my prototype ASAP and create a pull request for some improvement brainstorming / alpha testing :D