Custom Properties prototype

[sudara]

Here's a rough implementation of custom properties. The idea is to call this helper from your component:

// someComponent.h
#include "melatonin_inspector/melatonin/helpers/misc.h"
.
.
.
        melatonin::setCustomInspectorProperty(this, "Flavor", flavorNames[static_cast<int> (flavor)]);
        melatonin::setCustomInspectorProperty(this, "Theme Key", themeKey);

Behind the scene, this just adds 2 properties to the component, for example inspectorPropertyName1 and inspectorPropertyValue1 — their values then show up at the top of the property inspector:

@dikadk / @FigBug would either of you use this or have implementation opinions?

Implementation Qs:

• perhaps there's a more elegant naming convention for custom properties (vs. incrementing integers)
• including an inspector header is sort of over the top considering it just adds some props (vs. being an actual hook into the inspector, which could be more elegant)
• hard coded a limit of 10 properties

This isn't the first time I've wished a JUCE Component's properties were backed by a first class data store vs a flat NamedValueSet..

[FigBug]

I'm currently working on something complementary / conflicting: https://github.com/reFX/melatonin_inspector/tree/refx/property_improvements

My idea was to just to take the Component::getProperties(), iterate over them and then and then add properties for each of them. Maybe your custom components could be added to this same list?

[sudara]

Glad I brought it up!

My implementation is ugly in comparison since it relies on adding 2 properties (for key/value) following a naming convention.

Displaying getProperties seems more elegant! But I have a few thoughts:

• Maybe we should rename the PROPERTIES panel in the UI to FLAGS and add a new collapsable PropertyPanel below called PROPERTIES with the output from getProperties. I'd also be in favor of removing the dimensions, since the box model displays those and they are also editable there.
• jcclrs should be probably excluded by default (either with a config option or put in their own section under properties called ColorIDs?) It's sort of annoying/overkill that colors are one-way translated and stuck in props, and they are a sort of implementation detail of look and feels. But then again I avoid LookAndFeels where possible, so maybe they are valuable to someone.
• People store random stuff in props, I wonder if we need have a way to tell the inspector to opt-out of displaying getProperties on a component by component basis OR based on some fuzzy prefix matching on the key. Example: I store a LOT of string translations as well as colors in my plugin editor's properties... It might get awkward and sluggish for there to be hundreds of lines of key/values there, so I would like to say "no thanks" somehow!

[sudara]

Also, we current display rgb in the color picker, so if we do go with displaying jcclr, i guess we should align those and/or maybe allow the user to set (and remember) which color format they prefer. We don't have a place to store settings, I'd be happy to style a right click menu or something for that.

[FigBug]

I'd be ok getting rid of the sizes. What would be in properties and what would be in flags? Originally I was going to add another class like properties for the named properties from Component, but couldn't think of a good was to resize to lists with scroll bars.

[sudara]

I was thinking just all the existing stuff that's now in PROPERTIES would go in FLAGS, since especially after removing dimensions it's mostly that (with a few extra cosmetic things like alpha, lookandfeel).

Not sure what you mean re: resizing. Like, having two collapsable panels with scrollbars gets awkward?

What about jcclr — are those useful for you?

[sudara]

@FigBug Looking at your branch it looks like you are wanting to inspect/modify colors, so I'd say just make things how you want them, submit a PR and I'll do any UI cleanup/config stuff to make sure we're both happy!

[sudara]

Superseded by #48