Just had a little bit fun with the UI class. The options and colors members have some potential.
You can already change alot of the stuff like height, thumbsize etc. There also some members like button and toggle size, but it appears they do not change anything. It would be great if more members, esp. of the pars family could get exposed or be fixed to work. For example:
label.size, label.font, label. spacing, slider.rail.height and so on
At least I’m currently at the situation that I quite like widgets, but for performance and integration rasson still come back to just using a parameter top. Being able to adjust the appreance of this parameters and how they are displayed would be awsome to quickly create better looking UIs
Feel the same way about Widgets in general - but they suffer in the realm of dynamic UI creation. We simply cannot create lots of them on the fly. Hiding and showing pre generated UI gets us so far, but if we rely on this for too many variations of UI, invariably will end up with 100,000 nodes + in a network for building simple column layout style UI’s.
There are only a few things that the parameter COMP is missing that IMO would make it viable for production ready replacement for UI fitting the common column layout scheme. It’s already lightning fast, already custom param based, supports pages, separators, filtering, etc. However I realize these may not be easy things to add or change.
Ability to hide/disable the + icon on the left for expanding the parameter. This is useful for programming, but maybe not often as much for production / final usage in perform mode.
Restrict/allow ability to see or change binding, expression, parmode, etc. It could be useful to allow expression setting to users in some params, but maybe not binding. or maybe none of them for control only UI.
Being able to set things like font, gfx font size, row height, sep height, label position, knob height, colors of sliders, edge, highlight etc. would be helpful as @alphamoonbase said! Maybe styling info in general could be generalized and abstracted away into an optionally provided STYLE dat similar to CSS? This would allow select dat networks for global style changes.
Depending on how flexible styling was made, one could even consider the alternate use case of a single parameter comp per UI element, for building performance layouts and what not…
Anyways, just wanted to throw in my two cents to this post - realize these asks are potentially huge and time consuming on the back end. I also realize that Touch’s UI may be so fast because of how streamlined it is, lack of options etc. The parameter comp just has so much potential if a few things about it could be more configurable !
Just a word of warning that ui.options is undocumented and used for internal testing and adjustments. As you’ve discovered some of the options may be unused, they tend to come and go. I would not recommend having a project depend on it.
We do appreciate the feedback about ui in general and the parameter dialog in particular.
was affraid so. But it would be nice to open it up to us developers. Even the options that were working already showed a good way were it could go (bigger thumbs for sliders, general bigger sliders).
What would be a reason against opening the pars.options more?
Would be nice to know more about the internal workings
I checked, and the last time the parameter related stuff in uioptions changed is in 2015. Just to give you an idea of how often it might changed.
The main reason against opening ui.options is time constraints. It is also not particularly user friendly since it was just meant for internal use. I’m not opposed to more customization for parameter dialogs but possibly that’s better as options on the Parameter COMP or some other place that’s more user friendly. ui.options that we want users to access tend to turn into preferences.
Ah damit. I had the impression that the class is just about opening up attributes already existing in the corepart and was hoping that it could be done pretty fast.
But giving that options in a user friendly way and on a per ParameterCOMP basis is even better!
Will be waiting patiently
I’m exploring ParameterCOMP based UI, mainly for speed and crossplatform / cross resolutions compability, and find that the performance advantages are incredible, also the nice incremental units middle mouse button that we are used to…
If we could get an upgraded ParameterCOMP with the goodies listed above by @lucasm and @alphamoonbase the UI making would be smooth
another +1 from me, would love to have some customization options in the parameter COMP! Also correct scaling of parameters when the panel width becomes too small (currently the text starts scaling weirdly and becomes unreadable while the sliders/input fields remain too wide)
OK, thanks for your input about more customization of the Parameter COMP. We have on our radar an improved further shrinking of the panel, and some of your other suggestions are good too.
