Allow specifying the type of a property

[bjorn]

In some cases it may be nice to know the type of a property. This can also be used to determine an appropriate editor for the property value, once we have a more advanced property editor.

Suggestions for supported types: string (the default), number (floating point), int, bool

Possibly we could even have "file", which would enable a file chooser.

This issue spawned from the discussion at #12

[Hakkeduster]

The "file" type would be a great addition besides the more common types, as we store file links to object images as a property and having a file browser would speed up adding a file link much.

[ghost]

I implemented a basic version of property types here:
https://github.com/MegaJiXiang/tiled

You can specify int,uint,float,string,filepath, or link
Link is the interesting one. If you specify the unique id (new in this version) of an object as the value of a link property, it becomes part of the hierarchy of the parent object. You can then right click objects and select "clone hierarchy" to clone the object and also all of it's children which get new unique ids and relinked to the parent.

It will make more sense if you try it yourself. :)

[OniLink]

I would definitely love to see this implemented soon.

[LearnCocos2D]

+1

Currently trying to infer the type of a property from its value. It's a pain to do this in C++ (or C) and will lead to odd behavior:

• bool values have to be specified as "true"/"false" strings because 0/1 will be interpreted as int
• all integer values will be int even if the underlying data type is float and the value just happens to be an int

I don't think we need to differentiate between int/uint and float/double because there exist viable runtime conversions. A uint can safely be stored to an int and then cast back to uint if needed. Float values can be read as double, if needed, but I don't think any user will ever need to enter a value with double precision, so float will suffice. As for other uses of strings, their use (path, URL, image, etc) should be inferred from the property's name. But even where that is somehow not possible or feasible, it can easily be determined by using regex or string search. Although ... this could make sense with editor support, ie browse file dialog.

I'd propose to stick to the most common, most basic types in the TMX format for denoting a property's type (type-specific editor support notwithstanding):

• bool
• int
• float
• string

Update: I should have read the first post. :)

[hamilton-lima]

+1
One simple change would be allow to edit the property in a multiline editor with an extra "..." at the right side of the editor, that would allow lots of scripts possibilities.

[bjorn]

One simple change would be allow to edit the property in a multiline editor with an extra "..." at the right side of the editor, that would allow lots of scripts possibilities.

Multi-line editing is independent of supporting more property types than just strings, but it's definitely something I want to support as well! It is covered by issue #205.

[hamilton-lima]

that´s great @bjorn !

[bjorn]

This feature has been implemented and released with Tiled 0.16. I've opened #1278 regarding the addition of a custom file type, which is not available yet.

Also just recently I've implemented #205, adding a multi-line editor for string properties.