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

[Dalfy]

What are your most wanted widgets for the next release ?

[jacmoe]

I am not sure if CEGUI have this already, but a widget for drag and drop inventories (grid), like we have for RPGs for example: where you drag/drop icons/pictures.

Anyway, the most wanted feature (for me) is to bullet-proof and expand on the already exsisting widgets.
Take a look at what we have already, and make CEGUI faster and better.

Documentation and tools.

[Rackle]

Multiple column sort within the MultiColumnList. If there is none or only a single column currently sorted then the current behavior is activated; set the column sort or toggle the column's sort. When there are multiple columns sorted then that click would also remove all sorts. ctrl-click would specify the sort of an additional column or, if that column is already sorted, toggle ascending/descending for that column.

A basic HTML text support (colored text, hyperlink, image) would be greatly appreciated. Although I'm not sure I like the HTML image approach. A word processing image allows text to flow around the image.

[spannerman]

Anyway, the most wanted feature (for me) is to bullet-proof and expand on the already exsisting widgets.
Take a look at what we have already, and make CEGUI faster and better.

Documentation and tools.

Sorry jacmoe, I’m going to quote you and agree with you once again
Apart from a tree view control (which I would also love to see as a core supported widget), I can’t think of any further GUI widgets that would be deemed as ‘essential’ for a library such as this. So maybe now is the time for those bells and whistles?
I few examples of what I mean (sorry if this latest version already covers any of these):

- Unlimited tab control header bar space i.e. there is a limit to the number of tabs I can add to a tab control, because the space where the tab buttons appear gets filled up. Wouldn’t be a problem if this area was scrollable, or had a little drop down list of the hidden tab buttons, like with open documents in Visual Studio 2005.

- Enhanced text manipulation via basic tag syntax e.g. newlines, bold, coloured. Rackle and a few others have already suggested something similar.

- Tool tips that span multiple lines. (do they support this already? Couldn’t get them to do it).

- Menubar menu’s that disappear/rollup/close when a user does not click on a menu item. For example, if I click on a main menu item ‘File’, its submenus are displayed. The only way the submenus then disappear is if I click on one of them, what if I don’t want? Maybe something like a mouse off timeout, or detecting when a mouse click occurs elsewhere.

- Ability to specify a minimum relative padding space between columns in the multi-column list.

Those are just some features I have felt where missing during my time with cegui.

[Rackle]

Could also implement HTML Frames. I think those are called Sizer?

[drumicube]

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

I totally agree with this, and I have the feeling V0.5 is on the good move.
My concern is more about 3rd app tools, editors...

We all know only artists can design good skins and...
Have you ever seen an artist edit an xml file ?
Just kidding...

I'm quite sure, with good editors, the repository could soon host terrific skins.
Anyway, I love V0.5, congratulations on it.

[gcarlton]

I would prefer a 0.5.1 sort of release rather than another year-long milestone. It would have no major interface refactoring, and 0.5.0 code would work with it. Instead, focus would be on:
- TreeView widget, and any other other missing ones
- Common dialog support, perhaps as pure layout xml files.
- Rotational image support.
- Support for user addon components.. as far as I know this is already doable, but it would be good to make it easier for apps to extend.
- Major work put into tool support, ImagesetEditor, LayoutEditor etc. A good editor for every data file type.
- Lua 5.1 support, and support for providing external lua states rather than CEGUI being the one in control of it. The app should be able to be the one who owns it.
- Performance improvements, if profiling shows any low hanging fruit

So basically, now we've got 0.5.0, build on that base and keep it stable for another release. Just make it easier to use the 0.5.0 architecture to full effect.

[Das Gurke]

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.

This would be really great! Could maybe someone tell me if this is about to come sometime? Would stop me from hacking in some "own" language support (which i would probably base on filenames )

[gcarlton]

The ScriptingModules directory seems to be missing from the binary windows release - its in the full 0.5.0 source release though. Under the root, not \include though. Lua scripting functions still seem to need an integer returned, which would be more general as a string that the app tests for whatever format.

One thing that has always annoyed me slightly is that the window names must be unique: e.g. display two FileOpenDialog layouts and you get an exception about "Close" button not being unique. I'd prefer a simpler scheme:
- Direct children must be unique, but not across tree hierarchy
- Direct children are accessed as normal.. FindChild("Close")
- Hierarchical finding is accessed via FindChild("Dialog1.MainPanel.Close"), which is equivalent to FindChild("Dialog1").FindChild("MainPanel").FindChild("Close")
- Perhaps, windows can be marked "transparent" in terms of name access. So the above example may become FindChild("Dialog1.Close")

[Pompei2]

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.

This would be really great! Could maybe someone tell me if this is about to come sometime? Would stop me from hacking in some "own" language support (which i would probably base on filenames )

I'd most like that feature too !

[Rackle]

One gotcha with this approach (the .layout file containing multiple labels) is that the .layout file must be reloaded when the "language" is changed. A solution would be for the Cegui system to store every loaded .layout file and parse them for alternate language labels and reassigns their values.

[lindquist]

The memory overhead for that could turn out quite significant though :/

[Rackle]

I was thinking more in terms of storing the filename of the .layout. It can then reparsed and the existing widgets/CEGUI::Window renamed. But then what about those dynamic labels, such as selecting a radiobutton to change the label on a text? Clearly this idea is in development

Or there is a CEGUI::setLanguage(iso code/value) function to specify the language to use and the next time a .layout file is loaded the labels used are those specified by that language. If a label is missing the appropriate language entry then an exception can be generated. Another solution would be to specify a CEGUI::setDefaultLanguage() and use it when the language is not available, and if the default language is not present then generate an execption. Personally I'd prefer to not use such a default language: if I'm trying to support multiple languages then I better make sure they are all there...

[lindquist]

If CEGUI was to go international, I would very much prefer seperating the layouts and text strings. There are quite a few different approaches one could take on this, but I tend to write looknfeels instead of layouts, just to name an example!

[Das Gurke]

The memory overhead for that could turn out quite significant though :/

I wouldn't load all language strings the same time. Instead I would load only those matching to a language locale, falling back to some kind of defaultlang in case of nonexistance or just return a "" string.

Seperating language and style is a pretty good idea aswell =)