I have uploaded your update along with one from Tecnico.
This time I uploaded it without modifying anything. Downloaded from your Git, uploaded to VTQ.
Greetings right back at ya :) I'll be checking out your newer stuff later tonight. Always on the lookout to make improvements. Thanks for letting me know.
I've noticed my theme is suffering when it comes to clearly showing ghost notes and wonder if anyone has ideas? Track colors are always set to the following:
I gave it a shot but even setting foreground color to #ffffff results in too many undesirable side-effects. For example, shadows (I thought I disabled them... maybe I forgot this last time) are now white? The left-most area of the track takes on that color as well and despite both being set to the same color, there appears to be a tint of sorts applied which is clearly intended as a helper in order to help distinguish rows. Needless to say, it's clear all of these issues are a direct result of the magic coloring algorithm happening behind the scenes. Clearly, this algorithm offered tremendous value at one point (and still will for those who choose to avoid what is possible with QSS) but things are at a point now where it can certainly be a bit of a thorn in Qtractor's side. Even though I know it's a bit of a band-aid, perhaps I could request yet another global color option for the purpose of rendering this ghost data?
If the theme is dark gray (saturation 0), demand tracks with very saturated and light color.
Try #eaff04.
If you look at your events, the ghost notes are much more readable.
Another solution, as Rui indicates, is to darken the background in notes a little more. Not as much as in events, because the truth is that one of the cool things about your theme is clearly distinguishing the notes and events area, but something else.
The grayscale theme has been updated (e.g. heavily borrowed from our CSS-Jedi G3N-es). The biggest update is how the selected mixer strips are highlighted. I spent some time in qtractorMixer.cpp wrestling with things (getting nowhere) and ended up brute forcing my solution. There seems to be this assumption made that a selected track (and now his friends) should be darkened. With a darker theme, that's not going to work. There also seems to be some voodoo involving a strange (abusive?) relationship between the midlight and base colors I just don't understand. In order to overcome these issues, did terrible things in the form of the following:
The mixer strips (and sequencer) highlighted has been my great template frustration.
Although a QSS expression like the following should work, it doesn't:
What you propose about forcing it to be a specific color of the color theme that is not affected by "relationship between the midlight and base colors" may be a practical solution... but limited.
(I think it would be nice if something like this was implemented in official Qtractor. The current automatic behavior "midlight and base" you mention I think is intended to avoid conflicts between dark and light themes. But not only does it not solve it, but it makes it unpredictable and difficult for the user to solve it themselves by selecting the colors they consider most appropriate.)
I still don't know why it can't be accessed by QSS, which is the real solution.
I even tried modifying Qtractor code to see if I could make it highlighted accessible, but I didn't succeed.
In the end I decided to accept that it is a limitation of customization, and make customization possible within that limit (in this case playing with the midlight and base colors of the color theme).
Just so we're clear, the fact I brute forced a solution by way of editing and recompiling the source code wasn't meant as a "solution" as that approach just swaps out one assumption (darker) for another (lighter). I only shared details about what it took from my side in order to highlight the location of the issue.
Have you been able to to access/modify the [A] button? I tried via qtractorCurveButton:checked but was not successful. For reference, the class is define here
If you look closely, that button doesn't have a checked state. What is checked is the dropdown menu, not the button.
The lighting in case of recording or playing automation is custom created in Qt, and I don't think it can be customized by QSS.
It's a CSS limitation that QSS inherits: By having a cascading logic, the parents cannot be affected by the behavior of the children.
This limitation is sometimes a pain in web development as well. For those cases where CSS falls short we use JavaScript (usually JQuery which keeps the semantics of the calls in CSS but expanding it to affect parents).
Update on VTQ
I have uploaded your update along with one from Tecnico.
This time I uploaded it without modifying anything. Downloaded from your Git, uploaded to VTQ.
Greetings :)
https://sourceforge.net/projects/visualthemes-qtractor/
Greetings right back at ya :)
Greetings right back at ya :) I'll be checking out your newer stuff later tonight. Always on the lookout to make improvements. Thanks for letting me know.
Updated to v0.4
Updated to v0.4
Help requested on issue with ghost notes
Hello again,
I've noticed my theme is suffering when it comes to clearly showing ghost notes and wonder if anyone has ideas? Track colors are always set to the following:
Foreground: #222222 Background: #878c6a
re. Help requested on issue with ghost notes
increase lightness or value of the track foreground color; or/and use a darker base color on the palette.
ps. that's probably the price you take for having such a low-contrast color theme.
Hi Rui,
Hi Rui,
I gave it a shot but even setting foreground color to #ffffff results in too many undesirable side-effects. For example, shadows (I thought I disabled them... maybe I forgot this last time) are now white? The left-most area of the track takes on that color as well and despite both being set to the same color, there appears to be a tint of sorts applied which is clearly intended as a helper in order to help distinguish rows. Needless to say, it's clear all of these issues are a direct result of the magic coloring algorithm happening behind the scenes. Clearly, this algorithm offered tremendous value at one point (and still will for those who choose to avoid what is possible with QSS) but things are at a point now where it can certainly be a bit of a thorn in Qtractor's side. Even though I know it's a bit of a band-aid, perhaps I could request yet another global color option for the purpose of rendering this ghost data?
All the best
re. Help requested on issue with ghost notes
sorry, I meant track background color (not foreground)
and nope, there won't be any other color option for ghost notes: they are just dimmed/transparent versions of the non-ghost colors. and that's it.
byee
Darken the background in notes
I think it is mainly a problem of saturation.
If the theme is dark gray (saturation 0), demand tracks with very saturated and light color.
Try #eaff04.
If you look at your events, the ghost notes are much more readable.
Another solution, as Rui indicates, is to darken the background in notes a little more. Not as much as in events, because the truth is that one of the cool things about your theme is clearly distinguishing the notes and events area, but something else.
OK, I understand. Thank you
OK, I understand. Thank you both for the clarity. I'll muck with the piano roll's background.
oh yea!
oh yea!
The grayscale theme has been
The grayscale theme has been updated (e.g. heavily borrowed from our CSS-Jedi G3N-es). The biggest update is how the selected mixer strips are highlighted. I spent some time in
qtractorMixer.cpp
wrestling with things (getting nowhere) and ended up brute forcing my solution. There seems to be this assumption made that a selected track (and now his friends) should be darkened. With a darker theme, that's not going to work. There also seems to be some voodoo involving a strange (abusive?) relationship between themidlight
andbase
colors I just don't understand. In order to overcome these issues, did terrible things in the form of the following:re. mixer strips highlighted
The mixer strips (and sequencer) highlighted has been my great template frustration.
Although a QSS expression like the following should work, it doesn't:
qtractorMixer qtractorMixerStrip[selected= "true"] {}
What you propose about forcing it to be a specific color of the color theme that is not affected by "relationship between the midlight and base colors" may be a practical solution... but limited.
(I think it would be nice if something like this was implemented in official Qtractor. The current automatic behavior "midlight and base" you mention I think is intended to avoid conflicts between dark and light themes. But not only does it not solve it, but it makes it unpredictable and difficult for the user to solve it themselves by selecting the colors they consider most appropriate.)
I still don't know why it can't be accessed by QSS, which is the real solution.
I even tried modifying Qtractor code to see if I could make it highlighted accessible, but I didn't succeed.
In the end I decided to accept that it is a limitation of customization, and make customization possible within that limit (in this case playing with the midlight and base colors of the color theme).
Just so we're clear, the fact
Just so we're clear, the fact I brute forced a solution by way of editing and recompiling the source code wasn't meant as a "solution" as that approach just swaps out one assumption (darker) for another (lighter). I only shared details about what it took from my side in order to highlight the location of the issue.
hey G3N-es,
hey G3N-es,
Have you been able to to access/modify the [A] button? I tried via
qtractorCurveButton:checked
but was not successful. For reference, the class is define hereqtractorCurveButton:checked
If you look closely, that button doesn't have a checked state. What is checked is the dropdown menu, not the button.
The lighting in case of recording or playing automation is custom created in Qt, and I don't think it can be customized by QSS.
It's a CSS limitation that QSS inherits: By having a cascading logic, the parents cannot be affected by the behavior of the children.
This limitation is sometimes a pain in web development as well. For those cases where CSS falls short we use JavaScript (usually JQuery which keeps the semantics of the calls in CSS but expanding it to affect parents).
@G3N-es
@G3N-es
Just having a fresh look at your most recent themes, I was able to steal enough from Tecnico to finally fix this long-standing annoying problem.
Now, when I hover over the A button in a non-focused track, focus is no longer hi-jacked! It's so good, I can barely stand it! Thank you!
OK. I almost thought I was
OK. I almost thought I was clever enough to figure that one out. Thanks for chiming in and saving me from sinking further into the abyss :D
For the time being, I've
For the time being, I've supplied a git patch and updated the installation instructions so folks can use the theme if they want.
My cat likes the recent
My cat likes the recent improvements made to the theme
Add new comment