[Discuss] tool to make GUI based on shell script

xxx xxx bakshi12 at gmail.com
Thu Nov 8 00:03:22 PST 2007


On Nov 7, 2007 1:17 PM, John Blomfield <jabfield at shaw.ca> wrote:
> xxx xxx wrote:
> > On Nov 6, 2007 10:54 PM, John Blomfield <jabfield at shaw.ca> wrote:
> >
> >> xxx xxx wrote:
> >>
> >
> > To some extends you are right. But it is not just limited within a GUI
> > application based on cdrecord. I write shell script often to simplify
> > command based tasks. Hence I am searching for a way to add GUI
> > interface to my shell scripts because a shell script has the power to
> > call the linux commands directly ( here cdrecord) Now it can be a GUI
> > for a script which can do Cd writing or some thing else. Thanks for
> > the hints you have given regarding python. If I go for python it would
> > take some time as I have never used it before but I am quite familiar
> > with shell scripts hence I can immediately start with any tool which
> > can make GUI of shell-scripts. I have intensionally skipped
> > Kdeveloper; Qt etc.. as those are resource hungry. Honestly speaking I
> > like eye candy things but give priority to those tools which can do
> > the exact job in a simple way. Like shell scripts.
> > Thanks
> >
> >
> Yes, scripts are great for small jobs but if your GUI interface grows
> you may find interpreter based scripts eating up the resources also.  I
> believe that there may be some compilers being written for Python that
> may help solve that problem by producing a binary executable.  If you
> are running KDE then the Qt libraries are already there in the
> background so any executable you produce will be highly resource
> efficient, similarly with Gnome and gtk libraries.  Incidentally, you
> can call Linux commands directly from within a Qt executable.  i.e.
> start command processes from within the executable, pass arguments to
> them and redirect their stdout and stderr output to the GUI.  Qt4 now
> also allows you to pipe between two external process and redirect to
> files, what it can't do is interpret scripting syntax.  But what I have
> done to over come this short coming is to make the GUI executable write
> a script on a temporary file, run it from the GUI and when I'm done with
> it, delete it.  The benefit of this is that you only have to have one
> file to worry about (the executable) that contains everything i.e. does
> not depend on any script files that can get misplaced.
>
> I guess its all a question of balance!  I use Linux's excellent terminal
> commands to do many things and also write simple scripts but many Linux
> commands have hundreds of options that you never need and if used
> infrequently are easy to forget.  Then you have to plough through a man
> page trying to find the options you need.  If you write a script to
> limit the number of options you still have to provide an argument list
> or use a boring question and answer menu interaction approach.  My
> solution in this case is to write a GUI dialog program with a list of
> check boxes and/or buttons that can be selected for the various options
> I might be interested in and possibly show some output or error messages.
>
>
> John Blomfield
> >
> >

Nice response John,
I like to avoid the qt stuff as it is resource hungry and it works
well with KDE. And I don't like to make a tool with a lot of
dependency. Please note my interest is to simply make GUI based on
shell-script; those script which are already working well. What do you
think about xdialog ?

George I have not looked into zenity but I have done some work with
dialog and also interested in xdialog to use with shell script.

John I have already implemented the dialog feature in a script based
on cdrecord. It is working well but it is still not a complete tool.
My work are on progress.

Thanks

>
> _______________________________________________
> Discuss mailing list
> Discuss at vlug.org
> http://ladybug.vlug.org/cgi-bin/mailman/listinfo/discuss
>


More information about the Discuss mailing list