Is there a way left to move the cursor to the top of the window? Pageup used to do this, and while I understand that it's not HIG or like other apps do it, I was just getting used to it :-)
Regards,
Martin
On Dec 3, 2004, at 14:33, M Spreij wrote:
Is there a way left to move the cursor to the top of the window? Pageup used to do this, and while I understand that it's not HIG or like other apps do it
I haven't found any mention of this in AHIG myself -- I'm quite sure that the reason Apple's native text fields does it is laziness. They center the caret in the display each time it gets out of the visible region, so (move) page up/down simply moves the caret “visible lines” up/down.
Another place where this is IMHO a bigger disadvantage is how when the caret just goes a single line outside the visible text, the buffer scrolls half a page. Luckily no-one has complained that TM also break this behavior ;)
Regarding reinstating the old behavior, you can change the action methods for the page up/down keys to movePageUp: and movePageDown:.
So there's basically 3 behaviors: movePageUp/Down: -- old behavior scrollPageUp/Down: -- move only scroll bar, not caret pageUp/Down: -- move caret a full page and center it
Apple HI behavior regarding this point is very deliberate (not lazy) and is clearly defined. Having used and written software for Macs since 1990 I can assure you of this.
Pressing page-up scrolls up one window-full without moving the insertion point. Similarly for page-down. Home scrolls to the very top, without moving the insertion point. Similarly for End. (In 1.0.2b8 Home and End behave wrong.)
The relevant documentation (which also lists many other standard keyboard navigation shortcuts to do the other things you want to do) is here:
http://developer.apple.com/documentation/UserExperience/Conceptual/ OSXHIGuidelines/XHIGUserInput/chapter_2_section_3.html#//apple_ref/doc/ uid/TP30000361/TPXREF61
On 4. Dez 2004, at 01:50, Allan Odgaard wrote:
On Dec 3, 2004, at 14:33, M Spreij wrote:
Is there a way left to move the cursor to the top of the window? Pageup used to do this, and while I understand that it's not HIG or like other apps do it
I haven't found any mention of this in AHIG myself -- I'm quite sure that the reason Apple's native text fields does it is laziness. They center the caret in the display each time it gets out of the visible region, so (move) page up/down simply moves the caret “visible lines” up/down.
Another place where this is IMHO a bigger disadvantage is how when the caret just goes a single line outside the visible text, the buffer scrolls half a page. Luckily no-one has complained that TM also break this behavior ;)
Regarding reinstating the old behavior, you can change the action methods for the page up/down keys to movePageUp: and movePageDown:.
So there's basically 3 behaviors: movePageUp/Down: -- old behavior scrollPageUp/Down: -- move only scroll bar, not caret pageUp/Down: -- move caret a full page and center it
On Dec 4, 2004, at 19:20, Ryan Schmidt wrote:
Apple HI behavior regarding this point is very deliberate [...] Pressing page-up scrolls up one window-full without moving the insertion point. Similarly for page-down.
Sorry, I was actually talking about option-page up/down.
This does move the insertion point, and it was the behavior for this I didn't see defined.
Home scrolls to the very top, without moving the insertion point. Similarly for End. (In 1.0.2b8 Home and End behave wrong.)
Yes, this is because I change it in the default key bindings, as I previosuly did with page up/down also.
I did this because _every_ Mac user I (personally) know thinks the default (with scrolling) is not only useless, but also frustrating.
But all Mac users I know (incl. myself) didn't start using Mac before OS X, and apparently many existing Mac users did like the “scroll only”, so I removed the default page up/down key bindings. But since I never heard anything for home/end, I kept these.
I have considered removing them though (I have my own key bindings anyway ;) ).
The relevant documentation (which also lists many other standard keyboard navigation shortcuts to do the other things you want to do) is here:
Thanks
Sorry, I missed that you were talking about Option-Page Up/Down. I see that TextEdit uses Option-Page Up/Down the same as TextMate so you're in good company there.
But regarding some other TM choices, I must say that I've always been confused by applications that stray from the accepted user interface standards. Standards are what make a system easy to use. Users who have learned one application should be able to apply that knowledge to new applications they use. If your application does not follow conventions, users who are used to the established standards will find your application confusing.
Surely, if you find the default behavior to be wrong, then you believe that to be the case in every application you use. If you want page-up to work like it does on Windows, where it moves the insertion point, or if you'd rather that it make you a cup of tea, then you probably want that behavior in Mail.app and TextEdit and AppleWorks too, and not just in TextMate. Wouldn't the correct solution then be to write (the OS X-equivalent of) a system extension to modify the default behavior? That way this extension can be used by others sharing your view, and these users are then also able to enjoy a consistent user experience across all applications.
If you don't like the QWERTY keyboard, you don't hardcode a different keymap into your application. You code to the OS standards, then use System Preferences to select a different keyboard layout. If you don't like the Aqua user interface elements, you shouldn't create custom controls just for your application. You should use the custom controls, and then use ShapeShifter to select a different system-wide theme.
I'm very happy that OS X brings many new developers and users to the platform and welcome their contributions. But coming to the Mac platform means doing it the Mac way. I've used Mac OS X since before it was released, and I still haven't found a native mail client I can stand. Thunderbird, for example, is absolutely remarkable. I would be hard pressed to find another application that disregards more Mac HI guidelines. And that's my impression after trying to use it for only about half an hour. That kind of stuff won't fly. I have enough trouble trying to get Apple to make their OS X apps conform to established interface conventions (Mail.app, I'm lookin' at you).
On 4. Dez 2004, at 20:38, Allan Odgaard wrote:
On Dec 4, 2004, at 19:20, Ryan Schmidt wrote:
Apple HI behavior regarding this point is very deliberate [...] Pressing page-up scrolls up one window-full without moving the insertion point. Similarly for page-down.
Sorry, I was actually talking about option-page up/down.
This does move the insertion point, and it was the behavior for this I didn't see defined.
Home scrolls to the very top, without moving the insertion point. Similarly for End. (In 1.0.2b8 Home and End behave wrong.)
Yes, this is because I change it in the default key bindings, as I previosuly did with page up/down also.
I did this because _every_ Mac user I (personally) know thinks the default (with scrolling) is not only useless, but also frustrating.
But all Mac users I know (incl. myself) didn't start using Mac before OS X, and apparently many existing Mac users did like the “scroll only”, so I removed the default page up/down key bindings. But since I never heard anything for home/end, I kept these.
I have considered removing them though (I have my own key bindings anyway ;) ).
On Dec 4, 2004, at 22:30, Ryan Schmidt wrote:
But regarding some other TM choices, I must say that I've always been confused by applications that stray from the accepted user interface standards [...] coming to the Mac platform means doing it the Mac way.
I don't really know what you refer to, and I never signed a contract with Apple or anyone else forcing me to do it the Mac way, even though I try to do so where it makes sense (remember, AHIG are guidelines, not rules or standards).
But if you have concrete concerns about something in TM let me know, I'm open to feedback, and some AHIG negligence may simple be because I'm unaware of it (or have given it low priority because it requires resources better spent on something else) -- although much of the concrete behavior-related critic I've seen have actually been because I use the *standard* Cocoa behavior (which apparently is rather alien to some Mac users).