On 23 Sep 2002 at 0:45, Mark D. Lew wrote: > At 8:14 PM 09/22/02, David W. Fenton wrote: > > >PageDown and PageUp have moved the cursor since long before there was > >such a thing as a graphical user interface. Perhaps it's the Apple > >mouse religion that leaves the Mac with such an illogical decoupling > >of cursor movement keys from the cursor, wherein the original Macs > >had no cursor movement keys (or was it only the arrow keys?). > > Yeah, I remember the old computers with plain-character graphics where > page-down and page-up were essentially macros for 24 consecutive up or down > arrow keys. (I also remember when control-G caused the computer to make a > beep sound...) In some programs you couldn't scroll up at all; you could > only go down, and if you missed something you had to start over from the > top. > > I thought that everything was changed when character graphics were > abandoned and replaced by the whole paradigm of windows showing a selected > view from a larger total picture. At that point, the new conceptual > association was that "page-up" and "page-down" moved the underlying picture > up or down while the window stayed in place.
But, according to reports posted here, to move the *cursor* one page up or down, you have to use a shifted key. I don't see the point of using PageUp or PageDown for scrolling, when scrolling is by definition a graphical operation (i.e., appropriate for the mouse) as opposed to a cursor movement operation. > Presumably when Windows made the paradigm switch, they preserved the > original concept a little more completely than Mac did. That doesn't > surprise me. What surprises me is that Apple would include keys on the keyboard and then completely redefine their behavior in comparison to every other OS I'm aware of. Please, someone prove me wrong by providing examples of platforms other than the Mac in which PageUp and PageDown are indistinguishable in behavior from using the scrollbar. > >Sorry, but if the Mac does it this way, the Mac is simply wrong. > > There you go again. > > Don't get me wrong. I'm not stuck on the Mac way, and to be honest, in this > case I can see that the Windows way is more useful. But to say that Mac is > therefore categorically wrong is ... well, it's exactly what I would expect > from you, David. It *is* wrong -- it sacrifices a pair of useful keys for the dogma of the mouse. I *is* wrong because it makes Mac users and island of idiosyncratic UI behavior, with no actual benefit to that idiosyncracy. > >In any event, for Coda to have it implemented that way in this day > >and age shows that nobody has bothered to even look at it in over ten > >years, i.e., back in the days when Finale on Windows was still a > >clear port of a Mac program, with lots of non-native behaviors. > >Either that or they are not managing the differences between their > >two codebases very well. > > If this particular feature employs, on the Windows version, Mac behavior > which is non-standard on Windows, then I agree that that is shoddy design. > > It also gives a hint at why the Edit Lyrics window is so crappy over all. > Could it be that it is designed completely from scratch? Surely in either > operating system there exists some sort of generic edit-text window which > the program can employ wholesale and plug into the program, just like they > do with open-file dialogs, drop-down lists, and so forth. Isn't that how > programming is supposed to work in the modern world? I don't quite understand why the edit lyrics window does not show the same characteristics as the other text edit windows, which were successfully revamped back around Finale 3.5 (or was it 3.0?). -- David W. Fenton | http://www.bway.net/~dfenton David Fenton Associates | http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
