It seems that the most hot topic regarding CEGUI seems to be how to find the datafiles.
I also have a few problems regarding this when using the CELayoutEditor.
It seems that the only way to specify the path to the datafiles is to explicitly write it into the cegeuilayouteditor.ini file.
This makes it hard to handle the datafiles, move datafiles, have project specific layouts but use globaly defined schemes.
My suggestion is to use an environment variable to specify the path to the datafiles.
To handle this in the runtime (when using CEGUI in my app) Im using an environmentvariable CEGUI_FILE_PATH which is a semicolonseparated (in windows) and colonseparated (in unix) pathlist with directories where to search for /layout /scheme /fonts .. directories.
e.g. set CEGUI_FILE_PATH=path1;path2;path3...
In this way I can specify where to search for datafiles using the environmentvariables. If a file is not found in path1 it continues to look in path2...
In this way, the hardcoded way of finding datafiles is replaced with a lot more flexible way of finding files.
Its a very common way of handling datafiles used in lots of other projects.
If this would be built into CEGUI, both runtime and the CELayouteditor would work the same way.
I would really reccomend something like this implemented into CEGUI.
The #1 topic: Finding datafiles.
Moderators: CEGUI MVP, CEGUI Team
Not a solution
As if that would be a solution?
Problem 1: How many celayouteditor.ini can one harddrive hold?
The editor spreads out .ini files in each directory it is started.
Problem 2: Relative paths, relative to one top directory yes.
What if you have most of the base data (schemes, looknfeel, fonts) specified in a base directory for the game engine.
The layout is what most often differs between each project (for small projects)
How come that you cant have the layout in a separate directory than rest of the stuff.
THis leads to the problem that you have to spread out the schema, looknfeel and font files into each separate project (or wherever you want to store a layoutfile).
I would call this NOT flexible.
Actually, its a NON-working solution.
So, no relative paths does NOT solve the problem.
Imagine this instead:
set CEGUI_FILE_PATH=%PROJECT_PATH%\cegui_data;%BASE_PATH%\cegui_data
Now, any font,layout,looknfeel,schema,lua directory that is found in %PROJECT_PATH%\cegui_data is used before any path in the BASE.
This partially solves the problem in that you can have project specific data with most of the core data stored in a common place.
IF CEGUI would do this when looking for its datafiles, most of the HOWCOME I CANT LOAD MY LAYOUT... questions would go away...
I have portable code for handling this which I could share with CEGUI to make the problem go away...
I have already done this in CElayouteditor, but it would be a lot better to use this in CEGUI which would make the problem go away for any app using CEGUI.
/A
Problem 1: How many celayouteditor.ini can one harddrive hold?
The editor spreads out .ini files in each directory it is started.
Problem 2: Relative paths, relative to one top directory yes.
What if you have most of the base data (schemes, looknfeel, fonts) specified in a base directory for the game engine.
The layout is what most often differs between each project (for small projects)
How come that you cant have the layout in a separate directory than rest of the stuff.
THis leads to the problem that you have to spread out the schema, looknfeel and font files into each separate project (or wherever you want to store a layoutfile).
I would call this NOT flexible.
Actually, its a NON-working solution.
So, no relative paths does NOT solve the problem.
Imagine this instead:
set CEGUI_FILE_PATH=%PROJECT_PATH%\cegui_data;%BASE_PATH%\cegui_data
Now, any font,layout,looknfeel,schema,lua directory that is found in %PROJECT_PATH%\cegui_data is used before any path in the BASE.
This partially solves the problem in that you can have project specific data with most of the core data stored in a common place.
IF CEGUI would do this when looking for its datafiles, most of the HOWCOME I CANT LOAD MY LAYOUT... questions would go away...
I have portable code for handling this which I could share with CEGUI to make the problem go away...
I have already done this in CElayouteditor, but it would be a lot better to use this in CEGUI which would make the problem go away for any app using CEGUI.
/A
I'm also having difficulties trying to use the Layout Editor with multiple projects. My current solution is to create a LayoutEditor folder for each project, each a copy of the original folder. However this makes it difficult to update the LayoutEditor.exe and supporting files; I have to update multiple folders/directories.
Adding a command-line parameter to select the .ini file to use would help:
LayoutEditor.exe -ini c:\projects\CeguiTestbed\LayoutEditor.ini
LayoutEditor.exe -ini c:\projects\OgreTestbed\LayoutEditor.ini
LayoutEditor.exe -ini c:\projects\SuperDuperProject\LayoutEditor.ini
This would allow me to create multiple icons to start the Layout Editor, each with a different parameter.
Adding a command-line parameter to select the .ini file to use would help:
LayoutEditor.exe -ini c:\projects\CeguiTestbed\LayoutEditor.ini
LayoutEditor.exe -ini c:\projects\OgreTestbed\LayoutEditor.ini
LayoutEditor.exe -ini c:\projects\SuperDuperProject\LayoutEditor.ini
This would allow me to create multiple icons to start the Layout Editor, each with a different parameter.
Adding more command-lines will only partially solve the problem of finding datafiles.
I find this fact that people are copying around data pretty disturbing.
It will make an upgrade somewhat harder in the future.
Is there anyone that can either reject or accept my suggestion?
I have emailed paul directly with no response...
Should I email it as a bug (which I think it is
Cheers,
/A
I find this fact that people are copying around data pretty disturbing.
It will make an upgrade somewhat harder in the future.
Is there anyone that can either reject or accept my suggestion?
I have emailed paul directly with no response...
Should I email it as a bug (which I think it is
Cheers,
/A
- scriptkid
- Home away from home
- Posts: 1178
- Joined: Wed Jan 12, 2005 12:06
- Location: The Hague, The Netherlands
- Contact:
Hi,
a while ago the cegui team was discussing whether it's possible to create one tool framework which allows the modification of several type of xml files.
We had the idea that it should be possible to create a project file, which has those settings you mention. That way you could open a different project file and see those paths getting updated for that specific project.
That will probably be the most clean and understandable way of dealing with those paths.
You are right about the editor's saving and loading of layout files. At this moment they are always loaded from the INI path. I know that that's confusing. It's already in mantis:
http://www.cegui.org.uk/mantis/view.php?id=124
a while ago the cegui team was discussing whether it's possible to create one tool framework which allows the modification of several type of xml files.
We had the idea that it should be possible to create a project file, which has those settings you mention. That way you could open a different project file and see those paths getting updated for that specific project.
That will probably be the most clean and understandable way of dealing with those paths.
You are right about the editor's saving and loading of layout files. At this moment they are always loaded from the INI path. I know that that's confusing. It's already in mantis:
http://www.cegui.org.uk/mantis/view.php?id=124
Possible solution?
One call would solve quite a few problems here:
CEGUI::System::getSingleton().setLayoutFilePathList(".\layouts;c:\system\layouts;d:\hisdirectory\layouts");
after this call, CEGUI looks in the above mentioned directories after a given layout when loading it.
Another method:
CEGUI::System::getSingleton().setLayoutPathEnv("CEGUI_LAYOUT_PATH");
would read the environment variable CEGUI_LAYOUT_PATH ad call setLayoutFilePathList with the value.
This would solve ALL my current problems with CEGUI.
I think it would solve the same problem for quite a few other users too.
Dont you agree?
Because, adding yet another file, or input to a CElayouteditor.ini file wont solve the general problem, how to specify where to search for data files.
Now, to make it general, the above should apply to all data-files (font,schemes...)
/A
CEGUI::System::getSingleton().setLayoutFilePathList(".\layouts;c:\system\layouts;d:\hisdirectory\layouts");
after this call, CEGUI looks in the above mentioned directories after a given layout when loading it.
Another method:
CEGUI::System::getSingleton().setLayoutPathEnv("CEGUI_LAYOUT_PATH");
would read the environment variable CEGUI_LAYOUT_PATH ad call setLayoutFilePathList with the value.
This would solve ALL my current problems with CEGUI.
I think it would solve the same problem for quite a few other users too.
Dont you agree?
Because, adding yet another file, or input to a CElayouteditor.ini file wont solve the general problem, how to specify where to search for data files.
Now, to make it general, the above should apply to all data-files (font,schemes...)
/A
- Dalfy
- CEGUI Team (Retired)
- Posts: 130
- Joined: Tue Oct 11, 2005 16:13
- Location: Paris, FRANCE
- Contact:
vr just write your own resource provider it's easy to provide your facility with a custom resource provider. At the time being the CE*Editor tools don't have a custom resource provider with similar ideas but it will change soon. But sorry if I don't agree with you. It's definitely not a #1 topic simply because CEGUI provide the ability to define your own resource provider. I would even say the problem is already handle.
- Dalfy
- CEGUI Team (Retired)
- Posts: 130
- Joined: Tue Oct 11, 2005 16:13
- Location: Paris, FRANCE
- Contact:
Look at the ResourceProvider class it's the interface used by CEGUI to find resource then implement your own and register it to your renderer of choice.
The resource provider is accessible through the Renderer interface which can seem strange first but is natural in fact. It is due to the need to integrate services provided by a graphic engine.
The resource provider is accessible through the Renderer interface which can seem strange first but is natural in fact. It is due to the need to integrate services provided by a graphic engine.
Apparently I didn't search hard enough when I made the HOWTO: Multiple .ini configurations for the Layout Editor post; this is the thread I was thinking of at the time.
The ResourceProvider approach mentioned by Dalfy is the way to solve the problem within an application. My post is only useful with the Layout Editor. Two different solutions for two different problems.
The ResourceProvider approach mentioned by Dalfy is the way to solve the problem within an application. My post is only useful with the Layout Editor. Two different solutions for two different problems.
It works like a charm, 20minutes of copy pasteing and voila a ResourceProvide of my taste.
Thanks.
The CELayoutEditor is another beast though, as it requires to find ONE single directory for each resourcegroup, whereas my solution can consists of many, so there Im using a slightly different approach, but it works, sort of.
/A
Thanks.
The CELayoutEditor is another beast though, as it requires to find ONE single directory for each resourcegroup, whereas my solution can consists of many, so there Im using a slightly different approach, but it works, sort of.
/A
Return to “Bug Reports, Suggestions, Feature Requests”
Who is online
Users browsing this forum: No registered users and 8 guests