Hi,
> I'm curius to know how to write user-friendly front ends to programs.
> I'm referring to programs like KPakage, GnoRPM, aptitude and dselect and the
> various setup utilities for the Apache server that wrap around a console
> based utility (rpm or dpkg, for example).
aptitude sits on top of the apt library, which does all the talking to
dpkg; dpkg itself has been designed to be called by other programs,
specifically by dselect. dselect, on the other hand, uses the same code
dpkg does.
> How do I design the console based programs?
Think of the console app as a class in the frontend's design. I.e. it
should have a small, clean interface, hide the implementation details
and make sure it is always in a consistent state. If something goes
badly wrong, it should indicate the error in an easily understandable
way (return a nonzero exit code). It should have concurrency locks in
the right places, to avoid multiple simultaneous callers from messing
things up. Input and output channels should either transfer structured
data, be unstructured or let the structured form define an exit to
unstructured mode (and possibly with a transition back). Look at SMTP:
The both sides talk structured command-response, but for actual data it
switches to an unstructured mode, where a single dot switches back. If
you have a structured mode, be sure that you need to enable it
explicitly, and possibly that you can talk it over a separate fd ("gpg
--status-fd" and "dpkg --set-selections" are examples here).
> Should I implement an extensive command line argument interface
> for them?
Having everything as command line options is good, since sometimes
someone may want to call programs from scripts. If your program manages
a lot of state or for some other reasons has significant startup cost,
give it an "interactive" mode with a structured interface so that you
can start one and then talk to it until you are done.
> How do I parse the output produce?
If it's structured, the usual parsing is good. "scanf()", "cin >>",
"split", etc. If the output is unstructured, don't bother parsing, as
output changes with program version and locale. Instead, patch the
program to accept some sort of "--status-fd" switch and make sure the fd
gets flushed often enough or is unbuffered.
> What language is most suitable
> and easiest for writing the user-friendly interface (for instance, Tcl/Tk?
> Python?) ?
Depends. Python and Perl both have a high startup cost, which is
annoying on slower systems (reportbug takes about two minutes for the
"import" statements on my system). On some occasions, I write the
backend in C++ and the frontend in Java, so I can make the frontend an
applet.
In short, it varies. Performance, other than startup time, is seldom an
issue, since the amount of data that the user can perceive is
significantly lower than the amount of data almost any programming
language can handle in a given timeframe.
Simon
--
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
Attachment:
pgpI7ipejUot6.pgp
Description: PGP signature