[CELayoutEditor Patch] - Skin chooser, selection Lock/Unlock

[fjeronimo]

Hi all,

I've been playing around with the CELayoutEditor (great work btw guys) and I've added a few features that were missing and that I found were useful (it was also a nice way to get acquainted with the CEGUI universe).

In the hope that more might enjoy these changes, I've created two SVN patches based on the CEGUI and CELayoutEditor SVN trunk versions. I had to modify CEGUI itself in order to be able to change the skins in runtime.

The patches were done on the contents of SVN on 27/09/07.

NOTE: I've kept comment tags of the modifications I've done in the following format:

// [FJDS]

[...] Changes to code

// [/FJDS]

The code is fully documented and tries to follow the documentation style of the application.

---------------//-----------------

Patch features:

CEGUI (CEGUI-27-09-07.patch):
----------------------------------

- New - Falagard Look'N'Feel changer : Added function Window::setFalagardType() which allows to change the Look'N'Feel of a given widget and changes the mapped falagard type as well. It calls Window::setLookNFeel() internally.

- New - Properties Access : Easy external access to Look'N'Feel properties (via getters).

- Change - Renderer reassignment : Modified Window::setWindowRenderer() to allow modification of an existing widget's renderer (removed safety).

- Change - Look'N'Feel reassignment : Modified Window::setLookNFeel() to allow modification of an existing widget's Look'N'Feel (removed safety).

CELayoutEditor (CELayoutEditor-27-09-07.patch):
-----------------------------------------------------

- New - Skin chooser : Possibility to change the widget skin in realtime (dropdown with possible skins in the main dialog), with support for single or multi-selection. In the later case, the user can choose to display (via a radio box) only the common skins in the dropdown or all existing ones for the widget types (in which case, the widgets that cannot apply the chosen skin are simply ignored). In both cases, changes are applied immediately in runtime and all the user-editable property values are kept.

- New - Apply Layout Skin : New menu command 'Apply Layout Skin' which maps the chosen skin to ALL the widgets in the current layout.

- New - Lock/Unlock selection : Possibility to lock/unlock the current widget selection via a toolbar button.

- New - Widget Parent filter : Possibility to filter the widgets in the 'Add window' dialog by their need of a parent or to display them all.

- New - Widget type display : The main dialog now displays the type of the currently selected widget (multi-selection is not yet supported).

- New - VS2005 solution : Added a Visual Studio 8 (2005) solution. The solutions uses the environment variables present in the VS2005 guide at http://www.cegui.org.uk/phpBB2/viewtopic.php?t=2760.

- Bug Fix - Unselection crash : Fixed a bug where a crash would occur if the user unselected the top/last widget.

- Change - Code realignment : Some code realignment and other cosmetic modifications.

- Change - Misc : Minor changes.

---------------//-----------------

I've created a Mantis entry (156) at http://www.cegui.org.uk/mantis/view.php?id=156.

Btw, is there any way to edit a created mantis ticket? I've been looking around and can't seem to find any option to do that! Question of access privileges?

I hope you enjoy this and please let me know what you think.

Best regards,

[Pompei2]

although i don't need the cegui layout editor, it's always good to see people submit the changes they do ! and you make good posts with all the colors really like it

[fjeronimo]

Thanks Pompei2. I'm always glad to help. Btw, why don't you use the CELayout editor? Do you think that it misses critical features?

Has anyone tried the patch yet?

[Pompei2]

No, It's just that I prefer editing code by hand, I think it's faster (copy&paste) and more precise. Also, I don't want to go trough all this installing from the layout editor maybe one day I'll change my opinion. I once tried it and didn't get it to work with my own skin, but with all the changes that have been made to directory handling, it should work by now.

[scriptkid]

Hi fjeronimo!

Sorry for the late reply, but i didn't have much time to look at your patches earlier. I have applied both and i am now testing them. My first impressions are that you have made some very cool enhancements! Thanks a lot!

However i have some questions/comments :p

*I think that the look (the behaviour seems okay) of the lock button should be swapped. When i start selecting it is 'open' and hints that i can unlock the selection. However i expect to be able to lock it first.

*On the main dialog you have a nice toggle (radio) between all or common skins. With common do you mean that all selected widgets have that skin available? If that's the case it might be confusing with regards to the property grid below. That grid shows any available property (in the current selection) but will only update the widgets which actually supports it.

*I noticed some strangness after changing a skin, and i even got a crash.. But don't worry. I'll have a look at it today or this weekend. After that i will commit the code and maybe you can do some (more) testing after that as well.

*As a tiny comment i have made a few changes to parameters and return values (Strings and the Property getters in the looknfeel) into references for performance reasons.

Thanks again!

[fjeronimo]

Thanks for testing the patch scriptkid. I'm always glad to help in any way I can - after all, isn't that the spirit of the open-source movement? .

As for your comments,

*I think that the look (the behaviour seems okay) of the lock button should be swapped. When i start selecting it is 'open' and hints that i can unlock the selection. However i expect to be able to lock it first.

I can see how this can be confusing but actually that was the intended purpose. I tried to mimick the behavior and visual aspect of the functionality in most modelers and animation tools. The button reflects the current state of the selection and not the intended one. This means that, at first, the unlock icon is displayed because no selection is locked. As soon as a lock occurs, the icon changes to the locked icon to reflect this.

*On the main dialog you have a nice toggle (radio) between all or common skins. With common do you mean that all selected widgets have that skin available? If that's the case it might be confusing with regards to the property grid below. That grid shows any available property (in the current selection) but will only update the widgets which actually supports it.

Yes, when common is selected, only the skins that are common to ALL widgets in the selection appear in the combo box. For instance, if the selection has 3 elements and 2 support the vanilla look, 3 the falagard and 1 the windows, only the falagard will be displayed.

I didn't notice the conflict with the property grid though. Perhaps the best solution is to make the radio box also affect the contents of the grid accordingly in a future patch, and if common is selected only the common properties will be displayed as well.

*I noticed some strangness after changing a skin, and i even got a crash.. But don't worry. I'll have a look at it today or this weekend. After that i will commit the code and maybe you can do some (more) testing after that as well.

Ouch. A crash is never a good sign. I performed quite a few tests but I only run them in my machine. Also, I am pretty new to CEGUI so probably I didn't contemplate all test cases (at the moment, I can think that some widget properties deserved special treatment when a skin was changed and perhaps I missed some?). Can you replicate the crash? Also, what kind of strangeness did you encounter? When you changed an individual widget or only when you applied the skin to the entire layout?

Ah, and I only tried with the 3 default skins (vanilla, falagard and windows) and no custom one.

Of course, I'm ready to assist in further testing as soon as you commit the changes to the repository.

*As a tiny comment i have made a few changes to parameters and return values (Strings and the Property getters in the looknfeel) into references for performance reasons.

Thanks. I must admit I wasn't overly concerned with performance. Mea culpa!

[scriptkid]

Hi there,

I'm always glad to help in any way I can - after all, isn't that the spirit of the open-source movement? Smile.

That's very true, but cegui is quite big to actually jump into. So it's nice to see it happen now and then

I can see how this can be confusing but actually that was the intended purpose. I tried to mimick the behavior and visual aspect of the functionality in most modelers and animation tools. The button reflects the current state of the selection and not the intended one. This means that, at first, the unlock icon is displayed because no selection is locked. As soon as a lock occurs, the icon changes to the locked icon to reflect this.

Okay i see, sounds fair. However then the tooltip should be swapped, because it sais 'unlock selection' when the image is also unlocked. Right?

About the looknfeel and property grid: it might be nice indeed to make that a toggle for both! It's not a technical conflict though, but rather a usability one.

I only got a crash once, but the weirdness occured when i was playing around with the looknfeels, which made lots of widgets disappear when i started to drag them around (after changing their look). Maybe it requires a repaint hint or something. I'll have a look at it. Anyway i will commit the code tonight, so that we are in sync again. That is where the 'trunk' is for after all.

Ttyl!

[fjeronimo]

Okay i see, sounds fair. However then the tooltip should be swapped, because it sais 'unlock selection' when the image is also unlocked. Right?

Ops. You are absolutely right! I'll change it as soon as you commit the changes.

About the looknfeel and property grid: it might be nice indeed to make that a toggle for both! It's not a technical conflict though, but rather a usability one.

Sounds good. I'll work on it as soon as you commit the changes.

I only got a crash once, but the weirdness occured when i was playing around with the looknfeels, which made lots of widgets disappear when i started to drag them around (after changing their look). Maybe it requires a repaint hint or something. I'll have a look at it. Anyway i will commit the code tonight, so that we are in sync again. That is where the 'trunk' is for after all.

Somehow, I can't seem to replicate the weirdness you experienced. On my end, the widgets don't disappear after the skin change, even when you drag them around. Perhaps there are special cases I'm missing...

However, some cases might turn the widgets invisible (but that is expected behavior). For instance, if you change the skin of the children without touching the father itself.

An example would be to open the demo7 layout and to change the skin of the children of the 'window 1' from taharez look to windows look. The radio buttons text will disappear because the text color will change to black when the background is also black. If you change the 'windows 1' look to windows look afterwards, the text will become visible again. Likewise, if you rechange the affected children to their original taharez look.

As for the crash, I did manage to create a crash in demo7 layout as well when changing the skin of the itemlistbox in 'windows 2'. A crash always occurs in this case (somehow I missed this). As soon as you commit the changes, I will try to find out why this is happening.

Finally, I was wondering if you could supply me with further layouts for testing purposes. Since I haven't been using CEGUI for long, I haven't built anything remotely complex yet so my tests are perhaps somewhat limited so far (using only the ones that come with CEGUI). If you have any layouts and/or skins that you could send my way, I would appreciate it.

[scriptkid]

Ah, your explanation might indeed be the reason for the widgets disappearing.

I can send you a custom looknfeel + some layouts of my own game for testing purposes. They're not very complex, but it's nice to do some testing with a custom looknfeel i think. I'll try that tonight.

[fjeronimo]

Thanks. I'll be waiting.

Also, is there any way to edit the text of a mantis entry that I created? Or my access level of 'submitter' prevents this action?

[scriptkid]

Hi,

the patches have been committed I don't know about mantis tickets, some have -and other don't have- an Update Ticket button. I am no mantis expert though...

I'll send you some files through email.