QSS access for qtractorTrackButton

[G3N-es]

Estimated Rui:

Is it necessary to make Qtractor more accessible through QSS? I believe this would simplify the development of new features. Many of them without having to touch code or compile. It would simplify the internal code, you would only have to designate one property, the one that gives access through QSS. The rest, sizes, color... would be applied externally. I would separate the logic from the visual part.

But of course I could be wrong.

I suppose that performance and stability issues also come into play, which could be of concern in this approach.

My initial starting intention was:

qtractorMixerRackWidget & qtractorMixerRackTitleBarWidget type= BusIn, Track, BusOut

qtractorMixerStrip type=Midi, Audio selected=true, false

qtractorTrackButton type= Record, Mute, Solo

Of these I have only gotten "qtractorTrackButton". The rest do not apply the properties directly to the widget, and my limited knowledge has not allowed me to solve it.

I have come to the conclusion that with my proposals I hinder rather than help. If I don't have the knowledge, it's better to just enjoy what you've already given us.

Sorry for the inconvenience caused, from now on I will dedicate myself to enjoying Qtractor :) Thanks for everything.

[G3N-es]

qtractorMixerRackWidget & qtractorMixerRackTitleBarWidget solved. The key was in qtractorMixerRack.

[rncbc]

maybe you should make it once to qtractorTrackButton::ctor instead of qtractorMixer and qtractorTrackList individually? like here? https://github.com/rncbc/qtractor/blob/8cc65076b8f257b9e85dc1456ee2f6f9490ec1fb/src/qtractorTrackButton.cpp#L76-L99

[G3N-es]

Fixed: Buttons | Solved: midi audio type

Only the selected state of the track is missing, which should be in both qtractorTrackList and qtractorMixerStrip.

Without that state, if we customize the strip with qss, the highlighting functionality is lost when selecting. It is necessary to be able to recover it with QSS.

Of course nothing in this proposal is fundamental, but I have surprised myself by solving more than I thought I was capable of :-)

[rncbc]

one thing I'm really not sure of is whether this new "Type" property would be future-proof, so to speak...

subject to your reasoning ofc. wouldn't it be an idea to name these new custom properties after "TrackButtonType", and "MixerRackType" resp.?

[G3N-es]

Your comment has raised a question for me: Can child widgets inherit custom properties from their parents? I have done a test: qtractorMixerStrip[Type="Inputs"]{ background: red; }

If it inherits the qtractorMixerRack property the input strips should be red, but this is not the case. (I removed the "Type property" from qtractorMixerStrip to make sure.)

However, there may be conflicts in the future if a widget shares multiple types. So I think the cleanest thing to do is to call the property directly with a boolean.

qtractorMixerRack[Inputs=true] qtractorMixerRack[Tracks=true] qtractorMixerRack[Outputs=true]

qtractorMixerStrip[Audio=true] qtractorMixerStrip[Midi=true] qtractorMixerStrip[selected=true] //is not implemented

qtractorTrackButton[Record=true] qtractorTrackButton[Mute=true] qtractorTrackButton[Only=true]

what do you think?

[rncbc]

maybe following my last suggestion, mixer-strips would have two aditional properties?

for example:

• qtractorMixerStrip: MixerRackType = {Inputs|Tracks|Outputs} MixerStripType = {Audio|Midi}

the previous ones would stay as suggested before:

• qtractorMixerRack: MixerRackType = {Inputs|Tracks|Outputs}

• qtractoTrackButton: TrackButtonType = {Record|Mute|Solo}

[G3N-es]

Done :)

[rncbc]

is it working now for you on the mixer strips? what about this, as not inherited as I think you asked:

• qtractorMixerStrip: MixerRackType = {Inputs|Tracks|Outputs}

?

[G3N-es]

My doubt arose regarding possible conflicts due to inheritance. Now the way to access for your proposed example is for example:

qtractorMixerRack[MixerRackType="Outputs"] qtractorMixerStrip[MixerStripType="Audio"] {

}

We could even filter a button type to only Audio Outputs. qtractorMixerRack[MixerRackType="Outputs"] qtractorMixerStrip[MixerStripType="Audio"] qtractorTrackButton[TrackButtonType="Record"] {

}

The qtractorMixerStrip[selected=true] property is still not implemented. I tried in multiple ways, but I didn't succeed. Without it, modifying qtractorMixerStrip means losing the highlighting when selecting.

[rncbc]

and if you treat MixerRack's and MixerStrips separately? meaning not cascaded or nested?

[G3N-es]

From what I thought I understood from the tests (I could be wrong), custom properties are not inherited.

Therefore in: qtractorMixerStrip[MixerRackType = Inputs|Tracks|Outputs]

MixerRackType would be a unique property of "qtractorMixerStrip", even though "qtractorMixerRack" has another unique property with the same name. We could call it differently in the qtractorMixerStrip class (e.g. InOutOrTrackType ), and there would be no difference.

I don't see the point in creating that extra property. The logical method of accessing QSS (CSS) is cascading.

An "InOutOrTrackType" might make sense if there were no parent containers as is the case in other DAWS and the Buses are intermixed with the Tracks. But in Qtractor, fortunately, the person who designed it thought of differentiating these concepts into their own sets (who would it be?). :)

Although maybe I'm missing something.

By the way, I thought about assigning the values "Inputs, Tracks, and Outpus" by affinity to the interface text, although perhaps more precise names would be InputsBuses, Tracks, OutputsBuses (even for the interface).

[G3N-es]

After doing color tests with QSS I verified that the specific purpose of the proposal (to improve the display of the mixer by color) was wrong. It confuses more than it clarifies. Although I consider that in general terms Qtractor should be more accessible through QSS, for this specific case it is not sufficiently justified.

Also, I didn't implement it in an elegant way, it made the code dirty.

I close the request and thank you for your patience.

[G3N-es]

I thought only properties declared with setProperty could be accessed via QSS. I was wrong, it is possible to access properties declared with set. For example: QPushButton::setToolTip(tr("Only"))

can be accessed with: qtractorTrackButton[toolTip= "Only"]

That being the case, Qtractor is much more accessible through QSS than I thought.

Greetings