>> Originally I called it "Select beats", but then I realized that that was
>> misleading since they're not actually beats yet.
>
> "Guess beats" maybe?
OK, "Guess beats" it is.
>> I agree that "unadopt" is not so obvious. My head was still in the code
>> when I wrote that string.
>
> Plus it's not a word in English and sure isn't easy to translate. It's
> just some internal tech speak gibberish.
Internal tech speak gibberish is my native language. Ah well.
>> That menu item is only available when the cursor is in an adopted
>> segment,
>> so it could be just "Hide Segment". Would that make more sense?
>
> I kind of like leaving it tech speak gibberish in a way. On some level,
> it strikes me as more honest since this is an extremely obscure, highly
> advanced feature.
It just hides a fake segment. If the user is in a position to use it,
he's already done the obscure, highly advanced stuff. Now he's just
hiding something he's looking at.
I'll leave it up to you.
FWIW, I don't think it's quite that freaky to see an ornament written out.
>> That's the menu item of a variant NotationSelector that doesn't follow
>> ties. Ie, if you lasso a note N1 and it's tied to another note N2, only
>> N1 gets selected.
>
> Why do you want a variant of NotationSelector that doesn't follow ties?
When it's useful, it's very convenient. One thing it's nice for is
changing the duration of a tie by operating on the last note of it. If
you change the duration of every tied note in it, you break the tie. With
this you can just grab the last note. The original impetus was for
operating on ornaments that were long ties. After untying and retying too
many long ties, I felt a need for it.
> I made the thing follow ties because breaking ties leads to broken
> things and headaches and general vileness. Treating tied notes like
> single units was a big improvement, because they ARE effectively single
> units.
>
> I just hope whatever context in which you feel you need this is smart
> enough to remove all the mismatched tied_forward/backward properties
> from severed things that are no longer connected. The inappropriate
> properties are what screw things up.
It just selects them. It doesn't do anything to them itself. Any command
that operates on selection has always gotten whatever it gets as separate
events, regardless what is tied.
That's always been the case, so I don't think that changes how anything
works. That's not to say that no commands mess up tie properties, just
that I don't believe this creates new problems on that front.
I did worry that some tools might assume selection contains all events in
a tie - like they leave a dangling problem when they see tied note N1 that
they fix when they see N2. I didn't see anything where that appeared to
be the case and it seems unlikely.
FWIW, after what you said I took a look at SetNoteTypeCommand and
AddDotCommand. Regardless what selection tool is used, they seem to think
every note is untied, just plopping new events directly into Segment.
This may be the source of some of your headaches. I might as well add a
fix for that now.
Tom Breton (Tehom)
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
