Skip navigation.

GUI for (shell-)script languages

GTK
GTK

For a long time I wanted to have access to GUI widgets while using shell scripts. I wanted to have something for Linux, similar to "dtksh" on CDE. The Gimp Toolkit was the best looking choice to me.

So my goal was to think of a way which enabled GUI access for multiple script languages. It had to be flexible, extendable, it had to give access to GTK 1.x and 2.x, and it had to be a feasable project. Finally I did not want to investigate other people's sourcecode to implement extra GUI commands.

The concept of a GTK server was born. The basic idea behind this concept is a binary, which can be started from within a script. The script has to communicate with this binary by using 2-way pipes (stdin/stdout) or by using sockets (tcp). The script sends original GTK commands as plain text to the pipe or the socket, and the gtk-server sends information back which must be captured by the script.

A problem was the callback mechanism. The GTK-SERVER has to keep track of callback signals. Right now, every time a widget is created, one callback signal per widget can be realized.

Another problem was the variable GTK function name. How to look up a GTK function whose name is held in an array of chars? And if this function was found, how to handle the variable amount of arguments, each of which may have a different type? This is where the configfile comes in. In the configfile the user has to describe the name of the function, the callbacksignal, the returnvalue, the amount of arguments and the type for each argument.

You can find the GTK-server here. Both Linux as Windows are supported.

My site includes demo script programs, precompiled GTK-server binaries as well as the sourcecode. I hope somebody of the GTK community find my efforts useful.

Cheers

Peter.

Re: Needed: a revolution in shell scripting

Bourne shell syntax meets the need for both interactive entering of commands and lightweight scripting needs. Remember, programs are much bigger now than the used to be, and things that Perl or Python bring to the party just weren't needed for a command language 30 years ago.

Also, if you look at most short scripts, they require less typing (characters) in bourne shell than either perl or python. Naturally, if you require data structures or system programming ability, shell is the wrong choice. But I still use it for most of my unix scripting, just because it's damn convenient.

And also, if you like perl so much, noone prevents you from using it! ;-) I see diverity as a strength, not a weakness.