back/forward shortcuts?

Possible to add command-[ and command-[ as keyboard shortcuts for WebLink content page navigation? Those are "canonical" bindings in Safari (and now OmniWeb 5), avoiding possible conflict with command-left/right-arrow for start/end-of-line navigation during text input.

This will be probably part of v1.8.2 (to navigate both web pages and wiki/cross-link).

Cool.  Can home/end shortcuts also be added for scrolling item lists/icons?  Currently the home key behaves unpredictably; the end key does nothing.  Page-up/down seem to work fine everywhere I’ve tried them.  Thanks.

Version 1.8.1 supports Home/End keys. And you can use backspace or shift-backspace to go back/forward in HTML views (just like in Safari).

Home/End are great.  I’ve never used (shift-)backspace; there’s no backspace key on my iBook keyboard. :slight_smile:
Command-[ and command -] would still be useful.  And command-+ and command-- for Zoom In/Out, like Make Text Bigger/Smaller in Safari.  Thanks!

iBooks have this key too - maybe I’ve used the wrong name. Don’t know if it’s called backspace or delete :wink:

Delete it is. :slight_smile:

In browser discussions there’s a strong opinion that backspace/delete is a poor choice for a navigation shortcut since there’s risk it might accidentally erase text when input focus is unexpectedly in a text field.

Since I agree with that I’ve never used (shift-)delete for browser page navigation when it’s available.

I prefer command-[ and command-] because they’re clearly distinct from arrow key shortcuts similar to what I use with Codetek Virtual Desktop.

Anyone who’s using Safari might naturally first try its shortcuts in DT for navigation, zoom, etc. since both use WebKit.  Even if they’re using different shortcuts for the same functions a good thing to avoid is any conflict that might produce “destructive” results by mistakenly typing a Safari shortcut in DT, or vice versa.

I’ll always have opinions about interfaces I prefer, but I also appreciate consistency between them more now than when I was younger so sometimes I’m willing to compromise for that.

Back/Forward menu/toolbar items and standard shortcuts will be available in  v1.8.2

Acknowledged.  Thanks.

Btw, I’m guessing changes like this won’t be in the first release of DT Pro and will be added mostly in parallel with DT PE?

No. DT 1.8.2 and DT Pro will be developed concurrently (or you could say that DT PE 1.8.2 will get some of the improvements of DT Pro :slight_smile:)

Granting the comments about the virtues of consistency, I still vote to keep the Delete key function for moving back within WebKit pages. I prefer it over Cmd-[ because it’s a single key, not a “two-handed” key – hence Delete is much faster and more convenient for backing up a page at a time. (I use a couple of other applications where Cmd-[/] is the keyboard shortcut for moving back or forward. I detest Cmd-[, because I’ve got to position both hands on the keyboard to use it. When I’m reading Web pages, my natural inclination is to take my hands off the keyboard. One-hand actions to scroll the page or to switch pages “feel” better.)

Most DT users will also be Safari users. I’ve never confused the function of the Delete key outside browser windows, and I expect that will be the common experience of DT users.

I wouldn’t suggest getting rid of delete key’s navigation function (in DT, browsers, e-mail clients, et.al.) since it’s an overwhelming de facto standard. Yes, I dislike its dual purpose, context sensitive usage (from a UI design perspective), but its navigation function is easily ignored so erring on that side is usually less annoying than accidental text deletion.

[edit: was it clear I meant using the delete key can both navigate or erase text (e.g. in a form) on the same WebLink-rendered page depending on input focus?]

Actually, wouldn’t it have been more “sensible” choosing single insert keys like [b]b/b/[b]f/b instead of the (shift-)delete key? :slight_smile:

It’s so common using both hands on my iBook keyboard (even when using an external mouse) that most multi-key shortcuts feel “natural”, even navigation functions, tho’ it’s not the most comfortable keyboard for “chorded” key sequences (e.g. control-meta-<key>" in Emacs.

I do a great deal of one-handed (no-handed much of the time) computing, especially when reading (I do a lot of that on the computer, since I’ve got a lot of reference material to assimilate) and surfing. It’s amazing how many actions I can control with my TiBook’s trackpad (SideTrack helps), the Space bar, Delete and Enter.

What do I do with the other hand? Well, there are usually two dogs at my feet who like to be petted (sometimes that takes two hands). I drink a lot of coffee. And I like to smoke when I’m thinking something through.

Writing time, of course, is another matter; I do a lot of that, and that is a two-handed job. Sometimes the dogs get banished from the study. ;D

If DT is using safari’s webkit, it should use safari’s standard back and forward  keyboard shortcuts, as long as they are not already used by DT for another function.
Choosing letters based on the english language is as “sensible” as choosing  letters based in the german language, or Esperanto for that matter =)

User configurable shortcuts would be nice…

So, choose your language. :slight_smile:

I’m much in favor of user-customizable keyboard shortcuts, especially in heavily interactive apps like e-mail clients and web browsers.  John Gruber’s Losers, Weepers article is an interesting analysis of issues with them on OS X.  His conclusion:

I agree with him that Apple should provide that interface and hope developers will encourage them to do it.

Version 1.8.2 will add Cmd-[ and Cmd-] (or Cmd-Ö and Cmd-Ä if you’re using the German version :slight_smile:) without killing the existing (Shift-) Delete shortcuts.

Thanks.  Command-+/- for Zoom In/Out would also be handy, as I mentioned earlier this tread.  In the mean time maybe I’ll use Keyboard Shortcuts in System Preferences, but…

Both command-+ and command-= are Makes Text Bigger shortcuts in Safari.  Command-= is Zoom To Fit in DT so a new shortcut would be needed for that.

Also, I just noticed Zoom To Width is command-shift-W.  Is that a good choice since command-W is Close Window?

PS - Welcome back to the forum.

Or everybody could just buy Menu Master from Unsanity and make up their own shortcuts to suit themselves. I do, and oddly enough, have had no complaints, from system or apps. I do keep them consistent, like Com-/ for Close Window (because I work on a powerbook, that’s why, and weird key combos interrupt the flow) and only enable selected apps. Like DevonThink.

Actually, there is only one app that doesn’t reliably comply, need I add, made by Micro$oft.

And please, anti-haxies, I’ve already heard it. Have maintained stable systems since introduction of Jaguar. . .and would have gone quite mad without the ability to minimize windows, change the desktop font, and everything else that worked better in OS 9.x. The key word here being work. I remember gliding over the desktop, thanks to FinderPop, MoreFileInfo, the effortless way the CM dropped. . … never having to open a Finder window. . <sigh>

Zo

Oh, yeah -  so I’ve got Safari set to Back = Com-Left Arrow, Forward = obvious, swtiched Bookmarks Bar to Com-B. . . .like that.

Those shortcuts are already used to increase/decrease the font size of text documents (see menu “Format”) and IMHO it’s not a good idea to use the same command-shortcuts for different purposes depending on the context (e.g. the shortcut would appear sometimes after one menu item, sometimes after anothe one - that’s confusing…)

Haxies and APE are actually not the problem - buggy haxies (and contextual menu plugins) are the problem because haxies/CM plugins are able to access and modify DT’s memory.

And if such a bug in the worst case modifies the position and size of a database block, DT might overwrite the wrong part of the database. And therefore those things are dangerous.

But actually most problems of haxies and CM plugins seem to be harmless - "only" causing DT to crash sometimes  ;)