Eek! What's happened to the main toolbar?
The toolbar icons have suddenly gone from black to white in the latest Windows nightly (R3432cdc)
Which looks extremely odd on the light grey background I use.
Is this temporary or should I file an issue??
Do you still have an unanswered question? Please log in first to post your question.
Comments
It is temporary and you can file an issue if you want. You can swich to the dark theme in the meantime. (Edit -> Preferences -> General).
The light theme has been removed recently and the icons of the the light theme are used in the native UI for mac and windows...
In reply to It is temporary and you can by [DELETED] 5
Am I right in thinking that themes are controlled by CSS?
If so then I would be able to help with them, being fairly conversant with it from web design.
Still finding my way around the Git folder though so may need pointing in the direction of where they're stored :)
In reply to Am I right in thinking that by ChurchOrganist
Moving from SVN to Git had no effect on folder structure of MuseScore source code per se; so things should be where they were before. Of course, new 'things' have been added, some old removed and, possibly, some moved around; in other words, code is evolving (regardless of the version control system used).
Of course, this assumes you have a local copy of the source; if you work via web then, yes, browsing a Git repository might be different than browsing an SVN one!
As for your question, I have no clear idea of how themes are controlled / implemented, but the
MuseScore/share/styles/source folder contains some *.css files. You may browse the folder on-line at //github.com/musescore/MuseScore/tree/master/share/styles .M.
In reply to Moving from SVN to Git had no by Miwarre
Thanks Miwarre :)
I've already forked the Git MuseScore repo and now have it cloned on my external hard-drive.
If some kind soul could give me some idea of the theme architecture, I can probably produce some new ones.
In reply to Thanks Miwarre :) I've by ChurchOrganist
Its not that easy. I wasted a lot of time fiddling around with styles and it ended nowhere. Build-in styling conflicts with the *.css style files and it is hard to debug and find out whats going on (i.e. find out why it does not work as expected). Icons can only be switched programmatically. Some designer created dialogs contain icons. These icons have to be changed programmatically at several places depending on style. Other problems come up if you use the system file dialogs. There style can conflict with the MuseScore style which may result in disappearing of some text fields (white text on white background). This happend for some gtk based linux versions.
I want to concentrate on only _one_ style which is the current dark build in style with the build in file dialogs. All other style settings are unsupported (at least from my side).
The buildin style (mstyle) is an adaption of the kde oxygen style. Its about 25000 lines of code which gives an idea on the complexity of styling.
In reply to styles by [DELETED] 3
So you're saying CSS is a nono - is MuseScore currently ignoring the CSS files in the Styles folder then?
Maybe the way forward is for sets of icons then?
We probably need more than the single dark style, which I find doesn't how up the divisions between the tool sections clearly enough.
It seems to me that one way forward is to use a colour for the main tool palette which is equally visible on a dark and light background - a shade of green or blue should do it, or maybe red? Red would look awesome in the dark style :)
In the meantime I will have a look at the source code.
In reply to styles by [DELETED] 3
Werner - I spent a lot of time working on this yesterday.
There are one or two problems with using such a dark UI design, the most important being that as it is so dark it is diffcult to represent 3d shading on the icons - certainly on the Windows platform (my Linux box hasn't been set up yet after the move so I can't test on that yet). This means that it is difficult to see whether an icon is active or not.
In my programming days I would have got round this by using a multiple icon setup - so you have 3 sets of icons - one for the active state, one for the inactive state, and one for the on state. In terms of memory space that would take up roughly 1.5MB RAM - a fleabite by today's standards, although it would have been pretty significant in my programming days!
The exception would be the Voice Selection Icon which would require 6 state icons - Inactive, active, on 1, on 2, on 3, on 4
If it would be helpful to you for me to modify the existing set to cope with this, then I would be happy to do so. I will need to get set up so I can self-compile first though.