Re: Easiest/quickest method for very simple interfaces?
From: Dances With Crows (danSPANceswitTRAPhcrows_at_gmail.com)
Date: 07/12/05
- Next message: Alan Connor: "Correction: Re: CLI: Creating and Navigating the Dirextory Stack"
- Previous message: Peter T. Breuer: "Re: ten buck fedora"
- In reply to: Anton Suchaneck: "Re: Easiest/quickest method for very simple interfaces?"
- Next in thread: Anton Suchaneck: "Re: Easiest/quickest method for very simple interfaces?"
- Reply: Anton Suchaneck: "Re: Easiest/quickest method for very simple interfaces?"
- Reply: Lee Sau Dan: "Re: Easiest/quickest method for very simple interfaces?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 12 Jul 2005 08:42:08 -0500
On Mon, 11 Jul 2005 18:09:59 +0200, Anton Suchaneck staggered into the
Black Sun and said:
> Dances With Crows wrote:
>> If you know the basics of vim, you can edit text anywhere, which can
>> be Really Useful.
> That's true, but my case is different. I do not want to handle foreign
> systems, but I want to optimize my own for my special tasks.
"Want" isn't all that relevant here. At some point, you will have to
use a system that isn't yours, and you'll probably have to edit text on
that system. It's highly likely that vim will be there, while your
favorite editor may not be.
>> ? If the tasks are complex, you learn the interface well enough so
>> that you don't have to think about it when you use it.
> Yet you think more about it, than if you had the easiest possible GUI.
Please explain how you'd do "ls /work/stuff /work/things | sort | uniq >
~/templist && ls /work/junk | grep -f ~/templist" in a GUI. (That's one
way to do "find everything in /work/junk that's also in /work/stuff or
/work/things".)
> There wouldn't be any nuclear reactors if there were no graphical
> monitors and fool-proof (hardware) switches instead of a single
> command line interface.
There were nuclear reactors before *mainframes* were common. Pick a
different example for whatever it was you were trying to say.
>> Driving a car is a fairly complex task, but you don't see many people
>> complaining that there's no fancy GUI for their BMW.
> Because the usual "car system" is almost the most intuitive.
Now I wonder if the first drivers demanded reins and spurs, so the Model
T would be backwards-combatible with the Horse Interface they were used
to.
> Things just should be visual, because that's the way humans think.
Not necessarily; not for all things. Some things benefit from a GUI
more than others. And plain text can be grepped, while image files
can't be.
> Say you want to evaluate items and order them. With only a few items
> you look once, get an overall impression and know the order. With more
> items you need to resort to typical algorithms.
Of course. This is what scripts are for--reduce the number of things
you need to consider to a screenful or so. Not 7; 7 is the average
"recall" number, while having things displayed on a screen allows people
to use recognition instead of recall. People can recognize many more
than 7 things at one time.
>> When your command lines become too complex for you to remember how to
>> compose one of them, you write a script that contains that command
>> line (or lines) and invoke that script.
> That's OK for speed. What I have to do is to deal with (a moderate)
> amount of data files. Then it helps a lot if there are visual previews
> and I can click on them instead of looking up filenames.
This may be doable with Konqueror; if you set it to "icon view", it
displays previews for many image file formats. Drag the file you want
onto a shell script or executable, and the script gets that filename in
its first argument.
> Also seeing the files you use can never be a disadvantage.
Yes. Yes it can. ("Never" is a dangerous word; you don't know what
other people's workloads are like.) If I have 20,000 files to process,
I sure as hell don't want to have to look at a preview of each one
before processing it.
> I have datafiles. They can be added (many input, one output),
> subtracted, corrected (one input, one output) and plotted (many input,
> gnuplot output). Single data lines in the file can also be input
> parameters for other procedures. Looking at the raw data in an editor
> is not impossible, but inconvenient. A spreadsheet like parameter
> overview would help to find data with parameters I want to consider.
This is *still* kind of abstract. Ah well. If I were you, I'd specify
the problem more fully, figure out exactly what it was that I wanted to
do, then cobble together an interface in Gtk2::Perl or Python with GTK+
or something like that.
> I've written simple command line perl scripts, but they need
> optimization for the best infrastructure.
The First Rule of Program Optimization:
Don't do it.
The Second Rule of Program Optimization (for experts only!):
Don't do it yet.
Premature optimization is the root of all evil.
--D. E. Knuth
...in other words, don't bother optimizing your stuff until it for sure
works. Typically, you do this:
0. Make it work
1. Make it maintainable
2. Make it fast (optional!)
>> Computers aren't very smart, and you may wish to look at the Jargon
>> File's entry for "DWIM" to see some of the pitfalls inherent in
> I meant offering choices (e.g. checkboxes, choice lists).
OK. Yeah, that's appropriate. The DWIM entry is amusing though....
> future A.I. could offer commands where you can chose from if one of
> them suits your needs.
I wouldn't hold my breath--Minsky said we'd have strong AI by the late
1980s, after all. Strong AI, like practical fusion power, is always 30
years away.
Anyway--you said you wanted to learn Python earlier. So: Google "Python
tutorial", after you work your way through that, look up the
documentation on Python's GTK+ or WxWidgets or Qt bindings. Then you
can build Python scripts with GUIs. Then you can build an interface
that does what you need. Half the battle is figuring out what you need
in the first place.
Building an "intuitive interface" is harder than you may think--I've
done some interface work on a couple of commercial programs, and the
users didn't like some things that should've been easy for them to grok.
Well, they kept saying "Make feature N work like Photoshop!" when the
program that had feature N did totally different things from the things
Photoshop did. *shrug*.
-- Matt G|There is no Darkness in Eternity/But only Light too dim for us to see Brainbench MVP for Linux Admin / mail: TRAP + SPAN don't belong http://www.brainbench.com / -----------------------------/ This space sort of for rent.
- Next message: Alan Connor: "Correction: Re: CLI: Creating and Navigating the Dirextory Stack"
- Previous message: Peter T. Breuer: "Re: ten buck fedora"
- In reply to: Anton Suchaneck: "Re: Easiest/quickest method for very simple interfaces?"
- Next in thread: Anton Suchaneck: "Re: Easiest/quickest method for very simple interfaces?"
- Reply: Anton Suchaneck: "Re: Easiest/quickest method for very simple interfaces?"
- Reply: Lee Sau Dan: "Re: Easiest/quickest method for very simple interfaces?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|