Loading styles using an AssetLoader (with patch)

Hi,

I have the need in my project to make use of a custom chain of AssetLocator to retrieves my assets. These can get encrypted assets from an HTTP server, caches them locally, and more.

However, I found that Tonegodgui actually uses the class loader directly to load its style sheets (although uses AssetManager for everything else). I would like these to be treated as any other asset, so have patched Screen and created a new StyleLoader class to achieve this.

The patch can be found here.

Note, there is one gotcha. The StyleLoader is added to the AssetManager the first time a Screen is constructed. However, because the file name used for styles does not follow the same pattern as Meshes, I believe there is a potential for problems. This is best explained perhaps looking at the asset manager configuration file (if this were to be used instead of directly registering the new loader against the asset manager instance).

[java]
LOADER com.jme3.scene.plugins.ogre.MeshLoader : meshxml, mesh.xml
LOADER com.jme3.scene.plugins.ogre.SkeletonLoader : skeletonxml, skeleton.xml
LOADER tonegod.gui.core.StyleLoader : xml
[/java]

Note that both meshes and skeletons both have special suffixes. IF there were any other XML assets that get loaded this way, they would always go through style loader. As it stands this doesn’t matter, because there are no other XML types used, but tonegodgui should not assume this.

So being as Tonegodgui is native to JME3, I believe it should probably follow the same pattern, e.g. for the default style map, default.style.xml (or something). The same would go for any included component XML files.

On a side note, I wonder if it’s possible to have a way of using relative paths for assets pointed to in style files. Currently styles are not relocatable because of this.

RR

1 Like

Done and committed. I need to give some thought to the change from .xml to .xxxxx.xml.

It does need to happen, just want to see what I can break here first.

The only really change (I see off the top of my head) will be a single line code update for anyone using a custom style or atlasing…
And, a bunch of renaming local xml files.

As for the relative path to assets… Not sure on this one, because it completely depend on what they were relative to :wink: As it is, they are… but that’s also relative…

Ok… this is getting worse. You get the general idea though. Thoughts on how to resolve this?

Actually, not following on the “not relocatable”. Explain a bit more?

Oh… you mean separate from the XML file… no, as far as I can tell, there is no way of doing this. However, the related XML file would need to be updated with new data if you were to change the image(s) i.e. How to stretch the image, etc

There is no relative asset paths. Asset paths are absolute like class paths.

1 Like

@normen thanks for saving me time!

@rockfire The diff patch couldn’t be applied, as it was written against your local modified version of Screen. I missed the change to LayoutParser and will get this updated today

Oh, and lastly… I added the @author info to the loader, however I had to use your screen name as I didn’t have any other info. If you would like this changed, just let me know.

@t0neg0d said: Done and committed. I need to give some thought to the change from .xml to .xxxxx.xml.

It does need to happen, just want to see what I can break here first.

The only really change (I see off the top of my head) will be a single line code update for anyone using a custom style or atlasing…
And, a bunch of renaming local xml files.

As for the relative path to assets… Not sure on this one, because it completely depend on what they were relative to :wink: As it is, they are… but that’s also relative…

Ok… this is getting worse. You get the general idea though. Thoughts on how to resolve this?

Oh, thanks! I’ll check it out now. Understood on the file names, that would be a bit more of a pain for existing users.

So by relative paths I mean more like CSS / HTML where images, audio, fonts etc are usually referenced using paths relative to the location of the .css file that includes them.

As normen says, the asset manager itself uses absolute paths. Perhaps style.xml files themselves are a little different though? i.e. there could be lots more of them in a “set”, all pointing to various images, sounds and other related XML files.

I brought this up because a couple of times during refactoring I have changed the folder/namespace my styles are in (i.e relocated them). Each time I had to go through each style.xml and change the absolute locations. I mean, this is not really a big deal at all, it’s just something you don’t have to deal with, say, when using CSS ‘themes’. Generally you can just extract your CSS anywhere, as long as you point the HTML to the root of it, no further works needs doing.

I can’t see a reason why the tonegodgui style parser could not handle this itself. It knows the current location of the style file it is parsing, it just needs to translate the paths it finds into absolute ones for the asset manager to deal with.

I wonder if you could use another “type”. I.e, paths are currently using type=“String”, how easy would it be to add another type … type=“RelPath”. This is actually a String, but before it gets stored, its contents are treated as an relative path that needs to be absolutized against the current style file location.

@t0neg0d said: @normen thanks for saving me time!

@rockfire The diff patch couldn’t be applied, as it was written against your local modified version of Screen. I missed the change to LayoutParser and will get this updated today

Oh, and lastly… I added the @author info to the loader, however I had to use your screen name as I didn’t have any other info. If you would like this changed, just let me know.

Hehe, you must have replied while I was ranting my previous reply :slight_smile:

Apologies for the patch. I even actually looked at it to make sure it didn’t include anything to pollute it. I fail :\ Will get another patch together, expect it soon.

The rockfire name is fine also.

@rockfire said: Oh, thanks! I'll check it out now. Understood on the file names, that would be a bit more of a pain for existing users.

So by relative paths I mean more like CSS / HTML where images, audio, fonts etc are usually referenced using paths relative to the location of the .css file that includes them.

As normen says, the asset manager itself uses absolute paths. Perhaps style.xml files themselves are a little different though? i.e. there could be lots more of them in a “set”, all pointing to various images, sounds and other related XML files.

I brought this up because a couple of times during refactoring I have changed the folder/namespace my styles are in (i.e relocated them). Each time I had to go through each style.xml and change the absolute locations. I mean, this is not really a big deal at all, it’s just something you don’t have to deal with, say, when using CSS ‘themes’. Generally you can just extract your CSS anywhere, as long as you point the HTML to the root of it, no further works needs doing.

I can’t see a reason why the tonegodgui style parser could not handle this itself. It knows the current location of the style file it is parsing, it just needs to translate the paths it finds into absolute ones for the asset manager to deal with.

I wonder if you could use another “type”. I.e, paths are currently using type=“String”, how easy would it be to add another type … type=“RelPath”. This is actually a String, but before it gets stored, its contents are treated as an relative path that needs to be absolutized against the current style file location.

Oh… this is likely possible… Let me look at parseStyles and see how I can make this work.

EDIT: L&F style parsing is going to be slit out from the screen class sooner or later and condensed down to methods for performing repetitive tasks. This should have been a long time ago… but it was yet another one of those… I just need to get this working and move on to the 3000 other things on the todo list.

@rockfire said: Hehe, you must have replied while I was ranting my previous reply :)

Apologies for the patch. I even actually looked at it to make sure it didn’t include anything to pollute it. I fail : Will get another patch together, expect it soon.

The rockfire name is fine also.

Np on the patch… as long as it isn’t REALLY lengthy, I can go through it line-by-line. The diff patches contain enough code on either side for me to quickly find the locations in the source.

Also, don’t think I have forgotten about the layout stuff!

if you need to get xml/json inside of jar(asset folder) so you can get it with relative path:

[java]
InputStream inputStr = getClass().getResourceAsStream(relPath); // GET FROM JAR

// HERE IS THE EXAMPLE OF JSON PARSER
InputStreamReader inputStrRead = new InputStreamReader(inputStr);
BufferedReader bufRead = new BufferedReader(inputStrRead);
jsObj = new JsonParser().parse(bufRead).getAsJsonObject();
bufRead.close();
bufRead = null;
inputStrRead = null;
[/java]

You can “hack in” relative paths the way they work for ogre xml and other external formats too. As was indicated you simply create the assetpath at runtime. However this is against the paradigm of jME where we try to have an absolute reference to every file to avoid doubling and to be able to reference specific files from anywhere. In the end the only advantage is that you can move files from one folder to the other but your code has to be adapted anyway and the “folder” concept is void when you deploy your application and turns into what assetpaths already are.

@normen said: You can "hack in" relative paths the way they work for ogre xml and other external formats too. As was indicated you simply create the assetpath at runtime. However this is against the paradigm of jME where we try to have an absolute reference to every file to avoid doubling and to be able to reference specific files from anywhere. In the end the only advantage is that you can move files from one folder to the other but your code has to be adapted anyway and the "folder" concept is void when you deploy your application and turns into what assetpaths already are.

These are paths internal to the xml files. They will end up absolute paths once handed off to the loader or assetManager. At least conceptually they will :wink:

@t0neg0d

I’ve now updated to your latest source and I see you got the asset loader in, it’s all working good here.

However, my layout stuff seems a bit broken. I am trying to narrow the problem down, I’d hold fire before you do anything with it just yet.

@rockfire said: @t0neg0d

I’ve now updated to your latest source and I see you got the asset loader in, it’s all working good here.

However, my layout stuff seems a bit broken. I am trying to narrow the problem down, I’d hold fire before you do anything with it just yet.

Couple things you should make sure you do prior to trying to track down a bug that may not exist.

Recompile! (i.e. clean and build) - This is critical if this is an Android deployment anyways.

It is also likely that tonight’s patch with the xml extension name change will fix any conflicting xml related issues.

You likely did this, but wanted to mention it in case you overlooked it. I did while testing old projects. :wink:

Also note, the LayoutParser updates didn’t make it into this release (I don’t think). If you are using these, issues might show up.

EDIT: What problems specifically are seeing there?

Yup, thanks for tips, but did all that. Its certainly down to the layout code, as raw tonegodgui stuff is working fine. I think i’ve tracked down at least part of the problems though. Not sure of solution yet though.

Two problems so far

  1. Panels (and maybe other components) are getting crazy initial sizes.

This seems to be because of a slight change as to how orgDimensions is handled. Many of my controls use an orgDimensions of new Vector2f(Float.MAX_VALUE,Float.MAX_VALUE); (usually in the constructor) to signal that instead of fixed dimensions, the size should be calculated by using the layout of the children.

This massive size however should never “leak through” and be the final control size, it should always get intercepted by the layout manager and set to the right value. That is not happening in some places because I believe orgDimensions is changing (even if only slightly). Should this value always be the “orginal dimensions” or am I misunderstanding it’s name?

I think I need to change this behavior and have some other way to signal a fixed size should not be used.

  1. I also have a problem where the initial component layout is wrong too. This is something again isInitialized /setInitialized I believe. I just experimented by setting that flag myself when layout happens and it has improved things somewhere. I need to play more with this though.

RR

@rockfire said: Yup, thanks for tips, but did all that. Its certainly down to the layout code, as raw tonegodgui stuff is working fine. I think i've tracked down at least part of the problems though. Not sure of solution yet though.

Two problems so far

  1. Panels (and maybe other components) are getting crazy initial sizes.

This seems to be because of a slight change as to how orgDimensions is handled. Many of my controls use an orgDimensions of new Vector2f(Float.MAX_VALUE,Float.MAX_VALUE); (usually in the constructor) to signal that instead of fixed dimensions, the size should be calculated by using the layout of the children.

This massive size however should never “leak through” and be the final control size, it should always get intercepted by the layout manager and set to the right value. That is not happening in some places because I believe orgDimensions is changing (even if only slightly). Should this value always be the “orginal dimensions” or am I misunderstanding it’s name?

I think I need to change this behavior and have some other way to signal a fixed size should not be used.

  1. I also have a problem where the initial component layout is wrong too. This is something again isInitialized /setInitialized I believe. I just experimented by setting that flag myself when layout happens and it has improved things somewhere. I need to play more with this though.

RR

I’ll double check this, but I don’t think I have altered orgDimensions usage (as it is currently not used). This was added a waaaaaays back in hopes of being able to update how child resizing works. I wanted to be able to keep layouts proportionate to their component placement… i.e. if you have 3 items side by side, they will stay proportionately the same by altering both their position and dimensions. Unfortunately, I have yet to get this to work as I was hoping to. Once the first resize is complete, everything goes wonky.

So, as far as I know, orgDimensions is set when the component is… um… created and not used as of yet.

Turns it out this actually happened when I did a little, ahem, refactoring. I must have got copy and paste happy or something, and accidentally added a layout manager to Screen. This never worked before, and it still doesn’t.

The orgDimensions thing was a red-herring that was more a symptom than a cause.

Fix commited and It’s working as before now. I also took advantage of your new Element.getElements() method and got rid of the first of the reflection hacks :slight_smile:

RR

1 Like
@rockfire said: Turns it out this actually happened when I did a little, ahem, refactoring. I must have got copy and paste happy or something, and accidentally added a layout manager to Screen. This never worked before, and it still doesn't.

How could you??!?

I’ve never used cut/parste… ever…

Apparently, I’ve never told the truth before either.

Glad you found & fixed this! As I’m going to be milling over Layout stuff soon & will likely have a ton of questions.

Btw, was it you that submitted the list control update for Modeled Lists? That thread got corrupted right after I replied to it and until recently, I didn’t know you could log out and view it.

@t0neg0d said: How could you??!?

I’ve never used cut/parste… ever…

Apparently, I’ve never told the truth before either.

Glad you found & fixed this! As I’m going to be milling over Layout stuff soon & will likely have a ton of questions.

Btw, was it you that submitted the list control update for Modeled Lists? That thread got corrupted right after I replied to it and until recently, I didn’t know you could log out and view it.

Haha. I believe you, or not :slight_smile:

Yup, that was me. If you didnt realise, I separated the patch for them too. It’s here. Although it will probably conflict on style_map.xml now.

1 Like
@rockfire said: Haha. I believe you, or not :)

Yup, that was me. If you didnt realise, I separated the patch for them too. It’s here. Although it will probably conflict on style_map.xml now.

Np… I had a thought on how to wrap this into the existing controls to simplify the choice of which to use. I’ll likely have questions on this also =P