Re: graphical and command interfaces
From: andy (andy_at_earthsong.free-online.co.uk)
Date: 01/31/04
- Next message: John Winters: "Re: gpg"
- Previous message: Tomi Hakala: "PolyServ custering file system experiences ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 31 Jan 2004 20:03:47 GMT
>>>>> "Andy" == Andy Baxter <news4@earthsong.null.free-online.co.uk> writes:
Andy> i was thinking along the lines of - translate the man pages
Andy> to xml, with tags that could be parsed either as a flat-file
Andy> traditional man page,
>The man pages are marked up in nroff format. I can't see how
>converting them to XML would add any value.
my thought is that nroff is a page description language, like HTML or post
script, and doesn't include a way of marking up sections of the man page
according to their meaning, rather than the way they are displayed.
>And what makes an XML
>file less a flat-file than nroff?
it would be a flat file, but if it was marked up in the right way, the file
could be used to generate non-flat file representations.
Andy> single page bookmarked html, or multi-page html, plus extra
Andy> tags that could be parsed to generate a dialog for the
Andy> command in any gui toolkit (including the text based ones),
Andy> with the help text for each widget shown beside it.
>That's be a big deal of work, given the vast amount of existing man
>pages.
Yes. Also, nroff is a lot more complex than I had imagined, from having looked
at a few man pages.
<snip interesting stuff about emacs>
Andy> i've seen a couple of thing that make me think it might be
Andy> possible - there's a graphical programming language for
Andy> writing media applications called Max, where you can connect
Andy> boxes that do different things to the video stream with
Andy> lines, and the variables for each box are in other boxes
Andy> which you can adjust live with mouse buttons.
> As you said, it's "stream". The original data is sequential in
> nature. That makes using a GUI appropriate: the 2-D screen is quite
> adequate for representing multiple linear items and you can still mix
> them easily.
> But programs *in general* are not linear in nature. They're like
> trees when you stick firmly to structural programming. More often
> than not, they're not trees, but directed graphs, often with cycles.
> No, I find a 2D display not enough for displaying a tree of
> non-trivial sizes. For general directed graphs, it'd be a mess.
> Shell pipes, as the name suggests, may look linear at first glance.
> Sorry, bash (or maybe other shells too?) let's you make a tree of
> interconnecting processes. Such as
> diff <(cut -f1 file1 | sort) <(head -50 file2) | grep something | wc -l
> Just one line, and it would already crowd you screen with many
> interconnecting boxes. How to do a non-trivial shell program?
Andy> i was thinking of it more as a way to do some of the simpler
Andy> things that are possible with scripts in a graphical
Andy> environment, for people who like to work that way.
>I'd rather type a command like the one above rather than click click
>click. Typing is faster and more accurate.
i see what you're saying with all this, which is why i've said that it wouldn't
be suitable for writing complex programs.
>> How about one option that enables others automatically and
>> disable some others else? What if an command line argument is
>> a regular expression? I won't be interested in clicking out a
>> regex. Typing it is so much faster.
Andy> for the individual commands in the script, this could be
Andy> done through the xml pages i suggested.
> How would the graphical interface help me type the regular expresion,
> again?
it wouldn't, unless there was some kind of expression builder. but it needn't
stop you either.
Andy> for a script you'd written that needed options, it might
Andy> work if there was something like getopt where the internal
Andy> data structure needed to describe valid parameter strings
Andy> also defined the relationships between parameters you'd need
Andy> to build a graphical dialog.
>Sorry, the relation between the options can sometimes be so
>complicated that you have to express them with programs. Are you
>going to make your XML-based markups yet another general purpose
>language?
i guess the thing to do would be to make the markup as expressive as possible
without doing that, and then leave the rest to the user's common sense
and the program's parser.
Andy> something like a regex, you could type in manually or use a
Andy> dialog to build it.
> Then, why not type it DIRECTLY at the bash prompt or in Emcas or vi??
Andy> The main problem i could see with a system like this is that
Andy> the graphical side of things might constrain what you can do
Andy> with the underlying scripting language too much
>That's exactly why I hate graphical interfaces. They're too
>unexpressive. Remember, the GUI is a language with only a few words:
>click, move, drag. That's all.
They're the words that you have to use to use the interface, but then the
interface can present other words and relationships between them to you
through its design. The question is when is this a useful thing to do, and
when isn't it, which might be different for different people and different
purposes.
>Expressing something complicated with
>such a simplistic language is more difficult than learning a CLI.
Andy> - as soon as you wrote code beyond a certain complexity, it
Andy> would no longer be possible or sane to display it
Andy> graphically and the mapping would break down.
>That's exactly my point. GUI can only handle the simple cases well.
point taken. I still think that there might be some use for a system that
would handle those simple cases, as long as the way this was done didn't
prevent people from doing things as code, or take away from that way of
doing things.
where i started with all this was thinking about how GUI interfaces had
taken away from a lot of the things that are good about the cli way of
doing things, and wondering about how to make an interface that would
combine the things that are good about each of them. But i can see that
if it was done wrong it could easily go the other way, and just be
the worst of both.
- Next message: John Winters: "Re: gpg"
- Previous message: Tomi Hakala: "PolyServ custering file system experiences ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
