When is the next version available?

[Van]

Is there a date? And what has been fixed? And what WILL be working? I really hope there are some significant fixes and enhancements. I am really frustrated with the current state of the CEGUI Layout Editor. It only has basic functionality at best. It's not really a usefull tool for me in it's current state.

[scriptkid]

Hello Van,

the new editor will be out this week. All known bugs (those which were in Mantis) have been fixed.

As main additions, the following features will be in:
-Falagard support. The list of available widget types during "add window" is created from Falagard mappings, grouped by looknfeel;
-Recursive copy/pasting;
-Ability to "export" a current selection to a new layout. Which is handy when you want to split up a large layout into smaller ones for example.
-The ability to set a background, helps the wysiwyg idea.
-The "datafiles" folder does not have to be inside the startup folder anymore. (Can still be though).

I agree that the editor is too basic in some areas. After this release, the team will have an (open) discussion about the features which should be in. This will be mainly the support of more properties, or generate more complex widgets such as tables.

HTH.

[Van]

Thank you for your reply.

Those are NICE-a-ty enhancements... Nice to have, but are not really necessary. We need theNECESSITY enhancements:

1. TabControl support - a patch has been submitted what isn't incorrporated (not doc showing it has).

2. Scrollable Pane Support - I can't imagine why this isn't supported - probably the second most used window in CEGUI. I saw no bug fix for it.

3. ToolTips for windows

4. Lock Window Position (editor)

5. Lock Window Offests (editor).

6. Support for more than one root window in a single XML file.
If you try to use an XML file to hold MANY windows (at root level) the editor doesn't support it.

7. Auto Naming of Child windows
Why doesn't the Editor automatically insert the parents window name into all new child windows when created so that the user can just append the childs name to it?

8. Popup Menu support

9. Editor option (check box) to toggle the Metrics used to size a box by the mouse. For example, I may want to size in ABSOLUTES.

Like I said. It's a nice utility for a static text box and a button. But if you are trying to produce any serious CEGUI windows I find that I might as well create everything in code - makes the XML file and support for it all but worthless.

[Rackle]

I would add

• Redimensioning only the parent; the children retain their current dimensions (a patch has been submitted but I have not looked for it yet). At work I design user interfaces for a database application. The lack of this feature is quite frustrating.
  
• Indentation within the .layout file: each child is indented 2-4 characters to the right. Not needed by the editor itself but makes it easier when manually modifying the file. Myself I like the Browse Layout to reflect the logical order of the layout itself; left to right, row by row.
  
• A new alignment feature: evenly spaced. Imagine 4 buttons in a row. I would like the space between button 1&2, 2&3, and 3&4 to be identical. The leftmost (first in selection list) and rightmost (last in selection list) widgets would not be moved but the "inner" widgets would be.
  
• Preventing a widget (button, editbox, static text) to be shrunk beyond the capacity of one line of text.
  
• Creating a TabControl is not easy. Currently I create a TabControl within the Layout Editor and then as many TabPane widgets as needed. I overlay one TabPane over the TabControl and size it appropriately. Then I resize the other TabPane to match that first TabPane(same width, same height). The next step is to place widgets within each TabPane. To do this I hide every TabPane except the one I wish to work on. A new approach would handle the size of the TabPane for me; resizing the TabControl would automatically resize the TabPanes (but not its children, or it could be an option/setting). Selecting a TabPane within the Browse Layout would make that TabPane visible and hide every other. Or the Layout Editor would call addTab() to actually add the TabPane to the TabControl and let us navigate to a pane via the TabButton that would have been created.

Problems

• I select an entry within the Browse Layout, modify a property, then click on a different entry within the Browse Layout. The property is assigned to the second entry rather than the first. I must remember to press <enter> or leave the modified field by selecting a different field to have the property properly saved.
  
• The anchor/sizing boxes are not always easily targetted with the mouse; sometimes I have to place the mouse below to change the cursor to a sizing cursor.

Suggestions

• When adding a new window the focus should be within the Name field rather than the Look field.

[Rackle]

Sorry to hijack the thread...

My workflow usually copies widgets within the same parent. Thus if copy also selected the parent widget (of the selected widgets) then I could immediately paste. And if paste selected the newly created widgets I could then immediately move them to their intended position.

The ability to move (up/down the list) entries within the Browse Layout would eliminate my need to manually edit the .layout file.

[scriptkid]

Hi Van,

good suggestions i think!

1. TabControl support - a patch has been submitted what isn't incorrporated (not doc showing it has).

True, this patch is still pending. There was another large patch which i have applied first. Problem is that i always tend to forget watching that page. So it's a bit tough to apply a patch a few months later I don't see reason why not to apply it though..

[EDIT] A reminder has been added to Mantis: http://www.cegui.org.uk/mantis/view.php?id=70 [/EDIT]

2. Scrollable Pane Support - I can't imagine why this isn't supported - probably the second most used window in CEGUI. I saw no bug fix for it.

I guess you mean that it only renders a resize border? Because it is a container, it looks like that, but maybe we can do some defaulting on that widget when it gets added. Need to look into that.

3. ToolTips for windows

How would you see this? As a new "fake" property, such as Name and the URect values?

[EDIT] This is available in Xirnohn's patch: http://www.cegui.org.uk/mantis/view.php?id=69 [/EDIT]

4. Lock Window Position (editor)
5. Lock Window Offests (editor).

I think i read this request earlier, it's a good one. Should it block certain property changes then? And disable aligning and such?

6. Support for more than one root window in a single XML file.
If you try to use an XML file to hold MANY windows (at root level) the editor doesn't support it.

Somebody posted another patch which might just do that. But i have not seen this patch myself. The many-windows issue sounds like a bug to me. If so, feel free to put it in Mantis.

[EDIT] A reminder has been added to Mantis: http://www.cegui.org.uk/mantis/view.php?id=71 [/EDIT]

7. Auto Naming of Child windows
Why doesn't the Editor automatically insert the parents window name into all new child windows when created so that the user can just append the childs name to it?

Check

[EDIT] Has been added to Mantis: http://www.cegui.org.uk/mantis/view.php?id=72 [/EDIT]

8. Popup Menu support

Need to look into this one.

[EDIT] A menu ticket has been added to Mantis: http://www.cegui.org.uk/mantis/view.php?id=73 [/EDIT]

9. Editor option (check box) to toggle the Metrics used to size a box by the mouse. For example, I may want to size in ABSOLUTES.

Should be doable.

[EDIT] Has been added to Mantis: http://www.cegui.org.uk/mantis/view.php?id=74 [/EDIT]

Like I said. It's a nice utility for a static text box and a button. But if you are trying to produce any serious CEGUI windows I find that I might as well create everything in code - makes the XML file and support for it all but worthless.

I might be biased, but i think it can do a bit more then a button and an image already

[Van]

@Scriptkid,

Scrallable Pane
The scrollable pane will not hold nor save windows. Nor does the propery manager show the windows you add to a scrollable pane and therefore will not permit you to change the window either.

[EDIT] I need to verify this. [/EDIT]

Locking Windows
Perhaps start with a a a SIMPLE "lock" in the property window (check box or something). If the user locks it, then it can be SELECTED (for adding windows) but no propertys can change (including moving, resizing). Maybe a right-click on the window's name with a lock/unlock. If it's locked, then change the font (color or italic or something).

[EDIT] Has been added to Mantis: http://www.cegui.org.uk/mantis/view.php?id=75 [/EDIT]

Tab Control
This is a must and should be a high priority item.

I might be biased, but i think it can do a bit more then a button and an image already

LOL I understand however I can also tell from your statement that you really don't used your own product to produce serious (complicated) window configurations. If you did use it as much and as hard as some of us are doing so now then you would be way ahead of these suggestions!

[Rackle]

LOL I understand however I can also tell from your statement that you really don't used your own product to produce serious (complicated) window configurations. If you did use it as much and as hard as some of us are doing so now then you would be way ahead of these suggestions!

Maybe dropping wxWidget and using CEGuiSample would be the way to go

I managed to download and compile both Cegui and CeLayoutEditor v0.5. The Indentation within the .layout file I requested is already present; will make it easier to manually edit those files. I've started making patches already...

[scriptkid]

Rackle,

Redimensioning only the parent; the children retain their current dimensions (a patch has been submitted but I have not looked for it yet). At work I design user interfaces for a database application. The lack of this feature is quite frustrating.

Yep, good one too. That should be in the same aformentioned patch which will handle multiple root layouts

A new alignment feature: evenly spaced. Imagine 4 buttons in a row. I would like the space between button 1&2, 2&3, and 3&4 to be identical. The leftmost (first in selection list) and rightmost (last in selection list) widgets would not be moved but the "inner" widgets would be.

Ah okay isn't that called "justified"? Consider it to be taken into consideration :p

Preventing a widget (button, editbox, static text) to be shrunk beyond the capacity of one line of text.

You mean while resizing with the red border?

About the Tabcontrol, this seems to need high priority indeed then.

I select an entry within the Browse Layout, modify a property, then click on a different entry within the Browse Layout. The property is assigned to the second entry rather than the first. I must remember to press <enter> or leave the modified field by selecting a different field to have the property properly saved.

Hmmm okay, maybe this needs something like the Visual Studio project settings where it will prompt you whether you want to save the current pane.

The anchor/sizing boxes are not always easily targetted with the mouse; sometimes I have to place the mouse below to change the cursor to a sizing cursor.

I think this one is fixed for 0.5 since the border has been removed from the canvas, making the calculations more easy and accurate.

When adding a new window the focus should be within the Name field rather than the Look field.

Okay, should be doable

Thanks for your suggestions as well!

[Rackle]

>>>I select an entry within the Browse Layout, modify a property, then click on a different entry within the Browse Layout. The property is assigned to the second entry rather than the first. I must remember to press <enter> or leave the modified field by selecting a different field to have the property properly saved.

>>Hmmm okay, maybe this needs something like the Visual Studio project settings where it will prompt you whether you want to save the current pane.

I guess there are three possible options:

1) ask the user if he/she wants to save, ignore, or cancel switching to another entry
2) automatically save
3) automatically cancel the change

Myself I would prefer to automatically save. When I change the value of a property that value is automatically saved if I select another property. However that value is not saved if I select another widget (in the upper pane). That behavior (selecting another widget) is not consistent with the previous behavior (selecting another property of the same widget). And it could also be simpler.

[EDIT] Has been added to Mantis: http://www.cegui.org.uk/mantis/view.php?id=76 [/EDIT]

How can I submit a patch for the LayoutEditor? I've changd the height of the DialogAddWindow.cpp from 350x320 to 350x700 (I think) to allow us to immediately see most of the widgets rather than having to scroll and scroll and scroll to finally find it. The next thing that I would change would be the order of the widgets; alphabetical would make it easier. The grid lines also bother me; maybe dotted lines would be more appropriate, not covering the widgets as much.

>>Ah okay isn't that called "justified"?

Good name

[EDIT] Has been added to Mantis: http://www.cegui.org.uk/mantis/view.php?id=77 [/EDIT]

>>>Preventing a widget (button, editbox, static text) to be shrunk beyond the capacity of one line of text.

>>You mean while resizing with the red border?

I create an Editbox with the font tahoma-10. I would not want to be able to shrink the widget such that text within the Editbox could not be displayed properly. Or maybe the default size could be such that it supports one line of text in the selected font and the user/designer could then resize it to whatever he/she wants. Right now widgets (StaticText, Editbox) support multiple lines of text in their default size.

>>>Selecting a TabPane within the Browse Layout would make that TabPane visible and hide every other.

Maybe this could be an option/setting somewhere; selecting a TabPane hides every other TabPane, selecting a FrameWindow hides every other FrameWindow.

[Rackle]

>>The list of available widget types during "add window" is created from Falagard mappings, grouped by looknfeel

I miss having the widgets of a default looknfeel displayed; there's now one more step in locating the widget I wish to add.

[EDIT] Part of this Mantis ticket: http://www.cegui.org.uk/mantis/view.php?id=68 [/EDIT]

[scriptkid]

@Rackle,

i think that the automatic saving of a property when another window gets selected is the best option, and probably the most intuitively. So we agree

About default sizes: the editor just creates an arbritary intial size, where no logic is applied. Maybe this should be bit smarter and -for text containing widget- even taken into account the current font.

I don't see why you want to hide other windows of a same type, when you select one of them. To avoid "clutter" when you have big layouts? Just let me know...

You can post patches here: http://sourceforge.net/tracker/?group_i ... tid=605424
I'll do my best to look at that page more often

Thanks in advance for the help!!

[Rackle]

Oh, the CELayoutEditor is part of the CEGUI sourceforge. I was looking for a separate sourceforge entry...

>>I don't see why you want to hide other windows of a same type, when you select one of them.

I would limit this to FrameWindow and TabPane.

Within a .layout create 3 FrameWindow that each take up approximately 75% of the screen. Widgets (buttons) can be added to the second FrameWindow by selecting that FrameWindow within the Browse Layout. However positioning that widget within that second FrameWindow is not an easy task; you have to move the third FrameWindow such that it no longer covers the second FrameWindow. A second solution is to hide that third FrameWindow and a third solution is to temporarily change the AlwaysOnTop property of the second FrameWindow.

To make matters worse let's now add a TabControl to each FrameWindow and then create 4 TabPane for each TabControl (I usually create TabPane at the same hierarchical level as the TabControl). In order to work on a particular TabPane I have to use one of the previously mentioned technique: move widgets out of the way, hide other FrameWindow (which hide their TabPane), or temporarily assign the AlwaysOnTop property.

My current solution is to create one .layout per FrameWindow. This reduces some of the "clutter". And to work on a particular TabPane I use the hide/unhide trick.

The simplest solution might be to change the Z-order of the selected FrameWindow, the same behavior that a FrameWindow would exhibit during runtime; selecting a FrameWindow brings it to the top. TabPanes are somewhat more difficult to handle right now since they do not have a clear hierarchy; they are not children of a TabControl.

[Rackle]

The ability to move (up/down the list) entries within the Browse Layout would eliminate my need to manually edit the .layout file.

This also allows a tab order to be specified. I know that this feature does not yet exist officially but it surely would be a step in that direction.

[Rackle]

Rackle,

Redimensioning only the parent; the children retain their current dimensions (a patch has been submitted but I have not looked for it yet). At work I design user interfaces for a database application. The lack of this feature is quite frustrating.

Yep, good one too. That should be in the same aformentioned patch which will handle multiple root layouts

I'm unable to find that patch. I've found "[ 1452040 ] Falagard And Patch Support for Editor" and a few others but not that one.