Scripting API - TiledObject - Allow for invisible / readonly custom properties #3245

This request has come up before for in #3150. I considered whether it would be good to support binary data properties that would always be read-only, though this might not be as convenient for your use-case of storing a version.

I don't think any custom properties should be hidden from the user. I also don't think any custom properties should be truly read-only, I think it's more valuable to instead let users know that the data shouldn't be modified and that they should proceed with caution. To that end, perhaps custom property types can have a "warn before editing" checkbox that pops up an "are you sure you want to edit this property?" window before letting you modify the value. These properties would behave in the properties panel like the Image property of Tilesets does now, where it isn't directly editable, but has an Edit button you can click when you focus on it.

Also, rather than a special binary field type, I think it would instead be nice if Tiled provided access to its base64 functions for use by users, at least via scripting. That way the data can be displayed in the editor as just a regular string, as well as edited (e.g. to remove it, or to paste in other base64-encoded content).

I don't think any custom properties should be hidden from the user. I also don't think any custom properties should be truly read-only, I think it's more valuable to instead let users know that the data shouldn't be modified and that they should proceed with caution.

Right, the thing is that binary properties can't be displayed or changed in the UI, so it's effectively a hidden value. I think they could still have their use, even if you can only change them via the scripting API.

Also, rather than a special binary field type, I think it would instead be nice if Tiled provided access to its base64 functions for use by users, at least via scripting.

They are already available as Qt.atob and Qt.btoa functions.

Cool. And hopefully with today's documentation changes, that list of functions is linked from the docs now :D

I still think we shouldn't have a binary property type though, precisely because it can't be viewed or edited via the GUI. I think requiring base64 is reasonable. It would have to be base64-encoded in most of the available output formats anyway, and if a custom export format wants to output it as binary, they can decode it and do so.

Cool. And hopefully with today's documentation changes, that list of functions is linked from the docs now :D

Right, I've added links to https://doc.mapeditor.org/en/latest/reference/scripting/#javascript-host-environment, but the Qt object is not directly linked from there, but it was already linked from https://www.mapeditor.org/docs/scripting/modules/qt.html. However, it might make sense to document the atob and btoa functions there as well to make them easier to discover.

Yes please! I think anything linked from the Scripting manual page should ideally also be somewhere in the API docs, since they're separate now and I doubt I'm the only one who goes directly to the API docs for help. Obligatory weekly whining about how the manually-maintained docs were better ;D

I also think it would be good to document atob and btoa in there. Although, with TypeDocs apparently not searching descriptions, I worry it won't actually help discoverability all that much =_=

On a related note, it would also be good to link the Qt Namespace docs from there, along with linking the relevant section where keyboard and mouse button values are used (e.g. linking https://doc.qt.io/qt-5/qt.html#KeyboardModifier-enum in Tool.mousePressed, Tool.mouseMoved, Tool.keyPressed; linking https://doc.qt.io/qt-5/qt.html#Key-enum in Tool.keyPressed). I think some work on the latter has already been done, and the Modifiers are linked from the Tool description, but I think it's better to include them everywhere they're relevant instead, so there's less scrolling (in the docs) or clicking (in a code editor) to do to get to the link. Also, I just noticed there's no Tool.keyReleased to go with Tool.keyPressed o: