CEGUI (Crazy Eddie's GUI) Forums

Repro steps:
1. Run Python port of Falagard demo with immediate mode
2. Type "WindowManager.getSingleton().DEBUG_dumpWindowNames('LEFTIUM')" into console and press [ENTER]
3. Inspect CEGUI.log

OR

1. Modify FalagardDemo1 to call WindowManager.getSingleton().DEBUG_dumpWindowNames("LEFTIUM")
2. Run
3. Inspect CEGUI.log

Expected results:
- Window names have slash (/) between 'Demo' prefix and rest of window name
- Example: Demo/Vanilla/Console

Actual results:
- Window names missing slash (/) between 'Demo' prefix and rest of window name
- Example: DemoVanilla/Console


Comments:
- This probably repros with the C++ version of CEGUI, too, but untested.
- Possibly cause of Function WindowManager::getWindow won't work

Environment:

You did not really specify which aspect you thought was buggy - the prefix code not automatically appending a "/", or the client code supplying "Demo/" instead of "Demo" as a prefix? In a way these results actually help to clarify CEGUI's current approach to window-naming - it is entirely your responsibility.

The window-naming convention in CEGUI takes a global, non-interference naming approach. In other words, the relative-naming you think you see is just a farce. For example, the name "Vanilla/Console/Editbox" is the literal name of that single Editbox widget - that name is manually composed by the author of the Layout (see .layout file). As such, CEGUI cannot blindly assume the author is using a "/" hierarchy naming-convention. The client could very well be using a "-" hierarchy style, or may not even use a hierarchical style.

Also, the naming-convention CEGUI uses will be changed (imo improved) in v0.8. The "/" hierarchy style will be enforced. In this case, I would say it makes more sense for the prefix-code to automatically append a "/".