the Missing M
Group: Members
Posts: 35
Joined: Mar. 2007 |
 |
Posted: May 21 2007,16:54 |
 |
[sigh...] As soon as I got xterm to display a GUI notification dialog from a script, I was hooked...
Anyway, one thing I'd like to see, or write myself if I ever get good at this is a simple, graphical tool for grafting simple, graphical interfaces onto other programs. Kind of like this HTML form isn't the CGI itself, but a fairly straighforward way for the user to interact with it [I mean, you *could* type your Google search terms directly into a URL string, but why?]. Same idea; something like a WYSIWYG HTML editor for the UI, for putting together buttons and dialogs and such.
Maybe there's something like this already, or a few things, and I just don't know about them yet.
I have seen a few examples of a `front-end' coupled with a command-line program that does the actual work; passes command-line parameters down to the `real' application, and displays the results. GProFTPD is one, efax-gtk another; File-Roller and Xarchiver, which don't actually do any archiving themselves... and in some ways this might be a better idea.
Graphical apps tend to be more complicated, require more detailed interaction with other software [X.Org, window managers, etc], and as such tend to be more crash-prone. At least, they seem to generate more noise when started from a terminal; lots of GTK warnings, while at the same time, and on the same system I've never experienced a core-dump with any of the console apps I've used [but okay, maybe I just wasn't trying hard enough...].
So divorcing a [potentially unstable] GUI from the simple, or maybe not-so-simple task itself seems like a good thing. It's also in keeping with the UNIX philosophy of one program, one job, where you group several small tools together to do more interesting things, instead of building one great big monolithic application to do all of it.
BTW I don't necessarily want to slap a GUI over top of the whole systen, because there's really a lot of stuff that works better, and is easier to do from the command line. Don't know if I'd even want to supply `finished' front-ends for any applications; seems like giving people a tool to make their own would be more helpful, in terms of learning how this stuff works. I wouldn't want to hide the underlying `nuts & bolts' of things either, but reveal them in a way that's easier to learn.
It seems that in Linux, you have a command line, *or* graphical interface, and if you use one it won't help you learn anything about the other; very little [visible] cross-over between the two. In fact I've had to override the built-in defaults in a lot of applications, just to make full path-names even show up in the GUI.
But if you put together your own graphical front-end for something, with a checkbox, button, and/or text entry field that corrosponds to some command-line option or other, it would help you learn more about the command line, from the GUI side of things.
Something like that might also come in handy, in DSL and other `stripped-down' distributions, because then you could have one, probably quite small program that supplies a GUI for several command-line programs; parses one of several different display configurations, depending which CLI application it's supposed to be controlling in a given instance.
In some cases it might make the smaller, often more stable CLI program preferable to the graphical version, for stablility *and* ease of use.
Anyway, that's my rant and I'm sticking to it,
Patrick.
--------------
Q: What is the difference between
a joke, and a lie?
A: A lie tends to obscure the truth,
while a joke often reveals it.
|
.
DSL Market ,
Great VPS hosting provided by Tektonic
