On the multi-touch side there are a few problems. There is some sort of cooking issue on launch that prevents any interaction. Diving into the network fixes it, as does force cooking uberGUI with recurse=True. The multitouch is smooth for the left part of the screen, but the scrollbar works opposite to how one might expect it to.

It would be great if part of the Style page a scroll wheel speed modifier were implemented. While I can traverse all the parameters in 'Heavy' in the Parameters Inspector with a single wheel scoll, it takes me 30 full scrolls to do the same thing in UberGUI, and a public multiplier would be helpful in dialing in a user facing interface and making it feel good

the two finger scroll actually feels pretty good for flicks on a laptop mouse pad, but two finger scroll doesn't work unless you let up off the pad the hovers freak out a bit, which isn't the expected behavior in a browser... that very well may be a limitation of TD tho

On a touch screen things break a bit. Increasing the Scroll Bar width makes it fairly navigable from a touch ui, but a two finger multi-touch scroll would be amazing. To that end, the ability to adjust the fill weight between the left and right part of the panel, and set the texts H orientation would be fantastic. Right now most elements can be interacted with via touch screen, but they require a double click on a new one, otherwise the parameter gets stuck on a recently interacted with parameter. This can be fixed by using a regular mouse to engage a new parameter. Obviously touchscreen functionality isn't a priority with this UI, but I figured feedback on how its functioning with one could be helpful.

Thanks again for releasing this, its a great contribution. Looking forward to spending some more time with it

I think I only have one RFE remaining. Currently "header type" pars are rendered as editable strings. Imho these should get their own (header like) styling. Or, as a quick fix, those could be just rendered as headers.

spamming clicks on the left half of the interface returns some errors in converting string to float from the l_select chop. error looks like dis:

Traceback (most recent call last): File "/project1/container_UG_V4/chopexec_interact_mouse_lselect", line 11, in onOffToOn File "/project1/container_UG_V4/UG4", line 409, in Interact_LeftClick_Down ValueError: could not convert string to float: '0.97666666666666677OklOSVQsWDowLFk6MDwvdGl0bGU%2BCjxtZXRhIGNoYXJzZXQ9IlVURi04Ij4KPHN0eWxlPgoKOnJvb3QgewogIC0taG92ZXItdHJhbnNpdGlvbi10aW1lOiAwLjFzOwogIC8qLS1wYXJhbWV0ZXItcm93LWhlaWdodDogOyovCn0KCgpodG1sLCBib2R5IHsKICBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDEzLDEzLDEzKTsKICBtYXJnaW46IDBwdDsKICB1c2VyLXNlbGVjdDogbm9uZTsKfQoKCi5kZWJ1ZyB7CiAgY29sb3I6IHJnYigyNTUsMjU1LDI1NSk7CiAgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgwLDAsMCwuNSk7CiAgcG9zaXRpb246IGZpeGVkOwogIHRvcDogMHB0OwogIHBvaW50ZXItZXZlbnRzOiBub25lOwogIHdpZHRoOiAxMDAlOwogIHotaW5kZXg6IDUwOwogIG9wYWNpdHk6IDAuMDsKfQoKCi5ibGFua2l0IHsKICBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDEzLDEzLDEzKTsKICBwb3NpdGlvbjogZml4ZWQ7CiAgcG9pbnRlci1ldmVudHM6IG5vbmU7CiAgd2lkdGg6IDEwMCU7CiAgaGVpZ2h0OiAxMDAlOwp9CgoKLyogd2lkdGggKi8KOjotd2Via2l0LXNjcm9sbGJhciB7CiAgd2lkdGg6IDEwcHg7CiAgYmFja2dyb3VuZDogcmdiKDEzLDEzLDEzKTsKfQoKLyogSGFuZGxlICovCjo6LXdlYmtpdC1zY3JvbGxiYXItdGh1bWIgewogIGJhY2tncm91bmQ6IHJnYig3Niw3Niw3Nik7Cn0KCgouc3BhY2VyX3NlY3Rpb24gewogIHdpZHRoOiAxMDAlOwogIGhlaWdodDogMnB4Owp9Ci5zcGFjZXJfaGVhZGVyIHsKICB3aWR0aDogMTAwJTsKICBoZWlnaHQ6IDJweDsKfQoKCi5oZWFkZXJfY29udGFpbmVyIHsKICBmb250LWZhbWlseTogIkNhbGlicmkiOwogIGZvbnQtc2l6ZTogMTQuMHB0OwogIGZvbnQtd2VpZ2h0OiBib2xkOwogIG1hcmdpbi1ib3R0b206IDJweDsKICBwYWRkaW5nLXJpZ2h0OiA0cHQ7CiAgcGFkZGluZy1sZWZ0OiA0cHQ7CiAgbWFyZ2luLXJpZ2h0OiAycHg7CiAgbWFyZ2luLWxlZnQ6IDJweDsKICBoZWlnaHQ6IDMwcHg7CiAgYmFja2dyb3VuZC1jb2xvcjogcmdiKDE1MywxNTMsMTUzKTsKICBjb2xvcjogcmdiKDI2LDI2LDI2KTsKICB0ZXh0LWFsaWduOiBjZW50ZXI7CiAgdmVydGljYWwtYWxpZ246IG1pZGRsZTsKICBsaW5lLWhlaWdodDogMzBweDsKICBib3JkZXItcmFkaXVzOiAzcHg7Cn0KCi53aWRnZXRfY29udGFpbmVyIHsKICBoZWlnaHQ6IDI1cHg7CiAgZGlzcGxheTogZmxleDsKICBtYXJnaW4tcmlnaHQ6IDJweDsKICBtYXJnaW4tbGVmdDogMnB4OwogIG1hcmdpbi1ib3R0b206IDFweDsKfQoKCi53aWRnZXRfbGFiZWwgewogIGZvbnQtZmFtaWx5OiAiVGFob21hIjsKICBmb250LXNpemU6IDkuMHB0OwogIGZvbnQtd2VpZ2h0OiBub3JtYWw7CiAgY29sb3I6IHJnYigyMTcsMjE3LDIxNyk7CiAgdGV4dC1hbGlnbjogcmlnaHQ7CiAgcGFkZGluZy1yaWdodDogNHB0OwogIHBhZGRpbmctbGVmdDogNHB0OwogIGxpbmUtaGVpZ2h0OiAyNXB4OwogIG1hcmdpbi1yaWdodDogMXB4OwogIGhlaWdodDogMTAwJTsKICB3aWR0aDogNTAuMCU7CiAgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI2LDI2LDI2KTsKICBib3gtc2l6aW5nOiBib3JkZXItYm94OwogIHRyYW5zaXRpb246IHZhcigtLWhvdmVyLXRyYW5zaXRpb24tdGltZSk7CiAgYm9yZGVyLXRvcC1sZWZ0LXJhZGl1czogM3B4OwogIGJvcmRlci1ib3R0b20tbGVmdC1yYWRpdXM6IDNweDsKfQoKCgoud2lkZ2V0X3Rvb2x0aXAgewogIGZvbnQtZmFtaWx5OiAiVGFob21hIjsKICBmb250LXNpemU6IDhwdDsKICBjb2xvcjogcmdiKDIwNCwyMDQsMjYpOwogIG9wYWNpdHk6IDA7CiAgdGV4dC1hbGlnbjogY2VudGVyOwogIGxpbmUtaGVpZ2h0OiAyNXB4OwogIHdpZHRoOiAxNXB4OwogIHRyYW5zaXRpb246IHZhcigtLWhvdmVyLXRyYW5zaXRpb24tdGltZSk7CiAgcG9zaXRpb246IGFic29sdXRlOwogIHotaW5kZXg6IC0xNTsKfQoKLndpZGdldF9jb250YWluZXI6aG92ZXIgLndpZGdldF90b29sdGlwIHsKICBvcGFjaXR5OiAwOwp9Cgoud2lkZ2V0X3Rvb2x0aXA6aG92ZXIgewogIGZvbnQtc2l6ZTogMTRwdDsKICBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoNTEsNTEsNTEpOwp9Cgoud2lkZ2V0X2xhYmVsOmhvdmVyIHsKYmFja2dyb3VuZC1jb2xvcjogcmdiKDUxLDUxLDUxKTsKfQoKLndpZGdldF9sYWJlbDphY3RpdmUgewpiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMTAyLDEwMiwxMDIpOwp9Cgoud2lkZ2V0X2JvZHkgewogIG1hcmdpbjogMHB0OwogIHBhZGRpbmc6IDBwdDsKICBoZWlnaHQ6IDEwMCU7CiAgd2lkdGg6IDUwLjAlOwogIGRpc3BsYXk6IGZsZXg7Cn0KCi53aWRnZXRfaXRlbSB7CiAgd2lkdGg6IDEwMCU7CiAgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI2LDI2LDI2KTsKICBib3JkZXItd2lkdGg6MHB0OwogIG92ZXJmbG93OiBoaWRkZW47CiAgcG9zaXRpb246cmVsYXRpdmU7CiAgdHJhbnNpdGlvbjogdmFyKC0taG92ZXItdHJhbnNpdGlvbi10aW1lKTsKICBib3JkZXItdG9wLXJpZ2h0LXJhZGl1czogM3B4OwogIGJvcmRlci1ib3R0b20tcmlnaHQtcmFkaXVzOiAzcHg7Cn0KCi53aWRnZXRfSXRlbUNob29zZXIgewogIGZvbnQtZmFtaWx5OiAiVGFob21hIjsKICBmb250LXNpemU6IDkuMHB0OwogIGNvbG9yOiByZ2IoMjE3LDIxNywyMTcpOwogIHRleHQtYWxpZ246IGNlbnRlcjsKICBsaW5lLWhlaWdodDogMjVweDsKICBwYWRkaW5nOiAwcHQ7CiAgaGVpZ2h0OiAxMDAlOwogIGZsZXg6IDAgMCAyNXB4OwogIGJhY2tncm91bmQtY29sb3I6IHJnYigyNiwyNiwyNik7CiAgYm94LXNpemluZzogYm9yZGVyLWJveDsKICBib3JkZXItd2lkdGg6MHB0OwogIGJvcmRlci1zdHlsZTogc29saWQ7CiAgYm9yZGVyLWNvbG9yOiByZ2IoMTUzLDc3LDApOwogIG92ZXJmbG93OiBoaWRkZW47CiAgcG9zaXRpb246cmVsYXRpdmU7CiAgbWFyZ2luLWxlZnQ6IDFwdDsKICBtYXJnaW4tc'

Certain par types that take a string path, such as Op, OBJ, MAT, SOP. DAT, CHOP, Python, TOP. COMP etc. can't be interacted with until something has been assigned manually via the network editor parameter... once a value has been entered there, it can be double click edited as expected, but if the starting value is 'None', no interaction takes effect. This is easily reproduced by monitoring the 'Heavy' example and engaging the UI for such parameters

Hey again this behaves much better, but I'm still having touchscreen issues

ISSUE 1 open your demo file and scroll down to "Numeric special" touch RGB color pick "..." > dont change anything in the popup picker > try to close it by touching outside. If it closes open the color picker again and try to close it ... At some point (rather sooner than later) I get stuck in the opened popup picker and cant close it. If that happens , the only way to close it is to select a new color (or move the mouse)

ISSUE 2: open "RGB" picker by touching the blue "..." changeit to red touch outside to close color picker

touch "RGBA" ".." -> color picker opens with the correct color (orange) but if you click in the big square to pick a new orange tone the hue will jump to the hue of the previou(RGB) par (red)

Right now I can edit a param that is in expression mode, but that will put the param into constant mode. But for the end user of the gui this is not transparent, so he might easily break stuff

Maybe it would be better to (optionally) ignore parameters that are in expression (or export) mode

Or to fully support editing parameters that are in expression mode, i.e. to not change them to constant mode

Hey Lucas,

finally found time to check it out. Great job!

Small issue here:

Open the toe file and press "u" key to get out of project 1 then press "Enter" key

Traceback (most recent call last): File "/project1/container_UG_V4/keyboardin_hotkeys_callbacks", line 23, in onKey File "/project1/container_UG_V4/UG4", line 1396, in Trigger_Enter File "/project1/container_UG_V4/field/field", line 100, in Set AttributeError: 'NoneType' object has no attribute 'val'

Hi Lucas

I think this might be the same issue as someone else reported. Editing binded parameters via slider/buttons works perfectly, the issue is when you double click to edit a par, you get the value of the "constant mode" in the field

Open your demo file, load the custom OP example

drag the Bind slider to e.g: 0.5

double click the slider/value to edit the value manually

-> the field will show 0.0 (and NOT 0.5)

Now that the popup menu scrollbar width can be configured, the dropdown menu extends across the width of the parameter if you increase the scrollbar width

Hi Lucas

I appreciate the read-only mode for parameters in expression mode.

But imho bind mode should NOT be read-only. In my testing it worked perfectly (I was binding to a dependDict holding parameter presets)

Could you please re-enable parameters in bind mode (or provide a setting which pars modes will be read-only)

Also, is there a way to set the text colors for expression, read only and export mode? Thanks!

I've noticed that uberGUI doesn't always update read-only parameters reliably. I have a base with string parameters being updated by an extension, and while they dependably update at the base level, and if they are not read-only, when read-only is engaged I'm not seeing the feedback updating in the UG string parameter.

Hello Lucas, amazing work with UberGui!

I know the architecture is to make an abstraction layer over the Custom Parameters of COMP's, and that the Radio button option is not available natively in TD Custom Pars, but.. what do you think? is it something we can hope for?

For what I see, the menu par type is a good candidate, it generates a list of buttons already in UberGui implementation. What would be nice is to have an option to render that list of buttons directly instead of being "inside" the menu

cheers, Rui

right now if a parameter has an expression, or bind, it cannot be switched back to parmode.CONSTANT.

Have some macro or UI way to trigger a reset to default. maybe shift+right click, or shift+ctrl+rightclick?