Is there a good reason to remove theme support in qt5 reason???
Why do you think your home-made theme(s) will be better than all the coming qt5 themes?
Is it supper hard to support themes in qt5???
Or have you EVER got any MAJOR problems with any major qt theme at qt4 time???
We are a very (very) small team of developers and we don't want to support native themes on windows, mac and linux. It often means special icons for dark/bright theme difference etc... so we are just supporting dark and light theme we made (based on oxygen) and we are thinking about dropping the dark one.
We also think that it's better for users to have the same "Musescore" on every platform.
> We are a very (very) small team of developers and we don't want to support native themes on windows, mac and linux.
You are a very smal team of developers so you don't want to write a theme yourself, but use existing qt themes instead and then not even bothering providing an interface to select themes.
> It often means special icons for dark/bright theme difference etc...
It means you use whatever styling interface qt5 support and let users choose the right icon and color. This also means users can create themes for you. For application specific icons, it is enough to just provide a light and a dark theme (maybe even not the dark theme) and native themes can take care of fallback and theme-specific themes if necessary.
> so we are just supporting dark and light theme we made (based on oxygen)
Not even upstream?
> and we are thinking about dropping the dark one.
So you don't even care about create icons for the dark theme, and you don't need to do anything more if you support native themes either.
> We also think that it's better for users to have the same "Musescore" on every platform.
Users have the same "Musescore" if they use the same theme. And it is generally more important to make it looks the same with OTHER applications on the same platform for a user since he will most likely comparing Musescore with what he can see at the same time (which means other apps on the same platform). For users who cares about cross platform consistency (which actually is impossible) a cross-platform theme is the right way to go, e.g. default qt themes and the coming oxygen-qt5.
What you are doing is reinventing the wheel qt5 have made to have a cross-platform looking!!!
That's your opinion. MuseScore is primarly a multi platform application. And I mean Windows, Mac and Linux by multiplatform, not KDE and GTK only. I'm sure you know how hard it is to support one theme (https://github.com/yuyichao/qtcurve-qt5). We don't want to deal with all the disprecancies on each platform. Having one common theme also makes documentation clearer. Musescore users are typically not Arch users (unfortunately), they are typically musicians, on Windows, with limited computer abilities.
Except if you want to commit in supporting the interface with qt theme, I have nothing to add.
I admit it, I like the looks of some software more than others - but how would having more themes improve the music or writing process? I applaud the team for judicious control of the project scope. Or else, you know, musescore might turn into EMACS. :)
You don't need to support ANY themes, just don't write your own.
What I have done is porting qtcurve theme to qt5, so I know how hard it is to do this, and it is NOT hard at all. It is a little bit tricky to make x11 integration works but 1) this is sth you have not done with your oxygen fork, 2) this is not sth you need to care about to "support a theme" (although you don't need to "support" any themes anyway).
> We don't want to deal with all the disprecancies on each platform.
You don't need to do anything to support system theme. In fact, you need to deal with a lot more thing if you want to write your own theme. Moreover, since you are writing your own theme and don't want to deal with platform detail, the oxygen port looks horrible on X11 (e.g. with no menu shadow).
> Having one common theme also makes documentation clearer.
Using qt default theme is very clear.
> Musescore users are typically not Arch users (unfortunately), they are typically musicians, on Windows, with limited computer abilities.
> Except if you want to commit in supporting the interface with qt theme, I have nothing to add.
There is nothing special you need to do in order to support native theme and YOU ARE already using the qt theming interface! I have removed the lines that hard coded the theme in mscore.cpp and it works perfectly just as in 1.*. If you think it is acceptable for me to submit a patch fixing this issue, I can easily format a better patch and submit it on github.
> I admit it, I like the looks of some software more than others - but how would having more themes improve the music or writing process?
Why is it bad if it need less effort to maintain? (and it really is, what I have done to load my system theme is to comment out lines in the source code.)
> I applaud the team for judicious control of the project scope. Or else, you know, musescore might turn into EMACS. :)
Turning into EMACS is different from just using what the toolkit already supports. There is no script interface, no additional options, no extra code, no extra maintaining effort you need to support it. ONLY LESS.
My experience is different than yours. Its my decision for 2.0 to support only one buildin theme or at most two (light and dark).
So this is _not_ a bug. Maybe a feature request is acceptable.
If you want to discuss this further, please do this on the forum.
MuseScore is OpenSource, so grab the source and modify to your likings.
If it turns out to be useful and easy enough to maintain, Werner may change his mind on this ;-)
Here is the simplest patch I have mentioned above.
The point is they do this BY_DESIGN and want to maintain a broken theme (by broken I mean no X11 support) on their own and call this easier to maintain. The patch above only add native theme support back (by not doing anything) and it will be even easier to maintain if you just remove mstyle/.
Jojo-Schmitz:
1. I have already started a thread on the forum under "feature request" (and no one reply btw).
2. I post here again just because YOU reply here again!!
3. werner says "Maybe a feature request is acceptable" and so I have already changed this to "feature request".
The usual way here is to first discuss a feature request in the Forum and once some consensus is reached there, to submit a request via the issue tracker. You're doing it the other way round and are trying to apply preassure on the developers regardless their repeated and continuos resistancen. Constant nagging won't help.
The issue tracker is not for discussions.
Pull request https://github.com/musescore/MuseScore/pull/414 seems stuck since quite a while.
Considering that the core developers seem to have decided not to support it, shouldn't the PR get closed?
I'd like to address this issue with a final statement from Werner, Lasconic and myself. While you may not be satisfied with this answer, please do respect it.
MuseScore does not support native theme for these reasons:
* Development resources: Specific widgets (e.g. voice buttons) are developed for MuseScore and they don’t work or are not implemented in native themes. There are no development resources to support native themes. Using a native theme does not work out of the box.
* Documentation and support: Screenshots in documentation will be consistent across platforms. Overall having people using the same UI helps direct support efforts.
* Maintenance: MuseScore has control on the supported themes now while it doesn’t have control on native theme. If there is a bug in the theme, it’s easier to fix. If you encounter a bug, please report.
MuseScore does welcome improvement ideas or patches for the current supported themes.
Comments
Yes. That's on purpose. We don't want to support native theme.
Is there a good reason to remove theme support in qt5 reason???
Why do you think your home-made theme(s) will be better than all the coming qt5 themes?
Is it supper hard to support themes in qt5???
Or have you EVER got any MAJOR problems with any major qt theme at qt4 time???
We are a very (very) small team of developers and we don't want to support native themes on windows, mac and linux. It often means special icons for dark/bright theme difference etc... so we are just supporting dark and light theme we made (based on oxygen) and we are thinking about dropping the dark one.
We also think that it's better for users to have the same "Musescore" on every platform.
> We are a very (very) small team of developers and we don't want to support native themes on windows, mac and linux.
You are a very smal team of developers so you don't want to write a theme yourself, but use existing qt themes instead and then not even bothering providing an interface to select themes.
> It often means special icons for dark/bright theme difference etc...
It means you use whatever styling interface qt5 support and let users choose the right icon and color. This also means users can create themes for you. For application specific icons, it is enough to just provide a light and a dark theme (maybe even not the dark theme) and native themes can take care of fallback and theme-specific themes if necessary.
> so we are just supporting dark and light theme we made (based on oxygen)
Not even upstream?
> and we are thinking about dropping the dark one.
So you don't even care about create icons for the dark theme, and you don't need to do anything more if you support native themes either.
> We also think that it's better for users to have the same "Musescore" on every platform.
Users have the same "Musescore" if they use the same theme. And it is generally more important to make it looks the same with OTHER applications on the same platform for a user since he will most likely comparing Musescore with what he can see at the same time (which means other apps on the same platform). For users who cares about cross platform consistency (which actually is impossible) a cross-platform theme is the right way to go, e.g. default qt themes and the coming oxygen-qt5.
What you are doing is reinventing the wheel qt5 have made to have a cross-platform looking!!!
That's your opinion. MuseScore is primarly a multi platform application. And I mean Windows, Mac and Linux by multiplatform, not KDE and GTK only. I'm sure you know how hard it is to support one theme (https://github.com/yuyichao/qtcurve-qt5). We don't want to deal with all the disprecancies on each platform. Having one common theme also makes documentation clearer. Musescore users are typically not Arch users (unfortunately), they are typically musicians, on Windows, with limited computer abilities.
Except if you want to commit in supporting the interface with qt theme, I have nothing to add.
I admit it, I like the looks of some software more than others - but how would having more themes improve the music or writing process? I applaud the team for judicious control of the project scope. Or else, you know, musescore might turn into EMACS. :)
> That's your opinion. MuseScore is primarly a multi platform application. And I mean Windows, Mac and Linux by multiplatform,
That IS what I mean by platform as well.
> not KDE and GTK only. I'm sure you know how hard it is to support one theme (https://github.com/yuyichao/qtcurve-qt5).
You don't need to support ANY themes, just don't write your own.
What I have done is porting qtcurve theme to qt5, so I know how hard it is to do this, and it is NOT hard at all. It is a little bit tricky to make x11 integration works but 1) this is sth you have not done with your oxygen fork, 2) this is not sth you need to care about to "support a theme" (although you don't need to "support" any themes anyway).
> We don't want to deal with all the disprecancies on each platform.
You don't need to do anything to support system theme. In fact, you need to deal with a lot more thing if you want to write your own theme. Moreover, since you are writing your own theme and don't want to deal with platform detail, the oxygen port looks horrible on X11 (e.g. with no menu shadow).
> Having one common theme also makes documentation clearer.
Using qt default theme is very clear.
> Musescore users are typically not Arch users (unfortunately), they are typically musicians, on Windows, with limited computer abilities.
> Except if you want to commit in supporting the interface with qt theme, I have nothing to add.
There is nothing special you need to do in order to support native theme and YOU ARE already using the qt theming interface! I have removed the lines that hard coded the theme in mscore.cpp and it works perfectly just as in 1.*. If you think it is acceptable for me to submit a patch fixing this issue, I can easily format a better patch and submit it on github.
> I admit it, I like the looks of some software more than others - but how would having more themes improve the music or writing process?
Why is it bad if it need less effort to maintain? (and it really is, what I have done to load my system theme is to comment out lines in the source code.)
> I applaud the team for judicious control of the project scope. Or else, you know, musescore might turn into EMACS. :)
Turning into EMACS is different from just using what the toolkit already supports. There is no script interface, no additional options, no extra code, no extra maintaining effort you need to support it. ONLY LESS.
My experience is different than yours. Its my decision for 2.0 to support only one buildin theme or at most two (light and dark).
So this is _not_ a bug. Maybe a feature request is acceptable.
If you want to discuss this further, please do this on the forum.
Do you have a thread explaining why the decision is made??
MuseScore is OpenSource, so grab the source and modify to your likings.
If it turns out to be useful and easy enough to maintain, Werner may change his mind on this ;-)
Here is the simplest patch I have mentioned above.
The point is they do this BY_DESIGN and want to maintain a broken theme (by broken I mean no X11 support) on their own and call this easier to maintain. The patch above only add native theme support back (by not doing anything) and it will be even easier to maintain if you just remove mstyle/.
Just stop doing this, please. Submit a pull request maybe, but please, pretty please accept Werner's stand on this
Jojo-Schmitz:
1. I have already started a thread on the forum under "feature request" (and no one reply btw).
2. I post here again just because YOU reply here again!!
3. werner says "Maybe a feature request is acceptable" and so I have already changed this to "feature request".
The usual way here is to first discuss a feature request in the Forum and once some consensus is reached there, to submit a request via the issue tracker. You're doing it the other way round and are trying to apply preassure on the developers regardless their repeated and continuos resistancen. Constant nagging won't help.
The issue tracker is not for discussions.
So you mean, if I have a feature request and have a patch for that. I cannot submit it on the bug tracker?
Not without having reached some consensus in the Forum and the core developers that this change is a Good Thing (tm).
updated patch. Not for continuing discussing here, just to replace the previous one which has a few lines missing.
Pull request https://github.com/musescore/MuseScore/pull/414 seems stuck since quite a while.
Considering that the core developers seem to have decided not to support it, shouldn't the PR get closed?
Or is it pending because yuyichao hasn't yet signed the CLA (http://musescore.org/cla)?
re-reading I've realized that it had been turned into a feature request...
I'd like to address this issue with a final statement from Werner, Lasconic and myself. While you may not be satisfied with this answer, please do respect it.
MuseScore does not support native theme for these reasons:
* Development resources: Specific widgets (e.g. voice buttons) are developed for MuseScore and they don’t work or are not implemented in native themes. There are no development resources to support native themes. Using a native theme does not work out of the box.
* Documentation and support: Screenshots in documentation will be consistent across platforms. Overall having people using the same UI helps direct support efforts.
* Maintenance: MuseScore has control on the supported themes now while it doesn’t have control on native theme. If there is a bug in the theme, it’s easier to fix. If you encounter a bug, please report.
MuseScore does welcome improvement ideas or patches for the current supported themes.
OK, would then someone please also close that PR #414 ?