No more right click terminal

[Alexandre Oliva]

Sorry for bringing this old thread back to life, I've been away from
the list for a bit, and I think there are some very important points
that have failed to make into this discussion.

On Jul 15, 2005, Colin Walters <walters at redhat.com> wrote:

> On Thu, 2005-07-14 at 14:32 -0300, Alexandre Oliva wrote:
>> On Jul 13, 2005, Colin Walters <walters at redhat.com> wrote:
>> 
>> > Think of it this way: what if GNOME's historical audience had been
>> > musicians?  Then the right click menu might have had 
>> > "Open Musical Score Composer".  Having that makes as much sense to the
>> > general population as "Open Terminal" does.
>> 
>> FWIW, when I first introduced Cygwin to a musician friend of mine, he
>> absolutely *loved* the ability to issue commands without having to
>> point and click, and the ability to write scripts to automate common
>> or repetitive tasks.

> If your friend can write scripts, that means he or she has a level of
> technical knowledge we can not expect of all users.

He doesn't have such knowledge, and he can't write scripts (yet?).
What he can do is ask me how to do certain actions he does often from
the command line, then type those, one after the other, into a file,
and then make that file executable.  Oops, there's a script.  The
difficult bit is to figure out how to accomplish the point-and-click
actions from a command line.

>> Terminals should not be thought of as power-users only; they're useful
>> for everybody.

> Completely, totally disagree.  Every time a non-developer/non-sysadmin
> has to use the terminal for something is a bug.

I don't disagree with your point.  One *should* be able to accomplish
anything from the GUI.  But that was not my point.

My point was that, in *addition* to being able to accomplish actions
with the GUI interaction mechanisms, it would be ideal to *also* be
able to accomplish those same actions from a scripting language,
because this would enable users who happen to repeat the same
sequences of actions to script them.  It would enable other GUI
applications to record sequences of events to replay them later, to
ease scripting for users who still fear the command line.  It would
enable better testing of GUI apps, and would also enable users who
become power users to exercise their power to make themselves more
productive instead of remaining point-and-click monkeys who can just
wish they could do more.

>> Perhaps our desktop approach should take a stance
>> similar to AIX SMIT (sp?), a system administration front-end that
>> would not only enable you to perform various tasks with a point&click
>> interface, but *also* let you know the commands it was running to
>> perform those tasks.  

> Let me suggest something to you - what if we took an stance with GCC
> where when it compiled C code, it popped up a curses application which
> told you how you could be writing by hand the assembler it was
> generating and how it was doing.  Here's how the register allocator
> works, here's how it optimized away variable x, etc...

Why does it have to pop up a curses application?  Why not just give
users the *option* to see the assembly code they could use to
accomplish the same tasks by hand?  Why not give users the *option*
for the compiler to tell what it's doing behind the scenes, and let
users inspect what's going on in each of the optimization passes?  Oh,
wait, GCC can already do this, and some users see a *lot* of value in
that.

And there's more: if you want, you can take some of the assembly code,
tweak it, and feed it back into the compiler through the extended
asm() notation introduced by GCC, that's one of its most interesting
features for really low-level, power developers.

So, GCC already has means to let people watch what's going on behind
the scenes, if they choose to.  Unfortunately, there are still some
missing bits.  It would be very nice if GCC would expose its internal
API such that people could easily plug their own optimization passes
into, and we could feed code using GCC's internal representations into
certain passes.  This comes up every now and then in GCC lists, and
it's agreed that it would be useful, but we can't do it for political
reasons: the FSF won't let us do it because of fear that this would
make it too easy for people to develop proprietary extensions for GCC.
So we end up with a poorer testsuite and no plugin features, but
that's not because they're not desirable.

> Now, I happen to be one of the people who is in the target audience for
> GCC.  The entire reason I use GCC is because I don't *want* to know or
> care about assembler.  Just like our desktop, for the vast majority of
> people, GCC is a tool they use to get a job done, not something they
> care to know the internals of.  The curses/GCC thing would be extremely
> annoying at best for people just trying to get a job done, exactly like
> your suggestion of desktop commands would be.

If it's forced down everybody's throat, yes, it would be quite
annoying.  But it is useful for a number of people, and if you force
the *inability* to use such features down these people, you make
*them* unhappy.

>> I'm told Autocad is very much like this as well,
>> and even architects without any prior programming expertise end up
>> being able to automate tasks using the lisp-based programming
>> interface, which is one of the features that makes it so powerful.

> Autocad is a very specialized tool for a particular audience.  You can
> probably assume that most of its users spend 8 hours a day for years in
> front of it and that any time they can save helps a lot.

And isn't this the case for lots of applications that people use day
after day?

> The same is not true in general.  It is not worth the time for most
> users to learn how to program just so you can save a few seconds off
> your OpenOffice usage or whatever.

Sure, if they don't see the need for that, they don't have to.  But
the many that could do that would benefit from it.

> Don't get me wrong: it *would* be nice if we had an equivalent to
> AppleScript so somewhat technically inclined users could script apps for
> relatively obscure use cases.  But that's no substitute for actually
> fixing the desktop to just work for the major cases.

What is it that makes use cases that someone has to perform 100 times
a day obscure?  The fact that this person is not your idealized target
user?  Everybody deviates a bit from this user, so, by denying this
ability to everybody, you're making everybody's life harder.

>> This gave you the option to remain clueless 

> I think this reveals a lot about how you think about our target users.

Or about my lack of command of the English language.  I'm not a native
speaker.  Perhaps this term doesn't mean what I meant.  I just meant
the user could remain in...  would the term `blissful ignorance' not
carry the negative connotation you read into my words?

> If you consider them "clueless" and think that they have some need to
> know how computers work and how to program or else they're stupid, that
> strikes me as rather negative and arrogant.

cluelessness and stupidity are not quite the same.  One can choose to
remain ignorant on some topic that they think doesn't make much of a
difference to them.  Stupidity is related with someone trying hard to
acquire some knowledge, but still fails, because the topic is just too
difficult for them.

> Personally, I think *we* are the clueless ones, who spend all of our
> time in front of computers learning how they work.  The truly smart
> people are the ones who became surfing instructors at some beach in
> Hawaii and rarely see a computer.

Personally, I find it more fun to hack than to turn into a red tomato
at the a beach.  But then, I'm known to be geeky and nerdy :-)

> People in general want to use the computer to do their work, send email
> occasionally or something, and could care less how they work at all (and
> definitely don't care to learn how to program).

Sure, we shouldn't stop such people from using computers.  But even
those might have use cases that could be improved, and if they can't
come up with a solution themselves, they can keep on wasting their
time on such repetitive tasks, or they could ask a computer-savvy
friend to write a script for them, or write a script themselves,
after some studying, or even using a GUI app to create GUI scripts.

> You'd think this would be common sense...I feel pretty silly even
> explaining it.

I feel just the same way about the thoughts I've exposed above.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}