|Anonymous | Login||2019-09-19 23:10 UTC|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000491||CEED||[All Projects] General||public||2011-07-09 11:52||2012-02-05 15:15|
|Target Version||snapshot7||Fixed in Version||snapshot7|
|Summary||0000491: Property inspecting systems reworking|
|Description||This was one of the first pieces of code I have written for CEED and even though it's a decent design, it needs some reworking.|
First, what is a property mapping:
It's a mapping from CEGUI property (which means property name, property data type and property origin) to a property inspector - a mechanism able to visualize and edit data stored in the property. Because CEGUI is very flexible, it should be possible to map everything to anything, but of course some inspectors will be suggested (based on the data type).
I also plan to ship CEGUI 0.8 stock mappings that will map properties of the stock widgets and mappings per stock skin that map specific falagard properties of the skins.
There are several decisions to be made:
* Should it use the persistent settings API and interface?
I personally think it should not be done with the settings API as it is to be shared by all team members working on the same project (they are likely to use the same widgets).
* What if there is a property that doesn't have a mapping?
IMO the editor should pop a modal dialog letting you choose which inspector should be mapped to that precise property. Things that have the same data type will be bold and appear first in the list.
* What if I am not happy with the mapping?
The ability to edit existing mappings (or even remove them) will not be readily available (as the new mapping feature will be). You will have to go to some sort of a settings dialog to view and edit them. I don't think this will be an often used feature.
* How to add a new property inspector?
This is an issue I haven't solved yet. Even though the CEED API allows you to plug many things in (even new editors, because I can!), the ability to load external modules is not there yet.
|Tags||No tags attached.|
I would appreciate any ideas about this before I delve deep and redo it all.
This is your chance to whine, nag and complain! Take IT! :-D
|I will go ahead and make the stock mappings more or less complete and skip the mappings editor for now. Power users can always just hack the XML files and it's a lot of work for something not many people will use at this point I think.|
|And the property mappings editor is assigned to snizzo so that's another reason for me not to do that :-) That said though, I would like that editor to make it into the first stable or soon after that. It will make a lot of sense with looknfeel editor and so on.|
|Can't be done in time for snapshot4|
I've rewritten parts of the property inspecting system, the most useful change being that the property inspector can expand individual properties so their sub-properties can be edited (like the Qt Designer).
According to what we've said in IRC, the new functionality is already better than the old one so we can merge.
< pav256_> Do you think it's time to merge my branch and add missing handlers/editors later or should I wait for 0000708 and do them all first?
< mpreisler> from what I tried it works better than what is there now
< mpreisler> pav256_: so I would say it's ready to be merged
< mpreisler> pav256_: once 0000708 is merged it will automatically click and start working, right? or are there changes needed in your branch to make it work?
< pav256_> I think it will work but I haven't mapped all available properties yet
< pav256_> for example, the last two I did were Colour and ColourRect, without the last commit they would be edited as strings
< mpreisler> QColorDialog or something could be used for Colour and ColourRect
< mpreisler> though I don't know if they support alpha
< pav256_> Yeah, I haven't implemented any custom editors yet, the tree-style editing is more important imo.
< mpreisler> yeah
< mpreisler> custom editors can be plugged in at any time
< mpreisler> and the tree style editing is very neat
Merged with ebc86103ce5b
Thanks a lot!
|2011-07-09 11:52||Kulik||New Issue|
|2011-07-09 11:52||Kulik||Status||new => assigned|
|2011-07-09 11:52||Kulik||Assigned To||=> Kulik|
|2011-07-09 11:53||Kulik||Note Added: 0000576|
|2011-07-09 11:53||Kulik||Status||assigned => feedback|
|2011-07-16 21:31||Kulik||Relationship added||related to 0000515|
|2011-07-23 16:19||Kulik||Target Version||snapshot3 => snapshot4|
|2011-08-07 12:02||Kulik||Priority||normal => high|
|2011-08-17 20:42||Kulik||Note Added: 0000626|
|2011-08-17 20:42||Kulik||Status||feedback => assigned|
|2011-08-17 20:44||Kulik||Note Added: 0000627|
|2011-08-17 20:44||Kulik||Relationship added||parent of 0000567|
|2011-08-25 20:24||Kulik||Note Added: 0000646|
|2011-08-25 20:24||Kulik||Target Version||snapshot4 => snapshot5|
|2011-10-16 18:12||Kulik||Relationship added||parent of 0000631|
|2011-11-26 10:20||Kulik||Target Version||snapshot5 => snapshot6|
|2012-01-01 23:05||pav||Relationship added||related to 0000682|
|2012-01-02 22:22||Kulik||Target Version||snapshot6 => snapshot7|
|2012-01-03 07:37||Kulik||Relationship added||parent of 0000685|
|2012-01-11 18:56||pav||Assigned To||Kulik => pav|
|2012-02-03 11:01||pav||Note Added: 0000859|
|2012-02-05 12:22||Kulik||Relationship added||related to 0000706|
|2012-02-05 15:15||Kulik||Note Added: 0000866|
|2012-02-05 15:15||Kulik||Status||assigned => resolved|
|2012-02-05 15:15||Kulik||Resolution||open => fixed|
|2012-02-05 15:15||Kulik||Fixed in Version||0.8.3 => snapshot7|
|Copyright © 2000 - 2012 MantisBT Group|