User login

Navigation

Contribute

Interested in contributing to FootNotes? Click here to submit news stories to us or visit this site for more information about available opportunities.

GNOME Support

Friends of GNOME

Now's a good time to say thanks for the best desktop environment on the planet by becoming a Friend of GNOME or by upping your current Friends level. Contribute by joining the Friends of GNOME program. All contributions are tax-deductible in the U.S. Thanks to our generous Friends

Links of Interest

Syndicate

Online users:

omarlenovo

GUI for (shell-)script languages

Submitted by pjot on Fri, 2003-12-19 01:53. 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

Submitted by tbf on Sat, 2003-12-20 19:40.

why does ant suck

Because dependency resolution doesn't work properly. Since it force you to write your build script in an imperative way - instead of the nice declarative way make shows. If you try mimic some sane dependency-resolving with ant you'll end up with zillions of subtargets the users of IDEs like Ecllipse and NetBeans complain about or you end up with writing needless bloaty custom tasks. -- A poor replacement for the cleaness of make.

Ok, there are issues with make. Mainly three:

The compared with GNU make poor implementations shipped with legacy Unices.
Microsoft Window's inability to deal with make due it's default shell's insane (non existent) command line expansion and double-quotes-arround-paths handling. (IHMO the only reason for using something like Ant or NAnt).
This clueless majority of wannabe[?] programmers who don't realize the declarative nature of make. Yes, those who try to use make as imperative shell replacement and then wonder that they fail. Even worse: Those clueless people don't even have enough clue to realize their own faults to be the problem here. Hint: If the shell-part of one of your make rules takes more than one statement - ok, let's be lax and say three statements - then you definity are doing something dramatically wrong.

» parent