Keyboard handling driving me nuts: how to make it work like BC for Windows

[jeroenp]

BC for Mac keyboard handling is driving me nuts.

For instance left-right arrow don't move between left and right pane in the directory view. Tab doesn't get you there either.

Is there a quick way to fully make the keyboard handling match BC for Windows?

Is there a full list (in HTML or PDF) with all keyboard shortcuts on both platforms?

--jeroen

[Aaron]

Hello,

The issue is that OSX claims various keyboard shortcuts globally across all applications, and are are unable to use these. We've worked around them as best we can.

The Folder Compare matches Finder tree views, which requires Shift+ Left/Right Arrow to keyboard switch between sides.

Since Shift+Arrow is taken when editing text in the Text Compare, Ctrl+Shift+Left and Right is used to swap text panes.
Alt+Enter toggles Full Edit mode. When disabled, you can swap with the left/right arrows, or use Tabs to switch panes and paths.

We don't have a full keyboard list, but expose most commands next to their menu options or in the Preferences dialog -> Toolbars/Etc section.

[jeroenp]

I put the answer here: https://gist.github.com/jpluimers/12...1673920c3c72ea

Why? Well, I started writing here for a few hours, then the "IMG" button hung the editor taking me another hour to salvage the "auto-saved" (NOT!) post-text, and found out about:

The text that you have entered is too long (22316 characters). Please shorten it to 10000 characters long.

Then I found there is a stupid image limitation as well, so I moved everything to a [MarkDown](https://gist.github.com/dupuy/1855764) based [gist](https://gist.github.com).

So I split accross 10000 character boundaries but got this:

You have included a total of 59 images in your message. The maximum number that you may include is 4. Please correct the problem and then continue again.

None of the artificial posting limitations are made clear upfront. Luckily gists allow me to use a proper markdown instead of some vague buggy BB code knockoff implementation.

The answer starts out like this:

# Time for you to "make some docs" (;

Below is a start to get you going.

--jeroen

[Aaron]

Thanks for the write-up. We use vBulletin for our forum software, and have to implement some configuration restrictions to help control forum spam and resource bloat. Unfortunately, vBulletin doesn't have a great way to surface the limitations before a post is attempted.

[jeroenp]

Thanks for the write-up. We use vBulletin for our forum software, and have to implement some configuration restrictions to help control forum spam and resource bloat. Unfortunately, vBulletin doesn't have a great way to surface the limitations before a post is attempted.

OK. But are you working to get my write-up in the docs? Or better simplifying the settings?

--jeroen

[Aaron]

Hello,

From your first post? Most of the mentioned items are limitations of the host OS, where OSX has globally already claimed some of the shortcuts we had used on Windows and Linux. We had to create new methods that avoid these hotkeys, since they are already claimed conventions by OSX.

The Git resource you've created appears to be a selection of screenshots of our Toolbars/Etc dialog, which is already internal to our application, and is searchable for quick reference. Any updates we would do would be an extension of the Help file, which directs users to the Toolbars/Etc dialog as a searchable list of every command and hotkey shortcut. The hotkeys are not included in the Help file since they are customizable and exposed on the menu. The Help file -> Command Reference covers our commands and menu items as a full list, but doesn't necessarily show what the arrow keys do as OS convention. There's a definite learning curve going from Windows to OSX, which we had to make ourselves going from BC3 to BC4. We tried to keep as many commands as similar as we could, to make moving between the platforms as close as possible. Your GitHub post is useful for users that would like to see this information online rather than in-application.

For some of the mentioned wishlist items:
Compare was considered as a toolbar default, but we had to trim down toolbar space and it didn't quite make the cut. But this is why we make changing the defaults, to make user customization easy. Note that Compare is for a selection comparison scan, and duplicates functionality if you configure the Session Settings, Criteria tab to perform the scan on load automatically.
We don't expose a legend for each keyboard sign, but do use standard icon representations.
Where there any keys we have as defaults that are 'external keyboards only'?
Our dialog does not support resizing, so we have to pick a default size that's viewable on our minimum supported resolution, but also looks good at 4k resolutions. Our current sizing is the best compromise, but if we're able to enhance the Options dialog to support sizing we would allow for greater control.
The Select View dropdown helps limit the list of controls to only the controls of that view. In previous iterations of BC3, you had to launch the View first, then Customize Commands of that view. By adding the dropdown, a user can now customize any control regardless of the current view. What kind of simplification or UI were you looking for?

[jeroenp]

A few more questions:

- how can I view all shortcuts for all views at once?
- how can I sort them so I can get a feel for which shortcuts are common to what views?
- how can I search for 'shift', 'left', a letter or other key used as a shortcut?
- why is the main Beyond Compare window resizable but the settings window not?
- how can I export/import shortcut settings across systems and preferably platforms?

The simplified UI is to have all views in one overview with disableable checkbox marks to indicate for which view a shortcut combination would apply. A checkbox fore a view would be disabled in the column of a shortcut where it could not apply. Maybe also add an option to reset each row or checkbox to default.

This would be less flexible than the current setup, but in my experience users hardly want the possibility to set different shortcuts for common actions accross multiple views.

I'm very much in favour of the default shortcuts to be documented preferably both on-line and in the help in a searchable way (Google does a much better search than any help system I've seen so far, so ideally all help should be on-line in a similar way that MSDN contains the on-line help for Visual Studio or developer.apple.com has the on-line help for Xcode).

--jeroen

[Aaron]

Hello,

Most of the above questions are centered around one: our settings dialog does not support resizing due to some of the fundamental controls used in it. Because of this, we have to pick a good size that works on both low and high resolution displays. This doesn't leave a lot of extra room for the list of commands, however, so we don't have a view that lists every command in a single list; BC2 did this but BC3/4's list would be too large and unwieldy. As such, we have a dropdown control which limits the list to specific views to narrow the number of commands visible.

Improving how we allow customizing commands is something we've taken a stab at with each major release. We appreciate the feedback to help improve it further.

We don't currently support searching by hotkey. The search currently searches the name of the command or its description text, not the hotkey combination. If you try to create a hotkey that another command already uses, the dialog will warn of a conflict.

The Tools menu -> Export and Import supports cross-platform use (as the created .bcpkg file is actually just a .zip file with BCSetting.xmls inside). However, it will not perform any translation (exporting an external conversion that uses / instead of \ path delimiters, for example), so only globally safe commands would be expected to function. It could be useful, but given the number of conflicts between Windows and OSX (Ctrl+N for example), it isn't recommended unless you are comfortable avoiding these cases.


And I personally understand the transition from Windows to OSX hotkeys. Our BC4 Windows shortcuts had been set for over a decade from BC1/2/3, only to find that some global OSX hotkeys would override them. We can't override that behavior or convention, and struggled for quite awhile to come up with alternate keys to use for the defaults. They are as close to the Windows set as we could get, and there is a learning period if switching OS'es.

[Zoë]

I was responsible for the macOS shortcuts and implementation thereof, so hopefully I can defend the current approach. The short answer is that no, there isn't a way to make BC for macOS work like BC for Windows, driven somewhat by external design constraints, somewhat by implementation effort, and somewhat by our feelings on what makes a good macOS app vs what makes a good cross platform app.

Most keyboard shortcuts in most applications are not configurable and not explicitly documented, except on a "This is what the operating system conventions usually are" manner. Shift+Arrow to change the selection, for example. Even if we documented and allowed configuration of all of our custom controls (and there are quite a few in BC), those changes wouldn't apply to the path edits, filter edits, browse dialog, etc. Exposing all of those shortcuts would also be a nightmare to make configurable, since they're dependent on the focused control, may be shared across viewers, and generally would overwhelm the vast majority of our customers.

macOS actually does allow configuring shortcuts system wide using a text configuration file, and there are variants of that file available online that map everything to the Windows defaults. I seriously looked into what it would take to support that as an alternative to making it explicit in the interface, but unfortunately the file is basically a state table that allows calling arbitrary NSObject methods on the relevant controls, which are expected to react to specific protocols (basically re-implementing NSDocument). Since BC's internal model doesn't match that, and we would probably have to reimplement it when we switch from the Carbon backend to a Cocoa one, it would have been a lot of effort for an extremely small subset of our customers, and we just can't justify it.

The Lazarus IDE, which we use to develop the macOS version does support custom shortcuts for all of its editor commands, and I have set it up to match the Delphi shortcuts on the system I have set up using keyboard/mouse sharing. I understand the desire to do so. I can say that it is annoying to use too though. The editor works like a standard Windows edit, which is great, but it breaks down as soon as I bring up the "Find" edit. It mostly works because you generally spend all of your time interacting with the one control, but in BC you're going to bounce between at least two different controls, and probably interact with the system standard edits/comboboxes/treeviews more often (I certainly do).

The system also reserves a lot of standard Windows shortcuts for its own use. Alt+Letter is out because it's used for typing accented letters. Fn keys and Ctrl+Arrow are used by Mission Control and Accessibility, or need the Fn shift state to access.

All of that adds up to the simple fact that we can't closely match BC for Windows, which was already a mismash of shortcuts that grew haphazardly from v1 when all it had to deal with was a single folder compare that used listbox navigation keys. If we can't match it, and we want OS X customers to feel at home, that means matching the shortcuts used by the system and other applications as closely as possible. So we use Cmd+R for Refresh rather than F5, and Cmd+N for "New Window" instead of blindly copying Ctrl+N's "Next Difference". Once we'd decided on that route, overloading the Ctrl/Shift/Cmd/Alt+Arrow keys to perform both copying and navigation was a natural progression, and had the added benefit that a lot of work can be done without ever taking your hands off those keys. It's the best shortcuts we could come up with for the platform it it's on, and is much more consistant than the Windows version is. Cross-platform considerations aside, I think it's a better set of shortcuts.

The shortcut that started this thread (Left/Right arrow to switch folder compare sides) was removed because Shift+Arrow already did effectively the same thing, and allowed us to match the standard treeview shortcut for navigating between nodes. I will admit that it's one of the least defensible of the changes, but it's one I wish we'd done in Windows a long time ago, and was ultimately just a judgment call.

[Zoë]

One additional note: I assume your comment that we should avoid those keys was directed towards the usage of Home/End/PgUp/PageDn. On compact keyboards those keys are accessible using the Fn+Arrow keys, and any shortcuts that use them are doing so to match the default system-wide shortcuts. Delete/BkSpace is the same way. I'm not aware of any shortcuts that we came up with ourselves that require the Fn key.