[Bug] [Mac] Inconsistencies and conflict in keyboard shortcuts

[cculbreath]

Here's a quick initial list. I will continue to compile a list as I run into more.

• All (most?) UI references to CTRL should be CMD on the mac
• ESC key selects ok in delete note confirmation
• "Dev Tools" cannot be opened with CMD+SHIFT+I or CTRL+SHIFT+I
• System Emoji Palette (CMD+CTRL+SPACE) is inaccessible
• Clipboard functionality is inaccessible in dev tools console (desktop app only)
• Many shortcuts are utilize key combinations that are reserved for specific functionality (CMD+O for open, CMD+P for print) across the platform. Pretty much all developers avoid the use of these standard-value hotkeys for anything other than than their reserved purpose regardless of whether their app incorporates a print function (for example). That might be out of an some firm commitment to user-consistency, or maybe Apple somehow discourages/prevents it in their UI APIs—I don't why the convention is so widely held—but I can't think of any app that's uses these keys for anything else.
• MacOS Keyboard bindings persist in text-editor (for example, CMD+SHIFT+UP selects text from caret to beginning of document) preventing tree-navigation from the editor
• I see two possible solutions:
  • Develop a robust set of Mac keyboard shortcuts that align with standard MacOS conventions — and update UI elements to correctly distinguish CTRL from CMD
  • Maitain all bindings as currently printed within the UI and use CTRL as the defualt modifier for trilium shortcuts. Not only would this improve the experience in the desktop app, but would also minimize conflict in the browser envriornment where the confusion over hotkey priority is particularly acute. Nobody expects their browser hotkey functionality to depend on the foreground tab. CMD+T should always be "Open New Tab". Designating CTRL as the primary app-modifier key reduces this conflict and establishes an understandable convention.

[zadam]

ESC key selects ok in delete note confirmation

This is an electron bug and will be fixed with the electron upgrade (0.32 most probably). Very stupid bug though.

System Emoji Palette (CMD+CTRL+SPACE) is inaccessible

Frankly I don't even know what this is. I don't use Mac, have very little knowledge of how it is used and what are its standards. I did a port for Mac due to many people asking for it but maybe I should mark it as "experimental" since the quality/support seems to be obviously below Windows/Linux port.

Clipboard functionality is inaccessible in dev tools console (desktop app only)

Mac (probably in combination with Electron) has some strange handling of the keyboard shortcuts for clipboard - in the "main" trilium app I have to manually setup the keybindings, otherwise they don't work there either. But this workaround does not work in devtools unfortunately.

Many shortcuts are utilize key combinations that are reserved for specific functionality (CMD+O for open, CMD+P for print) across the platform.

It's impossible to design a rich set of keyboard shortcuts for all platforms and environments without any conflicts. There was an issue created month ago where some keyboard shortcuts clashed with Polish keyboard for example.

Develop a robust set of Mac keyboard shortcuts that align with standard MacOS conventions — and update UI elements to correctly distinguish CTRL from CMD

In general I don't want go this way because I want to limit platform specific functionality to absolute minimum and also for usability purposes - if I run the app on more platforms, I want it to behave consistently.

Maitain all bindings as currently printed within the UI and use CTRL as the defualt modifier for trilium shortcuts.

This is more realistic solution.

Nobody expects their browser hotkey functionality to depend on the foreground tab. CMD+T should always be "Open New Tab".

I did take some care to avoid at least most used keyboard combinations used in browsers - specifically e.g. CTRL-T/CTRL-W (CMD-T/CMD-W) so there should not be a problem ...

[cculbreath]

System Emoji Palette (CMD+CTRL+SPACE) is inaccessible

Frankly I don't even know what this is. I don't use Mac, have very little knowledge of how it is used and what are its standards. I did a port for Mac due to many people asking for it but maybe I should mark it as "experimental" since the quality/support seems to be obviously below Windows/Linux port.

I, for one, am very thankful that you took the time to make a Mac port. Trilium is the exactly the notes app/knowledge database that I've always wanted. I couldn't be happier with the design philosophy. The simplicity, versatility and clever incorporation of code notes strikes a perfect balance. And it's open source! Thank you, thank you. 👏 On the mac, the app feels like a well-developed beta; I wouldn't encourage you to add an experimental label. These notes aren't complaints, but are intended aid in trilium's development. I did not to intend to imply any amount of dissatisfaction. If at some point you're interested (and I have the time), I'd be happy to take a stab and generating pull-requests for some of these Mac-UI quibbles. My day job is as a physics instructor, but my coding hobby is gaining more of my attention all the time.

It's impossible to design a rich set of keyboard shortcuts for all platforms and environments without any conflicts. There was an issue created month ago where some keyboard shortcuts clashed with Polish keyboard for example.

Nobody expects their browser hotkey functionality to depend on the foreground tab. CMD+T should always be "Open New Tab".

I did take some care to avoid at least most used keyboard combinations used in browsers - specifically e.g. CTRL-T/CTRL-W (CMD-T/CMD-W) so there should not be a problem ...

I agree, you've done a good job of avoiding conflicts. I mention this point mostly to augment my suggestion that on the Mac—where non-standard use of reserved shortcuts is exceedingly rare— adopting CTRL as the primary modifier key makes a lot of sense. The existing scheme works. I make this suggestion so that you might consider it should a future development cycle include a revisions the KB shortcut scheme or Mac UI

[zadam]

If at some point you're interested (and I have the time), I'd be happy to take a stab and generating pull-requests for some of these Mac-UI quibbles.

This would be definitely appreciated. It looks like Mac port needs work, but I lack the knowledge and frankly motivation to learn it since I'm personally not really interested in Mac. Also development and testing for Mac is quite a pain for me (I don't actually own a Mac ...).

I agree, you've done a good job of avoiding conflicts. I mention this point mostly to augment my suggestion that on the Mac—where non-standard use of reserved shortcuts is exceedingly rare— adopting CTRL as the primary modifier key makes a lot of sense. The existing scheme works. I make this suggestion so that you might consider it should a future development cycle include a revisions the KB shortcut scheme or Mac UI

Actually originally all shortcuts were CTRL even for Mac - with my ignorance going as far as not being aware Macs have a CMD key. But then in #290 people said that all shortcuts should be with CMD instead of CTRL so I changed that with kind of a hack.

Anyway, I'm open to KB scheme redesign if we manage to find something which is conflict free against few main platforms (or more realistically which has fewer less important conflicts).

I also plan to expose some way of configuring the keyboard shortcuts, that way people would be able to fix the conflicts by which they are personally bothered or vice versa.

[Snuupy]

One other note I've noticed: going to the beginning or end of the line via fn+left/right arrow key doesn't always work.

In the current state, going to the beginning of the line only works if the current cursor is in the middle of a line, and going to the end of the line never works. Instead (when the cursor is at the beginning of the line already or anytime end is hit), the cursor goes to the beginning or end of the document.

On mac, we don't have home or end keys, so fn+left/right is the equivalent for apps that don't design with mac in mind. On most other applications (ex. Google Chrome, OneNote, etc), cmd+left/right go to the beginning or end of lines.

Edit: Upon further testing, fn+right arrow key (should go to end of line) brings the note editor to the end of the file. If you press the shortcut again, then it brings you to the end of the line (this is correct behavior, but needs to be pressed twice every time). How strange. I would guess this to be a strange interaction between electron and native shortcut behavior.

[number5]

@Snuupy Fn+Left/Right Arrow now works in 0.35.1 on macOS 10.14.6

[Snuupy]

It looks like that shortcut breaks if:

• the note has a table
• your cursor is focused outside the table
• you hit the Fn+left/right arrow key to go to beginning/end of line @number5

[zDEFz]

META+J doesn't Jump to Note for me
Ver:Version 0.45.2 (0.45.2)

[GPopZach]

I'm willing to take over macOS integration entirely if a list of current issues can be compiled. Which of these are still relevant?

How do you feel about such a collaboration @zadam

[zadam]

@Zachpocalypse Sounds good to me!

[fivestones]

@Zachpocalypse Does this mean also integrating other macOS stuff (e.g., menubar, etc.)? That would be awesome! But just keyboard shortcuts all working would be fantastic.

[GPopZach]

@fivestones Yes, I've tabled it for a couple months, I've got some fires to put out at work (I work for a game company and we just had to push a release of one of our biggest IPs back.) But I plan on implementing the Apple Human Interface Guidelines current as of writing.

I'll need to check again with @zadam for his thoughts when I have the time to actually get the code written, so we can avoid any misunderstandings or hiccups on licensing, but I'd like to distribute a compiled and signed binary via the App Store as well.

[peteshaw]

My two cents- what could be implemented was a hotkey system where all actions descend from a user modify-able 'action key' - that loads up a menu tree. So 'insert after' could be action + N + O, and 'insert child' could be action + N + A. This has a bunch of advantages. Cross platform support, all shortcuts in one place, etc. Of course I have no idea how hard this is to implement, so perhaps not the way to go.

[xxyxxyxyx1]

My two cents- what could be implemented was a hotkey system where all actions descend from a user modify-able 'action key' - that loads up a menu tree. So 'insert after' could be action + N + O, and 'insert child' could be action + N + A. This has a bunch of advantages. Cross platform support, all shortcuts in one place, etc. Of course I have no idea how hard this is to implement, so perhaps not the way to go.

This is done nicely in kitty with kitty_mod:
https://github.com/kovidgoyal/kitty/search?q=kitty_mod

[NyaomiDEV]

I'd also want to add that it is impossible to "unhide" the window by clicking on the Trilium icon on the Dock. This is an inconsistency with how Mac works, because usually windows are indeed closed on Mac when you close them, and not just hidden; but clicking on the Dock icon spawns a new window if one is not already open.

This can be worked around by mapping the "Show" tray icon menu action to the Dock icon.

[meichthys]

Trilium has entered maintenance mode. Future enhancements will be addressed in TrilumNext: TriliumNext/Notes#93