I have solved the problem of not being able to customize the MixerStrip through QSS because they lost the visual selection display.
This is the solution, not only had to assign the custom property, also update:
...qtractorMixer.cpp line 780
if (m_bSelected) { rgbBase = pal.midlight().color(); pal.setColor(QPalette::WindowText, pal.highlightedText().color()); pal.setColor(QPalette::Window, rgbBase.darker(150)); this->setProperty("selected", true); this->style()->unpolish(this); this->style()->polish(this); this->update(); } else { rgbBase = pal.window().color(); pal.setColor(QPalette::WindowText, pal.windowText().color()); pal.setColor(QPalette::Window, rgbBase); this->setProperty("selected", false); this->style()->unpolish(this); this->style()->polish(this); this->update(); }
And the QSS would be:
qtractorMixer qtractorMixerStrip[selected=true] {
background: red;
}
If you want to include it in the official code I would be grateful.
Sounds interesting. Can you
Sounds interesting. Can you share a before and after image?
It allows you to do things like this
First of all, it allows you to customize "qtractorMixerStrip" in its normal state. Borders, radius, width, background, etc.
By doing so, you lose the functionality of visually highlighting the selected track.
However, with the implementation of a custom property, setProperty(selected, true), in source code we can retrieve the state to configure it:
And you can do things like this:
Projected shadow effect when collecting tracks/expanding buses.
HOLY !@$#%!@#$^!!!!! That is
HOLY !@$#%!@#$^!!!!! That is the coolest thing ever!!!!
"By doing so, you lose the functionality of visually highlighting the selected track."
Don't forget though, the most important aspect of the current "highlighting" is the relationship between the selected track and the subsequent routing of the signal. Having the instant visual knowledge of what bus a track is routing to is big. That said, so eager to see where this goes! Nice job!
It is lost, but if it
It is lost, but if it implement "setproperty" as I indicate, you can recover it with QSS by accessing the "selected" property.
That is, implementing "setpoperty" is the way to not lose it, which is what happens now.
The gif example I have put is somewhat exaggerated, it does not work well at all, nor does it have to. It is just an example.
But I think that being able to change the background and border (radius, color and type) of the strips is important to create a style, because the mixer is the most iconic part of any daw.
Currently, if we do not want to lose any functionality, we can only change the background color, and not from QSS, but from the color scene.
What I propose would overcome this limitation.
Rui has not answered. There must be reasons for not including setProprtys in the code.
re. It is lost, but if it....
no, I don't currently see of any reason for this not getting implemented...
just busy with other things atm. cheers
I completely understand your criteria here
It might seem like you'd just have to copy and paste the code into qtractorMixer.cpp line 780.
However, looking at your code for my request for qss-related urls, I realize that things are not that simple.
You also have to take into account how that would affect the rest of the application, the readability, logic and coherence of the code, and anticipate possible errors in use by the user.
It's not that simple.
I completely understand your criteria here.
I'm learning a lot. Thanks for everything.
Coolness. This feels like it
Coolness. This feels like it's got some serious potential.
re. QSS for qtractorMixerStrip...
somewhat simpler in qtractor >= 1.5.2.3git.913f55 [develop]
check whether it's good for you
cheers
Thanks a lot!
It works fine and more elegant. There was no need to set the state to false.
I've noticed that the errors when doing crazy things like the ones in the gif examples (resizing from QSS) is because the whole "qtractorMixer" should be refreshed, not just the "qtractorMixerStrip".
I've seen in the code that it's not necessary to apply the refresh in "qtractorMixerStrip" for changes of backgrounds, colors etc.
Let's see what I can do now with all these new possibilities: url in qss, accessible MixerStrip and custom icons. :)
Thanks a lot!
Related reflection:
I've been thinking for a while about how to make the mixer more comfortable, to gain space.
This QSS exercise has given me an idea that seems to work.
In each Rack name bar (Track, Inputs, Outputs) add at the end on the right an icon that alternates between collapse ><, expand <>.
If collapsed, all the strips in the rack (Track or Inputs or Outputs) are reduced by 30px (for example, you would have to do some tests) in width.
That added up for each strip, is a lot of space.
If expanded, they return to their normal width.
Regardless of whether it is collapsed or expanded, if the mouse passes over a strip, it expands by 30px (for example, you would have to do some tests).
This would allow:
* Gain space if the user wants it.
* Although collapsing plugins makes them less legible, they still provide a sufficient functional reference (almost complete if the user has taken the trouble to edit the aliases).
* Hovering over plugins gives full readability and a better range of control in the shortcut handles. And this is all while sacrificing only 30px of the total Rack.
Add new comment