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)
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
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.
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:
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 ;)
the gif recorder simply destroyed the Color UIElement hihihih
it looks just nice in the renderer ;)
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.
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.
Bump, anyone created a Adobe CC style color picker yet for Elementa?
i guess no. Anyone interested in contributing with this? :)
would be cool if we have some sort of correct implementation guide…
this is something for mr documentation @sebescudie ;)
I am also interested in knowing how to implement in the right way. Maybe an extension workshop would be cool…
There’s already some sort of contribution guidelines for new widgets here :
It does not cover how widgets are patched but rather how the folders containing widgets are structured, how to forward dependencies, how to name pins, how to make a help patch and so on.
For now, the best way to understand how widgets are working inside is to open them, fiddle around and ask questions :)
Basically, a widget is “nothing more” (big quotes here) than a collection of Components :
LayoutableLeaf component that allows the widget to have a size and position
StringValue that gives the widget the ability to hold a value
- A default drawer for it to be drawn
Styleable component for it to have … a style
Focusable components for youveguessedwhat
Behaviour component that defines how the widget is interacted with (ex : for a slider, we want the mouse to hover the slider, then have a right click and drag that either increases or decreases the value of the
And then there are a bunch of other components that only apply for specific scenarios, such as
Orientable that allows a widget to be vertical/horizontal,
EditingMode that changes the dragging behavior (absolute, relative …).
Sadly, we did not take time to document the innards of the library and only focused on the “end-user” documentation so that most could start using the lib.
So yes, I know, “look it up yourself and come back with questions” is probably not the best answer, but we’re ready to answer all your questions because we’d be glad to see other widget contributions (there have already been some in the past!).
And yes, I guess a video like “Let’s patch a slider from scratch” would be a good addition to the documentation material.