CEGUI (Crazy Eddie's GUI) Forums

I created this thread following the discussion I have add with guyver6 and whitelynx on IRC. This thread is for you who are using CEGUI and want to suggest new features, cleanup, and more within CEGUI next development branch. In order to post here you need to spend some time with 0.5.

Feel free to suggest and ask for enhancement

Please use one post per feature or idea...

CEGUI need custom memory allocator.


Some user (can't remember who ) are interested in managing the memory allocated by CEGUI.

Code Cleanup
Cegui use to much exception (from someone on IRC.)

Speed, and ease of use.
But most of all: stability and predictability.

A more generic script interface, allowing you to utilise the scripting language you already use, would be a good thing to have.

A stream-lined production pipe-line is one of the things I'd like to see the most:
From visual skin creation, to layout editing and event handling - effectively removing the need to ever look at all those XML files again.

It would also be really cool to have a vector renderer. That would allow some really slick interfaces!

But the most important thing is to stabilise things: improve exsisting widgets/controls, create new ones (drag-and-drop grid control for RPG style inventories?)

CEGUI has taken it's twist and turns - I think it's time to focus and expand what's already in CEGUI, waiting to come out.

That probably means efforts in the way of tools, documentation and optimisation.

Numeric (enum) error handling as opposed to fully formed String. This would help internationalisation and maybe more precisely define the nature of a problem, giving the ability to apply the correct fix. Some error messages may only require an error number but others may require "parameters", such as when creating a window with the name of an existing one (the parameter would be the conflicting name).

Speaking of internationalisation, I'll eventually need the ability to load screens/layouts in multiple languages. My current just-waking-up approach would be something like this: and within the LayoutEditor I would be able to input this text in multiple languages at once, via a language combobox.

More layout possibilities such as anchoring the left side of an Editbox, only allowing the right to be stretched/shrunk and never stretching/shrinking vertically. I'm not sure if I'm clear in this.

jacmoe wrote:But the most important thing is to stabilise things: improve exsisting widgets/controls...

...CEGUI has taken it's twist and turns - I think it's time to focus and expand what's already in CEGUI, waiting to come out.

I couldn’t agree more. In my view it is absolutely imperative to strengthen the foundations before anything else.

The widgets are what make a G.U.I a G.U.I. The buttons, the textboxes, the scrollable pane…my preference would be to have these working consistently solid and polished, or even a new widget introduced, rather than have some other new peripheral (relatively speaking) feature.

Indeed. But I must say that 0.5.0 looks like a meaner and leaner CeGUI to me.

I talked to you a little on IRC, so I'll summarize here my propositions (which are based on real project we're using CEGUI in).

* Total code review for naming inconsistency (one class has setSortingEnabled() method, second has setSortEnabled() and another one sortingEnabled()).
* Rename methods due to removal of metrics mode and to clean API. Ie. Window::setWindowPosition() -> Window::setPosition() - removed repeatition, Window::setWindowXPosition() -> Window::setLeft() - removed repeatition, better shows intention (X is not always the lenght from left side of the screen, while Left is)
* Rename properties due to removal of metrics mode. UnifiedPosition, UnifiedSize, UnifiedArea can become Position, Size and Area since no name clashes will occur.
* Change syntax for Unified dimentions (why use { instead of (?, why so complicated syntax like {{0,4},{0,-5},{1,2},{1,3}} ? with some more thought it could be made easier to read)
* Add Window::getPropertyIterator() and Window::getEventIterator() methods to ease access to iterators of Window superclasses

Feel free to remove that change of syntax, it's more a wish, thou the rest is more due to my experiance with CEGUI. I'll create wiki page where I'll sum up all renaming propositions.

Rackle wrote:More layout possibilities such as anchoring the left side of an Editbox, only allowing the right to be stretched/shrunk and never stretching/shrinking vertically. I'm not sure if I'm clear in this.

That is already possible with UDims.

should be more stable, the scroll bar will cause the program's crash.

Rackle wrote:Speaking of internationalisation, I'll eventually need the ability to load screens/layouts in multiple languages. My current just-waking-up approach would be something like this:
...
and within the LayoutEditor I would be able to input this text in multiple languages at once, via a language combobox.

Very important point imho, a central string table/registry would be great for this kind of thing.

I find myself creating UI dialogs that share sub components. One example would be an inventory dialog as a 4x4 grid of buttons. Each button contains a StaticImage and a StaticText name. In the Layout Editor I would create the first button then copy-paste for the additional 15 needed. Then I create a merchant dialog and basically repeat these steps.

The problem is when I decide to update this button with image and name I then I have to find each dialog that contains these buttons and then update each instance. The solution could be to create a new XML element that would read the contents of a second .layout file. Something along the lines of:



The WidgetDefinition.layout file would contain the widget that I want to repeatedly import into the current layout.

The Name element and the Position and Size properties are used as normal. The Type element instructs to import a .layout and the Filename property specifies which file to import.

Taharez wrote:

Rackle wrote:Speaking of internationalisation, I'll eventually need the ability to load screens/layouts in multiple languages. My current just-waking-up approach would be something like this:
...
and within the LayoutEditor I would be able to input this text in multiple languages at once, via a language combobox.

Very important point imho, a central string table/registry would be great for this kind of thing.

The problem with string table is that they do not solve the issue at all. They are not enough and full internationalization of CEGUI is a lot harder than simply being able to set a string table. Solution for such thing exists (gettext) and can be used with CEGUI.

I don't think it's not an important topic but just a string table is not enough

Rackle wrote:I find myself creating UI dialogs that share sub components. One example would be an inventory dialog as a 4x4 grid of buttons. Each button contains a StaticImage and a StaticText name. In the Layout Editor I would create the first button then copy-paste for the additional 15 needed. Then I create a merchant dialog and basically repeat these steps.

The problem is when I decide to update this button with image and name I then I have to find each dialog that contains these buttons and then update each instance. The solution could be to create a new XML element that would read the contents of a second .layout file. Something along the lines of:

Code: Select all

<Window Type="TaharezLook/FrameWindow" Name="Demo7/Window1">
  <Property ...

  <Window Type="TaharezLook/Button" Name="Demo7/Window1/Quit">
    <Property ...
  </Window>

  <Window Type="LayoutImport" Name="Demo7/Window1/DynamicWidget1">
    <Property Filename="WidgetDefinition.layout" />
    <Property Name="Position" Value="x:0.2 y:0.2" />
    <Property Name="Size" Value="w:0.5 h:0.5" />
  </Window>

  <Window Type="LayoutImport" Name="Demo7/Window1/DynamicWidget2">
    <Property Filename="WidgetDefinition.layout" />
    <Property Name="Position" Value="x:0.2 y:0.2" />
    <Property Name="Size" Value="w:0.5 h:0.5" />
  </Window>
</Window>


The WidgetDefinition.layout file would contain the widget that I want to repeatedly import into the current layout.

The Name element and the Position and Size properties are used as normal. The Type element instructs to import a .layout and the Filename property specifies which file to import.

Lindquist would confirm this but it's already possible to import a layout from within a layout. There's a tag for this. You might have a look to the XML Schema file to be sure its available.

Porting the tree control would be nice.