Easiest/quickest method for very simple interfaces?
Anton Suchaneck
What can you recommend for simple/fast interface programming? The main
purpose is merely to run bash scripts and type in some input conveniently
(I could display files with external editors and so on...).
I don't want to learn too much stuff, but I'll probably learn python anyway.
Anton
No_One
Well, not sure this is what you want, however, you can try the dialog and
Xdialog programs...Xdialog uses the gtk library
Very simple to use....
Sample dialog script.............Xdialog is almost the same.
=======================================
#! /bin/sh
# Create a user unique lockfile
DIALOGRC=/etc/dialogrcpi
export DIALOGRC
touch /tmp/`whoami`
MENU=/tmp/`whoami`
# Function to prevent the shell from exiting after execution
do_wait() {
echo -n "[Return]"
read R
}
# Create the main GUI
dialog --title "PIM Menuing System" \
--backtitle \
" ** PIM ** | User: `whoami` | TTY: `tty` | `date "+%a %D"`" \
--menu " " 15 40 8 \
"Find Numbers" "Search" \
"Edit Phone Bk" "Edit and Add" \
=========================
ken
Chris F.A. Johnson
> Hi!
>
> What can you recommend for simple/fast interface programming? The main
> purpose is merely to run bash scripts and type in some input conveniently
> (I could display files with external editors and so on...).
The bash shell is excellent for simple (and even quite complex)
user interfaces.
printf "\n\n"
read -ep "Please enter your name: " name
printf "\nThank you, %s\n\n" "$name"
sleep 1
printf "Now please choose one of the following commands:\n"
printf "\t%d. %s\n" 1 date 2 who 3 cal
read -sn1 -p "Select 1, 2, or 3: " sel
echo
case $sel in
1) date ;;
2) who ;;
3) cal ;;
esac
For using the mouse with a shell script, see my article at
UnixReview.com.
--
Chris F.A. Johnson <http://cfaj.freeshell.org>
==================================================================
Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress
<http://www.torfree.net/~chris/books/cfaj/ssr.html>
zen...@highstream.net
wrote:
Perl/Tk
This is just a super simple example. You can change colors,
automatically execute what you want. Make a button to save
the output to a log file, etc, etc. Check out
comp.lang.perl.tk
and google for many free examples.
#!/usr/bin/perl
use warnings;
use strict;
use Tk;
use Tk::ExecuteCommand;
my $mw = MainWindow->new;
my $ec_dir = $mw->ExecuteCommand(
-command => 'dir; sleep 10; dir;',
-entryWidth => 50,
-height => 10,
-label => '',
-text => 'Execute dir ',
)->pack;
my $ec_date = $mw->ExecuteCommand(
-command => 'date; sleep 10; date;',
-entryWidth => 50,
-height => 10,
-label => '',
-text => 'Execute date ',
)->pack;
my $dir_but = $mw->Button(
-text => 'Execute dir',
-background => 'hotpink',
-command => sub{ $ec_dir->execute_command })->pack;
my $date_but = $mw->Button(
-text => 'Execute date',
-background => 'lightgreen',
-command => sub{ $ec_date->execute_command })->pack;
MainLoop;
__END__
--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
Grant Edwards
Do you want text-mode or GUI?
--
Grant Edwards grante Yow! I'm having an
at emotional outburst!!
visi.com
Anton Suchaneck
>> purpose is merely to run bash scripts and type in some input conveniently
>> (I could display files with external editors and so on...).
>> I don't want to learn too much stuff, but I'll probably learn python
>> anyway.
> Do you want text-mode or GUI?
It's much more motivating to work when the tools are fancy.
I've found many libraries myself, but I don't have time to learn them all.
Anywhere I can find a comparative review? Anyone has experience with
different methods/libraries?
Anton
Grant Edwards
If you want something that you can use from shell scripts,
xdialog is a drop-in replacement for dialog: http://xdialog.dyns.net/.
For quick, easy, and portable small applications I recommend
Python with Tk: http://www.python.org/doc/life-preserver/.
Python and Tk are pretty much universally installed on Linux
platforms.
Tiny apps are even simpler in Tcl/Tk, but Tcl is a really lousy
language for general-purpose programming. IMO, once you get
beyond 5-10 lines of Tcl code, you've got a mess and you're
better off with Python.
If you can tolerate something more complex, Python with
WxWidgets is also portable and you get a more native look and
feel (GTK under Linux). There are also Qt, GTK, and Fltk
bindings for Python.
--
Grant Edwards grante Yow! It's NO USE... I've
at gone to "CLUB MED"!!
visi.com
Dances With Crows
into the Black Sun and said:
> On Thu, 07 Jul 2005 13:53:39 +0200, Anton Suchaneck
> <asuch...@web.de> wrote:
>>What can you recommend for simple/fast interface programming? The main
>>purpose is merely to run bash scripts and type in some input
>>conveniently (I could display files with external editors and so
>>on...). I don't want to learn too much stuff, but I'll probably learn
>>python anyway.
Er... if you want to use Python well, you will probably have to learn
"too much stuff". Oh well, Python has a lot of bindings to GUI things,
including Tk and GTK+ and Qt.
> Perl/Tk. This is just a super simple example. You can change colors,
> automatically execute what you want.
[snip example]
I don't know that this example is that good. The Tk::ExecuteCommand
module had no ebuild, so I had to manually install it. I'm comfortable
with that, but Anton might not be. Also, the Tk widgets are ugly and
they don't look like GTK+ or Qt widgets. The only way I'd use Tk
widgets for a GUI app is if the only other choices were Athena and
Motif.
I recently learned how to use the Gtk2::Perl module, which does lots of
GUI stuff fairly easily and looks better than Tk. The main problems
that Anton might have with Gtk2::Perl are that A) it's not Python B) the
English tutorial for it is missing a bunch of stuff. The French
tutorial is more complete--quelle surprise.
The work I did with Gtk2::Perl is sitting on
http://crow202.dyndns.org/~mhgraham/cdburnbox-0.5.tar.gz , not quite
finished but it does work for the most part and has lots of comments and
stuff in it. (The CD-RW in the machine we're using for a testbed had a
mechanical failure sometime yesterday though. @#$%^.)
--
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.
Anton Suchaneck
>>>purpose is merely to run bash scripts and type in some input
>>>conveniently (I could display files with external editors and so
>>>on...). I don't want to learn too much stuff, but I'll probably learn
>>>python anyway.
>
> Er... if you want to use Python well, you will probably have to learn
> "too much stuff". Oh well, Python has a lot of bindings to GUI things,
> including Tk and GTK+ and Qt.
sure which of these bindings is easiest to learn and shortest to type.
For the easiest tasks surely xdialog will suffice.
>> The main problems
>> that Anton might have with Gtk2::Perl are that A) it's not Python
I've also had a look at Perl to deal with ASCII data I have.
It's just that I prefer to stick to one system (and I will need Python
sooner or later) or I will forget the others when not using it. Learning a
new programming system is a peace of cake, but remembering isn't for me :)
And my cheat sheets always turn out to be incomplete...
Anton
Grant Edwards
>> Er... if you want to use Python well, you will probably have
>> to learn "too much stuff". Oh well, Python has a lot of
>> bindings to GUI things, including Tk and GTK+ and Qt.
>
> I need to learn Python anyway to do some scientific
> programming. Now I'm not sure which of these bindings is
> easiest to learn and shortest to type.
Tk is probably the simplest to learn and the least verbose for
simple things.
Gtk is a bit more "low level" than Tk, and takes a more work to
get things done. WxWidgets is considerably more complex than
Tk with completely separate parentage and sizing hierarchies.
However, there are GUI "designers" that work with Wx and Gtk
and hide some of the complexity.
I've never used Qt, so can't comment on it.
> For the easiest tasks surely xdialog will suffice.
> I've also had a look at Perl to deal with ASCII data I have.
Using Perl makes you go blind. Or at least wish you had. ;)
> It's just that I prefer to stick to one system (and I will
> need Python sooner or later) or I will forget the others when
> not using it. Learning a new programming system is a peace of
> cake, but remembering isn't for me :) And my cheat sheets
> always turn out to be incomplete...
--
Grant Edwards grante Yow! Who wants some
at OYSTERS with SEN-SEN an'
visi.com COOL WHIP?
John Hasler
> If you want something that you can use from shell scripts, xdialog is a
> drop-in replacement for dialog: http://xdialog.dyns.net/.
It claims to be, but it keeps breaking compatibility.
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
Michael Heiming
> Hi!
Do yourself a big favor, open some xterm use it and learn vi(m)
the basics are easy enough and you'll never regret it. Vi should
be installed per default on any *nix system you happen to login.
The enhanced Vi (vim) used by Linux has syntax high-lightning and
other features that come in handy.;)
Good luck
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 158: Defunct processes
Anton Suchaneck
> the basics are easy enough and you'll never regret it.
When the actual tasks are very complex, you cannot afford to spend any
thought on handling the interface. As trivial as it might seem, but any new
thought shoves out another, so I don't want to think of what to do next and
how to enter the command. I need the computer to suggest how to proceed.
For example by offering choices.
Unintuitive interfaces are probably a big source of human error.
Anton
Dances With Crows
Black Sun and said:
> Michael Heiming wrote:
[ Anton said he wants to create GUI frontends to start some shell
scripts, capture their output, display it, and so forth. ]
>> Do yourself a big favor, open some xterm, use it, and learn vi(m)--
>> the basics are easy enough and you'll never regret it.
Michael speaks truth here wrt vim. vim (or its less-capable ancestor
vi) is on every Unix-like system. If you know the basics of vim, you
can edit text anywhere, which can be Really Useful.
> When the actual tasks are very complex, you cannot afford to spend any
> thought on handling the interface.
? 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. 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.
> As trivial as it might seem, but any new thought shoves out another,
> so I don't want to think of what to do next and how to enter the
> command.
Any new thought shoves out anoth... oh look, a puppy!
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. I'd guess you've already done some
of that, but the real key is to figure out which operations usually
follow one another and invoke those operations automatically.
Specifics on what it is that you want to do might help people assist
you--things like "I want to look for files named FOO in directories BAZ
and BARF, and take action QUUX if those files exist in BAZ but not
BARF..." Most of what you've said so far is really abstract. With
computers, Details Count, and specific examples are really useful.
> I need the computer to suggest how to proceed. For example by
> offering choices.
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 having a
machine try to figure out what it is that you're trying to do.
> Unintuitive interfaces are probably a big source of human error.
s/Unintuitive interfaces/Uneducated users/ . It doesn't matter how
intuitive the interface is if the user doesn't know what to do with it.
John Hasler
> It doesn't matter how intuitive the interface is if the user doesn't know
> what to do with it.
It would if there were any intuitive computer interfaces. There aren't.
Anton Suchaneck
> vi) is on every Unix-like system. If you know the basics of vim, you
> can edit text anywhere, which can be Really Useful.
systems, but I want to optimize my own for my special tasks.
>> When the actual tasks are very complex, you cannot afford to spend any
>> thought on handling the interface.
> ? 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.
wouldn't be any nuclear reactors if there were no graphical monitors and
fool-proof (hardware) switches instead of a single command line interface.
> 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.
you need Windows style OK-Buttons. Things just should be visual, because
that's the way humans think.
>> As trivial as it might seem, but any new thought shoves out another,
>> so I don't want to think of what to do next and how to enter the
>> command.
> Any new thought shoves out anoth... oh look, a puppy!
limited amount of items at once. 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.
> 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.
of data files. Then it helps a lot if there are visual previews and I can
click on them instead of looking up filenames. Also seeing the files you
use can never be a disadvantage.
> Specifics on what it is that you want to do might help people assist
> you
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.
I've written simple command line perl scripts, but they need optimization
for the best infrastructure. As always in programming...
>> I need the computer to suggest how to proceed. For example by
>> offering choices.
> 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 having a
> machine try to figure out what it is that you're trying to do.
I meant offering choices (e.g. checkboxes, choice lists). In the future A.I.
could offer commands where you can chose from if one of them suits your
needs.
Automated reinterpretation would be Windows programs which have those
hidden, terribly annoying autocorrect "features" I've always hated.
>> Unintuitive interfaces are probably a big source of human error.
> s/Unintuitive interfaces/Uneducated users/ . It doesn't matter how
> intuitive the interface is if the user doesn't know what to do with it.
I don't object. Let's agree on that you need both: Educated users and
intuitive interfaces.
Anton
Dances With Crows
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*.
Anton Suchaneck
>>> 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.
on computer administration.
> Please explain how you'd do "ls /work/stuff /work/things | sort | uniq >
> ~/templist && ls /work/junk | grep -f ~/templist" in a GUI.
a try:
In my visual approach you open "stuff" and "things" (hotkey, type, click,...
whatever you like). You mark all files and add them to a (predefined?) data
buffer. All can be done by hotkeys. These are pretty standard tasks. "Junk"
goes into buffer 2. In Buffer 3 you type the appropriate Boolean operation
on B1.name and B2.name. One key for the buffer number, one for the name
entry. The Boolean operation could be displayed as a tree before being
evaluated.
I believe the computer system should be brought up to date with current PC
speed and visual features.
> There were nuclear reactors before *mainframes* were common. Pick a
> different example for whatever it was you were trying to say.
The reactor did not have a single terminal in a dark room with a command
line, where you had to type "cat /dev/temperature". There were flashy LEDs,
switches and digital displays for easier handling.
>> 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.
Why would they want to? The system was improved. Forget
backwards-compatibility.
>> 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.
But people imagine files as some sort of object and not a sequence of
letters, that you get when you type "cat <file>". Showing it in a file
explorer is intuitive.
And of course all data, text or image, keeps its data character in order to
be processed.
>> 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.
Writing scripts and giving names to all of them would still be an ugly
solution for my current tasks. I'd have to think which scripts filter what.
There is a reason why people create flowcharts, UML-diagrams (or whatever
they're called) and so on. Also programming is very error prone. A decent
visual approach could help a lot.
>>> 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.
> This may be doable with Konqueror; if you set it to "icon view", it
> displays previews for many image file formats.
I need a proper parameter preview. Otherwise I have to open the file, copy
the needed line or even decompose it for further evaluation. It should be
like a table of parameters and maybe preview pictures.
>> 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
So in my case I don't have so many. And speed limitation is not a fact I'm
considering at the moment.
> 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.
That the thing I'm not sure about. What's the interface that is quickest to
program if I have a single window GUI with only a few buttons. However I'd
be thankful for nice predefined table objects and methods to display
images.
>> I've written simple command line perl scripts, but they need
>> optimization for the best infrastructure.
> ...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!)
That's what I did. It works. Now I want to add features and I notice the
hacks should be made more maintainable to easier extension. I also notice
that working at an actual research reactor is stressful enough so that I
need all my concentration to interpret incoming data.
>> 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.
It doesn't have to be too strong. Offering more sophisticated word
continuation or automatic suggestion for macros would be a good start for
editors.
> look up the
> documentation on Python's GTK+ or WxWidgets or Qt bindings.
I just wanted an opinion on which of these (or any other) is best.
Tcl, PerlTk,...?
> Building an "intuitive interface" is harder than you may think
I'll give it a go and learn.
Anton
CBFalconer
>
... snip ...
> > years away.
> It doesn't have to be too strong. Offering more sophisticated word
> continuation or automatic suggestion for macros would be a good start for
> editors.
> > look up the
> > documentation on Python's GTK+ or WxWidgets or Qt bindings.
> I just wanted an opinion on which of these (or any other) is best.
> Tcl, PerlTk,...?
> > Building an "intuitive interface" is harder than you may think
> I'll give it a go and learn.
What a mess. Blank lines work fairly well to separate paragraphs,
and to separate your comments from the quotations. Totally
illegible as it is.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Dances With Crows
Black Sun and said:
>>>> 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.
> That's not the point. My aim now is to handle my data and not to
> specialize on computer administration.
Whatever. You will probably find out what I mean later.[0]
>> Please explain how you'd do "ls /work/stuff /work/things | sort |
>> uniq > ~/templist && ls /work/junk | grep -f ~/templist" in a GUI.
Hmm, maybe I should've said "in a GUI that exists right now".
> In my visual approach you open "stuff" and "things" (hotkey, type,
> click,... whatever you like). You mark all files and add them to a
> (predefined?) data buffer. All can be done by hotkeys. These are
> pretty standard tasks. "Junk" goes into buffer 2.
This is all pretty doable.
> In Buffer 3 you type the appropriate Boolean operation on B1.name and
> B2.name. One key for the buffer number, one for the name entry. The
> Boolean operation could be displayed as a tree before being evaluated.
What, specifically, implements the things you described? You've come up
short on specifics in almost every message you've posted--this is
something you need to work on. I don't know why you're dragging trees
into this, either.
I picked the example that I described because it was something that I
could figure out how to do from the command line and *couldn't* figure
out how to do from any currently-existing GUI. It's possible that no
good GUI method exists right now.
>>> 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.
> But people imagine files as some sort of object and not a sequence of
> letters
That depends on the file. All files have a definite beginning and a
definite ending, and between those points, there are bytes. The
standard C library's functions are sort of based on that assumption.
"Forks" and "alternate file streams" are system-specific, and not to be
relied upon--there's a reason why most Windows programs don't use
alternate file streams, and all MacOS < X programs are distributed as
Stuffit or Binhex format on the Net. It is often *very* useful to be
able to dump those raw bytes out with cat or od or vim or whatever.
> There is a reason why people create flowcharts, UML-diagrams (or
> whatever they're called) and so on. Also programming is very error
> prone. A decent visual approach could help a lot.
Heh. Programming is error-prone no matter what you do. Some UML
monkeys got loose in some code that my co-workers had to deal with, and
they had a *very* hard time dealing with the resulting mess. Flowcharts
in their stereotypical form got shot to shit by the advent of
event-driven programming (which almost all GUI programs use in some
way.)
>> 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.
> That the thing I'm not sure about. What's the interface that is
> quickest to program if I have a single window GUI with only a few
> buttons?
Pick the language you know best. Pick any widget set. Personally, I'd
use Gtk2::Perl for this, but that's just because I like Perl and I have
some experience with its Gtk2 bindings.
> However I'd be thankful for nice predefined table objects and methods
> to display images.
This is where you have to read the documentation for the widget set you
decide on. Every set has functions for loading images and displaying
them. I don't know what exactly you want your "table objects" to do,
but Gtk2::SimpleList can be used to construct multi-columned lists that
contain text, icons, checkboxes, and all kinds of things. Other widget
sets may make this task harder or easier; it all depends on what you
want.
>> 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.
> It doesn't have to be too strong. Offering more sophisticated word
> continuation or automatic suggestion for macros would be a good start
> for editors.
This is totally orthogonal to the main question you asked, but I think
it's got limited utility right now. "Computers are fast, accurate, and
stupid; humans are slow, inaccurate, and brilliant--together, they are
unbeatable." In your programs, make the computer do the boring,
repetitive stuff, and let the human make the decisions that require
intelligence.
> I just wanted an opinion on which of these (or any other) is best.
> Tcl, PerlTk,...?
Look upthread; another poster said that Tcl was a total PITA if you had
to write more than 1 screenful of it. I mentioned upthread that Tk
widgets are ugly--though I don't know for sure if they're easier or
harder to develop with than Gtk2 widgets. It *is* possible to do almost
anything with Gtk2 or Qt widgets, which may not be the case for other
widget sets. You should try a couple of them in whichever language you
prefer, just to see how you like them.
>> Building an "intuitive interface" is harder than you may think
> I'll give it a go and learn.
Good luck, then. I find that if I build a complex GUI, it makes perfect
sense to me, but confuses other people. If I build a simple GUI,
everybody understands it. Whatever you end up doing will have to be
driven by whatever your users want. HTH,
[0] Experience keeps a costly school, but there are those who will learn
in no other.
Chris F.A. Johnson
> I handle my data on my computer and it doesn't have
> to work anywhere else.
That's a very short-sighted attitude. You never know when you
might need to change to a different distro, different hardware,
different X server, or even a different operating system. (In the
unlikely event that SCO wins its suit against IBM, you might find
yourself using *BSD.)
On one of my first UNIX projects, I made the mistake of
hard-coding things that should have been programmed portably. I
rationalized it by telling myself that this was a very specialized
application that would never need to run under a different
environment. A little while later, the client switched to
incompatible hardware, and I had to convert everything. If it had
been done properly (i.e., protably), nothing would have had to be
changed.
Anton Suchaneck
>> B2.name. One key for the buffer number, one for the name entry. The
>> Boolean operation could be displayed as a tree before being evaluated.
> What, specifically, implements the things you described?
computer in the world and being backward-compatible to the earliest
programs. I want to equip my own computer with tools to deal with certain
tasks in a modern way. I handle my data on my computer and it doesn't have
to work anywhere else.
>> But people imagine files as some sort of object and not a sequence of
>> letters
> That depends on the file. All files have a definite beginning and a
> definite ending, and between those points, there are bytes.
OK, I'm talking about ordinary files in the filesystem.
>> There is a reason why people create flowcharts, UML-diagrams (or
>> whatever they're called) and so on. Also programming is very error
>> prone. A decent visual approach could help a lot.
> Heh. Programming is error-prone no matter what you do. Some UML
> monkeys got loose in some code that my co-workers had to deal with, and
> they had a *very* hard time dealing with the resulting mess. Flowcharts
> in their stereotypical form got shot to shit by the advent of
> event-driven programming (which almost all GUI programs use in some
> way.)
Of course these methods are not to be applied thoughtlessly to just any
problem. They do their job when appropriate and I'm sure there are enough
application where these visual aids make life easier.
> Pick the language you know best. Pick any widget set. Personally, I'd
> use Gtk2::Perl for this, but that's just because I like Perl and I have
> some experience with its Gtk2 bindings.
I haven't programmed for a while and learning any new language would be
fine. For these simple problems experience is not that crucial. Gtk
bindings are said to be too low-level.
>> However I'd be thankful for nice predefined table objects and methods
>> to display images.
> This is where you have to read the documentation for the widget set you
> decide on.
I wanted to avoid reading all the documentation to decide which one to learn
finally. Of course I'll dive into that stuff once I've decided.
> "Computers are fast, accurate, and
> stupid; humans are slow, inaccurate, and brilliant--together, they are
> unbeatable."
That's a bit simplified. Humans can be faster when their brain structure is
superior to normal processors. I can't think of a good example, but maybe
the game "Go" is one. Obviously redesigning ordinary processors would
change that.
Stupidity for computers is relative. Computers are as smart as you are able
to make them. One day someone will find out a pattern how the brain
processes music and he will create a computer program to create "perfect
songs" which will beat any mortal composer. Then composing songs will be
defined as a primitive task.
>> I just wanted an opinion on which of these (or any other) is best.
>> Tcl, PerlTk,...?
> Look upthread
I saw that. That was a very good post.
> You should try a couple of them in whichever language you
> prefer, just to see how you like them.
I believe not to have such a strong programming language taste, so that
other peoples opinion would do for me.
>>> Building an "intuitive interface" is harder than you may think
>> I'll give it a go and learn.
> Good luck, then. I find that if I build a complex GUI, it makes perfect
> sense to me, but confuses other people.
Not a problem in my case, because I'm the only user (and anyone else who
likes the interface)
Dances With Crows
Black Sun and said:
> Dances With Crows wrote:
>> Anton Suchaneck wrote:
[ I asked Anton how he'd do "ls /stuff /things | sort | uniq >
~/list.txt && ls /junk | grep -f ~/list.txt" in a GUI. ]
>>> In Buffer 3 you type the appropriate Boolean operation on B1.name
>>> and B2.name. One key for the buffer number, one for the name entry.
>>> The Boolean operation could be displayed as a tree before being
>>> evaluated.
>> What, specifically, implements the things you described?
When someone asks "How do I do N?", it's really bad form to tell them to
use vaporware. If you don't know, say so. If you can't do it, say so.
*Don't* tell them that you can do N with programs that don't exist.
>> Heh. Programming is error-prone no matter what you do.
I stand by this statement, since I've been getting paid to write, test,
and debug code since 2000, and I've seen professional programmers (and
amateur programmers) make hundreds of stupid errors no matter what
methodology they were using. Like Brooks said, there's no silver
bullet.
>> Pick the language you know best. Pick any widget set. Personally,
>> I'd use Gtk2::Perl for this, but that's just because I like Perl and
>> I have some experience with its Gtk2 bindings.
> I haven't programmed for a while and learning any new language would
> be fine.
Pick one, then. You're not going to get very far until you do. You
mentioned Python earlier; that'll work fine. I don't know if there's an
equivalent of the Llama Book for Python, but there are online tutorials
for sure.
> For these simple problems experience is not that crucial.
The vital things are always simple; the simple things are usually harder
than you expect.
> Gtk bindings are said to be too low-level.
One poster said they were "too low-level", which may or may not be true
depending on what you need to do. What you said you wanted to do
(buttons, an image preview, a list) can be done in almost any widget
set. GTK+ can do almost anything, so you have the freedom to expand
what the widgets do as your programs suffer Feature Creep.
Using GTK+ from C/C++ can be annoying; you have to manage your own
memory and deal with type safety and all that. The Perl and Python
bindings remove those particular hassles, and you have to pass fewer
parameters to the functions since the bindings take care of some of them
automagically.
>>> However I'd be thankful for nice predefined table objects and
>>> methods to display images.
>> This is where you have to read the documentation for the widget set
>> you decide on.
> I wanted to avoid reading all the documentation to decide which one to
> learn finally.
Who said anything about "all the documentation"? You typically treat
documentation as a *reference*, not a novel. If you want to know
how FooWidgets treat "table objects" (whatever those are), then you
Google "FooWidgets reference manual" and grep that manual for things
that look promising. Or look at the sample FooWidgets code in the
tutorial section where they display a table.
>> "Computers are fast, accurate, and stupid; humans are slow,
>> inaccurate, and brilliant--together, they are unbeatable."
> That's a bit simplified. Humans can be faster when their brain
> structure is superior to normal processors. I can't think of a good
> example, but maybe the game "Go" is one. Obviously redesigning
> ordinary processors would change that.
Um. Humans are really good at fuzzy pattern-matching, which is really
useful in many real-world problems. Computers aren't currently good at
"fuzzy". I don't know how creating a new CPU would make computers
better at that. If you do, get yourself some funding and build some;
the militaries of various nations would probably be very interested.
> One day someone will find out a pattern how the brain processes music
> and he will create a computer program to create "perfect songs" which
> will beat any mortal composer.
I don't think this would work. Taste in music is one of those insanely
subjective things. ISTR some experiments in using computers to create
songs in the last year; the results got written up at /. , and many of
the commenters said things like "Man, those songs sucked. I'd rather
listen to Ashley Simpson."
> Then composing songs will be defined as a primitive task.
Just like laser printers made calligraphy obsolete and no longer
practiced, right? :-)
> I believe not to have such a strong programming language taste, so
> that other peoples opinion would do for me.
? You must like some languages better than others. Say which languages
you've used in the past, then say which one(s) you liked the best, and
someone will be able to suggest common languages with good GUI widget
bindings that are similar to what you've used before. I'd suggest Perl
or Python, since Perl's ubiquitous and Python's almost everywhere, they
both can be fun to use, and they both have good GUI bindings for several
widget sets.
Anton Suchaneck
> On 2005-07-13, Anton Suchaneck wrote:
>> I handle my data on my computer and it doesn't have
>> to work anywhere else.
> That's a very short-sighted attitude. You never know when you
> might need to change to a different distro, different hardware,
> different X server, or even a different operating system.
But I'm not dealing with hardware issues or other system sensitive stuff.
Recompiliation is very likely going to work. It is very unlikely that I
need to change to a completely different system. This computer works and I
keep it running. I don't understand why people speak of computers getting
obsolete when nothing with them changes. New software might not work, but
the old state remains.
Anton Suchaneck
>>> What, specifically, implements the things you described?
>> It has [yet] to be programmed.
> When someone asks "How do I do N?", it's really bad form to tell them to
> use vaporware.
if you bring that example I explain how I would implement it.
> I stand by this statement, since I've been getting paid to write, test,
> and debug code since 2000, and I've seen professional programmers (and
> amateur programmers) make hundreds of stupid errors no matter what
> methodology they were using.
applied appropriately. So programmers will do 100 mistakes instead of 200.
> Um. Humans are really good at fuzzy pattern-matching, which is really
> useful in many real-world problems. Computers aren't currently good at
> "fuzzy". I don't know how creating a new CPU would make computers
> better at that.
might not replace all human capabilities, but they might beat them on
various new areas.
>> One day someone will find out a pattern how the brain processes music
>> and he will create a computer program to create "perfect songs" which
>> will beat any mortal composer.
> I don't think this would work. Taste in music is one of those insanely
> subjective things.
I believe it is quite possible that the brain learn sounds it hears and
consequently identifies songs it likes in a simple fashion.
I mean the brain evolved for very primitive sound pattern recognition task
at first. Liking certain music is probably a by product of a basic
principle in nature.
> ISTR some experiments in using computers to create
> songs in the last year; the results got written up at /. , and many of
> the commenters said things like "Man, those songs sucked. I'd rather
> listen to Ashley Simpson."
That only means it was unsuccessful in the last years. It would be very
bigheaded of them to claim they've explored every possibility that could
ever be possible to create music. There are many years ahead for mankind.
>> Then composing songs will be defined as a primitive task.
> Just like laser printers made calligraphy obsolete and no longer
> practiced, right? :-)
That's not really the same type of example, because laser printer don't do
better at this. Anyway, it could happen that new generations lose interest
in calligraphy if they do not get told to practice it and then make their
own opinion about it, wondering why one should make things complicating.
There are not many people manufactoring soap manually.
>> I believe not to have such a strong programming language taste, so
>> that other peoples opinion would do for me.
> ? You must like some languages better than others.
Differences are subtle and it is more likely that a nice GUI feature has
more impact on my decision about the programming language. I don't mind
learning either. TCL looks a bit ugly though.
Lee Sau Dan
>> 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.
Anton> Because the usual "car system" is almost the most
Anton> intuitive.
I don't think so. Having to step on padels to "accelerate" and
another to "decelerate" the car isn't intuitive. What's "accelerate"
or "give oil", BTW?
A REALLY intuitive interface for driving a car: I move my legs (like
pedaling a bike) and it moves. I stop my legs and it stops. I pedal
faster and it accelerates. I pedal backwards and it moves backwards.
Neither is the conventional steering wheel intuitive. A joystick may
be better. But why doesn't the car follow my head and eyes, and
automatically steer towards whichever direction I'm looking at?
That you think a car's control is intuitive, is simply due to your
familiarity with it. You've essentially *internalized* it. If you
have come to this level of familiarity with Emacs and bash, you'll
find them the most "intuitive" interfaces, too.
Anton> I'm not saying you need Windows style OK-Buttons. Things
Anton> just should be visual, because that's the way humans think.
No. That's now what we ALWAYS think. We do have the capability to
think visual, and some people do it more often than others. But
that's now the only choice, and some people don't like this choice.
If your thinking is limited to visual only, you can't handle abstract
concepts that cannot be visualized easily. You wouldn't be able to
handle 4-dimension vector spaces. Neither would you be able to do
music!
Anton> I've written simple command line perl scripts, but they
Anton> need optimization for the best infrastructure. As always in
Anton> programming...
Why care about that optimization? One strength of scripting languages
is that they let you solve a problem fast (but dirtily). If you want
elegant designs, use a more appropriate language.
Anton> I meant offering choices (e.g. checkboxes, choice
Anton> lists). In the future A.I. could offer commands where you
Anton> can chose from if one of them suits your needs.
Sci-fi authors have been imagining those things about AI "technology"
for decades. But now, I still see no major breakthrough in AI that
would convince me to believe that what you described above would
happen in the next 50 years. Yes, hardware capabilities have
increased a million times in the past 30 years, but without a
breakthrough approach, I can't see any real hope in AI.
(The situation is similar to battery-powered cars. No breakthroughs
in battery technology in the past decades. We still can't make
extremely small batteries that are light and of high capacity. So,
not much improvements on battery-powered cars throughout the past
decades, and hence still no *practical* products on the market.
Rather, people are now switching the focus to cars powered by
fuel-cells instead of battery cells. That approach is more
promising.)
Anton> >> Automated reinterpretation would be Windows programs
Anton> >> which have those hidden, terribly annoying autocorrect
Anton> >> "features" I've always hated.
Autocorrupt fails to autocorrect "Autocorrect" to "Autocorrupt". :D
--
Lee Sau Dan 李守敦 ~{@nJX6X~}
E-mail: dan...@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
Lee Sau Dan
Dances> ...in other words, don't bother optimizing your stuff
Dances> until it for sure works. Typically, you do this:
Dances> 0. Make it work
Dances> 1. Make it maintainable
Dances> 2. Make it fast (optional!)
I'll change it to "2. Make it fast ENOUGH".
Very often, if you have chosen the correct approach, you'll achieve
(2) automatically.
Dances> Building an "intuitive interface" is harder than you may
Dances> think--
Because the requirement is unclear. There is no definition for what
is "intuitive". In software engineering, the biggest problem is
always _unclear requirement_. If you don't know where your goal is,
how can you ever get there?
Dances> I've done some interface work on a couple of commercial
Dances> programs, and the users didn't like some things that
Dances> should've been easy for them to grok. Well, they kept
Dances> saying "Make feature N work like Photoshop!" when the
Dances> program that had feature N did totally different things
Dances> from the things Photoshop did. *shrug*.
Haha... But that happens quite typically with users. I can't
understand why. It seems that to a typewriter-emulator interface
would be more "intuitive" to have a picture of the top view of an
electrical typewriter, and then let (or force) the users click(!) on
the typewriter keys on the pictures to do the typing. If you let they
use the computer keyboard to type, then they'd call it "unintuitive".
See? Clickable, pretty GUI pictures ==> intuitive.
Using the keyboard ==> unintuitive.
Randomly moving and clicking the mouse ==> intuitive.
Having to use the brain and to type even a single word ==> unintuitive.
That seems to be the logic of users nowadays.
BTW, intuitive != productive. But many users insist that they want
the software to be more intuitive, instead of more productive. Even
in business environments, where the users use the software routinely!
Strange...
Anton
> Anton> intuitive.
>
> I don't think so. Having to step on padels to "accelerate" and
> another to "decelerate" the car isn't intuitive. What's "accelerate"
> or "give oil", BTW?
OK, I wrote that to avoid more discussions on this topic. Of course it's
much more intuitive to point where you want to go and the car does so.
> Anton> I'm not saying you need Windows style OK-Buttons. Things
> Anton> just should be visual, because that's the way humans think.
> If your thinking is limited to visual only, you can't handle abstract
> concepts that cannot be visualized easily. You wouldn't be able to
> handle 4-dimension vector spaces. Neither would you be able to do
> music!
Most thinking is connected with the senses. Mostly visual. Music is the
acoustic sense. Maybe there is also some abstract thinking, but most of
maths is visual. I think of maths in pictures and it worked pretty well at
school with good results and the least notation.
> Anton> I've written simple command line perl scripts, but they
> Anton> need optimization for the best infrastructure. As always in
> Anton> programming...
>
> Why care about that optimization? One strength of scripting languages
> is that they let you solve a problem fast (but dirtily). If you want
> elegant designs, use a more appropriate language.
Design has not that much to do with the language. If I want to extend the
program, a dirty program would require much rewriting.
> Anton> I meant offering choices (e.g. checkboxes, choice
> Anton> lists). In the future A.I. could offer commands where you
> Anton> can chose from if one of them suits your needs.
>
> Sci-fi authors have been imagining those things about AI "technology"
> for decades. But now, I still see no major breakthrough in AI that
> would convince me to believe that what you described above would
> happen in the next 50 years.
It could be very basic approaches. It's doable to write a plug-in for an
editor that scans for frequent words and offers a list in a sidebar. Here I
mean offering choices and not do autocorrection. It really freaks me out
trying to find where to switch off autocorrection in those buggy office
suites.
Anton
adr...@satisoft.com
Best Regards,
=Adrian=