0.6.X What do you want to see in 0.6 series

Discussion regarding the development of CEGUI itself - as opposed to questions about CEGUI usage that should be in the help forums.

Moderators: CEGUI MVP, CEGUI Team

User avatar
Dalfy
CEGUI Team (Retired)
Posts: 130
Joined: Tue Oct 11, 2005 16:13
Location: Paris, FRANCE
Contact:

0.6.X What do you want to see in 0.6 series

Postby Dalfy » Wed Jun 21, 2006 12:05

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...

User avatar
Dalfy
CEGUI Team (Retired)
Posts: 130
Joined: Tue Oct 11, 2005 16:13
Location: Paris, FRANCE
Contact:

Postby Dalfy » Wed Jun 21, 2006 12:07

CEGUI need custom memory allocator.


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

User avatar
Dalfy
CEGUI Team (Retired)
Posts: 130
Joined: Tue Oct 11, 2005 16:13
Location: Paris, FRANCE
Contact:

Postby Dalfy » Wed Jun 21, 2006 12:09

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

User avatar
jacmoe
Just can't stay away
Just can't stay away
Posts: 136
Joined: Sun Apr 03, 2005 14:18
Location: Holbaek, Denmark
Contact:

Postby jacmoe » Thu Jun 22, 2006 11:46

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. :wink:

Rackle
CEGUI Team (Retired)
Posts: 534
Joined: Mon Jan 16, 2006 11:59
Location: Montréal

Postby Rackle » Thu Jun 22, 2006 12:31

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:

Code: Select all

<Window Type="TaharezLook/FrameWindow" Name="MyWidget" >
  <Property
  ...
  <language id="en" value="My label" />
  <language id="fr" value="Mon libellé" />
  <language id="de" value="Mein Wortlaut" />
</window>
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.

User avatar
spannerman
Home away from home
Home away from home
Posts: 330
Joined: Wed Jan 12, 2005 12:06

Postby spannerman » Thu Jun 22, 2006 21:50

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.

User avatar
jacmoe
Just can't stay away
Just can't stay away
Posts: 136
Joined: Sun Apr 03, 2005 14:18
Location: Holbaek, Denmark
Contact:

Postby jacmoe » Fri Jun 23, 2006 01:38

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

guyver6
Just popping in
Just popping in
Posts: 11
Joined: Wed Jan 12, 2005 12:06
Contact:

Postby guyver6 » Fri Jun 23, 2006 21:09

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.

guyver6
Just popping in
Just popping in
Posts: 11
Joined: Wed Jan 12, 2005 12:06
Contact:

Postby guyver6 » Fri Jun 23, 2006 21:41

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.

billconan
Just popping in
Just popping in
Posts: 12
Joined: Wed May 17, 2006 14:11

Postby billconan » Sat Jun 24, 2006 04:32

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

User avatar
Taharez
Not too shy to talk
Not too shy to talk
Posts: 30
Joined: Mon Mar 07, 2005 19:06
Location: Sweden
Contact:

Postby Taharez » Sat Jun 24, 2006 14:51

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.

Rackle
CEGUI Team (Retired)
Posts: 534
Joined: Mon Jan 16, 2006 11:59
Location: Montréal

Postby Rackle » Mon Jun 26, 2006 15:40

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.

User avatar
Dalfy
CEGUI Team (Retired)
Posts: 130
Joined: Tue Oct 11, 2005 16:13
Location: Paris, FRANCE
Contact:

Postby Dalfy » Tue Jun 27, 2006 09:26

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

User avatar
Dalfy
CEGUI Team (Retired)
Posts: 130
Joined: Tue Oct 11, 2005 16:13
Location: Paris, FRANCE
Contact:

Postby Dalfy » Tue Jun 27, 2006 09:28

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.

User avatar
muhkuh
Not too shy to talk
Not too shy to talk
Posts: 22
Joined: Wed Jan 12, 2005 12:06

Postby muhkuh » Wed Jun 28, 2006 15:07

Porting the tree control would be nice.


Return to “CEGUI Library Development Discussion”

Who is online

Users browsing this forum: No registered users and 13 guests