Slick Forums

You probably won't like the suggestion but I'll ask anyway

I'd like to suggest a potential enhancement to the way you can use Fonts. Currently, for example choosing the font colour, you are restricted by the initial colour options you have set in the theme.xml. The theme.xml provides lots of customisations (with the fontParam's) but it doesn't allow you have a user select a colour mid way through run time and to save a colour they want to use for reload next time they start the application. So….my suggestion is to extend the Font interface and provide methods for updating and overriding values of the FontState class. There is a slight difficulty in that there is a FontState per ActionState but I am sure you could get around this by allowing you to name the FontStates in the xml and to reference that in your code.

Hmm, can't think of anything - but why would you want to change the color of a font with font parameter sets?
This will get complex - eg how to decide which color each of the font parameters get?

You could also use white fonts and use the tint stack or TintAnimator helpers to color the fonts while rendering (this is used eg in TextArea).

Or just load custom fonts at runtime (via Renderer.loadFont) ?
The renderer will not load the texture again, it will only create additional meta data (probably <1KB).
This would allow you to create enough user fonts before creating a noticeable memory leak.
And to avoid that you could add a counter of how many user fonts you have discarded and reload the theme after a limit was exhausted.

But if you have an idea for an API which can modify already loaded fonts - post them.

In the fontParameter sets you can use if="selected" etc to change the color of buttons when you change the action state. With labels and text areas there is less of this but there are still circumstances when you would want to split the colours. The color of a font is always associated with a FontState so if you do have font parameter items you will have more than one FontState in the Font.

I'll have a look at the render as this could be what I need, what I had in mind was something similar with awt where there is a deriveFont method where you can clone a font but change the size or style. The more complicated bit in Twl is that a Font can contain one or more styles (FontStates) so you would need to reference the FontState you want to update. At the moment these FontStates don't seem to have an easy way to reference them (only looked briefly), something might need to be done here. I'll see if I can mock something up in the next day or so and post an example

Here is an example way to achieve what I was thinking. The renderer method of creating a new font is slightly less good as you lose all the fontParam stuff.

Example of how theme.xml currently looks for a font

<fontDef name="normal" filename="font.fnt" color="#FF0000">
<fontParam if="armed" color="#00FF00"/>
<fontParam if="hover" color="#0000FF"/>
</fontDef>

Changes :

Add a new attribute called statename (as an example), the fontDef should default to the statename="default" (as it needs a name)

<fontDef name="normal" filename="font.fnt" color="#FF0000">
<fontParam statename="armed" if="armed" color="#00FF00"/>
<fontParam statename="hover" if="hover" color="#0000FF"/>
</fontDef>

Let this be passed all the way to FontState in LWJGLFont (BTW this class could be moved out of lwjgl package, doesn't have any lwjgl code in) via the ThemeManager

FontState needs an additional parameter in the constructor so the statename can be saved for the update method

Add a new method to LWJGLFont (example below)

public void updateFont (String fontStateName, FontParameter fontParameter)

This finds the FontState to update (maybe these should also be stored in a HashMap too for easy access).

Add a new update method to FontState

public void updateFontState (FontParameter fontParameter)

This would do a similar thing to the current constructor except it only updates the font parameters you pass to it, so if you only pass a colour it only updates the colour and leaves everything else alone

Why not just load a new font? This seems to duplicate a lot of the font loading code.

Also LWJGLFont is the implementation of the Font class - other implementation might look different or have different FontState implementations (or none at all).
Eg the TWLFontMapper implementation uses the FontParameter objects directly - without the FontState class.

public Font loadFont(URL url, StateSelect select, FontParameter ... parameterList) throws IOException

Loading a new font needs a URL, if you can't extract what the URL is from a previous font you then need to hard code it. I have the theme.xml in a jar file and I also have all the font's in a jar file so providing a URL again is very difficult. I might as well not use the xml at all and load them all manually (which is against the xml philosophy of the api).

Also you need to pass the StateSelect's, again this is already defined in the xml and it doesn't make sense to start from scratch again!

Its not a very practical method for someone using the API, I just want to change the color I don't want redefine the entire logic of the Font again.

>Also LWJGLFont is the implementation of the Font class - other implementation might look different or have different FontState implementations (or none at all).
Eg the TWLFontMapper implementation uses the FontParameter objects directly - without the FontState class.

Ok but if you are going to have Font code which the renderer uses it makes sense to have a common one. But fair enough if you want it per renderer

Regarding the TWLInput issue - yes that is ugly. Maybe I'll let the renderer create a default input when none is provided?

The ThemeManager already has a getFont(String) method.

re : getFont(String font)

can't believe I missed the getFont(String font) method!

re : LWJGLInput

The renderer is the easiest place to put it but its not really a renderer thing. I was thinking it would be good to force people to enter one when you initialise the GUI (like with the renderer) but this isn't really backwards compatible and would probably break every single project out there.

The are done.

Thanks for the quick work