PerlTk - Perl's GUI

Author

Perl's GUI

Davy

2006-08-26, 7:58 am

Hi all,

I want to choose a GUI for my Perl program. Someone tell me there is
Perl/Tk and easy to use. But I found the latest version of Perl/Tk is
released on 11 Apr 2004. Does it mean Perl/Tk is mature and no update
for a long time or other?

And is there any other good choice for Perl's GUI?

Thanks!
Davy

Robert Hicks

2006-08-26, 7:58 am

Davy wrote:
> Hi all,
>
> I want to choose a GUI for my Perl program. Someone tell me there is
> Perl/Tk and easy to use. But I found the latest version of Perl/Tk is
> released on 11 Apr 2004. Does it mean Perl/Tk is mature and no update
> for a long time or other?
>
> And is there any other good choice for Perl's GUI?
>
> Thanks!
> Davy

wxPerl...google for it.

There is also Tkx which is a newer interface into Tk that is great and
coming from ActiveState. It is on CPAN.

Robert

zentara

2006-08-26, 7:58 am

On 26 Aug 2006 04:20:04 -0700, "Davy" <zhushenli@gmail.com> wrote:

>Hi all,
>
>I want to choose a GUI for my Perl program. Someone tell me there is
>Perl/Tk and easy to use. But I found the latest version of Perl/Tk is
>released on 11 Apr 2004. Does it mean Perl/Tk is mature and no update
>for a long time or other?

Tk will be the easiset for you to get going. The basics concepts of
writing a Tk program has not changed since 2004. There have been
bug-fixes in Tk since then, but Nick Ing-Simmons has left applying
the bug fix patches to the end users. He may be waiting to see how
they all work out, before issuing a new Tk version level.
Many are dissapointed by this, but it is not a "show-stopper". The only
bug which I absolutely had to patch, was one where Gtk2 apps were
crashing Tk apps. You can check the Tk buglist for details.

>And is there any other good choice for Perl's GUI?

Perl/Tk is based on Tcl/TK, and the 804.27 version level represents
the latest port. You might want to look at http://www.tcl.tk/ as an
alternative. Perl/Tk is for people who like Perl as there basic
language, but you might like Tcl.

The other real competitor is Perl/Gtk2. Perl/Gtk2 has had the
advantage of being built from the ground up with a consistent
object model, and widget design policies. WxPerl is based on
Perl/Gtk2.

The biggest complaint about Tk, is that it is a big hodgepodge
of independent widgets, whearas Gtk2 is all based on Glib objects.
This dosn't sound too important yet, but it becomes so when you
try to sub-class objects and control signalling between them.

Now for the bad news. Perl/Gtk2 can make it very difficult to do
what is simple in Tk. The most obvious thing is colorization of
widgets. Gtk2 has a powerful "theme" system, so you can make all your
apps look like your other Gtk2 apps like mozilla. BUT, that same theme
system, makes it quite difficult to give custom colors and fonts to
individual widgets.
Tk dosn't have that problem.

Use Tk. It will be easier for you to get your app up and running.
Afterwards, you can port it to Gtk2 or WxWidgets and compare
how easy it was to write.

--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

Ben Morrow

2006-08-26, 6:58 pm

Quoth zentara <zentara@highstream.net>:
>
> WxPerl is based on Perl/Gtk2.

No it isn't. wxPerl is a Perl binding for the wxWidgets toolkit, which
is a cross-platform GUI. It can be built to use Gtk; it can also use
Motif or raw X11 under unix, and native gui widgets under Max OS X and
Win32.

It's biggest di

vantage is that the Perl bindings are not very well
documented, and you end up having to translate from the C++ docs.

> Now for the bad news. Perl/Gtk2 can make it very difficult to do
> what is simple in Tk. The most obvious thing is colorization of
> widgets. Gtk2 has a powerful "theme" system, so you can make all your
> apps look like your other Gtk2 apps like mozilla. BUT, that same theme
> system, makes it quite difficult to give custom colors and fonts to
> individual widgets.
> Tk dosn't have that problem.

It's not a problem: that's the *whole* *point*. You shouldn't be messing
about making everything silly colours: it just makes things harder for
your users.

Ben

--
It will be seen that the Erwhonians are a m

and long-suffering people,
easily led by the nose, and quick to offer up common sense at the shrine of
logic, when a philosopher convinces them that their institutions are not based
on the strictest morality. [Samuel Butler, paraphrased] benmorrow@tiscali.co.uk

Dean Arnold

2006-08-26, 6:58 pm

Ben Morrow wrote:
> Quoth zentara <zentara@highstream.net>:
>
> No it isn't. wxPerl is a Perl binding for the wxWidgets toolkit, which
> is a cross-platform GUI. It can be built to use Gtk; it can also use
> Motif or raw X11 under unix, and native gui widgets under Max OS X and
> Win32.
>
> It's biggest di

vantage is that the Perl bindings are not very well
> documented, and you end up having to translate from the C++ docs.
>

s/very well//;

BTW: some of the bindings are in fact different than the C++ version.
And for extra fun, you get to guess which ones!

That said, you may have some success using wxGlade as a GUI builder,
as long as you're not doing anything too complicated.

However, IMNSHO, browser based is the way to go
for any modern GUI. Yes, there are some limitations, but you might
be surprised at what can be accomplished using (e.g.) Dojo
(http://www.dojotoolkit.org/), Rico (http://www.openrico.org/rico/home.page),
script.aculo.us (http://script.aculo.us/), etc. And if all you need is
some simple forms, then simple HTML may be sufficient.

Dean Arnold
Presicient Corp.

Ala Qumsieh

2006-08-27, 3:59 am

Dean Arnold wrote:

> However, IMNSHO, browser based is the way to go
> for any modern GUI. Yes, there are some limitations, but you might
> be surprised at what can be accomplished using (e.g.) Dojo
> (http://www.dojotoolkit.org/), Rico
> (http://www.openrico.org/rico/home.page),
> script.aculo.us (http://script.aculo.us/), etc. And if all you need is
> some simple forms, then simple HTML may be sufficient.

For most simple forms, then I would agree with you. But for any
application that requires intensive interaction with a Canvas-like
widget for example, then browser based solutions are much harder to
build and debug.

Even though many GUIs are being migrated to web 2.0 platforms (whatever
that means), which is a good thing, there will always be a market for
stand-alone GUI toolkits.

--Ala

Ala Qumsieh

2006-08-27, 3:59 am

zentara wrote:

> On 26 Aug 2006 04:20:04 -0700, "Davy" <zhushenli@gmail.com> wrote:
>
>
>
>
> Tk will be the easiset for you to get going. The basics concepts of
> writing a Tk program has not changed since 2004. There have been

It hasn't really changed since Tk was invented in the early nineties (91
I believe).

> bug-fixes in Tk since then, but Nick Ing-Simmons has left applying
> the bug fix patches to the end users. He may be waiting to see how
> they all work out, before issuing a new Tk version level.

You're making it sound like there are serious show-stoppers in Perl/Tk.
Of course, that is not the case (I know that you know this). Tk has been
around for ~15 years, and Perl/Tk for ~10, so 99.99% of bugs you will
encounter are either specific to some community-authored modules, or are
due to specific combination of software/hardware configurations, and
usually have easy work-arounds.

> The biggest complaint about Tk, is that it is a big hodgepodge
> of independent widgets, whearas Gtk2 is all based on Glib objects.

While Tk is not perfect, I don't see the fact above as being a drawback.
I would actually consider it a feature. Just as CPAN is one of Perl's
main strengths, community-developed pTk widgets can be regarded as one
of pTk's strengths. Moreover, pTk's syntax makes it really easy to
create custom widgets.

> This dosn't sound too important yet, but it becomes so when you
> try to sub-class objects and control signalling between them.

I'm not sure what you mean there. Do you have an example?

> Use Tk. It will be easier for you to get your app up and running.
> Afterwards, you can port it to Gtk2 or WxWidgets and compare
> how easy it was to write.

I agree with this conclusion.

--Ala

zentara

2006-08-27, 7:58 am

On Sun, 27 Aug 2006 04:53:37 GMT, Ala Qumsieh <notvalid@email.com>
wrote:

>zentara wrote:
>
[color=darkred]
>You're making it sound like there are serious show-stoppers in Perl/Tk.
>Of course, that is not the case (I know that you know this). Tk has been
>around for ~15 years, and Perl/Tk for ~10, so 99.99% of bugs you will
>encounter are either specific to some community-authored modules, or are
>due to specific combination of software/hardware configurations, and
>usually have easy work-arounds.

I thought that is what I said. The Gtk2 interference bug is pretty damn
serious if you ask me, because anyone running a recent linux system
using any Gtk2 apps (almost everyone), will find Tk unusable. Something
like that should be patched and released as a Tk bug-fix version, so we
don't have to keep dealing with new users complaining about Tk
segfaults.
It's not a show-stopper if you know what you are doing. But a newbie
will see weird segfaults in Tk, turn away from it muttering obscenities.

I've seen the question raised quite a few times. How come the Tk's
latest release is 2004?
Wheareas Gtk2 is releasing updates and bug-fixes to all of it's
components almost every month?
It gives you a feeling that the GTk2 people are actively interested
in producing an up-to-date product, compared to benign-neglect
in the Tk camp.

[color=darkred]
>I agree with this conclusion.

Ok, :-)

--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

zentara

2006-08-27, 7:58 am

On Sat, 26 Aug 2006 17:37:03 +0100, Ben Morrow <benmorrow@tiscali.co.uk>
wrote:

>Quoth zentara <zentara@highstream.net>:
>
>No it isn't. wxPerl is a Perl binding for the wxWidgets toolkit, which
>is a cross-platform GUI. It can be built to use Gtk; it can also use
>Motif or raw X11 under unix, and native gui widgets under Max OS X and
>Win32.

Yeah but in reality, almost every linux distribution builds it on Gtk2.
And when building it, it will default to Gtk2 if it's found.

>
>It's not a problem: that's the *whole* *point*. You shouldn't be messing
>about making everything silly colours: it just makes things harder for
>your users.

Why does making a textbox with a black background, (which is easier on
the eyes), make things hard for the user?

I was chastised by other Perl/Gtk2 users for saying this, and their
reason was that "themes" should never be tampered with..... like
some mantra learned in CS classes.

But I've written alot of little apps, and for appearance, and ease on
the eyes, colorization is very useful.

A few other comparisons bewtween Tk and Gtk2 (and WxWidgets built on
Gtk2).

1. Tk is very easy to install, and install cross-platform, thanks to
ActiveState's inclusion of it in it's Perl for windows.
Gtk2 on the other hand, can be a nightmare of interrelated packages,
which must be installed in a particular order. Window's versions are
finicky and difficult to get running.

2. The Canvas, which in my opinion, is the best all around widget, is
quite good on Tk. And has a big-brother named Zinc, which has many
extra features like transparency, rotations and scaling.
In Gtk2, the Canvas is "up in the air" and cannot be counted on to
be stable into the future. Apparently their are competing replacements
coming along, but no one knows where it will settle out. So Canvas
use on Gtk2 based apps is an iffy proposition right now.

Finally, don't get me wrong. I like and support Gtk2. But it is much
harder to learn and use than Tk.
I do find the thoughtful design,
where all widgets all based on Glib's Gobjects, very satisfying, in the
sense that it makes it apparent that there are brains behind the design.

I think that in about 5-10 years, when Perl/Gtk2 has had time to work
out better docs, and maybe have a book published on how to
use it, it will be the best thing going.

But for now, I reach for Tk first.

--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

zentara

2006-08-27, 6:58 pm

On Sun, 27 Aug 2006 13:02:13 GMT, zentara <zentara@highstream.net>
wrote:

>On Sat, 26 Aug 2006 17:37:03 +0100, Ben Morrow <benmorrow@tiscali.co.uk>
>wrote:
>
^^^^^^^^^^^^^^^^^^^^^^^^^[color=darkred]

>
>Yeah but in reality, almost every linux distribution builds it on Gtk2.
>And when building it, it will default to Gtk2 if it's found.

Sorry, I did make a mistake there.
I just downloaded the latest WxWidgets and it does use X11 by default.
The WxWidgets c libs did build Ok.

But I still couldn't get wxPerl going.
First Wx-0.56 said I needed Module::Pluggable and Alien-wxWidgets
Ok, 2 prerequites, no big deal, but when building
Alien-wxWidgets I get errors:

Manifying blib/lib/Alien/wxWidgets.pm -> blib/libdoc/Alien::wxWidgets.3
'gl' library not found at inc/My/Build/Any_wx_config.pm line 141.
'animate' library not found at inc/My/Build/Any_wx_config.pm line 141.
'fl' library not found at inc/My/Build/Any_wx_config.pm line 141.
'stc' library not found at inc/My/Build/Any_wx_config.pm line 141.
'deprecated' library not found at inc/My/Build/Any_wx_config.pm line
141.
'gizmos' library not found at inc/My/Build/Any_wx_config.pm line 141.
'ogl' library not found at inc/My/Build/Any_wx_config.pm line 141.
'plot' library not found at inc/My/Build/Any_wx_config.pm line 141.
'mmedia' library not found at inc/My/Build/Any_wx_config.pm line 141.
'svg' library not found at inc/My/Build/Any_wx_config.pm line 141.

########################################
#################
So I'm not going through all those problems, when Tk builds just
fine with

perl Makefile.PL
make
make install

Sorry, I still say WxPerl is too much hassle, let alone there are no
docs.

I still maintain Tk still is easiest for a new gui programmer.
Followed second by Perl/Gtk2 (which does build and install fine)

--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

Michele Dondi

2006-08-27, 6:58 pm

On Sun, 27 Aug 2006 13:02:13 GMT, zentara <zentara@highstream.net>
wrote:

>A few other comparisons bewtween Tk and Gtk2 (and WxWidgets built on
>Gtk2).

On an OT basis and on behalf of a friend of mine[*]: he's been having
difficulties using threads with Tk. I don't have experience with
either so I couldn't really help him, but from posts both here and on
PM I already knew about the possible issues, so I just reminded him of
good ol' fork(). Now the question is: is Gtk2 thread safe? Which
toolkit is, if any?

[*] Really!

Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{po
p^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

QoS@domain.invalid.com

2006-08-27, 6:58 pm

Michele Dondi <bik.mido@tiscalinet.it> wrote in message-id:
<d7o3f25kukj6tsihku7l09uf6a10i185gb@4ax.com>
>
>On Sun, 27 Aug 2006 13:02:13 GMT, zentara <zentara@highstream.net>
>wrote:
>
>
>On an OT basis and on behalf of a friend of mine[*]: he's been having
>difficulties using threads with Tk. I don't have experience with
>either so I couldn't really help him, but from posts both here and on
>PM I already knew about the possible issues, so I just reminded him of
>good ol' fork(). Now the question is: is Gtk2 thread safe? Which
>toolkit is, if any?
>
>
>[*] Really!
>
>
>Michele
>--
> {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{po
p^pop}->(map substr
>(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
>.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
>256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

I belive much of the Tk thread issue has largely been solved.
If you create the threads and shared variables prior to the Tk
bits of your application; the threads behave quite nicely.

I've begun re-writing some of my applications to use this trick,
and have developed one from the ground up using this approach.
The new threaded apps are quite reliable and seem fine.

zentara

2006-08-28, 7:59 am

On 27 Aug 2006 20:19:36 +0200, Michele Dondi <bik.mido@tiscalinet.it>
wrote:

>On Sun, 27 Aug 2006 13:02:13 GMT, zentara <zentara@highstream.net>
>wrote:
>
>
>On an OT basis and on behalf of a friend of mine[*]: he's been having
>difficulties using threads with Tk. I don't have experience with
>either so I couldn't really help him, but from posts both here and on
>PM I already knew about the possible issues, so I just reminded him of
>good ol' fork(). Now the question is: is Gtk2 thread safe? Which
>toolkit is, if any?

>Michele

Well that is one of the good points about Gtk2 which I did not list.

It does have a "thread-safety mechanism", which appeared releatively
recently, around the 2.8 series of modules. Although it isn't perfect,
it does show that the Gtk2 developers are aware of the problems and
power of threads.

What it does, is allow you to set ( see the thread_usage.pl in the
examples subdir of the Perl/Gtk2 distro).

use Gtk2 qw/-init -threads-init 1.050/;
die "Glib::Object thread safetly failed"
unless Glib::Object->set_threadsafe (TRUE);

then in your threads, in the actual thread code block, you
can do things like below, where you use enter and leave,
to tell the main Gtk2 code that you are dipping into the thread and
are going to modify a widget in the main thread.

Gtk2::Gdk::Threads->enter;
$progress->set_fraction ($i);
$progress->set_text ($i * 100 .'%');
Gtk2::Gdk::Threads->leave;
# we're state employee's, so let's do some 'work'...
sleep $sleep;

This is a great advance, and similar code in Tk will result
in the dreaded "free to wrong pool error" or a segfault.

But as QoS pointed out, with proper precautions, threads can be
successfully used with a main thread containing Tk code, but it is
kind of a hack.

So yes, Gtk2 is thread-safe (with some limitations). I've tested this
quite a bit, and the Gtk2 thread-safety mechanism CAN be very finicky,
but it's a start.

--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

Joe Smith

2006-08-29, 6:59 pm

zentara wrote:

> Why does making a textbox with a black background, (which is easier on
> the eyes), make things hard for the user?

There are "high contrast" themes to make things easier on the
eyes of those who need it. Selecting such a theme makes all
textboxes "easier on the eyes", not just one or two.
-Joe

Jeff Hobbs

2006-08-29, 9:58 pm

zentara wrote:
> The biggest complaint about Tk, is that it is a big hodgepodge
> of independent widgets, whearas Gtk2 is all based on Glib objects.
> This dosn't sound too important yet, but it becomes so when you
> try to sub-class objects and control signalling between them.

I have very few issues subclassing Tk widgets in either pure Tcl (using
snit) or in Perl Tkx.

> Now for the bad news. Perl/Gtk2 can make it very difficult to do
> what is simple in Tk. The most obvious thing is colorization of
> widgets. Gtk2 has a powerful "theme" system, so you can make all your
> apps look like your other Gtk2 apps like mozilla. BUT, that same theme
> system, makes it quite difficult to give custom colors and fonts to
> individual widgets.
> Tk dosn't have that problem.

Yes and no. You can give yourself this problem in Tk as well
(specifically for perl users, with Tcl::Tk or Tkx). Tk has the tile
themed widget extension which provides access to the newer themed native
widgets of OS X and Windows (and even has an extension on itself that
will use the Qt theme engine on unix). Using those of course creates
the same limitations that you see in Gtk2. However, you can always fall
back on the classic Tk widgets for one-offs or other special cases.

--

Jeff Hobbs, The Tk Guy, http://www.activestate.com/

zentara

2006-08-30, 7:59 am

On Tue, 29 Aug 2006 20:35:53 -0700, Jeff Hobbs <jeffh@activestate.com>
wrote:

>
>Yes and no. You can give yourself this problem in Tk as well
>(specifically for perl users, with Tcl::Tk or Tkx). Tk has the tile
>themed widget extension which provides access to the newer themed native
>widgets of OS X and Windows (and even has an extension on itself that
>will use the Qt theme engine on unix). Using those of course creates
>the same limitations that you see in Gtk2. However, you can always fall
>back on the classic Tk widgets for one-offs or other special cases.

Maybe it's my lack of experience as a language developer, but why isn't
it setup so that theme settings are automatically overridden, if a
widget specifies a customization option in it's new declaration.

For instance, if I do
$widget = $mw->new( -bg => 'skyblue' );
it should automatically override the theme.

As it is now, in Gtk2 anyways, I need to find the EXACT (and poorly
documented syntax) for the theme settings for that particular widget.
Override in a local theme file (yes it has to be from disk file) that
particular setting by explicitly nullifying it. THEN cross my fingers
and hope the new setting takes. It is hours and hours of B.S., just
to change a simple widget setting.

Just blowing off pent up steam over this...................... :-)

--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

zentara

2006-08-30, 7:59 am

On Tue, 29 Aug 2006 08:40:56 -0700, Joe Smith <joe@inwap.com> wrote:

>zentara wrote:
>
>
>There are "high contrast" themes to make things easier on the
>eyes of those who need it. Selecting such a theme makes all
>textboxes "easier on the eyes", not just one or two.
> -Joe

Yes, that is true; but what if you have a situation where you want to
introduce a multiude of special colors.... for instance to show the
results of complex regexes on the text? The high-contrast themes
will often mask the desired colors. My point being, Tk has much more
flexibility in this area than Gtk2, and it seems to me that the
inability to easily adjust colors and fonts in individual widgets, gives
the appearance of an incomplete toolbox.

--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

Jeff Hobbs

2006-08-30, 6:59 pm

zentara wrote:
> On Tue, 29 Aug 2006 20:35:53 -0700, Jeff Hobbs <jeffh@activestate.com>
> wrote:
>
>
> Maybe it's my lack of experience as a language developer, but why isn't
> it setup so that theme settings are automatically overridden, if a
> widget specifies a customization option in it's new declaration.
>
> For instance, if I do
> $widget = $mw->new( -bg => 'skyblue' );
> it should automatically override the theme.

Actually, some of the Tk themed widgets do allow that, but not all. It
depends on how "special purpose" the widget was determined to be. For
example, the themed label widget allows fg/bg color changes, but the
themed entry doesn't, while the themed frame allows relief/bd changes,
but the themed button doesn't. Of course, you can create special styles
based on the original. The following sets the invalid state of themed
entries and labels to use a red foreground in Tkx:

# Make invalid state entry/label widget change color scheme
Tkx::style(map => "TEntry", -foreground => [invalid => "red"],
-fieldbackground => [invalid => "yellow"]);
Tkx::style(map => "TLabel", -foreground => [invalid => "red"]);

The state invalid can be controlled automatically through the entry
widget's built-in validation mechanism, or the state method on the
widget. Modifying an existing style works like so:

Tkx::style(default => 'Slim.Toolbutton', -padding => 2);

which just changes the padding of the regular Toolbutton style, and you
would apply like so:

my $slimbtn = $mw->new_ttk__button(-style => "Slim.Toolbutton");

so it's probably still easier than other toolkits, but still "different"
from classic Tk.

--

Jeff Hobbs, The Tk Guy, http://www.activestate.com/

Sponsored Links