Being able to create several IGUIEnvironment

[teto]

Hi there,

I use gamestates In my game with every state having its own ISceneManager which prevents a state from messing with a scene from another state. I wish I could do the same with IGUIEnvironment (that is to say one IGUIEnvironment per state) because right now I have to check my whole gui element tree wasn't changed by the last removed state. While doing so I noticed there is a IGUIEnvironment member in ISceneManager:
//! GUI Enviroment ( Debug Purpose )
gui::IGUIEnvironment* GUIEnvironment;

which is used only once in CSceneManager to create a billboard scenenode (and if you set a valid font in your addBillboardSceneNode call, GUIEnvironment is not even used). It creates an unncessary dependancy between the 2 don't you think ?

I also add that IrrlichtDevice could let the user set the two
-setCurrentGUIEnvironment(gui::IGUIEnvironment* )
-setCurrentSceneManager(scene::ISceneManager) //!< that would be the same as InputRecieverSceneManager.

Or would you have any advice on how to prevent side effets of one state over the IGUIEnvironment of another ?

[CuteAlien]

I usually add one top-level element for each dialog. See here for the class I use for that: http://irrlicht.sourceforge.net/forum/v ... =1&t=36577

Then I can just enabled/disable that top-element.

[teto]

that's how I've been doing things until now (using an invisible IGUITab* as main parent) but as each state needs to create its gui elements, I still need to pass an IGUIEnvironment to the state in order to create the elements. So if another programmer is not careful, he might not think of setting the state top-parent as parent of this newly created gui element.
And then you have focus. You need to take care your top-element is on front which might be another task to do when going back and forth to other states.
I know this is no big deal and that there are workarounds but to me they are still workarounds, aren't they ?

[CuteAlien]

You need IGUIEnvironment to create gui-elements. But I do not quite understand the problems, or how having another IGUIEnvironment would help you. If you have only one dialog active at a time then there should be no problem with focus (as the other dialog wouldn't be visible). If you have more than one active at a time then focus would be rather impossible to handle with several IGUIEnvioronment's active as they wouldn't know about each other. But maybe I'm not getting what you meant.

[teto]

Forget about focus (my fault for making things confusing sry ^^'').

My point is that once my GameState class gains access to an IGUIEnvironment* (and I need it to create gui elements), from there it gains access to the root gui element ( via IGUIEnvironment::getRootGUIElement () ) and thus any GameState instance can mess with the gui elements of other game states:

What I do right now:

Code: Select all

 
class IGameState {
IGUIElement* parentTab;
virtual void load(IGUIEnvironment* guienv); ///!< if I were using a IGUIelement I wouldn't be able to create gui elements in my laod function so it has to be this way.
}
 
//! perfectly fine state
class GameState1 {
virtual void load(IGUIEnvironment* guienv)
{
   parentTab = guienv->addStaticText(...)
   IGUIElement* otherGuiElement = guivenv->addStaticText(...)
otherGuiElement -> setParent(parentTab)
}
};
 
//! Rogue state
class GameState2 {
virtual void load(IGUIEnvironment* guienv)
{
    guienv->clear();   //!< will remove all gui elements even those belonging to an instance of GameState1
}
 
};
 

whereas if you can create several IGUIEnvironnement, you just create one you pass to your GameState loading function and a gamestate can't impact another anymore.

[CuteAlien]

Ok, I get what you mean. But unfortunately it wouldn't be trivial to have several gui-environments as it's not really the same as in the case of the SceneManager. The GuiEnviornment does care about focus, so mentioning that wasn't so far off. I don't know - probably it would be possible, just not trivial.

I guess I never really noticed that problem much because the way I work I never create the elements in code. Instead I load xml's with dialog-layout and then my dialogs look for certain elements by name. But I realize that this also used certain patches to engine (name, I really want to add name to IGUIElement... I think I just do that now, so I've got at least that off my todo).

[teto]

I added a few lines ( ~20 ) to add the function setGUIEnvironment (drops current and grab the one passed as argument) in IrrlichtDevice and its derivatives. Seems to work until now but I prefer to do more tests to check for side effects.

In fact for focus, in my case it makes things a bit easier, I don't need to bring gui elements to front etc... In other cases, people can stick with current way of doing things.

[CuteAlien]

Ah yes - only one active at a time, that might work. Then there shouldn't be focus problems. I guess I was too much thinking about my usual case (I often need several dialogs at the same time, so having one guienvironment per dialog wouldn't work for that).

[teto]

Well everything looks ok until now so here is a zip with 3 patches (1 per file: IrrlichtDevice, IrrDeviceStub.h/cpp I think all devices inherit from CirrDeviceStub ?) :
http://downloads.tuxfamily.org/bluecosm ... atches.zip

If anyone has a good method to create patches (on windows especially I am using diff from cygwin, not cool), I will be happy to learn (how to aggregate several patches into one).

As I said it's about adding ~20 lines so it might be easier to do it manually.

[REDDemon]

you should use SVN tortoise.

Just add as repository the link of irrlicht's repository to a folder (everything done through windows explorer and right click).

Then it will automatically download the last trunk at last revision from sourceforge . then every change made to that folder is memorized. So that after you have made some changes you have to right click the main folder and select "create patch". there will be a unique patch file. And you can check if that patch is compatible with latest changes of developers because Tortoise check if there are changes to the same files or same lines of code. You can find a lot of tutorials about how to setup SVN tortoise

(no more than 10 minutes required).

you should notice that unless hybrid gives you a password you can't "submit" changes to the trunk. so the only way is to post that patch on the tracker. Since for developers would be boring having to create and apply patches they have a faster way wich is "submit".

That's a great tool. probably should be added to FAQs