Live data from Hacker News

Show HN: A fork of sudo with Touch ID support

github.com

121–130 of 134 posts

Re: Show HN: A fork of sudo with Touch ID support

#121

This here is what gets me salivating: Using the toolbar as a context-sensitive test runner/controler: https://pbs.twimg.com/media/CwC8SNvW8AQgeWN.png:large

My emacs already does that if I want it to. My vim did it before I switched to spacemacs. I still don't understand why you'd want to give up physical buttons for an awkwardly angled small touchscreen that requires using your laptop's keyboard.

I'm probably not the target market I suppose, my keyboard's keycaps are blank: http://www.daskeyboard.com/daskeyboard-4-ultimate/

Re: Show HN: A fork of sudo with Touch ID support

#122

Earlier quoted context omitted.

Use your thumb print.

Lift the thumbprint off of the TouchID sensor itself? That is, assuming the premise of the grandparent comment is valid and fingerprints lifted off of the keyboard would be enough.

You only use your thumb on the space bar, and when you do, it's the side. But when you scan your thumb, it's the face of the print, ergo, impossible to lift thumb print from nearby key.

Re: Show HN: A fork of sudo with Touch ID support

#123
post #114

Earlier quoted context omitted.

With PyCharm and most Jetbrains IDEs I can remap keys to run test. So pressing two or three keys will run tests AND!!! I don't have to look at my keyboard to run the tests NOR see the results.

… and you can continue to do that just fine. Meanwhile, the other 90% of users will probably love it when their IDE, profiler, every browser's developer tools, etc. can display context-appropriate labels so they don't need to remember what F8 does in the current mode of the current application.

90% of users consistently and/or constantly look at and/or check their keyboards with the new touchbar. That sounds so AWESOME! Thumbs up! /s

The touch bar is a regression.

Re: Show HN: A fork of sudo with Touch ID support

#124
post #118
post #116

Earlier quoted context omitted.

The computer already has a fantastic dynamic display built in—the display. Your eyes even naturally fall there. Why do we need a second display at all, much less on the keyboard where people do not look?

Unless you're touch-typing your function keys, you certainly do look there. I don't want a "second display"; I want dynamic, context-aware buttons. Focusing on the fact that it's "another display" misses all the benefits of it not being static hardware buttons.

> I want dynamic, context-aware buttons.

The buttons on your keyboard are already context aware. All this does is make them difficult/impossible to touch type (I touch type my F-keys), forces me to look away from my display to perform operations, and removes the good tactile feedback you get from a keypress.

Re: Show HN: A fork of sudo with Touch ID support

#125

Earlier quoted context omitted.

Remind me again how function keys can produce full colour multitouch interfaces, such as video/image scrubbers, colour pickers, etc. The standard "function keys can do anything" response is getting old.

> The standard "function keys can do anything" response is getting old. That "function keys can do anything" is, in my opinion, the exact reason they had to go. They're scary for the typical user. What is F7? You may know, but it's not obvious in any way. That some of them cause destructive actions (e.g. Alt+F4 on Windows) makes it worse - they're scary to many users. And even when after figuring out what some of the…

> That "function keys can do anything" is, in my opinion, the exact reason they had to go. They're scary for the typical user.

Then make the whole screen touch enabled and bypass the silly, tiny screen gimmick.

Re: Show HN: A fork of sudo with Touch ID support

#126

Earlier quoted context omitted.

Yeah, but you're ignoring the functionality loss from not having the function keys. You may not use them, but many people do. For example, in Emacs (and I'm assuming most IDEs) I can map a function key to run my tests and have a status bar entry saying how many passed or failed. It's the exact functionality in your screenshot, no touch bar required. At best the touch bar is a nice gimmick, and it's not adding anythin…

Remind me again how function keys can produce full colour multitouch interfaces, such as video/image scrubbers, colour pickers, etc. The standard "function keys can do anything" response is getting old.

But "full colour multitouch interfaces" are awful compared to keyboard keys! Getting to switch back to my mouse + kb after using my phone is so fantastic.

This bar is all the bad stuff about a touchscreen (limited/no tactile feedback, reduced ability to rely on muscle memory) plus the bad stuff about keyboards (primarily that they are not where your eyes are naturally). There are a few tiny niche uses cases that will be nice, like video scrubbing, but 90% of the time it's just going to be functionality that is more difficult to use than it was previously.

Re: Show HN: A fork of sudo with Touch ID support

#127

Earlier quoted context omitted.

Yeah, but you're ignoring the functionality loss from not having the function keys. You may not use them, but many people do. For example, in Emacs (and I'm assuming most IDEs) I can map a function key to run my tests and have a status bar entry saying how many passed or failed. It's the exact functionality in your screenshot, no touch bar required. At best the touch bar is a nice gimmick, and it's not adding anythin…

You're not losing function keys, they're just becoming more powerful. You can still set the touch area to be a row of function keys, if you like that! Or they might become more dynamic, by updating which binds are available based on what's on screen. It is a nice gimmick. Is there anything wrong with an improvement, even if it's a little one?

First, your F keys already change binds based on what's on screen. Second, you are ignoring all the things that are worse. You can't really touch type any more, you have to take your eyes away from the screen, and you get greatly reduced tactile feedback.

It is a gimmick, but in my opinion it's not an improvement, it's counterproductive.

Re: Show HN: A fork of sudo with Touch ID support

#128
post #88

Earlier quoted context omitted.

To what exact cases are you referring? Do you not use an ide with a test runner? What exactly is desirable about triggering and monitoring this from a second display on the keyboard--where you're looking all the time, naturally--over clicking a button on screen?

Take a good look at the IDE running there. It's Vim. I use that all the time, and so do many other people on HN. Do you need a button like this on your keyboard? No, you could set up a new Vim bind. But this is more dynamic; what if the test re-run buttons were only visible after having modified a file, and replaced with a deploy or commit button if tests succeed? If you're vigorously opposed to it, don't buy a Mac.…

Would vim be fun/useful to use on an iPad? Because, I think that is what your argument really says...

>But this is more dynamic; what if the test re-run buttons were only visible after having modified a file, and replaced with a deploy or commit button if tests succeed?

More dynamic in that you have to look away from your work to trigger a re-run? Or more dynamic in that its completely worthless if you use an external display and external keyboard? Or more dynamic in that it's another avenue for show-stopping macOS bugs?

Re: Show HN: A fork of sudo with Touch ID support

#129
post #118

Earlier quoted context omitted.

Unless you're touch-typing your function keys, you certainly do look there. I don't want a "second display"; I want dynamic, context-aware buttons. Focusing on the fact that it's "another display" misses all the benefits of it not being static hardware buttons.

> I want dynamic, context-aware buttons. The buttons on your keyboard are already context aware. All this does is make them difficult/impossible to touch type (I touch type my F-keys), forces me to look away from my display to perform operations, and removes the good tactile feedback you get from a keypress.

"Context-aware" as in the applications you use will decide what to do with the inputs, I guess, sure. The applications you use being able to create their own inputs is an entirely different thing and what I meant by "context-aware".

I agree, though, that the lack of feedback was a mistake.

Re: Show HN: A fork of sudo with Touch ID support

#130

Earlier quoted context omitted.

> The standard "function keys can do anything" response is getting old. That "function keys can do anything" is, in my opinion, the exact reason they had to go. They're scary for the typical user. What is F7? You may know, but it's not obvious in any way. That some of them cause destructive actions (e.g. Alt+F4 on Windows) makes it worse - they're scary to many users. And even when after figuring out what some of the…

> That "function keys can do anything" is, in my opinion, the exact reason they had to go. They're scary for the typical user. Then make the whole screen touch enabled and bypass the silly, tiny screen gimmick.

That seems entirely unrelated to what you quoted. Regardless of whether the whole screen becomes a touchscreen, or a bar is used, the F-keys in their form are bad UX.
Post reply on HN