Support native qt theme again

• Jul 17, 2013 - 20:57

revert ddbb8f5e706585d328d4f92344051ab87de19e67.

Comments

• Jul 18, 2013 - 12:24

Implement your proposed change, build it on your system and then show us the benefits in the form of some screen shots.
It had been taken out for a reason, so give good reason for putting it back.
Convince People, esp. the core developer(s), don't try to force them.

Discuss it here and not in the issue tracker, that is just the wrong place.

Reply

• Jul 18, 2013 - 12:30

Seems OK and non-intrusive to me, giving users a choice is a good thing IMHO. I would still like to see some screen shots (using the native scheme, on Linux, Mac, Windows) to check on the visible consequences

That brace style change for musescore.cpp is not really needed, better drop it

Reply

• Jul 18, 2013 - 12:37

Nt 100% my taste, but looks OK to me, it is all readable (as far as that can be said about chinese chars ;-))
And still Looks recognizable enough so won't get us into dificulties with a handbook and its pictures.

BTW: you can attach PNGs directly here and even show them inline

Reply

• Jul 18, 2013 - 13:02

Some thoughts.

1. MuseScore should look distinctive so that a user seeing it on any platform should be able to say - ah! that's MuseScore.
2. Supporting QT5 themes would make it look exactly like the million and one other QT applications
3. What is wrong with the light version of the existing theme?

I honestly don't see the point of yet another upheaval in the source code.

We're nearly 2 years behind with a stable release of MuseScore 2 already, and adding this is only going to delay things further!

Reply

• Jul 18, 2013 - 13:10

1. Can you give some examples of the "cross-platform uniform-looking" applications you have mentioned.
2. Isn't this a qt application?
3. Oxygen has too big padding for me and it looks different with other applications.
4. If you want to go deeper, there are high contrast themes designed for people with disability. Neither the light or the dark theme can do this.
5. Having to maintain a theme yourself will delay it, not if you use whatever the toolkit already have.

Reply

• Jul 18, 2013 - 13:58

1. Can you give some examples of the "cross-platform uniform-looking" applications you have mentioned.
* Spotify client
* Sublime text 2
* Chrome
* Hydrogen

2. Isn't this a qt application?
It happens to use Qt but it's not a Qt application. Are Maya or Skype Qt applications just because they happen to use Qt?

3. Oxygen has too big padding for me and it looks different with other applications.
Yes. That's somehow the point. Be different.

One of the problems of custom theme is the color of icons. In your examples, the color is fine because the background is gray.

Reply

• Jul 18, 2013 - 14:17

* Spotify client
* Sublime text 2
* Chrome
* Hydrogen

Not sure about other ones but both chrome and sublime text use system gtk2 themes.

> It happens to use Qt but it's not a Qt application. Are Maya or Skype Qt applications just because they happen to use Qt?
Why aren't they? (And Skype is also a cross-platform application using system qt theme btw.)
Qt is a toolkit and any apps that uses the library is a Qt application for me. I am not going to argue the precise definition of Qt application but I don't see why looking like an application written with Qt is bad or why you want to make it looks different from normal Qt applications taken into account it looks similar (because oxygen is the default theme in KDE) but worse than (because X11 specific part is removed) the default theme under KDE.

> Yes. That's somehow the point. Be different.
Basically I mean it may not be the preferred theme for someone and it may looks totally inconsistent with all other applications.

> One of the problems of custom theme is the color of icons. In your examples, the color is fine because the background is gray.
I didn't add a "system theme with dark icon" option just because you said[1] you are dropping the dark theme. It can be easily added if the dark theme will not be dropped.

[1] http://musescore.org/zh-hans/node/21875#comment-82633

Reply

• Jul 18, 2013 - 16:09

To me, the question of whether or not MuseScore is a Qt application in some sense beyond the fact that it happens to have built with Qt libraries seems crazy. 99% of the world has never heard of Qt and has no concept of what being Qt application might mean. If it happens to be easy to support whatever this native theme thingamajig is, then fine, that 1% of the world who understands how to take advantage of this fact would be happy. But no way could I possibly see it being worth impacting the 99% who just want MuseScore to work. If it can be done without ever introducing more than days delay in the release schedule now or at any point in the future, then sure, why not. But at this point, it sure sounds like the prevailing opinion is pretty strong that it *does* carry risk, and right now, I see no reason to thnk it is worth it.

Reply

• Jul 18, 2013 - 18:16

I do not have the technical expertise to say what the risk might be in any precise terms. All I can say is that two people who *are* intimately familiar with MuseScore internals seems to think it is not as simple as your 30 minute hack might lead one to believe. Maybe they are wrong and you are right, I don't know. But until someone can conclusively show otherwise, I tend to trust their opinion in these matters.

Reply

• Jul 18, 2013 - 18:35

Can you please quote the word you mentioned about "two people" "think it is not as simple as" my "30 minute hack"? Correct me if I am wrong but I think you and Jojo-Schmitz are the only two people who have ever said anything after my patch and Jojo-Schmitz doesn't seems to have strong option against the patch yet.
Werner said he is the one that made the decision and only he said he had some different experience on this before I uploaded the patch but I have never get any reply/explanation on that anywhere later.

P.S. There is nothing hacky about this patch, it just adds back what ever removed in the commit at July 10th which removes native style support.

Reply

• Jul 18, 2013 - 18:46

It kind of seems you are being argumentative just to be argumentative. The details of which person said what and when are there in plain sight but don't seem relevant. Werner and lasconic are the two lead developers on MuseScore, and both have expressed reservations about supporting native themes, supported by some specific reasons. Right now, as far as I am concerned, it's their word against yours. As I said, maybe you are right and they are wrong, but until this is demonstrated objectively, I will continue to trust their expressed opinions.

Reply

• Jul 18, 2013 - 20:21

> It kind of seems you are being argumentative just to be argumentative.

That's because you are just saying what other people says without anything helpful. Moreover anything they said is before the patch with nothing and lasconic also said he has nothing to add if I want to commit for this.

Reply

• Jul 18, 2013 - 16:53

And in fact, if you think 99% of the users only care about a working application, you shouldn't fork oxygen and provide your own theme anyway, which means removing 20k+ lines of code that contain totally irrelevant stuffs in it (e.g. hack for certain applications support like konsole in mystyle).

Reply

• Jul 18, 2013 - 20:35

Thing is yuyichao there has been a lot of time and effort put in by a significant number of people in getting MuseScore to look the way it is now.

You are suggesting that we simply throw all that away because of your whim.

If you don't like the way it looks you are at perfect liberty to set up a fork of MuseScore which caters for your own personal tastes.

Just don't expect the rest of us to be very enthusiastic about this until a lot further down the line when you have established it as a stable fork.

Reply

• Jul 18, 2013 - 23:23

> Thing is yuyichao there has been a lot of time and effort put in by a significant number of people in getting MuseScore to look the way it is now.

git log of mstyle folder:
5 authors (three of which has only 1 commit)
34 commits (most of which are white space/style changes, doing and undoing each others, removing broken x11 support, fixing for warnings)
After removing non-relate and no-op changes, there is only < 100 lines of changes. I appreciate the effort ws put into finely tuning some coordinate and colors but I somehow don't think it is "a lot of time and effort put in by a significant number of people". (This makes sense, as you have said, because musescore is a music application so it is not the most important how it looks and also because you don't have a lot of people to maintain it)

> You are suggesting that we simply throw all that away because of your whim.

My feature request was to add back native theme support but not removing the built-in theme, which is as simple as you can see in my patch. However, you are telling me you don't have enough people and that's why I am saying dropping the built-in theme is actually what you should do if that is a problem. It doesn't make sense not having enough people to support native themes since it actually requires less effort to maintain.

Reply

• Aug 13, 2013 - 23:55

..or I would have expressed my feelings (for what they are worth..) more timely.

I agree to a large extend with yuyichao. At least, for the part about 'supporting' native themes (but 'not inhibiting' would be more appropriate).

Most of the replies on this aspect involve some narcissistic need for a "brand look": 'we' need to distinguish MuseScore from the pack, so 'we' use 'special' visual effect (be it a specific colour or something else) and 'we' force users to have an application which is unusual in some respect (if it is not unusual, it is not 'recognizeable').

I totally disagree with this approach: I find irritating that too many applications force me to cope with different colour schemes, different shapes of controls, different indications of which is the default button of a dlg box, down to apparently minor details like the shape of the tree expand/collapse symbol (only apparently minor, because it is something you meet very often).

This is disturbing, makes things more difficult to use, not less, and force the user to spend time (or a fraction of his/her brain 'clock cycles') after irrelevant matters, rather than having the 'job done' (not to mention the time I usually spend after installing something new, trying to de-skin it, to remove all the 'fancy' things, the 'cute' icon sets and so on, which in most cases are simply visual noise on the screen).

Of course, the most important point is to have a working (and a reliably working) application, but this cannot be an excuse for forcing upon the users something unusual: if there are no enough resources to support fancy visuals, than drop them, stick to native visuals and focus on the 'real' code (the musical part).

The amount of effort, time, discussions, ... spent on the colours of the new icon set is a clear indication that supporting a custom, non-standard, colour scheme is MORE expensive than sticking to native visuals, not less. (Note that I do not include in this the discussions about icon shapes: this is on a different level and would have applied regardless of theme or colour scheme).

And the final result is still debatable as, particularly for the dark theme, having a black which is not black and a white which is not white forces a reduced contrast which affects readability (not to speak of the hack of having active icons indicated with azure, which has an even lower contrast with the background than the non-active foreground). Major lines of development of UI's know about these issues since long and have a greater experience in approaching them; 'they' do not get it right every time, but most of times they actually do, methink.

Summarizing my (unorthodox, I know) position:

1) Inhibiting native visuals makes little sense and, for some users, is an added malus, not a bonus.

2) Support for additional, non-standard, visuals might be interesting, but may also be rather expensive in terms of resources (see the amount of code in the mstyle folder) and, if resources are scarce, this is the first corner to cut, not the last.

Of course, these aspects do not change my opinion on MuseScore; they are just "visual noise on the screen" of a great application.

Thanks,

M.

Reply

• Aug 14, 2013 - 21:24

Miwarre, I couldn't have put it better myself!

In a past life, I supported very early model IBM PCs which ran emulator programs to let them work as IBM mainframe computer terminals. We had a standard colour scheme (black background, green text, etc., etc.) for the emulator program, which we applied company-wide to make it easier for people used to using the Real Terminals to switch to the 'new-fangled' PCs.

Having rolled this out maybe 300 times, one user called us to say they couldn't use the emulator because of the colours, which made it very hard for them to read anything. It turned out they had very bad colour-blindness which required what to anyone else would seem a garish, weird colour scheme on their PC, and they needed the emulator program to do that as well. Luckily I had the tools with me to do that, and the changes were done, tested, tweaked, and approved and installed within 15 minutes.

Ever since, I've remembered that incident and made it my mantra that, whatever else you do when you're coding, you use standard widgets, or at least widgets which inherit the user's chosen colours, fonts, sizes, etc. fom the OS. If that's not possible, it seems to me that, as a responsible coder*, you have two options: a) give the user the built-in tools to be able to change colours etc. themselves; and/or b) provide enough themes/skins/whatever you call them in a full range of different colours such that everyone can find one they can live with. I have no idea how Qt5 widgets work, but if it's easily possible without a massive amount of work — and others in this thread have sought to prove that it is — then some option to allow 'use the equivalent native OS colours/fonts/etc.' would be a very welcome addition to the visual themes available in MuseScore v2.0.

*Reponsible also to not making your creation unusable to a small but significant part of its potential user base, i.e. not scoring an 'own goal.'

PS: My vote would be for yuyichao's "Ms Windows 9.0" theme, assuming it would be too much work to just inherit the user's OS settings.

Reply

• Aug 14, 2013 - 22:27

Re: "I totally disagree with this approach: I find irritating that too many applications force me to cope with different colour schemes, different shapes of controls, different indications of which is the default button of a dlg box, down to apparently minor details like the shape of the tree expand/collapse symbol (only apparently minor, because it is something you meet very often)."

I totally agree with this comment.

I have no grasp on the details that you are discussing, but I too am annoyed by constantly having to look in different places for similar functionality.

Being different just for the sake of being different is, to me, a waste of time. Making an application easier to use is far more appealing than something that looks different.

I also second the last part of Miwarre's post: "Of course, these aspects do not change my opinion on MuseScore; they are just "visual noise on the screen" of a great application."

A great application, thanks.

Reply

• Aug 15, 2013 - 19:42

FWIW, I don't think any of this is really better where you go to look for functionality. It's really just about the physical appearance of controls. For instance, none of this is about whether you find Hairpins under the Dynamics or Lines palette, or whether you use Style / General / Score or Layout / Page Settings to control some aspect of score layout. It's just about whether the palette has square or rounded borders, what shade of grey is used for inactive menu items, etc.

Reply

• Aug 15, 2013 - 22:59

Marc, of course you are correct.

I agree it may seem like 'eye candy' and very trivial compared to the core functionality (which I agree with), and yet … If one finds an application more difficult, or just more tiring, to use because of the way it looks, then one won't want to have to spend long hours in front of it.

Also, you won't do your best work if you feel that at some level, you're having to 'fight' the GUI. It's a slightly intangible thing, but I'm sure you can think of some apps. which somehow just feel harder to use than they need to be in some way you can't quite nail down and put your finger on. Sometimes, it's as simple as the look-and-feel, and rounded corners, colour use, etc. are big parts of that. Ditto, an application should be accessible as possible to people with all kinds of disabilities, including vision problems of all sorts.

Yes, these things are small fry in the cut and thrust of producing a new, improved version of MuseScore. They are also usually easier to sort out if they are done early in the development process, and can involve only very small code changes. The recent issue of removing the underline in dropdowns being a case in point: probably only a minute or two (?) to change, but instantly makes all dropdowns in MuseScore much more usable for me, and probably a lot of other users as well. Surely that's the type of 'bang per buck' that most developers would be proud of? And it doesn't really delay other, more important fixes and improvements being produced.

So I'm always grateful when a developer takes a little issue like the underline in the dropdowns on board, and takes the few minutes to 'fix it.' Disproportionate amount of pure win for all concerned ensues, it's one fewer thing to tweak, and we all move on to the next thing.

Oh, and like Miwarre, I really do think MuseScore is a great application! If I had the choice of using Finale, Sibelius, or MuseScore, I would choose MuseScore every time: no question.

PS: Before anyone asks, yes I'm a coder; but no, I don't code in any C-type language. Otherwise I might well have looked through the source code by now!

Reply

• Aug 15, 2013 - 23:19

BTW, you might be interested to learn that accessibility is a special area of interest for me. But my focus is on those with essentially no sight whatsoever - making sure as much as possible is keyboard-friendly and screenreader-friendly. And I've contributed a (very) small amount to MuseScore 2.0 in this area already. But there is quite a lot more to do before one could reasonably call MuseScore usable to a blind musician, and much of this work requires expertise in Qt I don't have. So I don't see myself being able to really do anything for 2.0. I am, however, actively trying to drum up interest in this on the MENVI mailing list. I have no insight at all into the issues of limited-vision folks - like, for instance, I don't understand how rounded versus square button corners make any sort of difference - but I think that dealing with those sort of issues also requires expertise in Qt I don't have.

Reply

• Mar 25, 2014 - 01:32

As a user with minimal dev experience, I would love this to be implemented -- for sure, keep your custom styles as the default, but definitely allow a native UI for those users who want one. Whether users prefer apps to be individually themed or consistent across a system is highly personal and not really something that devs should be enforcing either way without good reason.

if you really really don't want to deal with "Native UI combo boxes are 1px too small when using QtCurve 5.4.1230a" bugs then hide it behind a command line option (Qt uses --style by default I believe) with "UNSUPPORTED" plastered all over it. The given patch is tiny, useful, and I can't see how it adds any significant maintenance burden.

Reply

Do you still have an unanswered question? Please log in first to post your question.