Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for nested (dictionary-type) properties #489

Open
LearnCocos2D opened this issue Aug 4, 2013 · 8 comments
Open

Add support for nested (dictionary-type) properties #489

LearnCocos2D opened this issue Aug 4, 2013 · 8 comments
Labels
Milestone

Comments

@LearnCocos2D
Copy link

@LearnCocos2D LearnCocos2D commented Aug 4, 2013

Currently it is not possible to create your own nested properties (like Position, Size). If a single property needs to encode multiple parameters, it needs to be done by embedding all parameters in the same string:

FollowPath | path=p1;speed=10;repeat=0

Or alternatively each property needs to have its own name:

FollowPath | p1
FollowPathSpeed | 10
FollowPathRepeat | 0

Both solutions are supoptimal for editing, and terrible for reading properties in a generic way. For example the above would require reading each property individually, while the example below could be mapped to a "createFollowPath" method that simply gets the properties dictionary passed in. With technologies like KVC (Key Value Coding, ie setting properties in the object hierarchy by key path like "FollowPath.speed") this would lend itself towards more automatisms.

So what I'd really like is to be able to add "dictionary" type of objects. Ideally with unlimited nesting, which once the nesting functionality is there should come natural anyway. The above would then look like this:

V FollowPath
path | p1
speed | 10
repeat | 0

To make this possible the user should be able to create a "dictionary" property.

This could be done by offering another [+] icon next to it, perhaps [++] that creates a property of type dictionary. Then with the dictionary property selected, or one of its children, any click on [+] or [++] adds the new property to the selected dictionary property instead of the root properties.

@bjorn
Copy link
Owner

@bjorn bjorn commented Aug 7, 2013

Feature makes sense, though I guess it kinda screams for predefining types that automatically have a set of nested properties.

@LearnCocos2D
Copy link
Author

@LearnCocos2D LearnCocos2D commented Aug 7, 2013

Funny, now that you mention it this is what I happen to have here. ;)

On 07.08.2013, at 20:33, Thorbjørn Lindeijer notifications@github.com wrote:

Feature makes sense, though I guess it kinda screams for predefining types that automatically have a set of nested properties.


Reply to this email directly or view it on GitHub.

@fontmas
Copy link

@fontmas fontmas commented Sep 27, 2014

@bjorn a sugestion for curstom property window could be a sub tree view.

Example idea:
image

@fontmas
Copy link

@fontmas fontmas commented Sep 27, 2014

Things to think about and ponder...

Is a nested property could be a nest for others nested properties?

How to could be the format in XML files?

@Chaoseiro
Copy link

@Chaoseiro Chaoseiro commented Oct 3, 2014

I believe that, at least from a XML standpoint, it could be something like this

<properties>
    <property name="a property" value="some value"/>
    <properties name="maybe a name attribute is unnecessary?">
        <property name="a nested property" value="some nested value"/>
        <property name="a nested property 2" value="some nested value 2"/>
    </properties>
    <properties name="nested properties 2">
        <property name="a nested property again" value="some nested value"/>
        <property name="a nested property again 2" value="some nested value 2"/>
        <properties name="we must go deeper">
            <property name="are we there yet" value="false"/>
            <property name="limbo" value="false"/>
            <properties name="insanity">
                <property name="limbo" value="true"/>
            </properties>
        </properties>
    </properties>
   </properties>

or, to keep only property nodes inside properties nodes:

<properties>
    <property name="a property" value="some value"/>
    <property name="nested properties 1" value="irrelevant?">
        <property name="a nested property" value="some nested value"/>
        <property name="a nested property 2" value="some nested value 2"/>
    </property>
    <property name="nested properties 2" value="irrelevant?">
        <property name="a nested property again" value="some nested value"/>
        <property name="a nested property again 2" value="some nested value 2"/>
        <property name="we must go deeper" value="irrelevant?">
            <property name="are we there yet" value="false"/>
            <property name="limbo" value="false"/>
            <property name="insanity" value="irrelevant?">
                <property name="limbo" value="true"/>
            </property >
        </property>
    </property>
   </properties>
@theHacker
Copy link
Contributor

@theHacker theHacker commented Jun 18, 2016

I am missing such a feature for a long time.

For a first step (may be this could be an independent feature) I would like to see Tiled not removing custom XML data in a file. Currently if I write my custom tags inside a Tiled file and edit the file with Tiled and save it, Tiled would remove all tags it does not know.

If Tiled would preserve these tags it would be possible to easily save nested properties within the files. Tiled doesn't even have to understand these very game specific properties. The only thing Tiled would have to do is providing a possibility to view and edit these XML fragments.

Custom tags could be nested inside a special tag (for example <custom-properties>) to prevent clashes with existing tags.

With this solution the Tiled file would not be as bloated as with @Chaoseiro's XML and offers more flexibility because you can use tags and attributes as you seem fit.

<properties>
   <!-- Tiled's simple properties -->
</properties>
<custom-properies>
  <a-property>some value</a-property>
  <nested-properties-1 foo="some" bar="value" attributes-as-you="wish">
    <a-nested-property>some nested value</a-nested-property>
    <a-nested-property-2>some nested value 2</a-nested-property-2>
  </nested-properties-1>
  <nested-properties-2><!-- here: no "irrelevant?" -->
    <a-nested-property>some nested value</a-nested-property>
    <a-nested-property-2>some nested value 2</a-nested-property-2>
    <we-must-go-deeper><!-- here: no "irrelevant?" -->
        <are-we-there-yet value="false"/>
        <limbo value="false"/>
        <insanity limbo="true" />
    </we-must-go-deeper>
  </nested-properties-2>
</custom-properies>
@bjorn
Copy link
Owner

@bjorn bjorn commented Jun 19, 2016

@theHacker I don't really like that approach, because there is no place to keep arbitrary XML data around between loading and saving, and it would be non-trivial to add this. Tiled would have to keep around an XML DOM representation of the original file, and update it with changes made in Tiled before saving it back.

It would also be hard for 3rd party libraries to add support for that, as opposed to the slightly more verbose version proposed by @Chaoseiro.

@kheftel-old
Copy link

@kheftel-old kheftel-old commented Jun 19, 2016

With the new multiline properties, you could put arbitrary JSON or xml data in a string property as a workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.