Future standard GUI library

Chris Angelico rosuav at gmail.com
Sat Jun 1 16:46:02 EDT 2013


On Sun, Jun 2, 2013 at 4:18 AM, Wolfgang Keller <feliphil at gmx.net> wrote:
>> > A GUI that can not be used without taking the ten fingers off the
>> > keyboard is indeed entirely unusable for any half-proficient
>> > screenworker. And anyone doing actual productive screenwork every
>> > day for more than just a few months will inevitably (have to) get
>> > proficient (unless completely braindead).
>>
>> My ten fingers stay on my keyboard, which looks somewhat thus:
>>
>> http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg
>>
>> See the red dot in the middle? Mouse.
>
> I didn't mean "trackpoints" or similar devices, but full keyboard
> "navigation" of the entire GUI through shortcuts etc.
>
> A "touch-type" GUI is a "must have" for any application that's supposed
> to be used productively. The mouse is nice to "explore" a GUI or for
> occasional/leisurely use, but once you use an application daily to earn
> your living, it's a hopeless roadblock for productivity.

You have seriously underestimated the power of the combined
keyboard+mouse interface. I absolutely agree that keyboard-only will
(almost) always beat mouse-only, but keyboard AND mouse together can
beat either alone, if the UI is designed correctly.

Case in point: Partial staging of a file in git. I can use 'git add
-p' or 'git gui'. With the former, it's all keyboard; I can step
through the hunks, choose what to stage, move on. With the latter,
it's more visual; I right-click a hunk and choose "Stage this hunk"
(or "Stage this line", which is actually quite fiddly with 'git add
-p').

I am a self-confessed keyboard junkie. I will use the keyboard for
pretty much everything. Yet I use git gui and almost never git add -p,
the one exception being when I can't use git gui (eg it's not
installed on some remote headless system and installing it would
require fetching gobs of GUI libraries). It uses the mouse to good
result.

> As is the "response time" behaviour of "web applications".

On a LAN, with a proper back-end, I can get instant response from a
web app. Obviously over the internet there's latency, but that's
nothing to do with the use of a web browser as a UI; you'll see that
with ssh just as much.

> "No cursor animation ever" is an absolute "must have" requirement for
> productivity applications.

Not really. There are times when the human will be legitimately
waiting for the computer. http://xkcd.com/303/ for one. But this still
has little to do with the use of a web browser UI; I can achieve
exactly that with the Yosemite Project, which can actually be a
three-computer system: the content is stored on one, the HTTP server
is on another, and the web browser is separate again. And this is only
a 100Mbit LAN. If you need moar speeeeeeed, you can always demand
gigabit or better.

>> THIS is a professional programmer's workspace. :)
>
> And by "screenworkers" I didn't refer to programmers. Those people
> rarely have to use the stuff that they implement.

Of course not, programmers never use software they've themselves
written. Never. Not in a million... oh wait, what's this I have? Hmm,
gcc used to compile gcc, RosMud being used by Rosuav, Neil Hodgson
using SciTE... naw, they're all statistical anomalies, carry on!

You really have a very low opinion of programmers for someone on a
programming mailing list :)

ChrisA



More information about the Python-list mailing list