Appearance dialog

[kybos]

I am trying to understand the Appearance dialog, it has confused me a lot from the beginning.
It includes many different concepts which don't really match:

1. "Normal" settings, reflecting the current global configuration (applied with Apply/OK).
2. The Colors with live update (applied with Apply/OK, but only temporarily for the current session).
3. Color scheme, which ignores Apply/OK, must be applied using its own Change button (very confusing for the user, it there a technical reason for this special treatment?).
4. The font definitions, which ignore the actually used (system) fonts and propose "arial" for everything (BTW: It should at least be Helvetica as a generic sans serif font IMHO, Arial is a Microsoft font and in no way a standard, especially not on Linux). As a consequence, every time Apply/OK is pressed, the application font is changed to what Qt thinks is the best match for Arial (which must look like a bug to the user, because the initial MusE font apparently comes from the Qt style or a stylesheet and will be different in most cases, usually Qt takes the system font as a default).
   The Qt docu states that QApplication::setFont should never be used in connection with stylesheets, and it seems there is a good reason for it. I tried a couple of things already but could not find a satisfactory solution yet.

[terminator356]

Sorry for late reply. Appearance is a complex topic. So much to say.
Just to say I'm in there working hard on some of the problems.
Not sure yet where it's leading, may or may not be many small areas to fix up.

The Colors with live update (applied with Apply/OK, but only temporarily for the current session).

Wasn't sure what you meant by 'temporarily' until I observed it today.
Yeah, I know, our whole colours/fonts vs stylesheets thing is slightly flawed.
It gave me a lot of trouble before. But the more I learn the more I shape it like putty.
Careful examination today showed the nature of the colour/font problems.
I have succeeded in exposing the rack and background colours. Hang in there, there's more to come.
Today I learned for the first time how to use style::unpolish() and polish().
It means I was able to this, in ctrlpanel.cpp : CtrlPanel::setControlColor()
_patchEdit->setReadoutColor(color);
style()->unpolish(_patchEdit);
style()->polish(_patchEdit);
It means we set our colour, then if there is anything related in the stylesheet,
the stylesheet overrides. And it will not let our colour override, enforcing the sheet's priority.
I struggled all day with that - the colour refused to update from the stylesheet.

This is good. For example calls to CtrlPanel::setControlColor() do not necessarily
happen as a result of changes in Appearance or Settings or signals like configChanged().
They happen simply by selecting the midi control to view!
The control is not destroyed and recreated. So stylesheet had no effect without un/polish().
Then I applied the fix to the mixer strips where a similar problem was.
I observed as you probably did that once you set any of our colours it wipes out
the stylesheet's with all of ours.

At this point before we start exposing more colours we have a few options.
Coexistence of our colours and stylesheet IS possible.

• Good: Use the code above everywhere, and warn users "stylesheet has priority if set".
• Better: Introduce a boolean priority flag for each colour "this colour has priority".
  The user is able to keep a stylesheet AND modify colours. But it's more user 'micromanagement'.
  We could simply modify the above code to check the flag and if false don't call polish().

I need to point out: I have a way to expose all of our configuration colours.
Since stylesheets only work with QWidget not QObject, it would not help to say,
make our configuration structure inherit QObject.
The colours can be housed in a widget or kept outside, but either way
the widget will have Q_PROPERTYs with setters / getters for each colour.
Here's the thing about that: You may end up with a choice: You can modify a
config colour in the stylesheet and it will affect ALL the controls that use it.
Or, you can modify each control separately in the stylesheet since we expose
their colour properties. Exposing the Rack and ElidedText and CompactKnob
background colour properties allows this. Normally they all have our config colour in common.
At the moment I have them all different colours!

Also, I have an eye towards being able to switch stylesheets on the fly without restarting.
There are challenges. Resetting colours for example. Looking into it...

All for now... Cheers.

[kybos]

Sounds good. So I will wait for your changes to avoid potential conflicts.

[terminator356]

Exposed new colours for stylesheets.See Ardour and Dark qss files.
I didn't go as far as any of the things I mentioned. No time ATM.
But at least the new colours added should stay that way and should not be overwritten
when someone changes a colour in Appearance.