On 20 Jun 2004 at 22:04, Christopher BJ Smith wrote: > At 7:40 PM -0400 6/20/04, David W. Fenton wrote: > >On 20 Jun 2004 at 17:36, Christopher BJ Smith wrote: > > > >> At 5:02 PM -0400 6/20/04, David W. Fenton wrote: > >> > > >> >No, I didn't try using a clip file, because I have absolutely no > >> >comprehension of why the hell there are three different methods > >> >for copying data. > >> > >> Two. . . . > > > >No, three. Ctrl-C/Ctrl-V is different from SHIFT-CLICK copying, and > >then there's Clip Files. That's three. > > Well, clip files accomplish the same thing between files that > drag-and-drop does INSIDE the same file (except for clefs, > apparently, which ARE copied in clip files, but not by default by > drag-n-drop) which makes really two DIFFERENT methods. Drag some > measures around, and between files, to see what method does what. You > know, check out under the hood, kick the tires, etc.
If it's the same thing why is it called something different? Why does it have a different method? > >What is the purpose of clip files? > > See above. I still don't get why it's necessary. There is not a single other application that I've ever used that had more than one copy mode. [] > >Finale should be able to know if where it's copying from and where to > >and then be intelligent about what it copies. It should copy all clef > >changes if the source and target clefs for the systems are the same, > >don't you think? > > Hmm, not me. I often drag cello parts to double bass staves, then > transpose 8vb with a key stroke. Or trombone parts to saxophone > staves. . . . All right, same clef and transposition. The point is, Finale should have sufficient information to know that the exact same notation is going to be correct with the same clef changes, and it should copy them. The only except I could think of would be, say, copying a viola da gamba part, with bass and alto clefs, to a cello part, where you want bass and tenor clefs. But that's a very rare situation. And, of course, knowing this, I could easily turn off the copying of clefs. > . . . I would hate for the target staff to inherit clef changes in > this case. If I ever need it, I know where to find it. One of the > things I really liked about Finale when I started using it is that I > could drag things to other staves and have them assume the defaults > of the target staff. That was very easy for me to grasp. If the defaults are the same, why shouldn't all information be copied? > I agreed with you for most of what you complained about when you had > issues with the lyric tool, but in this case, I guess I know things > too well to want them to change. I wonder if that is related to the > way you took to MS Word more easily than I do, and we're vice-versa on > Finale? I just think that having exceptions to copying is a bad idea. For instance, in Windows Explorer, drag and drop works one way when copying between folders within the same drive and another when dragging between drives (the first is a move, the second a copy), and if what you are dragging is an application file rather than a data file (for apps it creates shortcuts, for all other data, it behaves as just described). The vast majority of users simply can't understand this distinction because there is no real clarity to the way it is represented in the user interface. I get around it by always right dragging, because that always pops up a confirmation menu to ask you what you want to do. To me, Finale's copying is just as wrong-headed a design -- there are too many details to learn. That said, for copying from staff to staff within a file, I don't find it difficult (though I wish it copied clef changes between staves defined with the same clef and transposition), but for any other kind of copying, it seems the defaults are badly designed, and I still haven't figured out how to actually manage to copy everything. > > > > . . I remember early on this was an issue, and they > >> changed the default to go along with what most people were using > >> this for. Shift-clicking to copy large sections and then alt-shift > >> click to accomplish the same thing is just an easier way to > >> accomplish drag-and-drop on large sections. > >> > >> Clip files do pretty much the same thing, but between files, > >> because the system's clipboard won't copy things that drag and > >> drop will copy. That's all. > > > >What are you talking about the "system's" clipboard for? It's not > >involved -- it's Finale's use of the clipboard. I have no other > >applications that don't do just fine with copying all of their own > >metadata, even between separate instances of the same application > >(let alone between different documnets within a single instance of > >the application). > > > >If you're blaning the underlying OS's for the problem, then I think > >you're letting Coda off too lightly. Just as with EPS, other > >applications manage it, so Finale could, too. > > Well, I asked Coda about it about a hundred years ago, and that was > what they said. I don't know enough about it to support the argument, > though. You can't blame such things on the underlying OS. Every application I've ever used understands the data on its own clipboard. If Finale can't, then it's a deficiency in Finale's programming. > >Except I tried that, and it still didn't copy the clef changes. > >Actually, it copied mid-measure clef changes, but not the ones that > >happened on the bar line. Is there any justification for *that*? > > Hmm, I just tried it, too, and got the same results, and no, not that > I can see. I would write to Coda about that, for sure, as you have a > good point. This is inconsistent. Why, indeed, copy mid-measure clef > changes and not start-of-bar changes? Not good. Well, for me, the problem is in the whole concept of having completely different behaviors for different modes of copying. To me, all copying is the same. That it is different behind the scenes is irrelevant to me, the user -- I should not need to understand that there's a difference in order to use the program. This is what Joel Sposky calls a "leaky abstraction," where the underling complexities of implementation bleed through into the UI: http://www.joelonsoftware.com/articles/LeakyAbstractions.html (Joel is a wonderful writer, and I think that, even though he's mostly writing for programmers, even non-programmers can learn a lot about why computers are frustrating from reading his articles) -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
