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:

Postby Dalfy » Thu Jun 29, 2006 05:50

What are your most wanted widgets for the next release ?

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 29, 2006 09:18

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

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

Postby Rackle » Thu Jun 29, 2006 11:07

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.

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

Postby spannerman » Thu Jun 29, 2006 13:06

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


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
CEGUI Team (Retired)
Posts: 534
Joined: Mon Jan 16, 2006 11:59
Location: Montréal

Postby Rackle » Thu Jun 29, 2006 13:13

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

User avatar
drumicube
Not too shy to talk
Not too shy to talk
Posts: 43
Joined: Thu Nov 02, 2006 12:09
Location: France

Postby drumicube » Sat Nov 04, 2006 01:04

jacmoe wrote: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 ? :lol:
Just kidding... :roll:

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

User avatar
gcarlton
Just can't stay away
Just can't stay away
Posts: 149
Joined: Wed Jan 12, 2005 12:06

Postby gcarlton » Sat Nov 25, 2006 00:43

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.

User avatar
Das Gurke
Not too shy to talk
Not too shy to talk
Posts: 31
Joined: Sat Sep 02, 2006 15:45

Postby Das Gurke » Sat Nov 25, 2006 09:29

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:

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 :oops: )

User avatar
gcarlton
Just can't stay away
Just can't stay away
Posts: 149
Joined: Wed Jan 12, 2005 12:06

Postby gcarlton » Sun Nov 26, 2006 23:12

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
Home away from home
Home away from home
Posts: 489
Joined: Tue May 23, 2006 16:31

Postby Pompei2 » Mon Nov 27, 2006 08:24

Das Gurke 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:

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 :oops: )

I'd most like that feature too !

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

Postby Rackle » Mon Nov 27, 2006 15:40

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.

User avatar
lindquist
CEGUI Team (Retired)
Posts: 770
Joined: Mon Jan 24, 2005 21:20
Location: Copenhagen, Denmark

Postby lindquist » Mon Nov 27, 2006 20:51

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

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

Postby Rackle » Mon Nov 27, 2006 23:33

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 8)

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

User avatar
lindquist
CEGUI Team (Retired)
Posts: 770
Joined: Mon Jan 24, 2005 21:20
Location: Copenhagen, Denmark

Postby lindquist » Tue Nov 28, 2006 01:57

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!

User avatar
Das Gurke
Not too shy to talk
Not too shy to talk
Posts: 31
Joined: Sat Sep 02, 2006 15:45

Postby Das Gurke » Tue Nov 28, 2006 18:42

lindquist wrote: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 =)


Return to “CEGUI Library Development Discussion”

Who is online

Users browsing this forum: No registered users and 5 guests