Searching \ for '[EE] Simple GUI wrapper for command line applicati' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=simple+gui+wrapper
Search entire site for: 'Simple GUI wrapper for command line applicati'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Simple GUI wrapper for command line applicati'
2005\11\10@012725 by Chen Xiao Fan

face
flavicon
face
My knowledge of Win32/Linux GUI programming is next to zero.
Still I would like to seek some advice on writing very simple
GUI program to call command line applications.

I think maybe it is a good exercise to give xwisp2 a GUI just
as a learning exercise for me. In fact it can be used for
quite some simple command line applications.

Requirement:
1) Visual Basic.Net Express 2005 or other free tools. VB6 is
another option even though it is not free. Cross-platform tools
may be too difficult for me. But maybe I am wrong. I only
know some simple C and a bit of Basic. ;-(

2) File open/save dialogue for the hex file (to pass the hex
file name to xwisp2w.exe). Display of the hex file may be a
bit tough so this will be optional. For that maybe I can
learn from PICkit 1/2 host applications.

3) Option to select COM port and Baud Rate (to pass the option
to xwisp2w.exe)

4) Extra options (user input for extra options to pass to
xwisp2.exe)

5) Menu items: "go", "write", "read", "erase" and "verify"
command (to pass the command to xwisp2w.exe).

6) A text box to display all the output

Is this a good exercise? Will this be difficult to implement?
I would like to follow an existing example if possible.

Regards,
Xiaofan

2005\11\10@020148 by Wouter van Ooijen

face picon face
> I think maybe it is a good exercise to give xwisp2 a GUI just
> as a learning exercise for me. In fact it can be used for
> quite some simple command line applications.

If you are not married to a specific tool I suggest you get Python and
one of the many GUI tookits. Totally free, and if you don't do crazy
things your GUI will run not only on Windows but on Mac, Linux, OS/2 and
nearly any other system around.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2005\11\10@024606 by Stef Mientki

flavicon
face
you could take a look at AutoIt,
free and it can do all you want (and even more)
Stef

Chen Xiao Fan wrote:

{Quote hidden}

2005\11\10@045521 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu]
>Sent: 10 November 2005 07:02
>To: 'Microcontroller discussion list - Public.'
>Subject: RE: [EE] Simple GUI wrapper for command line applications
>
>
>> I think maybe it is a good exercise to give xwisp2 a GUI just as a
>> learning exercise for me. In fact it can be used for quite
>some simple
>> command line applications.
>
>If you are not married to a specific tool I suggest you get
>Python and one of the many GUI tookits. Totally free, and if
>you don't do crazy things your GUI will run not only on
>Windows but on Mac, Linux, OS/2 and nearly any other system around.
>

Wouter,

I don't know about VB.Net, but in VB6 to capture stdout and stderr from command line applications takes a lot of messing with the Win32 API.  Does Python make this easier?

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\11\10@051824 by Wouter van Ooijen
face picon face
> I don't know about VB.Net, but in VB6 to capture stdout and
> stderr from command line applications takes a lot of messing
> with the Win32 API.  Does Python make this easier?

I don't know. But if you can live with running the command line to the
end you can use the command line redirection.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\11\10@080348 by Rolf

face picon face
Have a look at Java. There are "simple" java constructs called streams,
and with a basic understanding of those you can then use the "Process"
object to run your application.

Your program would look something like:
.....
... //get all the details you want. Use
http://java.sun.com/docs/books/tutorial/uiswing/components/filechooser.html
for choosing an input file.
... // see
http://java.sun.com/docs/books/tutorial/uiswing/components/components.html
for ideas on what "Swing" can provide to the programmer.

... // once you have all your parameters in hand, construct a
command-line for xwisp2w

... // then do something like:

// Start running XWisp using the command line you created with your input...
Process xwisp = System.getRuntime().exec(xwispcommand);

// Get Streams that represent the STDOutput and STDErr of the xwisp program.
final InputStream STDOUT = xwisp.getOutputStream();
final InputStream STDERR = xwisp.getErrorStream();

// This will become a "background" thread to read the STDOutput, and
display it in the log.
Runnable outrun = new Runnable() {
  public void run() {
    try {
       BufferedReader br = new BufferedReader(new
InputStreamReader(STDOUT));
       String line = null;
       while ((line = br.readLine()) != null) {
         .... // do something to add the line of output to your logging
window.
       }
    } catch (Exception e) {
       e.printStackTrace();
    }
  }
};

// This will become a "background" thread to read the STDError, and
display it in the error/warning log.
Runnable errrun = new Runnable() {
  public void run() {
    try {
       BufferedReader br = new BufferedReader(new
InputStreamReader(STDERR));
       String line = null;
       while ((line = br.readLine()) != null) {
         .... // do something to add the line of output to your
error/warning window.
       }
    } catch (Exception e) {
       e.printStackTrace();
    }
  }
};

// Start reading the output from xwisp now. Daemon threads are used
(they die if the program dies...).
Thread outreader = new Thread(outrun, "STDOut Thread");
outreader.setDaemon(true);
outreader.start();
Thread errreader = new Thread(errrun, "STDErr Thread");
errreader.setDaemon(true);
errreader.start();

// Wait for xwisp to complete... record the exit code.
int exitcode = xwisp.waitFor();

// make sure all the output is dealt with from the program.
outreader.join();
outwriter.join();

// Raise an error if XWisp failed.
if (exitcode != 0) {
 throw new Exception("XWisp Program failed. See error/warning screen
for details.");
}


Rolf



Chen Xiao Fan wrote:
{Quote hidden}

2005\11\10@091916 by Danny Sauer

flavicon
face
Michael wrote regarding 'RE: [EE] Simple GUI wrapper for command line applications' on Thu, Nov 10 at 04:02:
>
>
> >{Original Message removed}

2005\11\10@113243 by Bill Freeman

flavicon
face
Danny Sauer writes:
> ...  Python and Java are both going to require comfort with OO concepts.

       True of Java, but you can happily write lots of Python code
without ever creating a class.  That you say f.readline() rather than
readline(f) when f is a file object is simply the interface that you
look up, rather than an understanding of OO.  Modern Perl is, my local
Perl boosters tell me, is as OO as Python.

                                                       Bill

2005\11\10@134718 by Peter

picon face

On Thu, 10 Nov 2005, Chen Xiao Fan wrote:

> My knowledge of Win32/Linux GUI programming is next to zero.
> Still I would like to seek some advice on writing very simple
> GUI program to call command line applications.
>
> I think maybe it is a good exercise to give xwisp2 a GUI just
> as a learning exercise for me. In fact it can be used for
> quite some simple command line applications.
>
> Requirement:
> 1) Visual Basic.Net Express 2005 or other free tools. VB6 is
> another option even though it is not free. Cross-platform tools
> may be too difficult for me. But maybe I am wrong. I only
> know some simple C and a bit of Basic. ;-(

tcl.tk

free, open source, cross platform, not a 'moving target' (although still
evolving it has been around for 15 years), supports any language (native
Unicode in widgets). Used by MAJOR companies for their guis and
backends. Extensible in any language you want (but especially in C, it
was designed for that).

Gui builder (rad): vtcl, tkBuilder and many others

> Is this a good exercise? Will this be difficult to implement?
> I would like to follow an existing example if possible.

An existing example of what ? If this is the first time you write a GUI
do a 'hello world' and work some examples first imho.

Peter

2005\11\10@143308 by Wouter van Ooijen

face picon face
> tcl.tk

<flameshield>
juk! tk is much too good to use it through tcl. Better use
Python/tkInter.
</flameshield>

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\11\10@155645 by Danny Sauer

flavicon
face
Wouter wrote regarding 'RE: [EE] Simple GUI wrapper for command line applications' on Thu, Nov 10 at 13:40:
> > tcl.tk
>
> <flameshield>
> juk! tk is much too good to use it through tcl. Better use
> Python/tkInter.
> </flameshield>

I think you mistyped perl/tk - the website's at http://perltk.org/ ;)
http://sourceforge.net/projects/guido/ is handy, too (see vtcl below).

http://vtcl.sourceforge.net/ is nice for those who actually want to
use TCL, for whatever reason, but feel more at home in a VB-type
setup.

--Danny

2005\11\10@195207 by Chen Xiao Fan

face
flavicon
face
I know requirement 6) (A text box to display all the output)
is the difficult part. I think I can handle the rest with
VB6. What is your suggestion if I want to stick with VB6?

Requirement 6) comes with the experience asking my brother
to write a simple Linux GUI for a command line application.
He is an experienced UNIX c++/Java developer but got little
experience with GUI. He tried to use ncurses but the problem
is that the stdout/stderr output (printf or similar) is all
over the place. Now I ask him to try out WxWidgets. Java
seems very weak in terms of interfacing with PIC especially
when USB comes to the picture.

Python may be another option. I feel it is quite C-like and
I can understand quite some Python code since I am looking at
Mark Rages' Python based PICkit 1/2 program. I looked at
WxPython but I find it is quite complicated as well (like MFC)
which I do not want to touch right now. MFC/Gtk+/KDE
are all too difficult for me right now since I do not even
know enough C++.

I will also look at other options. Thanks for the suggestions.

Regards,
Xiaofan



-----Original Message-----
From: piclist-bouncesspamKILLspammit.edu
Sent: Thursday, November 10, 2005 5:55 PM
To: Microcontroller discussion list - Public.
Subject: RE: [EE] Simple GUI wrapper for command line applications

Wouter,

I don't know about VB.Net, but in VB6 to capture stdout and stderr
from command line applications takes a lot of messing with the Win32
API.  Does Python make this easier?

Regards

Mike

2005\11\11@005029 by William Chops Westfield

face picon face

On Nov 10, 2005, at 4:52 PM, Chen Xiao Fan wrote:

> He tried to use ncurses but the problem is that the stdout/stderr
> output (printf or similar) is all over the place.

Why is that a problem?  I'm far from being a windows programmer, but
isn't it relatively trivial to redirect stdout and stderr to files,
pipes, sockets, or something else that enables it to be easily read
by another application and display in whatever way you want?

BillW

2005\11\11@011517 by Chen Xiao Fan

face
flavicon
face
This is a problem. ncurses is kind of terminal GUI
(like Turbo C under DOS). The printf output will disturb
the running of ncurses based application. Anyway,
ncurses seems not a good option to me.

If I need to redirect the stdout and stderr to files, it
defeats the purpose of the GUI wrapper IMHO. I am
comfortable with console based program but sometimes
people like a GUI based program, even though it can
be a simple one. In the case of a simple command line
application wrapper, to redirect the stderr/stdout
to an windows seems to be nice in my opinion.

For example, MpasmWin is an example. It would be better
to have a text box in the bottom to capature the output
instead of the pop up screen.

I know very little of GUI programming so maybe I am wrong
here. What will be a better option if we do not want to
change the command line program but just want to add
a GUI to it?

Regards,
Xiaofan

{Original Message removed}

2005\11\11@053002 by Peter Onion

flavicon
face
>
> I know very little of GUI programming so maybe I am wrong
> here. What will be a better option if we do not want to
> change the command line program but just want to add
> a GUI to it?
>
> Regards,
> Xiaofan

Several suggestions have been made about GUI tool kits for various languages
you could use.  I would take some time to go and learn about GUI
fundamentals using which ever language you are most comfortable with.

It's been a few years since I last used it, but tcl/tk is good for the sort
of thing you are talking about.

Peter

2005\11\11@054638 by Matthew Miller

flavicon
face
On Fri, Nov 11, 2005 at 02:15:13PM +0800, Chen Xiao Fan wrote:
> This is a problem. ncurses is kind of terminal GUI
> (like Turbo C under DOS). The printf output will disturb
> the running of ncurses based application. Anyway,
> ncurses seems not a good option to me.
>
> If I need to redirect the stdout and stderr to files, it
> defeats the purpose of the GUI wrapper IMHO. I am
> comfortable with console based program but sometimes
> people like a GUI based program, even though it can
> be a simple one. In the case of a simple command line
> application wrapper, to redirect the stderr/stdout
> to an windows seems to be nice in my opinion.

To use ncurses, you would need to redirect the three std* file descripters
to either some pipes or sockets (maybe even a fifo...) before executing the
command line program. Then ncurses isn't bothered by any printfs in the
command line program. I have a C++ program I can send that shows how this is
done; the program is a GUI wrapper around another command line program, just
what you want. I expect the C/C++ file descriptor redirection routines are
similar to what would be done in Python or Perl. I'll send the program
source to you if you're interested.

Matthew

--
"The prestige of government has undoubtedly been lowered considerably by the
prohibition law. For nothing is more destructive of respect for the
government and the law of the land than passing laws which cannot be
enforced. It is an open secret that the dangerous increase of crime in this
country is closely connected with this."
-- Albert Einstein, "My First Impression of the USA," 1921

2005\11\11@102911 by olin piclist

face picon face
Chen Xiao Fan wrote:
> For example, MpasmWin is an example. It would be better
> to have a text box in the bottom to capature the output
> instead of the pop up screen.

Yes, a GUI is silly for something like an assembler.  That's one of the
things my preprocessor PREPIC (http://www.embedinc.com/pic) takes care of.
It runs MPASMWIN, checks the error output file, write any errors found to
standard output, then sets the program exit status code to 0 if no errors
found and non-zero if there were errors.  Just like a real assembler.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\11@125354 by Peter

picon face

On Mon, 14 Nov 2005, Wouter van Ooijen wrote:

>> tcl.tk
>
> <flameshield>
> juk! tk is much too good to use it through tcl. Better use
> Python/tkInter.
> </flameshield>

I will not answer that directly ;-) But tcl is a good language for light
and medium weight programs. There are several large applications written
in tcl out there. And if Python is so good, then why does it have to
borrow the gui part of tcl (namely, tk) ?

Peter

2005\11\11@125526 by Peter

picon face

On Thu, 10 Nov 2005, Danny Sauer wrote:

> Wouter wrote regarding 'RE: [EE] Simple GUI wrapper for command line applications' on Thu, Nov 10 at 13:40:
>>> tcl.tk
>>
>> <flameshield>
>> juk! tk is much too good to use it through tcl. Better use
>> Python/tkInter.
>> </flameshield>
>
> I think you mistyped perl/tk - the website's at http://perltk.org/ ;)
> http://sourceforge.net/projects/guido/ is handy, too (see vtcl below).

and perl also uses the gui of tcl (namely tk), just like Python. Why
would such a good language not be able to supply its own ? Hmm ?

> http://vtcl.sourceforge.net/ is nice for those who actually want to
> use TCL, for whatever reason, but feel more at home in a VB-type
> setup.

afaik vtcl does not have *anything* to do with VB.

Peter

2005\11\11@130921 by Peter

picon face


On Thu, 10 Nov 2005, William Chops Westfield wrote:

{Quote hidden}

No, it is not ;-). In a native Windows application stdin and stdout and
stderr do not exist. You have to make special efforts to implement them
and certain implementations clash with other objects provided and used
in the Windows API (i.e. you can't include stdio when including certain
Windows api headers). Same for BSD sockets. Most cross platform
scripting languages come with pages of warnings and workarounds for the
serial and stdio interfaces on windows. This includes Tcl and Python.

>From my own experience, a plain TCP BSD socket server program used about
100 lines of C on *nix and became about 400 lines when ported to Windows
because of the winsock startup and threading magic required (there is no
fork() on windows, you use threads, i.e. write your own fork() from
scratch afair - this was winsock 2.0 and a few years ago so it may
have improved meanwhile).

Peter

2005\11\11@131104 by Peter

picon face


On Fri, 11 Nov 2005, Chen Xiao Fan wrote:

> here. What will be a better option if we do not want to
> change the command line program but just want to add
> a GUI to it?

expectk (a version of tcl/tk). It was written specifically for that.

Peter

2005\11\11@132111 by Bob Blick

face picon face

> I know very little of GUI programming so maybe I am wrong
> here. What will be a better option if we do not want to
> change the command line program but just want to add
> a GUI to it?


Hi Xiaofan,

Yesterday someone mentioned AutoIt, and I downloaded and checked it out.
It is way cool! I have been automating all sorts of things I normally
waste time interacting with. Try it, you'll like it:

http://www.autoitscript.com/autoit3/

Cheers,

Bob


2005\11\11@133251 by olin piclist

face picon face
Bob Blick wrote:
> Yesterday someone mentioned AutoIt, and I downloaded and checked it out.
> It is way cool! I have been automating all sorts of things I normally
> waste time interacting with.

Now if we could only get developers to create command line instead of
annoying clickety-click interfaces in the first place...


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\11@140132 by Wouter van Ooijen

face picon face
> I will not answer that directly ;-) But tcl is a good
> language for light
> and medium weight programs. There are several large
> applications written
> in tcl out there. And if Python is so good, then why does it have to
> borrow the gui part of tcl (namely, tk) ?

A library concept and the language used to interface to it are (or: can
be) two separate things. Python and TCL have littel incommon (except
they are both interpreted languages) but spme Python guys took what is
good in tcl/tk and made a Python interface for it.

I agree tcl is good for small programs. I don't think it is good for
medium size programs.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\11\11@140650 by Alex Harford

face picon face
On 11/11/05, Wouter van Ooijen <.....wouterKILLspamspam.....voti.nl> wrote:
> > And if Python is so good, then why does it have to
> > borrow the gui part of tcl (namely, tk) ?
>
> Python guys took what is good in tcl/tk and made a Python interface for it.

And it should be noted that tk isn't the only GUI frontend for Python,
there is also WxWindows, GTK, QT, FOX (?).

http://www.metaslash.com/brochure/tutorial/

Alex

2005\11\11@145242 by Danny Sauer

flavicon
face
Peter wrote regarding 'Re: [EE] Simple GUI wrapper for command line applications' on Fri, Nov 11 at 11:57:
>
> On Thu, 10 Nov 2005, Danny Sauer wrote:
>
> >I think you mistyped perl/tk - the website's at http://perltk.org/ ;)
> >http://sourceforge.net/projects/guido/ is handy, too (see vtcl below).
>
> and perl also uses the gui of tcl (namely tk), just like Python. Why
> would such a good language not be able to supply its own ? Hmm ?

A good launguage doesn't reinvent the wheel when there's a library that
already provides a wheel.  TK is one graphics toolkit which is often
used from within TCL and was designed to work with TCL's weird
structure, but is quite separate from TCL.  GTK, QT, and WXWindows are
other arguably better graphics tookits easily accessible from perl
(and other languages), but TK was suggested because it's most commonly
available.

Honestly, I think people are suggesting using a language other than
TCL because other languages are actually useful. :)  Useful, in this
case, is defined by the number of job postings requesting knowledge of
a language.  Search for jobs asking about perl - you'll find more than
you can count.  Python will get you a lot of hits.  TCL will get you
almost nothing.  Sure, TCL's a decent structured language, and isn't a
bad way to learn programming.  It even has some nifty features.  But
if someone inexperienced is looking for a new language to learn which
will get them the widest variety of practical uses (writing new
programs, using existing programs) for the time invested, TCL probably
shouldn't be the first one on their list.  Perl probably shouldn't be
either, since it lets so many poor practices go by without complaining
- I think perl's best suited for experienced programmers who want to
save time, honestly.

This is rather off-topic, though - I only mentioned perl/tk as a joke
because the other person suggested pyton/tk. :)

> >http://vtcl.sourceforge.net/ is nice for those who actually want to
> >use TCL, for whatever reason, but feel more at home in a VB-type
> >setup.
>
> afaik vtcl does not have *anything* to do with VB.

Vtcl is a program that allows visually laying out an interface and
easily integrating that interface with a program written in a
simplistic scripting language.  As is VB.  That's how they're related.
I think someone used to developing in VB woudl be more at home with a
visual interface builder like vtcl than they would with just a text
editor - even though similar results can be had either way.

--Danny

2005\11\12@074826 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

>> Yesterday someone mentioned AutoIt, and I downloaded and checked it out.
>> It is way cool! I have been automating all sorts of things I normally
>> waste time interacting with.
>
> Now if we could only get developers to create command line instead of
> annoying clickety-click interfaces in the first place...

Or at least make the functionality that's already there available through
the command line, in addition to the GUI interface.

Gerhard

2005\11\12@123645 by Peter

picon face

On Fri, 11 Nov 2005, Wouter van Ooijen wrote:

>> I will not answer that directly ;-) But tcl is a good
>> language for light
>> and medium weight programs. There are several large
>> applications written
>> in tcl out there. And if Python is so good, then why does it have to
>> borrow the gui part of tcl (namely, tk) ?
>
> A library concept and the language used to interface to it are (or: can
> be) two separate things. Python and TCL have littel incommon (except
> they are both interpreted languages) but spme Python guys took what is
> good in tcl/tk and made a Python interface for it.
>
> I agree tcl is good for small programs. I don't think it is good for
> medium size programs.

I disagree. I have 5000+ lines programs working (just be sure to use the
C-equivalent lines when comparing program sizes. The C-equivalent of
tcl/tk is between 10:1 and 20:1 lines/lines afaik).

Peter

2005\11\12@124613 by Peter

picon face

On Fri, 11 Nov 2005, Danny Sauer wrote:

> Honestly, I think people are suggesting using a language other than
> TCL because other languages are actually useful. :)  Useful, in this
> case, is defined by the number of job postings requesting knowledge of
> a language.  Search for jobs asking about perl - you'll find more than

tcl was designed for a particular purpose and it does that very well. It
is a scripting language and it does not try to be the
microscope-that-can-bash-all-the-nails which is what Perl, Python, and
Php try to be. Instead it is a small, solid *scripting* language that
sticks to *scripting*, as opposed to taking over the universe, and it
also makes it extraordinarily easy to call or invoke other programs,
such that *they* can be used to do whatever it is that they do best.

tcl is very much like Basic. There is enough rope in it to hang yourself
with but if you are disciplined you will be safe & happy. Typical code
size for tcl vs. python is 1/2. This, and the sanity of the tk toolkit
which allows guis to be built without ever needing to bother about
layout tools, has made me choose it, over Python. That, and the need for
a language that is mostly typeless (almost everything is a string in
tcl).

Peter

2005\11\12@132434 by Wouter van Ooijen

face picon face
> This, and the sanity of the
> tk toolkit
> which allows guis to be built without ever needing to bother about
> layout tools, has made me choose it, over Python.

So you say tk is less sane when called from Python?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\11\12@132434 by Wouter van Ooijen

face picon face
>> I agree tcl is good for small programs. I don't think it is good for
>> medium size programs.
>
> I disagree. I have 5000+ lines programs working (just be sure
> to use the
> C-equivalent lines when comparing program sizes. The C-equivalent of
> tcl/tk is between 10:1 and 20:1 lines/lines afaik).

I (of course) respect your opinion, but there fact that working programs
of a certain size exist doe snot prove that the language used is suited.
It just proves that it can be done. I also disagree with the 10:1, or
tcl must have changed substantially since I used it (~6 y ago).

Note that I don't think Python is suited for large programs.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\11\12@181412 by Peter

picon face

Ok, I read this article that compares several scripting languages but I
lost the link. Now I looked it up and I found it. Well worth reading
imho:

http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprt_computer2000.pdf

(in English of course). Imho the following two tables in this document
are highly relevant:

1. "source text productivity [LOC/hour]"
2. "total time for programming [hours]"

The only thing I'd like to add is, *none* of the languages are compared
in the context of a gui application, *but* tcl/tk would come out at the
same place at least in the two tables indicated above if the comparison
would be for graphical programs. For example, adding a full gui to any
of the tcl programs compared in the article would add only 20 or so
lines of tcl to the program.

Peter

(who used and uses Perl and some Pyhton but prefers to *script* guis in
Tcl/Tk)


2005\11\12@200211 by Xiaofan Chen

face picon face
Thanks for all the comments so far. Take note I do not want to
start a language war on the GUI front.

I did some research yesterday. Firstly google points me a some
nice articles from http://www.codeproject.com written in VC++ and
VB. I got exactly what I want for the console output redirect and I think
I can use that as a good start. This will be a Windows only solution.
Anyway I need to learn a bit on Windows GUI programming as well.

Interestingly, later I called my brother who is a Visual C++ programmer at
Creative Technology (the soundcard make) and he told me he just finished an
assignment for his M.Sc. computer graphics course using the same thing for
a GUI wrapper of a console program.

I've also downloaded AutoIt and will give it a try later.

Then I added Linux to the google search keywords, tk/python/gtk are the
top hits. Since gtk/gtk+ seems to be difficult for me, Python with tk seem to
be a good option. I will try this route as the preferred
cross-platform solution.

For the other brother who is a Unix programmer but without much GUI
programming experience, I will recommend GTK+/WxWidgets to him as
he is good at C++.

Thanks again for all the helps and I will report my progress once I have done
the simple GUI wrapper for xwisp2 and pk2 (Linux/Windows program to
drive PICkit 2).

Regards,
Xiaofan

2005\11\12@204224 by Danny Sauer

flavicon
face
Peter wrote regarding 'Re: [EE] Simple GUI wrapper for command line applications' on Sat, Nov 12 at 11:53:
>
> On Fri, 11 Nov 2005, Danny Sauer wrote:
>
> >Honestly, I think people are suggesting using a language other than
> >TCL because other languages are actually useful. :)  Useful, in this
> >case, is defined by the number of job postings requesting knowledge of
> >a language.  Search for jobs asking about perl - you'll find more than
>
> tcl was designed for a particular purpose and it does that very well. It
> is a scripting language and it does not try to be the
> microscope-that-can-bash-all-the-nails which is what Perl, Python, and
> Php try to be.

Actually, PHP is a language designed to ease web processing which has
only recently "grafted on" some of the neccesary features for CLI
scripting.  I find PHP somewhat appealing for some small scripts for a
few reasons, most of which are syntactic sugar which doesn't really
provide amazing features, but makes certain things simple.  The
wordwrap() method comes in handy, for example.

> Instead it is a small, solid *scripting* language that
> sticks to *scripting*, as opposed to taking over the universe, and it
> also makes it extraordinarily easy to call or invoke other programs,
> such that *they* can be used to do whatever it is that they do best.

If you want a simple scripting language that just glues things
together, though, I'd think that a shell (I'm partial to Bash and the
bourne-style shells) might be more appropriate. :)  Bash has both
traditional and associative arrays, looping/conditional structures,
good filehandle support, and support for simple network sockets.
String manipulation can be cumbersome in some instances, but it's
surprising how much one can really do in Bash if one wants to do so.

> tcl is very much like Basic. There is enough rope in it to hang yourself
> with but if you are disciplined you will be safe & happy. Typical code
> size for tcl vs. python is 1/2.

For a really good objective comparison of languages, I'd suggest
checking out http://shootout.alioth.debian.org/.  There are a few
unimplemented TCL entries, maybe you could submit some of them?  I've
been going through optimizing (within the spirit of the comparison)
and contributing in the perl and php sections, for what it's worth.
They compare primarily CPU time, memory use, and lines of code for
implementations of several different algorithms.

Specifically comparing Python to TCL, it looks like the lines of code
are usually in the 3/4 to 1/2 range in favor of TCL - but TCL's also
2-3x slower in most, too. :)

--Danny

2005\11\13@150654 by Peter

picon face


On Sat, 12 Nov 2005, Wouter van Ooijen wrote:

>> This, and the sanity of the tk toolkit which allows guis to be built
>> without ever needing to bother about layout tools, has made me choose
>> it, over Python.
>
> So you say tk is less sane when called from Python?

The code is much less readable. Tk was really made to work with tcl and
when you use Tk in another language you mostly write mangled tcl code
imho.

Peter

2005\11\13@153452 by Wouter van Ooijen

face picon face
>> So you say tk is less sane when called from Python?
>
> The code is much less readable. Tk was really made to work
> with tcl and
> when you use Tk in another language you mostly write mangled tcl code
> imho.

I definitely disagree, in my experience the Python version is much more
readable (and writeable!).  But unfortunately (for others who might want
to draw conslusions form our opinions) that might just mean that you are
better at writing Tcl (compared to your Python skill) and I am likewise
better at writing Python.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...