Resource Provider

[_mental_]

I thought I'd start a thread about the resource provider that I'm working on to let people know the progress. I've just finished my first pass of the code and have .scheme files loading using OGRE's resource management system. There's still plenty to do before I can submit this as a patch though.

[CrazyEddie]

Great to hear that you're making good progress with this. Whenever you have the patch ready that cool with me; I'm just grateful that you're taking the time to do this

[_mental_]

Just to give everyone an update, I am still working on this project but have been busy with work & family commitments recently. I'll post again when I've made more progress.

[_mental_]

OK as of tonight I have hammered out the last of my resource loading issues (namely loading xsd files from memory). I have now got my local copy of CEGUI to load all of its resources from the OGRE resource manager via a sub-classed CEGUI resource provider.

I still have a few things to do before this is complete:
1) Write a default resource loader which will act in the way CEGUI currently loads files (half complete).
2) Refactor texture loading in the ogre renderer to use the CEGUI resource provider.

I'm sure there are others I just can't remember them right now.

[CrazyEddie]

This is going to be great

Thanks for the progress update.

[_mental_]

CE a quick question.

Because of the way the resource provider deals with loading data I've had to modify the font, imageset, scheme etc classes to take an InputSource instead of a filename. Since each of the respective managers control the creation of each of these objects do I need to keep the load by filename option? I'd rather remove it if it's not going be used anymore, but if you know of a need for it thats fine too

[PeterNewman]

So a side effect of this will be that CEGUI will have a standard replacable resource provider? This will help me no end.

Good work _mental_, and CE too!

[CrazyEddie]

@_mental_:
I don't really have any objection to removing the old methods, though there may be others who still wish to use them. If they're not harming anything, leave them in for now.

Having said that I may go back and remove them myself at some stage later on, but for now I'd like to minimise any further uproar. What you could do is add a documentation note to say that the old methods are depreciated, and that the new system should be preferred.

CE.

[_mental_]

@PeterNewman: Yep. The idea is that you could create your own sub-class if you so wished.

[_mental_]

hmm... now that this project is 95% finished I think I'm going to have to re-think parts of the design. At the moment the resource provider relies on using Xerces memory buffers which work perfecly when combined with the OGRE resource system, but I'm having a bitch of a time using them with the default resource provider.

The default resource provider is quite simple as it literally just loads a file into an Xerces memory buffer, but something seems to be going wrong when creating the buffer as I'm continually getting unexpected EOF errors. It occurs to me that I shouldn't really be loading file myself as Xerces deals with that internally without any issue.

So back to the drawing board.

[_mental_]

Ok I think I have my design issues sorted. Hopefully I can finish this all up tomorrow.

[CrazyEddie]

Cool. I'm looking forward to this as I'd like to test this out and get it in before packaging up the first downloadable release for the system in the very near future.

CE.

[_mental_]

Ok make that tomorrow.. there's just not enough hours in the day sometimes.

[_mental_]

CE,
Could you review the following files for the resource provider and let me know what you think.

http://sourceforge.net/tracker/index.ph ... tid=605424

[CrazyEddie]

Everything looks okay generally, save for a couple of memory leaks...

In DefaultResourceProvider::loadRawDataContainer, if the exception path is taken 'buffer' is left allocated.

The other one is for DataContainer in general, the object referred to (mData) is never released.

I think the most obvious thing to do is add a free() or release() method which can be called from the destructor, though due to the delete/delete[] difference between the two specialisations, I think possibly the best approach is have 'delete' as a default, but provide a specialisation for the unsigned char version to use delete[].

We may also want to consider calling this 'free' method to release any previous object/buffer when setData is called, though this would not strictly be required depending upon the expected use of DataContainer (i.e. it's mainly an internal thing).

CE.