PerlTk - Tk versus other libraries?

Author

Tk versus other libraries?

Vorxion

2004-06-03, 7:10 pm

I swear to God, this isn't a troll. It's a legitimate question.

I finished my first Perl/Tk application. Took me 4 days going in pretty
much cold after reading through about 4 chapters of "Mastering Perl/Tk" and
doing research to get the rest of what I needed on the fly, and this
included the guts of my program, which actually took 60%+ of the code. I'm
used to CLI and CGI programming, and usually UI code is 80%+ in those
cases. This was a wonderful experience.

At one point during the polishing stages, I ran into troubles replacing the
system icon on win32. It was mucking with my geometry and the size of a
ROText widget that it wasn't even related to. (Never change the icon
-before- a menubar is created appears to be the moral of the story, since
that fixed the ROText issue, and specifying a minsize for the MainWindow
fixed the fact that it kept drawing a bit shorter than it should have
despite an explicit geometry call already being in effect.)

At any rate, during this, I asked a few old acquaintances, and one person
(actually a few) said flat-out, "Tk? Not my first choice of bindings." I
kind of blinked and said, "Okay, what would you use?" The answer that came
back was wxPerl. I looked at this, and it pointed me to the whole
wxWidgets deal.

At this point I got into an argument over it, as I had issues with
wxWidgets in principle. Besides being invested in learning Perl/Tk already
with my book at my side and some experience behind me now, I don't -want- a
native look per platform. I think it's philosophically better to retain a
universal look across -all- platforms. That way, if someone migrates, they
barely have to blink, as all that will change are checkboxes and
scrollbars, for the most part.

At any rate, my look at wxWidgets and wxPerl's version numbers suggest to
me that it's relatively young compared to Tk's long and robust heritage.
Granted, from what I've read of the history of it, the pTk offshoot is
younger, but still heavily influenced by the original.

Add to this the point that O'Reilly, for instance, has at least two books
on Perl/Tk, and I'm not -aware- of any for wxPerl, and I find myself
feeling I've made the right decision in staying by pTk and continuing
onward.

However, on the off chance that the person that took the heaviest hand in
the argument wasn't just having a severe attitude problem (quite probably
they were, they're prone to it historically), I'm wondering if my views are
skewed or relatively accurate. "Nobody does Tk anymore." He made it sound
dated, basically--all but obsolete. Frankly, after seeing the power it
imbues the coder with, I find it anything but.

Seems to me that this group is relatively populated, development is still
ongoing, the project isn't stagnant, etc.

So, was this person basically full of it and/or prejudiced towards their
favourite pet rock of the w

, or is there more to think about than I
already have?

In no way do I want to start a holy war of any kind. I'm just looking for
a bit of reassurance that I'm making the right call and not overlooking
something that I should further consider. Obviously asking -either- side
will yield some biased results, but I figure that since I pretty much
intend to stick with Tk, this would be the place to get the accurate,
unbiased views on any possible Tk shortcomings, rather than propoganda from
someone who likes some other flavour of the w

and isn't conversant with
Tk because they're part of that "Nobody" group--that doesn't use it anymore.

Thanks in advance for any useful replies...

--
Vorxion - Member of The Vortexa Elite

H. Wade Minter

2004-06-03, 7:10 pm

Vorxion <vorxion@knockingshopofthemind.com> wrote:
> At any rate, during this, I asked a few old acquaintances, and one person
> (actually a few) said flat-out, "Tk? Not my first choice of bindings." I
> kind of blinked and said, "Okay, what would you use?" The answer that came
> back was wxPerl. I looked at this, and it pointed me to the whole
> wxWidgets deal.
>
> At any rate, my look at wxWidgets and wxPerl's version numbers suggest to
> me that it's relatively young compared to Tk's long and robust heritage.
> Granted, from what I've read of the history of it, the pTk offshoot is
> younger, but still heavily influenced by the original.
>
> Add to this the point that O'Reilly, for instance, has at least two books
> on Perl/Tk, and I'm not -aware- of any for wxPerl, and I find myself
> feeling I've made the right decision in staying by pTk and continuing
> onward.

I've investigated wxWindows/wxPerl a couple of times. I really like the
look of the wxWindows widget set, and the fact that they're natively
cross-platform on Unix, Win32, and OS X. However, there are a couple of
big weaknesses that I see that make them less attractive than Tk on Perl.

1) Binding support: The wxPerl bindings are pretty new, and I don't think
they're as stable or featureful as the python bindings or native C++ APIs.
That may change as time goes on, but wxPerl doesn't appear to have as much
momentum behind it as wxPython, for example.

2) Documentation: From what I can tell, the wxPerl documentation is a
pointer to the C++ API, which itself is just a listing of methods and
which arguments they take. Plus a couple of semi-complete Hello World
entries in a Wiki. There's nothing that compares to Learning/Mastering
Perl/Tk. The Perl/Tk documentation and community is second-to-none, and
that's what makes learning how to build a GUI in Perl/Tk so much fun.

I was able, with no previous GUI experience, to sit down with Learning
Perl/Tk and very quickly get a functional GUI up. Then, I could progress
into the more advanced stuff in the documentation, with the archives of
c.l.p.tk answering many more questions. I don't think that type of resource
exists for wxPerl.

So, yeah. wxPerl looks like a good choice if you're already comfortable
programming with wx, and wx itself looks like a fine GUI toolkit. But
I'll be sticking with Perl/Tk, personally.

--Wade

Robert

2004-06-03, 7:10 pm

"H. Wade Minter" <minter@lunenburg.org> wrote in message news:cJKsc.76161
<snip>
> 2) Documentation: From what I can tell, the wxPerl documentation is a
> pointer to the C++ API, which itself is just a listing of methods and
> which arguments they take. Plus a couple of semi-complete Hello World
> entries in a Wiki. There's nothing that compares to Learning/Mastering
> Perl/Tk. The Perl/Tk documentation and community is second-to-none, and
> that's what makes learning how to build a GUI in Perl/Tk so much fun.
>
FWIW, the Python documentation does pretty much the same thing and if you
are not a C++ programmer it is pretty frustrating to try and pick up. The
rumor mill says a "Python" version of the docs is in the works. We shall
see.

Robert

lvirden@yahoo.com

2004-06-03, 7:10 pm

According to Vorxion <vorxion@knockingshopofthemind.com>:
:At this point I got into an argument over it, as I had issues with
:wxWidgets in principle.

....

: I don't -want- a
:native look per platform. I think it's philosophically better to retain a
:universal look across -all- platforms. That way, if someone migrates, they
:barely have to blink, as all that will change are checkboxes and
:scrollbars, for the most part.

Hmm - but Tk, at least as used with Tcl, makes use of native widgets
where possible. Does that change with the Perl/Tk binding? It seems
rather ... unlikely.

Now, granted, in most cases one gets the 'tk look' rather than the native
look. Almost amusingly enough, though I agree with you, Vorxion, the
majority of developers - at least the ones on Windows and MacOSX - ask
for MORE native look and feel, rather than less. And the developers on
Unix ask for their Tk apps to take on the GNOME/KDE desktop look and feel.
They claim that their users don't move from platform to platform as much
as they move from application to application on the same platform. And
their users want Tk applications to look and act like the other apps on
their desktop.

So it's a tough call.

--
<URL: http://wiki.tcl.tk/ > In God we trust.
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >

lvirden@gmail.com

2004-06-05, 3:57 am

According to Slaven Rezic <slaven@rezic.de>:
:lvirden@yahoo.com wrote in message news:<c9792u$4mn$3@srv38.cas.org>...
:> According to Vorxion <vorxion@knockingshopofthemind.com>:
:> :At this point I got into an argument over it, as I had issues with
:> :wxWidgets in principle.
:>
:> ...
:>
:> : I don't -want- a
:> :native look per platform. I think it's philosophically better to retain a
:> :universal look across -all- platforms. That way, if someone migrates, they
:> :barely have to blink, as all that will change are checkboxes and
:> :scrollbars, for the most part.
:>
:> Hmm - but Tk, at least as used with Tcl, makes use of native widgets
:> where possible. Does that change with the Perl/Tk binding? It seems
:> rather ... unlikely.
:
:Last I looked into the source code of Tk804 (and hence tk8.4) only
:half of the core widgets were "native" widgets on Windows. Mega
:(composite) widgets are another issue, these often behave and look
:completely different (e.g. Tk::BrowseEntry vs. native Windows comboboxes).

Right. And I suppose one could write specialty code that deletes
the native widget procs on Windows and then define a new set of procs
that provides a different look and feel.

However, the poster to whom I was responding appeared to be arguing that
he wanted to use perl/tk over wxwidgets because with perl/tk he had
a standard look across platforms, and unless one is uses a subset of perl/tk
that doesn't seem like the effect one is going to see.
--
<URL: http://wiki.tcl.tk/ > In God we trust.
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >

Sponsored Links