Bar line palette drops only affect some bar line properties

• Jun 17, 2014 - 10:29
S4 - Minor

Git commit: 17a2ce0

- Create a new score with some bars in it.
- Pull a "tick"-style barline from the palette on a measure
-- at this point the barline style correctly changes
- pull a full barline from the palette on the bar with the "tick" - the length of the barline doesn't change.

This behavior is quite confusing. As I understand the "tick" etc. only changes the length of barline, but not the actual type so when you want to revert back to full height barline, you have to edit and change.
The barlines in the palette should actually put the same barline what is shown in the palette. If you need some extra (a short dotted), you should use the inspector...


I spent some hours understanding the barline span code. It seems somewhat overengineered and still not clearly elaborated.
I think 25251 is not related to this.
There are some fancy conditions about when how to interpret a palette barline as type/subtype/span override etc. which is very unclear from a user's point of view.
My intention is to make this superclear:
- you get what you pull from the palette
- if you want some very rare stuff (tick-size double bar line) you should do that manually
And there are some other glitches to fix:
- if you drag a tick from the barline palette, it is not saved
- the Spantype selector is not effective from the inspector

Title Barline type cannot be reverted Bar line palette drops only affect some bar line properties
Status (old) active by design

As far as I see it, a bar line can have up to four properties:

1) span: from which line of which staff to which line of which (other) staff it runs; the two flavours of 'tick' and of 'short' fall in this category; span also includes the Mensurstrich case, which requires a rather peculiar management;
2) line style: continuous, dashed, dotted;
3) bar style: single, double (thin-thin), end (thin-thick);
4) function: none, start repeat, end repeat, end-start repeat.

Additionally, it makes quite a difference if a bar line property is dropped on a individual bar or on a measure:

A) if dropped on an individual bar, the code assumes that individual bar line has to be customized from the default situation.

B) if dropped on the whole measure, the code assumes that:
B1) for spans, the user wants to modify the bar lines of the whole staff: the most common situation is to have bar lining span consistent over the whole staff or staves => generalize in horizontal sense;
B2) for line/bar styles, the user wants to modify the bar lines of the whole measure: the most common case is to have double or end bar lines consistent across all the parts of a measure => generalize in vertical sense.

(Aside: The last property, function, is the only structural one and it should not be possible to assign a function to a single bar line of a measure, as it would make no sense that a part repeats while the other go on or vice versa).

@Bertalan Fodor:

You may think this to be over-engineered; I would say it is flexible. Also, the current situation -- with a single exception, not related with this issue -- is working correctly (and I would say predictably) for the great majority of users, who just need 'common' bar lines and do not care about peculiar bar line spans or styles.

If you need the 'tick' bar line, you are probably in the niche of users with specialized needs, as I feel I am myself by quite often needing the Mensurstrich bar lining. We could go on indefinitely arguing which approach is better, without reaching an agreement: your approach (a palette drop should affect all the bar line properties) may well be more suited to your specialized needs, my approach (a palette drop should affect only the property it conveys) to my specialized needs and still another approach to someone else's specialized needs. If by chance we could arrive at some agreement, it would concern only a rather tiny minority of MuseScore users, so I tend to rate the primary issue you describe as rather minor.

In summary, as far as this issue is concerned, I can only say that, so far, it is "by design".

Does the above means that everything is perfect? Far from it! There are still things which do not work and/or could be improved:

*) Undoing a bar line property change is unpredictable (this is the exception I was referring to above) and is covered by #25251: Unable to create barline after undo.
*) The Inspector part related to bar lines is mostly unreliable.
*) The bar line palette could probably be re-organized.
*) Labels for bar lines palette items could be improved.

and probably many other as well. Creating specific issues in the tracker covering the individual details as they are noticed would help: step by step, I hope we will fix them.



One more thought. I think you are not right with your four aspects of barlines, only from a developer's point of view, and I think this is the thing that complicates a lot. There is normally no such a thing as a dashed double barline with repeat in tick size... if I understand well you would make those first class citizens... while there are only a few, like seven, which are really first class - they should be selectable from the palette, just as in Sibelius 7

Status (old) by design active

Could I propose to make this bug active? You set this to "by design" - but the design is confusing.
I suggest one very simple (from a user's point of view!) change at least: get what you take.
So when you take a full barline from the palette, draw a full barline! Because when you take a tick, a tick is drawn, you take a short barline, a short barline is drawn. That simple.
An other, not so important part: if you take a tick from the palette and then the bar (and only that bar) you dropped the tick on changes, then changing that tick's span should not change all the other barlines. (Ok, I know you can use Shift + Ctrl, that's not intuitive at all besides hard to press :).)

----- Random rambling below -----
This is one part. The other is that I think due to the overcomplicated nature of the behavior and thus the code, even the bugs you mentioned and the ones I found are quite hard to fix in a robust way. So I'm a bit concerned that if the behavior remains the same with this superflexibility even the simplest case will not work reliably. (Ok, you might not believe me as I'm not a serious MuseScore contributor, but well, I have seen and written lot of code, and I could tell stories about npath and cyclomatic complexity, the relation between code quality, maintainability and code length, variable naming etc.)

Otherwise I want to emphasize, that your contribution to MuseScore is really great, and I'm very keen on using the result of your work even in its current way, I just want to make some humble points to make the stuff even greater :)