This is minor, because there is nothing below minor. As stated in the previous discussion, it's not a bug but a feature according to me. Unit are more readable without the space in spinboxes. Moreover, several other major open source software adopt the same behavior than MuseScore.
The concensus in the discussion also favor the current behavior. I will let this bug open for a couple of weeks but close it if the consensus doesn't change.
Nicolas: "This is minor, because there is nothing below minor."
Ha, ha, ha! What arrogance!
Nicolas: "Unit are more readable without the space in spinboxes."
No, that's not true. It is just sloppy program writing, that is the reason it's there.
Nicolas: "Moreover, several other major open source software adopt the same behavior than MuseScore."
Not e.g. Scribus, one of the most graphically aware and knowledgeable programs.
Nicolas: "The concensus in the discussion also favor the current behavior."
No, not at all. Marc advocates to provide space and a more legible version by having the unit outside the spinboxes, and Jojo is not against the space between numbers and unit. Their arguing with me is mostly based on personal aversion.
To clarify, since my views are being misrepresented:
No, I do not advocate moving the unit outside the spinboxes. What I have I said is that of the three common and valid styles, that one happens to be my usual preference. But I would not advocate spending effort changing from one valid style to another valid style just on account of my own personal preference. If it ain't broke, don't fix it.
As for why I have argued my point here, it is not personal aversion, at least not aversion to you. Perhaps, aversion to wasting time on unnecessary changes when there is so much important real work to be done.
But FWIW, based on my current understanding, and checking the Qt documentation, I would say that *if* one were to want to change this to the style being requested in this issue - adding the optional space as used in Scribus and a few other programs - the correct way to do so would be to add the space to the string "sp". I base this on the example given for setSuffix() here:
which shows an explicit leading space in the string being passed in. Which is to say, it appears they the Qt folks are perfectly aware some people might want a space, and that they expect that users who desire that behavior will encode the space into the string. Presumably this would need to happen each and every place it appears in the GUI / code, and would need to propagated into each and every translation, but I haven't looked that far to see if there is perhaps a simpler way.
Again, I am not advocating anything here - I still don't think it's broken. But if someone who were sufficiently obsessed about this were to want to volunteer to spend some time on it, that is how I'd recommend their doing so.
BTW, despite the fact that I personally prefer the units outside the spinbox in general, I believe I also pointed out that some of these dialog boxes might get too cluttered if we actually did that. Also, moving the suffixes outside the suffix would be a more invasive change than simply adding a space. So *if* we were to change - which again I see no reason for - I would agree that adding a space would be preferable in this instance to moving the units outside the spinboxes.
Marc: "No, I do not advocate moving the unit outside the spinboxes."
OK.
Marc: "What I have I said is that of the three common and valid styles, [...]"
I see no validity in a style that goes against a common writing recommendation.
Marc: "But I would not advocate spending effort changing from one valid style to another valid style just on account of my own personal preference. If it ain't broke, don't fix it."
I agree, but your starting point is flawed as I pointed out above.
Marc: "As for why I have argued my point here, it is not personal aversion, at least not aversion to you."
OK, thanks; nice to see.
Marc: "Perhaps, aversion to wasting time on unnecessary changes when there is so much important real work to be done."
As I have pointed out, it is not unnecessary.
Marc: "[...] adding the optional space as used in Scribus and a few other programs - the correct way to do so would be to add the space to the string "sp"."
That would go against the OpenOffice.org User Interface Text Style Guide, but I would think it is a very simple and possible way of doing it.
Marc: "Presumably this would need to happen each and every place it appears in the GUI / code, [...]"
No, not necessarily. I shall try to register all the occurences in the GUI of MuseScore version 1.3 and see where it is needed. I will get back with the results. However, I still miss the answer to my question about from where the usage of "sp" for an abbreviation of "space" comes from. Both Sibelius and Igor Engraver do not abbreviate "space".
Marc: "But if someone who were sufficiently obsessed about this were to want to volunteer to spend some time on it, that is how I'd recommend their doing so."
There is no need to use pejorative expressions like "sufficiently obsessed" since a correct writing style is a basic demand on a GUI.
Marc: "BTW, despite the fact that I personally prefer the units outside the spinbox in general, I believe I also pointed out that some of these dialog boxes might get too cluttered if we actually did that."
Do you have an example? In the dialog I first noticed this fault there is enough space for the units outside the spinboxes. However, I would perhaps instead recommend the usage of a remark at the top or bottom of a dialog window that says e.g. "All values signify spaces". Igor Engraver uses this method in several dialog windows; see attachment.
Marc: "So *if* we were to change - which again I see no reason for - [...]"
In the Swedish version of MuseScore 1.3 dialog window "MuseScore: Bearbeta stil" the following panes need a space before "mellanrum": Partitur, Sida, Ackolad, Takt, Noter, Arpeggion and Artikulationsbeteckningar/Ornament. In the pane Balkar the unit "mellanrum" is placed outside the spinbox (and two spinboxes lack units), and in Dynamikklykor the units are missing.
In R.d760826 there are missing spaces before units in every pane of MuseScore: Bearbeta stil, except in Header/Footer/Numbers and Clefs. In Balkar there is a missing unit for the second spinbox; in Hairpins for spinboxes 2-4; in Tuplets for the first one.
> every pane of MuseScore: Bearbeta stil
I guess (Swedish is relatively similar to German here) you mean Menu->Style->General...
>In Balkar
Menu->Style->General...->Beams
The missing unit is mentioned before the spinnbox: "(in beam thinkness units)" and so refers to the setting just above it, it is a factor (beam distance: 0.5 times the thinkness of a beam), so I guess no unit needed? Maybe better a % value (and suffix)?
>in Hairpins
Menu->Style->General...->Hairpins, Volta, Ottava
>in Tuplets
Menu->Style->General...->Tuplets
True, indeed no unit there. Guess these should be "sp" (or " mellanrum")?
Sorry, but you'd need to tell mere mortal (and non-Swedish) people how to get the dialog you complain about, using a) the path to it and b) the (US) English names is called for in this case...
It was only the similarity between the Swedish "Bearbeta stil" and the German "Stil bearbeiten" that led me to it, many others wouldn't have had the slightest chance.
It should be "sp", for consistency, it is not "spaces" anywhere else.
And of course without a leading space ;-)
Jojo:"It was only the similarity between the Swedish "Bearbeta stil" and the German "Stil bearbeiten" that led me to it, many others wouldn't have had the slightest chance."
No, I doubt there are many others who did not know what I was referring to with respect to the very long and much read discussion earlier.
Jojo:"It should be "sp", for consistency, it is not "spaces" anywhere else. And of course without a leading space ;-)"
Ha, ha, ha! Consistency is only good when the starting point and example are. But you have obviously made it your mission not to follow the general writing recommendation in this case. Sometimes I wonder how old you are.
52, why? I only added 4 times "sp" rather than changing many many "sp" to " sp"...
IHMO 100% consistency is more important that 100% correctness. And it is the lazy way out too.
And it is you wanting a certain bug fixed, so it is your task and best interest to make it as easy as you possibly can to find where exactly the bug is you're seeing. It's not the task of anyone else to have to guess what you might have meant.
Comments
Discussion in http://musescore.org/node/23621
This is minor, because there is nothing below minor. As stated in the previous discussion, it's not a bug but a feature according to me. Unit are more readable without the space in spinboxes. Moreover, several other major open source software adopt the same behavior than MuseScore.
The concensus in the discussion also favor the current behavior. I will let this bug open for a couple of weeks but close it if the consensus doesn't change.
Nicolas: "This is minor, because there is nothing below minor."
Ha, ha, ha! What arrogance!
Nicolas: "Unit are more readable without the space in spinboxes."
No, that's not true. It is just sloppy program writing, that is the reason it's there.
Nicolas: "Moreover, several other major open source software adopt the same behavior than MuseScore."
Not e.g. Scribus, one of the most graphically aware and knowledgeable programs.
Nicolas: "The concensus in the discussion also favor the current behavior."
No, not at all. Marc advocates to provide space and a more legible version by having the unit outside the spinboxes, and Jojo is not against the space between numbers and unit. Their arguing with me is mostly based on personal aversion.
To clarify, since my views are being misrepresented:
No, I do not advocate moving the unit outside the spinboxes. What I have I said is that of the three common and valid styles, that one happens to be my usual preference. But I would not advocate spending effort changing from one valid style to another valid style just on account of my own personal preference. If it ain't broke, don't fix it.
As for why I have argued my point here, it is not personal aversion, at least not aversion to you. Perhaps, aversion to wasting time on unnecessary changes when there is so much important real work to be done.
But FWIW, based on my current understanding, and checking the Qt documentation, I would say that *if* one were to want to change this to the style being requested in this issue - adding the optional space as used in Scribus and a few other programs - the correct way to do so would be to add the space to the string "sp". I base this on the example given for setSuffix() here:
http://qt-project.org/doc/qt-5.0/qtwidgets/qspinbox.html#suffix-prop
which shows an explicit leading space in the string being passed in. Which is to say, it appears they the Qt folks are perfectly aware some people might want a space, and that they expect that users who desire that behavior will encode the space into the string. Presumably this would need to happen each and every place it appears in the GUI / code, and would need to propagated into each and every translation, but I haven't looked that far to see if there is perhaps a simpler way.
Again, I am not advocating anything here - I still don't think it's broken. But if someone who were sufficiently obsessed about this were to want to volunteer to spend some time on it, that is how I'd recommend their doing so.
BTW, despite the fact that I personally prefer the units outside the spinbox in general, I believe I also pointed out that some of these dialog boxes might get too cluttered if we actually did that. Also, moving the suffixes outside the suffix would be a more invasive change than simply adding a space. So *if* we were to change - which again I see no reason for - I would agree that adding a space would be preferable in this instance to moving the units outside the spinboxes.
same for me, I second Marc's and lasconic's view...
Marc: "No, I do not advocate moving the unit outside the spinboxes."
OK.
Marc: "What I have I said is that of the three common and valid styles, [...]"
I see no validity in a style that goes against a common writing recommendation.
Marc: "But I would not advocate spending effort changing from one valid style to another valid style just on account of my own personal preference. If it ain't broke, don't fix it."
I agree, but your starting point is flawed as I pointed out above.
Marc: "As for why I have argued my point here, it is not personal aversion, at least not aversion to you."
OK, thanks; nice to see.
Marc: "Perhaps, aversion to wasting time on unnecessary changes when there is so much important real work to be done."
As I have pointed out, it is not unnecessary.
Marc: "[...] adding the optional space as used in Scribus and a few other programs - the correct way to do so would be to add the space to the string "sp"."
That would go against the OpenOffice.org User Interface Text Style Guide, but I would think it is a very simple and possible way of doing it.
Marc: "Presumably this would need to happen each and every place it appears in the GUI / code, [...]"
No, not necessarily. I shall try to register all the occurences in the GUI of MuseScore version 1.3 and see where it is needed. I will get back with the results. However, I still miss the answer to my question about from where the usage of "sp" for an abbreviation of "space" comes from. Both Sibelius and Igor Engraver do not abbreviate "space".
Marc: "But if someone who were sufficiently obsessed about this were to want to volunteer to spend some time on it, that is how I'd recommend their doing so."
There is no need to use pejorative expressions like "sufficiently obsessed" since a correct writing style is a basic demand on a GUI.
Marc: "BTW, despite the fact that I personally prefer the units outside the spinbox in general, I believe I also pointed out that some of these dialog boxes might get too cluttered if we actually did that."
Do you have an example? In the dialog I first noticed this fault there is enough space for the units outside the spinboxes. However, I would perhaps instead recommend the usage of a remark at the top or bottom of a dialog window that says e.g. "All values signify spaces". Igor Engraver uses this method in several dialog windows; see attachment.
Marc: "So *if* we were to change - which again I see no reason for - [...]"
The reason is a correct writing style.
In the Swedish version of MuseScore 1.3 dialog window "MuseScore: Bearbeta stil" the following panes need a space before "mellanrum": Partitur, Sida, Ackolad, Takt, Noter, Arpeggion and Artikulationsbeteckningar/Ornament. In the pane Balkar the unit "mellanrum" is placed outside the spinbox (and two spinboxes lack units), and in Dynamikklykor the units are missing.
No more bug fixes or translations for 1.3.
So if you're reporting problems, please base them on a recent nightly build.
For 2.0 feel free to add those spaces to your Swedish translation.
In R.d760826 there are missing spaces before units in every pane of MuseScore: Bearbeta stil, except in Header/Footer/Numbers and Clefs. In Balkar there is a missing unit for the second spinbox; in Hairpins for spinboxes 2-4; in Tuplets for the first one.
> every pane of MuseScore: Bearbeta stil
I guess (Swedish is relatively similar to German here) you mean Menu->Style->General...
>In Balkar
Menu->Style->General...->Beams
The missing unit is mentioned before the spinnbox: "(in beam thinkness units)" and so refers to the setting just above it, it is a factor (beam distance: 0.5 times the thinkness of a beam), so I guess no unit needed? Maybe better a % value (and suffix)?
>in Hairpins
Menu->Style->General...->Hairpins, Volta, Ottava
>in Tuplets
Menu->Style->General...->Tuplets
True, indeed no unit there. Guess these should be "sp" (or " mellanrum")?
No, if I write MuseScore: Bearbeta stil, I mean exactly that, but one gets to it via Style -> General.
It would be more consistent in style if the unit "beam thickness" is placed after the number.
Jojo: "Guess these should be "sp" (or " mellanrum")?"
Preferably "spaces" instead of "sp". Pay attention to not omitting the space between number and unit.
Sorry, but you'd need to tell mere mortal (and non-Swedish) people how to get the dialog you complain about, using a) the path to it and b) the (US) English names is called for in this case...
It was only the similarity between the Swedish "Bearbeta stil" and the German "Stil bearbeiten" that led me to it, many others wouldn't have had the slightest chance.
It should be "sp", for consistency, it is not "spaces" anywhere else.
And of course without a leading space ;-)
Added those to my PR #772
Jojo:"It was only the similarity between the Swedish "Bearbeta stil" and the German "Stil bearbeiten" that led me to it, many others wouldn't have had the slightest chance."
No, I doubt there are many others who did not know what I was referring to with respect to the very long and much read discussion earlier.
Jojo:"It should be "sp", for consistency, it is not "spaces" anywhere else. And of course without a leading space ;-)"
Ha, ha, ha! Consistency is only good when the starting point and example are. But you have obviously made it your mission not to follow the general writing recommendation in this case. Sometimes I wonder how old you are.
52, why? I only added 4 times "sp" rather than changing many many "sp" to " sp"...
IHMO 100% consistency is more important that 100% correctness. And it is the lazy way out too.
And it is you wanting a certain bug fixed, so it is your task and best interest to make it as easy as you possibly can to find where exactly the bug is you're seeing. It's not the task of anyone else to have to guess what you might have meant.
Jojo:"52, why?"
My, oh my.
Jojo:"It's not the task of anyone else to have to guess what you might have meant."
As I said earlier, it didn't take any guessing.
Jojo: "IHMO 100% consistency is more important that 100% correctness. And it is the lazy way out too."
Incredible. You really shouldn't be anywhere near a software project. How can Werner let you be around?
Yeah, I made a bad mistake discussing with you. Won't happen again, promised.
Jojo:"Yeah, I made a bad mistake discussing with you."
From your perspective that you exposed your foolishness, that is true, but I do think it will turn out to be good for MuseScore that it happened.
Jojo: "Won't happen again, promised."
Let's see if you can keep your promise.
https://github.com/musescore/MuseScore/pull/4672