matt wrote:Why is it naughty to create Windows by 'new' ?
There are two main reasons, the first is for management reasons - basically it's somewhat helpful for the system to know what objects were created in order that they can later be cleaned up nicely. The other reason is related to the structure of the provided widgets and the fact that (as you found, I think) if you create a CEGUI::PushButton via the new operator, nothing will be rendered for it - this is because when creating a objects via the WindowManager, usually you are actually creating two objects - one of a CEGUI::Window derived class and another of a CEGUI::WindowRenderer derived class - and then associating these with each other along with a 'WidgetLook' specification (usually that was loaded from looknfeel XML), and together these three items form the 'Window' that you see rendered on the screen.
It should be possible to create Window subclasses that do all of their own rendering; that do not rely on a WindowRenderer or WidgetLook. You would just add this to WindowFactoryManager via the addFactory template (in 0.7.x likely using the TplWindowFactory wrapper). Then you could create instances via WindowManager. If this does not work, and you get some exception about needing a WindowRenderer, then that's a bug which should be reported
KishukuOni wrote:In my project (uses CEGUI 0.7.5) we use empty "" names for all of the windows that are created in code (as opposed to xml). We are using the WindowManager to create windows.
CE, it sounds like you are saying that that capability will not be in 0.8. Even if things HAVE to have names, it would be nice to be able to say: "Create a window/widget, I dont care what its name is."
I will explain the situation in a bit more detail
In 0.7.x when you create a window using the WindowManager and pass the empty string for the name, the window will actually receive a unique name that is generated internally, and this has not changed in 0.8.x.
The change in 0.8.x basically introduces the concept of a name 'path' for windows that are part of a hierarchy. Prior to 0.8.x, the idiom has been that windows are named according to the hierarchy the user creates. So typically you have a root window named "Root" and to this you might add a FrameWindow, and because it's attached to the root, you name it "Root/MyWindow", and if you then decide to add a button to that FrameWindow, typically you name it "Root/MyWindow/SomeButton". Which is all very nice, but in complex scenarios, it becomes a real PITA to keep names unique. In 0.8.x, windows are named more simply: the root would still be "Root", but the FrameWindow should be named simply "MyWindow" and the button simply "SomeButton" (it is possible to create multiple windows with the same name). When you combine these windows, CEGUI 0.8.x automatically deals with the path-like aspect of hierarchical names - so even though the separate windows no longer contain the full 'path' of the name, you can still ask the root window for "Root/MyWindow/SomeButton" and get the right window. The really cool thing is that you can remove the button from "MyWindow" and add it to "MyOtherWindow" and the path to the button changes to "Root/MyOtherWindow/SomeButton".
Anyhow, how does this relate to what I said, and why would empty names not work in 0.8.x? Basically, I said that because matt is creating names via the new operator rather than WindowManager, and I said that he could probably get away with using empty names. When creating windows in this way, if you specify an empty name, the name really would be empty, as opposed to receiving a generated name from WindowManager. This is significant because in 0.7.x you can theoretically add multiple child elements to a window, where those child elements all have the same name (bypassing the WindowManager would allow that to happen). In 0.8.x, because detached windows with the same name are fully supported, and because the path-like behaviour is constructed internally, we must check that each window only has one immediate child with any given name - so adding multiple child elements with the same name would throw an exception.
That's a lot of waffle to basically say: do not worry, when using WindowManager to create windows with blank names, this will continue to work in 0.8
CE.
This said, I'm glad you found a pretty simple way to handle the naming - although if names are not going through CEGUI::WindowManager, I think you could use blank names anyway, though I'm not 100% sure (ironically, that should would work in 0.7.x, but probably would not in 0.8.x).