Forum

VL.UIElements

Hi

I started to create a library of UI widgets for skia.
The idea is to have a collection of process nodes (Slider, Label, Toggle,…) that you can easily put into your patches to create an interactive UI.
The programming pattern I’m using is the State Pattern.
you can find more about it in this video: https://youtu.be/N12L5D78MAA

All the feedbacks are welcome and I hope someone will join the development! :)
this is the repo:

this is the current state of development:
VL.UIElements_0.1.zip (215.8 KB)

Cheers

9 Likes

Nice one!

I really like it!

I have a small question though: why did you store the state of each widget inside a reference (i.e. Reference<IInteractionState>)? I thought that class nodes were automatically passed by reference

@maro
You would need to store into the Pad of the state the state itself, which is not currently possible.
We would need a special pin called “me” that holds the instance pointer within itself, in order to operate on it.
So for now we need to introduce another level of indirection through a reference.

…probably @Elias or @gregsn can give you a better explanation :)

happy that you like the UIElements.
More will come soon.
Feel free to contribute with new widgets

So if I understand correctly, this is how you would implement a this pointer inside VL? Good to know. Thanks for the response

Wow, super clean implementation and patches, my widgets are ashamed now :D I’ll consider merging the efforts when beta updates to support this.

Have you considered adding also some Color Palette (or general Style) property class for styling? Right now I see it’s hardcoded IOBoxes, which might be fine from a prototyping standpoint but when this is used as a library you might want to avoid the user having to edit it at every update.

Properties that should be outside of the *Drawer classes and shareable among them are imo:
Background, Idle, Hovered, Pressed, Focus, Text Idle and Text Preview Colors
Optionally Font Family and Font Size or even Text Enable to disable text overlay for sliders

If you need anything more then you would create your own Drawer but this feels like the very common basics.

Also I think there should be a Force pin for setting the value ORd with the change. As it is now, you can’t do a simple reset trigger without modifying the library.

What do you have planned next? Color (RGBA) and Spreads?

A nice color picker could be made by compounding the 2DSlider and a VSlider, with the right background it’ll be pretty much the somewhat ubiquitous Adobe CC style picker.

image

Here’s the patch generating the above image, feel free to use any part of it.

ColorPicker_Gradient_Generator.v4p (431 Bytes)

Edit: The rainbow gradient in this is made of multiple composite LinearGradients, the moment VL.Skia is updated to support multiple colors on linear gradients (like Skia itself does), it can become just one single gradient. Skia - Linear Gradient with multiple colors/positions

Hello @domj !
Good to know that you like it.
Your contribution would be precious indeed.
We are currently two people working on this: the brave @sebescudie joined the development.
we did some progress since the last post.
here you can see some new UIElement available:
Elements_Preview_low

I definitely want to give the possibility to define the style properties from outside.
I’m considering passing a dictionary<StyleEnum, Object> that gets interpreted by each UIElement drawer.

Thanks for the Color picker! I’ll def have a look at it. As you said it shouldn’t be hard to implement it as a new UIElement.

Before the end of this week there will be a new release here in the forum.
In the meantime feel free to checkout the repo ;)

ciao
N

NOTA:
the gif recorder simply destroyed the Color UIElement hihihih
it looks just nice in the renderer ;)

2 Likes

Ok, I just thought that an explicit data type for the style would be better then a dictionary. :)
(so that the parameters are typed already and there’s no need to cast anything)

some UIElements will use all the properties of the style, some other will get just what they need

the repo looks good so far, cool initiative

I am just dearly missing multitouch. what do you think about some kind of cursor/pointer abstraction (in screen space) that can eventually be a mouse, a touch, or a kinect hand position?

am I right in assuming that something like this would be done in e.g. IdleSliderState (H)

as an example, the vl MTStack works in such a way that any new touch will be locked onto exactly one gui element if it “appeared” while hovering over an element, and will only be unlocked when the touch disappeared.

@velcrome Thanks for checking this stuff ;)
In the last days me @gregsn and @tonfilm set down and rethought the library architecture.
In this new cool scenario it will be much easier to think to multitouch.
I’ll clean a bit the patches and then report.

stay tuned

3 Likes