Display Panel Data in Property Editor
-
Hey, I was wondering what y'all think about the idea of adding the Panel Data to the property editor?
Similar as how the FloatingTile displays the ContentData, this would make the panel data handling more verbose. If we could simply display the values in the property editor this would be a huge deal! Also this would eliminate the need to use scripting to set all values to a panel, especially handy for custom buttons and just makes the panel easier to work with.
-
The borderRadius and text properties are already available in the property editor. The isMomentary is not a panel property, it's a key/value you've added to the panel's generic data object.
-
@d-healey I am fully aware that the border-radius is already available as a standalone property, I've just used this as an Example. I am specifically asking to display the saved custom data inside the panels PropertyEditor. There are all types of data that we can save inside a panels value and to make the current panel data more verbose we could display.
-
@oskarsh do you mean the
panel.data
object that you can populate with stuff with scripting? I don't think that's a good idea as I consider those to be in the responsibility of the script code and you usually define those properties in your panel's factory function where you use them in the paint routine.You can view the panel properties in the script watch table though so that helps at debugging (at least).
-
@oskarsh It's a generic data object so you have to populate it with key/value pairs, I don't see why it makes a difference if this is done in the property editor or the script editor. In the end you still have to write the same thing.
-
@d-healey @Christoph-Hart That's what I am currently doing... using scripting to set the panel data however I think it would be more verbose and easier for debugging to also be able to set this data via the Property Editor. As you said David in the end its the same thing, I see the value here to simply click a panel and see its current "state". As I get more into custom graphics I often define values inside the script and assign them to the
panel.data
for custom UI properties. Its also a great way to reduce script clutter.I see this as a valuable non breaking workflow enhancement not as a necessity.
-
@oskarsh Why not use custom look and feel instead. I very rarely use panel's to replace UI controls these days.
-
@d-healey There are cases where the default components with look and feel are not enough and the components requires multiple custom properties. Panels can be used to create custom components using the paint routine.
Consider this example:
Create a custom card component that displays a image, heading and a text inside a container that is clickable.
Sure you can use a ScriptButton and add everything to the text property and then parse this inside the LAF function.
it would look like this -> text: "images/test.jpg;Heading1;Some description that can be super long"
I can then parse this by splitting the text and using each index to render the data inside the LAF. For me this is not very verbose I prefer to use panels with the data object for this which would look like this:{ image: 'images/test.jpg', heaing: 'Heading1', description: 'Some description that can be super long' }
Here is a example component from a popular web framework:
https://react-bootstrap.github.io/components/cards/Panels have opened the possibility of complex custom components, that are easily saved in the preset. Furthermore they have quick access for timer and other goodies.
I am not saying that this cannot be done currently via scripting, in fact I am using this method but the ability to quickly change the panels custom data seems like a great workflow enhancement.
-
@oskarsh said in Display Panel Data in Property Editor:
it would look like this -> text: "images/test.jpg;Heading1;Some
If you use local look and feel you can load the image directly into the laf object and use the button's id as the image reference. No need to put it in the text property. Since this is a local laf you can set the text type for this one object and reuse it for multiple components. I don't see a reason to use a panel for this.
Currently the only times I use panels as components is if I need to create them dynamically. For everything else local laf is doing the job.
-
I see how the ability of viewing the data object quickly might become in handy, but I still think that it's a bad idea making this editable outside the scripting code - this creates two places where it needs to look for the data and in most of my real world use cases I'm using non-trivial scripting expressions to define the panel data anyways - either references to other objects, globally defined constants or programmatically defined arrays so a static property editor would not be helpful at all.
What I can imagine is that the same as selecting a component and pressing J where it shows the current properties as JSON data I could add a shortcut (either
P
for panel orD
for data) that opens a (read-only) JSON editor popup with the currentpanel.data
state - this way you wouldn't have to search in the script watch table. -
@Christoph-Hart That sounds good
-
@Christoph-Hart Sounds good as well!
-
Alright, I've added this as customizable shortcut (with P as default). If you select a panel and press P, it will show the data object and it even lets you manipulate it, and if you press Apply it causes a repaint() so you can quickly check what the properties do.
The editing only works if the
panel.data
object can be stringified without data loss - that means as soon as you have a reference to an object in there, it will stop working and become unpredictable, but it's really useful for flipping some bools or constants and check how the panel is rendered.I've also added the ability of viewing table row datas when you select a viewport in table mode with the same restrictions.
-
@Christoph-Hart Hey that's nice, and the keyboard shortcut works on Linux :D
-
@Christoph-Hart awesome! Thanks for implementing this!
-
@oskarsh Oh, I forgot - the edits you make there will not be stored anywhere, so consider it rather like changing variables in a debug session.