Sliderpack CSS
-
@Matt_SF
Thanks for the idea. However, the label refers to the floating text overlay (see image).However, I would like to remove the dark text over the sliders.
-
I had a similar issue when styling a knob with CSS.
Not all the elements of the control are targetable with CSS selectors.
These replies might be relevant:
https://forum.hise.audio/post/87527
https://forum.hise.audio/post/87536
https://forum.hise.audio/post/87541Sounds like CSS will take us some of the way to simple customization but not all the way.
Coming from a web dev background I can imagine CSS being used extensively in the HISE UI system but it doesn't sound like that's the plan.
-
try
content: '';
(thatโs two single ticks not a quote). -
@Christoph-Hart
Thank you for your answer. I have tried it everywhere:.scriptsliderpack
.packslider
.packslider::before
.packslider::before:hover
.packslider::before:active
labelUnfortunately, the text is still visible. Any other ideas?
-
@Oli-Ullmann Oops, sorry, the correct value is not an empty string, but a space (an empty string is treated as no entry so it will render the default text - so in order to overwrite it you have to give it a non-empty string without characters:
.packslider { background: blue; content: ' '; }
You'll need the empty string to make the
::before
/::after
elements visible, that's what I'm doing most of the time. -
Sounds like CSS will take us some of the way to simple customization but not all the way.
Oh and I was referring to the task of styling a knob where the CSS system hits its limitations (because there is too much to customize). The slider pack is fully customizable with CSS.
-
@Christoph-Hart said in Sliderpack CSS:
Sounds like CSS will take us some of the way to simple customization but not all the way.
Oh and I was referring to the task of styling a knob where the CSS system hits its limitations (because there is too much to customize). The slider pack is fully customizable with CSS.
Good to know
Are knobs the only UI element that isn't fully CSS'd up? Or are there others?
-
@dannytaurus I would say the knob is the most out there because you easily hit the limitation of the two pseudo elements (most of the other complex UI elements can be addressed through multiple selectors, eg. the table has these selectors:
.scripttable {} .tablepoint {} .label {} .playhead {}
so you're not likely to run out of elements.
-
@Christoph-Hart
Yes, that worked! Thank you very much! :-) -
@Christoph-Hart said in Sliderpack CSS:
@dannytaurus I would say the knob is the most out there because you easily hit the limitation of the two pseudo elements (most of the other complex UI elements can be addressed through multiple selectors, eg. the table has these selectors:
.scripttable {} .tablepoint {} .label {} .playhead {}
so you're not likely to run out of elements.
I think I'm just misunderstanding how CSS is implemented in HISE.
If a table can have all those custom selectors, why can't a slider have custom selectors for all of its elements too?
I appreciate you wanting to do as much as possible with native selectors like div, label, etc, and the pseudo-elements
::before
and::after
, but I don't understand why you can add.tablepoint
and.playhead
to a table but you can't add a.valuetext
or similar to a knob. -
@dannytaurus because this would make it the only UI element which then has a separate selector for its text, so it's not consistent with the rest. Also this is a black hole of feature requests: what if you want an additional selector for the value ring? No problem, let's add a
.knob-value-ring
class selector. Now the next guy comes along and wants to display the modulation value with another ring, so.knob-mod-ring
needs to be added. Would be great to have another text label to statically show the name. No problem, slap a.knob-static-text-label
class on it...You see all this can already be done with a few lines of HiseScript code and it doesn't require any specialised CSS selectors that I have to prethink for you and add in the hope that you're use case does not deviate from my intentions in the slightest way, or you're back at square one where you ask me to add Just One More Class Selector.
All the other elements have a predefined amount of sub elements which can be addressed pretty easily and cover 99% of the usage, but with the knob (and not the slider, I really mean knob), the options are basically endless - plus you have to script the mouse logic & path creation anyways so from there to writing the paint routine in HiseScript too is not a big leap.
-
@Christoph-Hart Feel free is skip over the rest of this reply since I don't think I'll ever come to terms with this
However, that's exactly my fundamental disconnect with this - I don't get why all other elements have "a predefined amount of sub elements" while the knob doesn't?
The stock HISE knob has a predefined amount of sub elements, and two of those elements are the name and the value. So why can't we address all those stock elements with CSS?
I totally get the 'one more lane' reasoning and that's why I'm only talking about the stock decisions you've already made with the knob control.
Let us style what's already there in the stock control with CSS, anything else we have to go full LAF.