4 ms·
I dunno. As another person who's also used tiling WMs for years, I find the mouse to operate in a different model, and I wish it was played with more. Like how
by accoil 4y ago
I dunno. As another person who's also used tiling WMs for years, I find the mouse to operate in a different model, and I wish it was played with more. Like how in Acme you could select arbitary text, press the middle mouse button and it'd be sent off to the appropriate handler.
Keyboard UI tends to be verb first. E.g in Vimium if you want to open a link in a new tab you press F to start the "Open in new tab" command. Then it lists the links you can open in a new tab for you to select from.
Whereas mouse UI tends to be noun first. E.g you see a link, and right click it to list the commands. You then select the "Open in new tab" command.
I think the reason for the difference is that the mouse can reach an arbitrary location easier than a keyboard, but once it's there it has much less options to continue.
For me, this means that the mouse is more exploratory, and the keyboard is more task oriented. If I'm toying around with ideas the mouse works better, but if I have something specific I want to do you can't beat the keyboard.
Writing this I've realised that I could repurpose the underutilised side buttons on my mouse as modifiers :p Hold top thumb button: press left click to go previous window, right to go next; hold bottom thumb: press left to go to previous workspace, right to go to next. Could have top thumb + mouse wheel for volume (and middle click for mute). I guess bottom middle could open a radial menu of commonly used apps/commands :)
- crabbone 4y agoI use Surfingkeys, it's similar to Vimium, but the experience of opening links is a lot better than what you describe (I haven't used Vimium, so cannot tell). "Clicking" a link is two key presses, maybe three, if there are a lot of links on the same page. If it were a contest, I'd probably be able to open links faster than someone using their mouse, but this being a relatively infrequent activity doesn't really need to be that fast. On the other hand, things like Surfingkeys, accidentally, sometimes allow me to circumvent bad design of a Web page, like when there's text you wouldn't be ordinarily able to select by dragging your mouse (because it responds to mouse events and changes etc.) this is still usually possible with Surfingkeys. (Without it, you'd have to "inspect element, find the element with text and extract it from there). Also, often times I can use this extension to scroll things that you wouldn't be able to scroll with mouse (again, due to bad Web page design). Mouse only wins in situations with NIH GUI elements, esp. s.t. require drag-and-drop (volume adjustment on video clips), or controlling built-in elements (like this text area) to resize them (which is really just a browser defect in accessibility, but hey, most of the time I have to use Web, I have to overcome the incompetence of the people building it, thus the selection of tools).
- accoil 4y agoSurfingkeys 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 there is interesting potential in having a tool that can interrogate arbitrary things on your screen. [1]: https://github.com/oantolin/embark https://github.com/oantolin/embark