/ i work with keypresses and render text onscreen -.-/
Text rendering is implemented quite extensively in current PreUI
. Keypresses are not processed internally yet, though, as I mostly work with mouse. Priority increased.
/At first read I've found very difficult to read your code because you don't follow Java naming conventions/
My bad. Since it's public now, I have to clean it up.
What would be the good naming choice that would allow to separate sorting-IDs (A, B, C) from the class name itself? I use such sorters only in examples, to make the order in which sources are to be read more self-explanatory.
Uppercases will be fixed in R3, thanks.
Static resource loading is done consciously. Apart from being "bad practice", what harm does it bring? IMHO, having a predefined set of basic resources is good. If they trouble you, I can make them non-loaded by default and require an explicit call from programmer.
I probably should add some integration with Slick ResourceManager, but it's a question that needs further investigation -whether any sort of additional integration is actually needed, or if it would Just Work (TM) already.
Dependencies: most of them actually are Slick ones, PreUI generally depends on itself and on Slick. Complete pack is included to simplify the checkout process - I provide the pack I work with personally so that ""Which version?" question would not arise.
Logging: once again, my bad. I hope I'll migrate to proper logger by R3.
/About SlickStateTemplate, I have another library (MarteEngine) build on top of slick that already extends BasicGameState, do you have in mind to extend it or do you think is possible to encapsulate logic in my code without extend anything?/
I'll have a look at it, I don't know how much they overlap. Probably one of us could extend from the other. Or I could externalize most of the UI construction logic to non-State module, but you'll lose some of the briefness then, as you'll have to write "someModule.addButton" rather than simply "addButton". It's minor, but can be annoying
What is your extended BasicGameState? "World" class or something else?
/Can you explain "processClickedMarker" way to retrieve click on buttons? Seems to be something unusual for Java, where this kind of thing is handled usign Listeners/
Listeners are fat
. In order to implement one, you need to define one additional method per button (or per group of buttons if we take Nifty - overhead coding anyway). I use a simpler (prehistoric) way: check if mousebutton is clicked, then check coords from the list of stored State elements to find out which element is under the mouse now (unclickable elements like menus are ignored). It's not as expensive as it sounds: as I've mentioned above, both redraw and click processing for state with 300 element stayed at constant 100 FPS, so that shouldn't be a problem.
What good do the listeners bring to the table? I suppose system could be taugth to silently catch button listener signals and redirect them to something like processClickedMarker for further processing - but is it actually worth doing?..
Thanks for the valuable advice... And sorry for the mess: even though I've been leisurely coding for about half of my life (not in Java, though), I'm not a properly educated programmer, and I guess it shows