On Tue, Sep 11, 2012 at 12:11 PM, John Maher <JohnM_at_rotair.com> wrote:
>> You're confusing a single application with the whole command line
>> and *everything* it can invoke. In your picture that whole set of all
>> commands available now or in the future is the 'the application' for
>> which you'd need to design a GUI, would you want to have its
>> available in a GUI.
> I don't understand this statement at all. I'm talking about a simple
> wrapper. And it would be very easy in incorporate *everything*. Even
> command that have not been added yet.
On the command line, every piece of text, including the base command
to run can be the expansion of shell variables, file wildcards, or the
output of any other program. If a GUI offers any of those options
you pretty much lose any point/click advantage it might have since the
choices approach infinity. The input can be the output of any other
program. If the tool doesn't do the complete job, the output can go
to any other tool.
>> Interaction with *other* applications (the trailer) isn't designed in,
>> and can't be automated.
> Again, if necessary it can be, very easy. However that is not the point
> of the wrapper. If I want to build a car you can say but it can't fly.
> And it can't float. You're right. It isn't supposed to. You can
> always pick fault about something if you go beyond its scope.
That's the point here. Things based on text stream processing don't
have 'scopes' or associated limits. Likewise for command lines based
on text expansions.
>> GUI applications are designed to interact with a user, and not with
>> other applications
> Again that is not true. Well the first part is. The second part (("not
> with other applications") may or may not be true. Depends on the app.
> I'm starting to learn who isn't a programmer because they have common
> misconceptions about how programs are designed. I wonder if its from
> watching TV?
Starting here worked out pretty well for me:
The concepts still save me time every day.
Received on 2012-09-11 19:52:10 CEST