Resource Provider

[CrazyEddie]

The next thing is to modify the texture loading in the OGRE renderer to use the OgreResourceProvider rather than its current method.

I'll update the other renderers too. While it will not affect the current (default) behaviour, it's important that these go via the resource provider for when people opt for something other than the default.

CE.

PS. Thanks for the excellent work I've tried it all out now - no problems at all

[_mental_]

No probs. Sorry that it took so long for such a small bit of code Life is very hectic with a little one on the way.

[CrazyEddie]

Hey man, don't worry about it, size isn't important you know

Sounds like you're going to really going to have your hands full in a little while though - congratulations!

CE.

[Nitro]

Hi,

first of all, very nice work on the ResourceProvider!

Now, i got a little problem with it. I load my files like:

SchemeManager::getSingleton().loadScheme("/dcsdk/Resources/GUI/datafiles/schemes/TaharezLook.scheme");

This string is passed along to the resource loader and loads as expected. Then cegui tries to load the .xsd file to validate the scheme. unfortunately i get only a "GUIScheme.xsd" passed as a filename. this is clearly not enough as i need to know the path it is in. I could hack it and see if there's no path in the filename i get passed (or if it ends on .xsd) and then prepend some standard path where all the .xsd files are stored. Like if I get GUIScheme.xsd, I add a ("/dcsdk/Resources/GUI/datafiles/XMLSchemas/") in front of it. The problem with this appraoch is that i will also get filenames from inside the various schemes/imagesets/etc. which may look the same (perhaps without .xsd extension, but u never know). So the detection whether i need to prepend the path or not is not 100% fail-safe. Another stupid thing is that i need to keep some kind of central directory for the XMLSchemas.
Ideally, i would get the filename of the .xsd along with the path that the .xml file is in. That way i need to store the .xsd just along with the .xml files.
Of course if i got a lot of .xml files scattered around different directories, I'd need multiple copies of each .xsd file which is probably a bad idea. So CEGUI should have a setting like SetXMLPath() which gets prepended to the currently hard-coded "GUIScheme.xsd". That way i don't need to do some messy detection whether this is an xsd file or not to determine the proper path.
Another issue arises due to relative filenames used in the different resource files (like scheme, imageset etc.). Most of them reference to other files with sth. like "../datafiles/XXXXXX". It seem the .. is interpretted relative to the path of the executable. if i move around my exe this will change and i need to adjust all of the paths in those files which sucks. usually i'd only need to change the mountpoint in our engine and don't need to change the datafiles.
I tried to interpret the relative path in such a way that the file it is in is the "base path" and references in the file are relative to the file itself. unfortunately i can't do that cause i have no way to figure out from which specific file the "sub-file" (referenced file) was loaded. I'd need to know this to gain the base path.
Now, my final question Am I messing things up seriously here (missed some settings/don't understand cegui) or is this sth that might need to be cleared up/added to cegui?

Thanks for your answer!

-Nitro

P.S.: The babble above may be a bit unclear at times, if you have any questions about it, just ask them.

[CrazyEddie]

The first problem is that you did not state which renderer you're using; this is important since for the Ogre renderer, resource loading is done via the Ogre resource manager.

The files under the datafiles directory are designed to support the samples that will be added to the system, the paths were put in place so that these samples will function correctly when using the default resource provider. If you wish to make use of these example files yourself, then some adjustments may be required.

For the schema files, the default resource provider will try to load the file from the current directory if it's there, otherwise it will try to load from the same directory as the XML file being parsed (which is basically the behaviour ou just asked for ). For any non-default resource providers, you just need to make sure to take whatever steps are required to expose the schema file to your underlying resouce loading system.

My general opinion at the moment is that the system which is now in place is fine. I have no immediate plans to make any changes at all to these areas of the system.

It sounds to me like you need to implement your own sub-class for the resource provider and plug that into the system (very simple, just two methods to implement). This approach allows you to use whatever system you currently have in place to load the CEGUI files and you can then do away with the current paths completely.

CE.

[Nitro]

Hi crazyeddy,

thanks for your answer and sorry, that i didn't state which render i am using. i use my own renderer along with my own resource provider.
I already modified the example files to suit my needs.
Basically i created my own resource provider from the ogre example one. First it is passed a simple "GUIScheme.xsd" filename (without path). Since this can't be loaded (isn't in the current path, but in the path where the .xml file is) it throws an exception and thus loading is cancelled. Not what i want. So I tried to remove the exception after you stated that:

For the schema files, the default resource provider will try to load the file from the current directory if it's there, otherwise it will try to load from the same directory as the XML file being parsed (which is basically the behaviour ou just asked for ). For any non-default resource providers, you just need to make sure to take whatever steps are required to expose the schema file to your underlying resouce loading system.

I made it return an empty buffer, but that didn't do the trick either.
Now i've taken a look at the standard resource provider. It uses that LocalFileInputSource object. It seems to make absolute paths from relative ones (if u pass a relative one in). So our "GUIScheme.xsd" will be prepended with the current working directory i guess. Does this mean you are setting the current working directory before loading an xml file? Then it would indeed load the .xsd file from the same path where the current .xml file is.
Unfortunately i have no way to get the current working directory as this is never told to my virtual file system (via the resource provider for example). If i knew the working directory or the path where the .xml file belonging to the "GUIScheme.xsd" is in, then it would indeed be no problem mapping everything to my own file system, but i feel there's something missing (it's possible i'm wrong though).
So basically it boils down to how do i know the path to prepend "GUIScheme.xsd" with? Getting it from the xml file path ain't possible and if u set the current working directory to the xml file location (i don't know if you are doing that) i have no chance to get the path aswell.

-Nitro

[CrazyEddie]

The loading of .xsd from the same dir as the xml file that happens in the default resource provider is basically an internal thing that xerces is doing; there's nothing in cegui that sets the current directory or anything else of that nature.

I understand how this is causing difficulties, though at the moment I do not have any much in the way of suggestions. Your earlier mention of a schemas path setting may be the way to go here, though I don't want to commit to that unless I'm sure it's the best solution to the problem.

CE.

[Exsortis]

Eddie, I have a good one for you regarding this issue.

My app is using OGRE+CEGUI with the default OGRE resource provider. My OGRE resources are all zip files. Here's the situation:

I have one zip archive that contains all my UI files, under a directory called "ui" within the archive. The files are subdivided logically, so my scheme files are in "ui/schemes", layout files are in "ui/layouts", imageset files are in "ui/imagesets", and so on.

I encountered an initial error when trying to load and validate the initial scheme file. I pass the path of the scheme, "ui/schemes/IronHellsLook.scheme", which the resource provider loads and then attempts to find the schema definition, GUIScheme.xsd. That's where the first failure occurs. The .xsd file is located in the same directory as the .scheme file, but it is not found. An exception is thrown stating that "GUIScheme.xsd" cannot be found. Note that file contains no path, so the resource provider will be looking for the file at the root of whatever resources I have defined.

So, to fix this, I moved the .xsd files into the root of one of the archives, and the resource provider is able to find them. Since you stated that the loading of the .xsd file and its pathing is internal to Xerces, moving them to the root of an archive is still an acceptable solution, so I don't think it's anything that requires fixing, but it should be noted to others who run into this issue.

However, another error arises at this point. In the GUIScheme, I define an imageset, "ui/imagesets/IronHellsLook.imageset". When CEGUI attempts to load this file, somewhere along the way some path resolution occurs, and I end up with this path:

Code: Select all

/Users/pauly/Projects/Builds/Iron Hells.app/Contents/Resources//ui/schemes/IronHellsLook.scheme

Since my resources are located in archives defined as OGRE resources, only the last part of the path, the part defined in the scheme file, should be used.

I had a peek at OgreResourceProvider.cpp, and it seems that it takes the filename as provided, without path resolution, so that must be occurring within CEGUI.

[CrazyEddie]

What will now be known as "The Schema Situation" is a pain in the rear end. I could add yet another parameter where the schema path could be passed in, but I think that's kind of sucky. In a (hopefully short) few weeks, xerces and schema usgae will become an option, but we still need a 'better' option for people (like me) who will still be using the .xsd files.

For your other problem, I'll have to do some checking (I'll get back to you later today with any luck).

CE

[Exsortis]

I prefer using the .xsd files as well. I might fiddle around a bit with the code that specifies the schema file, and toss a patch at you if it works out.

[CrazyEddie]

Okay, cool. I'll wait and see if/what you come up with

[Exsortis]

*sigh* Sometimes I wonder if I should be procreating.

Exsortis wrote:
However, another error arises at this point. In the GUIScheme, I define an imageset, "ui/imagesets/IronHellsLook.imageset". When CEGUI attempts to load this file, somewhere along the way some path resolution occurs, and I end up with this path:

Code: Select all

/Users/pauly/Projects/Builds/Iron Hells.app/Contents/Resources//ui/schemes/IronHellsLook.scheme

My app is the one doing the path resolution. Since the implementation of resource providers, this isn't necessary. Apparently I missed this when updating.

Now, on the issue of XML schemas: I was thinking that parsing out the path of XML file and then appending the .xsd file would work. For example, I have "ui/schemes/IronHells.scheme". So, CEGUI would provide the XML loader with "ui/schemes/GUIScheme.xsd". The drawback of this is that it forces the app creator to provide a copy of the .xsd in the same directory as the XML file, which could be a problem if multiple files of the same schema are stored in multiple locations. (It also means that when (re)building the path to the .xsd file, CEGUI has to account for platform-specific path separators, or use something (like boost) to do it.)

I'm sure this has all gone through your head already, CE. Putting the .xsd files at the root of the resource archives "works" for now.

[CrazyEddie]

Exsortis wrote:
*sigh* Sometimes I wonder if I should be procreating.

Code: Select all

/Users/pauly/Projects/Builds/Iron Hells.app/Contents/Resources//ui/schemes/IronHellsLook.scheme

My app is the one doing the path resolution. Since the implementation of resource providers, this isn't necessary. Apparently I missed this when updating.

Hehe This would explain why I couldn't work out what was going on.

I think the schemas situation, while not ideal, is likely to stay as-is for the time being. I've thought about various solutions and none are particularly inspiring; so for now (as you said) everyone just has to make sure the .xsd files are in the root of any of the locations in the resources.cfg.

CE

[Exsortis]

CrazyEddie wrote:
What will now be known as "The Schema Situation" is a pain in the rear end.

I had a thought today about this issue.

Is it possible to add another function to the CEGUI::ResourceProvider object to locate a resource? The ResourceGroupManager in Ogre provides calls to locate files (or groups of files that match a pattern) and return the respective paths within the resource containers. I don't think it would be too much of a stretch to add a method to CEGUI's ResourceProvider to take advantage of this. Generic or renderer-specific providers could perform their own searches, or just access the current directory as an implementation of the locate function.

This would allow the schema files to be stored deeper within the renderer's resource containers, and only add a small amount of code to your XML parse setup. I'm currently doing this in my app to find the schema file:

Code: Select all

               Ogre::StringVector matches = *(Ogre::ResourceGroupManager::getSingleton().
                         findResourceNames("General", SchemaName));
               schemaFile = matches[0];

which could probably be implemented as:

Code: Select all

    RawDataContainer rawSchemaData;
    String schemaPath = System::getSingleton().getResourceProvider()->findResource(GUISchemeSchemaName, resourceGroup);
    System::getSingleton().getResourceProvider()->loadRawDataContainer(schemaPath, rawSchemaData, resourceGroup);
    MemBufInputSource  schemeSchemaData(rawSchemaData.getDataPtr(), rawSchemaData.getSize(), GUISchemeSchemaName, false);
    parser->loadGrammar(schemeSchemaData, Grammar::SchemaGrammarType, true);

What do you think?

-E

[CrazyEddie]

This is certainly a good possibility, and certainly solves the issue of putting the .xsd files in zips for Ogre use.

I'll see if I can get this, and also another fix to restore previous behaviour to DefaultResourceProvider some time shortly.

Thanks for the good suggestion.

CE.