On 8 Jul 2005 at 1:04, Johannes Gebauer wrote: > David W. Fenton schrieb: > > > I honestly see nothing about any of these suggestions that belongs > > with what I conceive of as the concept of "house styles." > > I don't for a minute doubt that, but believe me, I thought this > through some time ago, and it is pretty much all that is needed. The > reason I suggest it this way is the fact that it requires very little > for a big improvement, and with very little extra functionality or > data structures in the main Finale application and file format.
I didn't mean to discount your suggestions -- all of them have merit. I just don't see the relationship to "house styles." > > I guess my point is that the kind of restructuring I'm calling for > > here would go much further to making it possible to manage "house > > styles" than any of the things you mentioned. > > Except it won't happen. I'm not certain about that. The Finale developers are computer programmers. They understand better than *you* do the advantages of non-duplication of data, of sub-classing, of object-oriented programming. My bet is that they'd love to have the luxury to be turned loose on Finale and rework its data structures in order to support the kinds of UI and feature requests I've been talking about. But the realities of business don't allow them to pull a Netscape (and, of course, they shouldn't do that, anyway: Things You Should Never Do http://joelonsoftware.com/articles/fog0000000069.html where "you" means software developers. Don't be daunted by that -- Joel Spolsky is a superb writer, and the article is amusing even to non-programmers) And I think that implementing dyanmic parts will *require it*. So, I see it as a first step towards a new Finale that works the way a modern database program ought to work. -- 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
