Front-end builder?

Forum: Programming and Scripting
Topic: Front-end builder?
started by: the Missing M

Posted by the Missing M on 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.

Posted by mikshaw on May 21 2007,17:39

DSL includes the Whiptail program, which is basically a smaller version of Dialog with fewer features. This provides a way to create a keyboard-driven interface within shell scripts that can be used either in the Linux console or an x terminal. An example of its use in DSL is xsetup.sh

Most of the DSL-specific gui tools were created by Robert using murgaLua. This is essentially a version of Lua which includes FLTK widgets and a few other features. With murgaLua you can create "normal" text-based Lua scripts, as well as X-based FLTK interfaces that are controlled by Lua.
The official murgaLua release includes Fluid, which is a graphical tool used to create FLTK interfaces, and a lua script that converts the C++ output of Fluid into a Lua script that can be interpreted by murgaLua.
< http://www.murga-projects.com/murgaLua/index.html >

Posted by lucky13 on May 22 2007,13:37

You can also get vtcl from the repository (UCI, iirc). I've scripted together various boxes to manage frequently used commands, etc. I add text boxes to some of them (see the second link below) so I can get output directed to them to check status of whatever's running. Here are a couple examples of what I've done to manage network connections and daemons:

Here's the lua4 (DSL 2.1b) version of my wireless "tool":
< http://lucky13.blogsavy.com/madwifi-tool/ >

And here's another one I made with vtcl that includes controls for net daemons (prettier than "packing" widgets in regular tcl):
< http://lucky13.blogsavy.com/dsl-network-tool/ >

I'm just starting to dabble with murgalua (for another project), but I find it a fairly easy transition from lua4 and its bindings.

Posted by the Missing M on May 27 2007,12:14

Oooh, shiny buttons! Thanks, I think I just found a new hobby. ;-)

Seriously, thanks. The more I looked, the more I wondered how could there *not* be something like this already? Turns out there was.

I also noticed the thank-you note to you, for coming up with some example apps early on. Did you put together the example windows in those screenshots? Looks like they were taken on a machine running WinXP, but that doesn't necessarily mean they were writen on one.

Quote (mikshaw @ May 21 2007,06:39)

DSL includes the Whiptail program, which is basically a smaller version of Dialog with fewer features.

Really? I thought Whiptail had a few enhancements. Seemed to run a little smoother here, anyway. Sysvconfig depends on Dialog though, so I ended up with both.

Quote

This provides a way to create a keyboard-driven interface within shell scripts that can be used either in the Linux console or an x terminal. An example of its use in DSL is xsetup.sh

Yeah, I didn't realize that was Lua, but use it fairly regularly, because the framebuffer wants to use 1024x768, while the screen only supports 800x600. [This isn't as bad as my first try installing Xubuntu though; in DSL, some of the `screen' spills off-screen until you fix that, but Xubuntu's X server couldn't even start properly, until I brought the max resolution down to 16-bit 800x600.]

Hold on... No, I'm thinking of Xvesa setup, one of the items referenced from DSL Setup. *That's* Lua, right? The xsetup Q&A thing only starts up if I specify `vga=788' as a boot option, which I usually don't.

Quote

< http://www.murga-projects.com/murgaLua/index.html >

Thanks again,

Patrick.

Posted by the Missing M on May 27 2007,12:32

Quote (lucky13 @ May 22 2007,02:37)

[...]
Here are a couple examples of what I've done to manage network connections and daemons:

Here's the lua4 (DSL 2.1b) version of my wireless "tool":
< http://lucky13.blogsavy.com/madwifi-tool/ >

See, there's a great example of ths kind of thing I'd want to do. Thanks for showing me that.

Quote

And here's another one I made with vtcl that includes controls for net daemons (prettier than "packing" widgets in regular tcl):
< http://lucky13.blogsavy.com/dsl-network-tool/ >

Well, if you're seeking enlightenment, you might want to have a look at pyChing, an adaptation of the I Ching which also uses tcl/tk to put a visual interface in front of Python. Might be too much script there to parse out any useful tcl examples from it, but it is a very nice little program. :-)

Unfortunately, its list of dependancies might make for a not-so-little download, depending how much Python you've already got installed.

In any case...

Happy hacking,

Patrick.

Posted by mikshaw on May 27 2007,14:20

Quote

the more I wondered how could there *not* be something like this already?

There actually was already a similar tool in DSL, named Lua-FLTK. Unfortunately it was apparently a one-shot project that was created six years ago and never updated. MurgaLua, on the other hand, is active and is already quite far beyond what Lua-FLTK was..

Quote

Did you put together the example windows in those screenshots?

No. Shortly after murgaLua was released and added to DSL I just started messing around with it and posting the tests here. I guess since there weren't many existing murgaLua demos at the time, some of what I came up with ended up being added to the package. I've never experimented with it outside of Linux, but I assume that as long as you don't depend on os-specific applications the scripts should be portable [for example, use os.date() rather than os.execute("date")]. I'm not sure about how line breaks are handled, though. You may need to use a lot of semicolons =o)

Quote

Yeah, I didn't realize that was Lua

It isn't Lua. Whiptail is a self-contained application which is independent of the shell, so it could be used with Lua, or Bash, or Perl, or whatever. It's simply a way to create menus and buttons in a console/xterm, from a script, without the need to program with ncurses.

Quote

No, I'm thinking of Xvesa setup, one of the items referenced from DSL Setup. *That's* Lua, right?

Correct. Or more specifically, it's Lua and FLTK...Lua being the language that does all the work, and FLTK being the buttons.

Posted by roberts on May 27 2007,19:45

I have tried to remember to name all my Lua/Fltk stuff with the suffix of .lua. So a simple find command should give you many many examples. Most all of which date prior to murgaLua and have been converted. The whole idea to adopt Lua/Fltk was to provide a simple GUI frontend to command line programs. I wanted something that provided more than Dialog / Whiptail.

Last time I counted, DSL has over 55 Lua Lua/Fltk programs.