I Use My Mouse

• blog

  13 100 8.6

  I might write stuff here sometimes (by madprops)

• sensible-side-buttons

  29 1,829 0.0 C

  A macOS menu bar app that enables system-wide navigation functionality for the side buttons on third-party mice.

On macOS, I use SensibleSideButtons to map my Logitech mouse side buttons to Swipe Right and Swipe Left. This works as a generic Forwards/Back in lots of places: Safari, Firefox, Finder, iTerm2.

Unfortunately the app appears to be abandoned (no Apple Silicon builds), but if there's interest I will resurrect it.

https://sensible-side-buttons.archagon.net

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• mac-precision-touchpad

  100 8,530 0.0 C

  Windows Precision Touchpad Driver Implementation for Apple MacBook / Magic Trackpad

I love my CST L-Trac but sometimes I wish I'd gotten the version with the extra button inputs to setup some extra keybinds.

Alternatively I've finally become used to having a magictrackpad2 and gestures. And thank you other devs[1] for someone getting it working on Windows x86/ARM64 builds as well. Next step is trying to find out if I can get it working fully under FreeBSD.

[1]https://github.com/imbushuo/mac-precision-touchpad

• embark

  65 831 8.8 Emacs Lisp

  Emacs Mini-Buffer Actions Rooted in Keymaps

Surfingkeys looks pretty similar (though I have yet to try it); I'm just describing the experience poorly. You press f, little labels show up on the links (I called this "listing the links"), and you then press the keys on the label (the "select from" part). Probably me using the open in new tab command F (as opposed to open in current tab command f) did not help.

Not saying it's a bad experience. I find it's quite nice if I'm currently looking at the correct link so I can get the letters from the label easily.

It's just a different paradigm. If I didn't know what a link was, I wouldn't know that I could press f to open the link selection. This means I can't select a link unless I had a "select unknown" button, and then use that to inspect it.

Select unknown can be done with the keyboard: Emacs' embark[^1] is a good example of it. You use search/arrows to go to an interesting piece of text (e.g something underlined), run embark, and it lists all the potential things you can do with it (e.g open in external browser, or download an archived copy). It's just that keyboard UIs do not tend to be geared around it.

That though is the sort of thing the mouse is good at: you see something interesting, you prod it to see what you can do with it.

Say you saw a phrase you didn't understand in the browser. Currently, with a mouse you'd highlight it, right click, and then select the search with search engine option. With keyboard you'd open the search engine, and enter the phrase. Both get you to the same place.

Now if we extend the mouse to have a "I would like to know idioms better" option. You could just select the phrase, right click, and a definition could be there waiting for you next to the context menu. It could even be there on hover.

With the keyboard though, you'd generally run an "I would like to know idioms better" command. This would then ask you which idiom on the page would you like to understand. You then select it, and presto. A faster version could potentially have idiom meanings show up the moment you ran the command by a similar hover effect (or just listing all discovered idioms in a popup etc).

One of the differences here though is that from the mouse you still have a list of actions on the text open, so maybe if you liked the definition you could then copy the phrase.

This certainly could be done from the keyboard UI: just have it list other applicable commands that could be run on the selection generated from the command that searched for phrases. No reason why it could not then spawn something asking if you wanted to "(c)opy, c(u)t" etc like the context menu.

But that is only visible because there was a phrase you didn't know. If you didn't know that there was a command to define phrases, you wouldn't have found out. In theory you could have commands register everything they could act on, and then have another command let the user select an interactive thing, and list the commands that registered for it. I think that would be overwhelming though, as something like a dictionary command would register for every word.

Ultimately the mouse is just different then the keyboard, and I think that discarding it because you majorily use a keyboard is missing the interesting potential of having a tool that can interrogate arbitrary things on your screen.

[1]: https://github.com/oantolin/embark

Suggest a related project