Re: Perl/Tk and Tk 8.5

149 views
Skip to first unread message

Michael Carman

unread,
Jul 8, 2008, 10:46:32 PM7/8/08
to
[Cross-posted to comp.lang.perl.tk with follow-ups set to go there.]

Steve wrote:
> Is there any word on when the enhancements in Tk 8.5 (Tiles, themes,
> better-looking widgets) will be made available in the Perl/Tk port? I
> know that ActiveState has made some of this available for awhile in the
> "Tkx" module, but I'm interested in cross-platform support and am
> wondering when 8.5 will be incorporated in the base "Tk" port module.

Dunno. As Nick Ing-Simmons has passed away I don't know if there will
even be an 8.5 version of Perl/Tk. Slaven Rezic has been doing some
maintenance patches but I haven't had the impression that he (or anyone
else) is interested in doing continued development.

Personally, I've started using Tkx. That's partially because as of 5.10
ActiveState includes Tkx by default but no longer includes Perl/Tk. It's
also partially because I'm horribly sick of the Motif-style and really
wanted the native look available via tiles.

The transition hasn't been too painful -- Tkx is more similar to Perl/Tk
than I had expected. My main beef with it is a lack of good
documentation. Tkx is a thin layer over Tcl and you have to go to the
Tcl docs for almost everything. It can be a little challenging to
translate Tcl (which I don't know) into what you should do in Perl.
Sometimes even the Tcl documentation is sorely lacking.

I'm not terribly optimistic about the long-term prospects for Tkx,
though. Switching from Perl/Tk has been bearable but I can't imagine
trying to start with Tkx. ActiveState needs to put more into
documentation if they want it to catch on. They might not care, though,
as long as they can use it for their own tools (like PPM).

Isn't Tkx cross-platform? I've not tried it but I would expect it to be.

-mjc

smallpond

unread,
Jul 10, 2008, 4:33:46 PM7/10/08
to

I'm curious what people want when they say they want "better-looking"
interfaces. What is important to you?


Color scheme
Rounded corners
Better icons
Separator widget
Control shapes which match other apps
Other


** Posted from http://www.teranews.com **

Michael Carman

unread,
Jul 10, 2008, 8:35:50 PM7/10/08
to
smallpond wrote:
> I'm curious what people want when they say they want "better-looking"
> interfaces. What is important to you?

For me "better looking" means "match the look & feel of the OS." That
means I want native widgets, system fonts and colors, etc. I usually use
Tango [http://tango.freedesktop.org/Tango_Desktop_Project] for my icons.
They aren't "native" but they're easily good enough for me.

-mjc

zentara

unread,
Jul 11, 2008, 8:03:04 AM7/11/08
to
On Fri, 11 Jul 2008 00:35:50 GMT, Michael Carman <mjca...@mchsi.com>
wrote:

Gtk2 calls that themes. But be careful what you ask for..... overriding
the default color scheme in Gtk2 is a difficult thing to do for certain
widgets. Tk makes it soooo easy.

zentara


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

smallpond

unread,
Jul 11, 2008, 3:44:53 PM7/11/08
to

The tradeoff is portability. Not only would we need to port the framework
to run on top of a different widget set on each desktop manager, but also
each app is going to look funky when the sizes and shapes of the elements
change.

Personally, I think I prefer having the widgets be drawn by perl/Tk so
they are consistent. But they could stand to be updated with some better
icon and control art.

Steve

unread,
Jul 12, 2008, 3:55:27 PM7/12/08
to
> I'm curious what people want when they say they want "better-looking"
> interfaces. What is important to you?


Matching the look and feel of the native OS. Period.

When I write an application, I want it to behave and appear like it
belongs alongside the other applications running on that system.
Sometimes you might want some crazy, borderless, "skinnable" interface
for something like a snazzy media player app. However, the other 99% of
the time, you want it to look like other native apps. Toolkits with
their own custom-drawn widgets, unless they're completely revamped
almost annually, quickly take on a stale and outdated look.

Even if you do keep your look and feel "fresh", the difference in look
and feel from native apps makes your applications seem amateurish to
common users. Take Java, for example. There have been native Java
compilers for a decade or more now, which deliver reasonable execution
speed for desktop apps. Nevertheless, Java never caught on as a desktop
app language... because Swing just doesn't "look right". Only in the
past few years have you started to see serious development of desktop
Java apps, and that coincides with the rise of Eclipse and its SWT
framework... which relies on native GUI widgets.

GTK and Qt get away with having their own look and theme capabilities
because they basically ARE the "native" widgets in the *nix world.
However, GTK apps look out of place when ported to Windows, which is why
the wxWidgets framework (using native widgets) is so popular for
cross-platform development.

I understand that custom-drawn widgets might be easier from a
portability standpoint for the developer of the widget framework. Since
I'm not personally volunteering to re-write Tk or Perl/Tk, I don't
begrudge you that. Nevertheless, the jury has firmly returned its
verdict that native-widget frameworks are more appealing to average
users... and it's silly to pretend that this isn't the case.

smallpond

unread,
Jul 12, 2008, 5:52:33 PM7/12/08
to

Then just use the Win32 module and be done with it. There's
no point in trying to make a cross platform toolkit run on
top of 5 different OS with 5 different widget sets. It will
always be missing the features "needed" on the OS you want
to run on.

Steve

unread,
Jul 12, 2008, 7:15:29 PM7/12/08
to
> Then just use the Win32 module and be done with it. There's
> no point in trying to make a cross platform toolkit run on
> top of 5 different OS with 5 different widget sets. It will
> always be missing the features "needed" on the OS you want
> to run on.

The problem with that is that it's, by definition, limited to Microsoft
Windows. That is useless for writing a GUI app than can be run across
multiple platforms.

I can always use the wxPerl bindings for wxWidgets, which is an
approach I've started moving toward. The problem with that is that wx
is relatively enormous, provides an army of core utility classes and GUI
widgets that I have no use for, and requires a bunch of dependencies
that can make it a pain to install (and/or package up with something
like PAR). I sometimes write GUI Java apps using SWT and compile
natively using GCJ, which works great... but the problem with that is
that it takes me 10 lines of Java code to do what would take a couple of
lines in Perl.

You have a point in that no cross-platform GUI framework is going to be
able to exploit EVERY exotic feature available in every native
platform... whether it uses native OR custom-drawn widgets. However, so
what? Tk doesn't come close to this level of completeness as it is. I
just believe there is a need for a small and simple GUI framework that
looks native, yet is low-dependency and either comes standard with Perl
or is trivial to install. Tk is an ideal candidate for this, as it's
already pervasive in Perl installations. Also, base Tcl/Tk itself
started moving toward the native approach in 8.5 with Tile... so it
seems odd to suggest that the Perl bindings should permanently fork off
or stay behind rather than follow the underlying library.

smallpond

unread,
Jul 13, 2008, 9:39:15 AM7/13/08
to

So, to sum up your wishes:

- uses native widgets, but has few dependencies
- has all the features that you need, but doesn't have all those extra
features
- cross platform, but trivial to install
- able to match look and feel of native apps, but is small and simple
- and free and available real soon and you aren't interested in doing
any of the work

OK, get right on it, anything else?
Are you sure you wouldn't be happy with:

$mw->bisque;

Steve

unread,
Jul 13, 2008, 10:41:50 AM7/13/08
to
> So, to sum up your wishes:
>
> - uses native widgets, but has few dependencies
> - has all the features that you need, but doesn't have all those extra
> features
> - cross platform, but trivial to install
> - able to match look and feel of native apps, but is small and simple
> - and free and available real soon and you aren't interested in doing
> any of the work


What I would like is a Perl equivalent to the SWT framework in the Java
world.

- It has all the features that I need, which is to say that it has all
the features that Perl/Tk currently offers. You act like I'm calling
for some serious expansion in functionality. I am not. Perl/Tk's
feature set is fine.

- It consists of one native-code shared library, and one Java archive
(i.e. Perl module) containing the bindings to that shared library. You
copy those two files to the same directory as your application, and
you're done. When I talk about installation and dependency issues...
I'm talking about a module depending on a dozen different modules, which
in turn depend on a dozen each. That makes it hard to bundle up with
something like PAR for distribution, which is oftentimes the whole point
of doing a GUI app with Perl. Most of the cross-platform complexity
you're talking about should occur at the native-code shared library
level. I'm just saying that you shouldn't have to install dozens of
Perl modules to get rolling with a GUI framework, and no issues you've
raised with cross-platform support suggest that this would be necessary.


Let me see if I can sum up YOUR wishes:

- To receive no feedback or suggestions on Perl/Tk development, unless
it coincides with your own opinions.
- For anyone who does not agree with you to take over development, start
their own fork, or otherwise just go away.
- To remain on a custom-drawn widget model indefinitely, despite the
fact that the underlying Tcl/Tk we're binding to is going in the other
direction.

As you say, I'm not jumping in to code, so your prerogatives matter
more than mine here. However, I'm just stating the obvious. Perl/Tk
has been the de facto standard for ages. However, it's fallen behind
and seen its approach superseded, coders are increasingly turning to GTK
or wxPerl instead, and this newsgroup draws about two new threads a week
at best. Even the Tcl/Tk base project itself has recognized and started
adapting to this. If the Perl/Tk maintainers have no problem with
irrelevance as the price for familiarity, then that's certainly their
right. However, that IS the fork in the road here.

Steve

unread,
Jul 13, 2008, 11:38:37 AM7/13/08
to
By the way, can you perhaps elaborate on what added complexity is
required at the Perl level? Perl/Tk is not a new GUI framework written
specifically for Perl. I understand it to be a set of Perl bindings to
Tk as implemented in Tcl/Tk. To what extent does Perl/Tk modify Tcl/Tk,
as opposed to simply writing a Perl wrapper around it?

If the underlying Tcl/Tk library is moving toward transparently
replacing its current widgets with native versions, then will not this
change be reflected in Perl/Tk... so long as it continues to use recent
versions of Tcl/Tk as its base?

Michael Carman

unread,
Jul 13, 2008, 1:40:30 PM7/13/08
to
Steve wrote:
> To what extent does Perl/Tk modify Tcl/Tk, as opposed to simply
> writing a Perl wrapper around it?

AFAIK Perl/Tk doesn't modify Tcl/Tk, but it does provide some
extensions. For example, there's no read-only text widget in Tk.

> If the underlying Tcl/Tk library is moving toward transparently
> replacing its current widgets with native versions, then will not
> this change be reflected in Perl/Tk... so long as it continues to use
> recent versions of Tcl/Tk as its base?

Unfortunately, this is wrong on a multiple levels.

1) The Tile support in Tk 8.5 is through an additional widget set. It is
not a transparent replacement of the existing ones.

2) From what I've read of the Perl/Tk implementation, it was
written as a set of deep custom bindings (for performance reasons). This
means that updating Perl/Tk to a new version of Tk is not a simple task.

3) Nick Ing-Simmons (the author and AFAIK only real developer of
Perl/Tk) has passed away. Slaven Rezic appears to have taken over
maintenance but I haven't seen signs of him (or anyone else) wanting to
continue development.

-mjc

Steve

unread,
Jul 13, 2008, 1:49:30 PM7/13/08
to
> 1) The Tile support in Tk 8.5 is through an additional widget set. It is
> not a transparent replacement of the existing ones.

Understood. However, the point I was making is that the Tcl/Tk guys
are using Tiles as a transitional step. The eventual goal is to replace
the standard widget set with the Tile equivalents. I'm not suggesting
that Perl/Tk should jump ahead of this, but simply adopt more recent
versions of Tcl/Tk and reap the benefit as that effort is completed.


> 2) From what I've read of the Perl/Tk implementation, it was
> written as a set of deep custom bindings (for performance reasons). This
> means that updating Perl/Tk to a new version of Tk is not a simple task.
>
> 3) Nick Ing-Simmons (the author and AFAIK only real developer of
> Perl/Tk) has passed away. Slaven Rezic appears to have taken over
> maintenance but I haven't seen signs of him (or anyone else) wanting to
> continue development.

I'm sad to hear about Ing-Simmons. However, neither of these points
speak to the pros or cons of ongoing compliance with the progress of
Tcl/Tk. They just say that Perl/Tk is a one-man project with no current
developer interest, that is unlikely to move forward in any direction at
all. That's a real shame.

Michael Carman

unread,
Jul 13, 2008, 3:07:43 PM7/13/08
to
Steve wrote:
> the Tcl/Tk guys are using Tiles as a transitional step. The eventual
> goal is to replace the standard widget set with the Tile equivalents.

I hope that's true but I think that the interim step will hurt them (in
terms of user-base) in the long run. I imagine that there was a good
reason from a development standpoint but all users will see is a
fragmented toolkit that requires rework to get the best results.

> neither of these points speak to the pros or cons of ongoing
> compliance with the progress of Tcl/Tk.

The direction that Perl/Tk should go is irrelevant if there's nobody to
do the work.

> They just say that Perl/Tk is a one-man project with no current
> developer interest, that is unlikely to move forward in any direction
> at all. That's a real shame.

Agreed. I keep hoping that someone will chime in and tell me that I'm wrong.

-mjc

smallpond

unread,
Jul 13, 2008, 7:19:40 PM7/13/08
to


perl/tk is not a binding to Tk, it is a port of Tk source to perl.
Nick I-S had partially automated this to keep up with updates,
but Tk 8.5 is not an update. The file names are changed with
the whole ttk tree added. It would be a new port from scratch.
Given that perl/Tk source is about 2500 files, that would be
a lot of work. Plus it looks as though all of the contributed
widgets and code that have been done would have to change,
since all of the style code is moved out of the widget code
and centralized.

I think that you are correct that many users want a native
widget set, the problem is that there is no cross-platform
way of providing this. There may be some common features at
the gross level - they all use buttons, frames, etc. But as
soon as you look closely, the semantics are different. And
a UI that only supports the common features won't satisfy
anyone.

As for perl/Tk I can't speak for where it will go. I'm just
a hobbyist, not a maintainer. I think patch sets can still
be created if there are features that people want to add and
enough interest. But at this late stage, doing a non-backward-
compatible change to perl/tk to support only Windows users is
unrealistic and not likely to be accepted.

--S

Jeff Hobbs

unread,
Jul 14, 2008, 1:13:14 AM7/14/08
to
On Jul 13, 10:40 am, Michael Carman <mjcar...@mchsi.com> wrote:
> Steve wrote:
> > To what extent does Perl/Tk modify Tcl/Tk, as opposed to simply
> > writing a Perl wrapper around it?
>
> AFAIK Perl/Tk doesn't modify Tcl/Tk, but it does provide some
> extensions. For example, there's no read-only text widget in Tk.

As noted elsewhere in this thread, Perl/Tk was a re-binding of Tk onto
Perl that replaced the Tcl part with Perl (C/Perl).

> > If the underlying Tcl/Tk library is moving toward transparently
> > replacing its current widgets with native versions, then will not
> > this change be reflected in Perl/Tk... so long as it continues to use
> > recent versions of Tcl/Tk as its base?
>
> Unfortunately, this is wrong on a multiple levels.
>
> 1) The Tile support in Tk 8.5 is through an additional widget set. It is
> not a transparent replacement of the existing ones.

Correct, because native widgets are not 1:1 with user-drawn
(traditional) widgets. The native ones are theme based and can
provide a high degree of compatibility, but not 100%.

> 2) From what I've read of the Perl/Tk implementation, it was
> written as a set of deep custom bindings (for performance reasons). This
> means that updating Perl/Tk to a new version of Tk is not a simple task.

The performance part is a misconception. Tkx (reintroducing the Tcl
binding) is both faster and more memory efficient, not to mention more
flexible. This was enabled when people with both deep Perl and Tcl
knowledge (at ActiveState) got together to make a low-level Tcl to
Perl C object translator.

> 3) Nick Ing-Simmons (the author and AFAIK only real developer of
> Perl/Tk) has passed away. Slaven Rezic appears to have taken over
> maintenance but I haven't seen signs of him (or anyone else) wanting to
> continue development.

I communicated with Nick before he passed away and we discussed the
merits of keeping Perl/Tk as is versus doing Tkx. While Slaven does a
good job keeping Perl/Tk up-to-date, I still believe that Tkx is the
way to go. There is also the possibility of the Perl-Tcl/Tk binding
that has 100% Perl/Tk compat. There is a part of this already in
Vadim's work, he just never went beyond proof of concept because he
used a different syntax.

What we ship in ActivePerl (and is used by the PPM UI as well as the
Perl Dev Kit UIs) uses Tkx with a single-file tkkit with all the bits
and more to do what Perl/Tk offered.

Jeff

Michael Carman

unread,
Jul 14, 2008, 10:12:27 PM7/14/08
to
Jeff: Thank you for joining the conversation. There don't seem to be
many people in a position to speak authoritatively about the newer Tk
bindings so it's great to have you here.

Jeff Hobbs wrote:
> native widgets are not 1:1 with user-drawn (traditional) widgets. The
> native ones are theme based and can provide a high degree of
> compatibility, but not 100%.

Are there plans to merge the two widget sets? It would be much nicer to
just create a button, optionally with a global setting to use themed
widgets where available. One of the things that has irked me is that
built in megawidgets like dialog boxes *don't* use tile, which means I
have to either be inconsistent or build my own.

> While Slaven does a good job keeping Perl/Tk up-to-date, I still
> believe that Tkx is the way to go.

It seems to me that in the long run Perl/Tk is a dead end. The question
I'm asking myself is should I move to Tkx, wxPerl, Win32::GUI, ...

> There is also the possibility of the Perl-Tcl/Tk binding that has
> 100% Perl/Tk compat. There is a part of this already in Vadim's work,
> he just never went beyond proof of concept because he used a
> different syntax.

That's Tcl::Tk, right? I'd be delighted to have an easier migration path
to get the newer Tk goodies. I'd even be willing to help.

> What we ship in ActivePerl (and is used by the PPM UI as well as the
> Perl Dev Kit UIs) uses Tkx with a single-file tkkit with all the bits
> and more to do what Perl/Tk offered.

My primary issue with Tkx is a lack of good documentation. "Go read the
Tcl docs" is fine for people with a Tcl background but rather rough on
Perl folk, particularly when you're trying to translate everything from
a language you don't know into an API you don't (yet) understand. Tkx is
bearable as a migration path from Perl/Tk but unless the documentation
improves I don't see it gaining traction amongst people who haven't done
GUI programming in Perl before.

In some cases even the Tcl docs are lacking. The PPM GUI appears to make
use of undocumented features (e.g. the C<-style => 'Toolbutton'> option
for ttk buttons). The snit stuff is even worse; it doesn't appear to be
documented at all. In a couple of cases I've used
C<$w->info('body', 'methodname')> to get the Tcl source in order to
figure out what a method does, the options it takes, etc.

-mjc

Jeff Hobbs

unread,
Jul 15, 2008, 2:17:16 AM7/15/08
to
On Jul 14, 7:12 pm, Michael Carman <mjcar...@mchsi.com> wrote:
> Jeff Hobbs wrote:
> > native widgets are not 1:1 with user-drawn (traditional) widgets. The
> > native ones are theme based and can provide a high degree of
> > compatibility, but not 100%.
>
> Are there plans to merge the two widget sets? It would be much nicer to
> just create a button, optionally with a global setting to use themed
> widgets where available.

As you may know, the themed widgets are the tile widget set in 8.4 and
in the core in 8.5. During the development of tile, experimenting
with theming in general and how to tie it best with Tk, the widget set
was designed to be largely replaceable. That is to say you could do
what you wanted above and have 100% compatibility with Tk "classic"
widget options. However, not all options were actually adhered to -
some were ignored, some meant something slightly different. Oddities
like "highlightthickness" meant little to a themed widget, and the
handling of background on some widgets could be meaningless as well
(eg, jelly buttons on OS X).

It was decided in prep for core inclusion to give full meaning to both
sides of the equation - "classic" Tk widgets that are all "owner-draw"
and can be utilized still in many clever ways, and "native" themed Tk
(Ttk) widgets that had a theming engine and a different set of
options. For the most part, simple applications can use either with
little to no modification. Take buttons as an example, they both have
-text, -command, -image, and -compound. When it comes to special
cases like a button in a toolbar, the Tk classic button had earned
options over time to style it appropriately. With Ttk, you instead
use -style Toolbutton for the same effect.

> One of the things that has irked me is that
> built in megawidgets like dialog boxes *don't* use tile, which means I
> have to either be inconsistent or build my own.

Yes, in core Tk 8.5 the dialogs make use of Ttk elements. BTW, while
ActivePerl currently comes with Tk 8.4 + Tile for Tkx, the next
releases will be Tk 8.5-based.

> > While Slaven does a good job keeping Perl/Tk up-to-date, I still
> > believe that Tkx is the way to go.
>
> It seems to me that in the long run Perl/Tk is a dead end. The question
> I'm asking myself is should I move to Tkx, wxPerl, Win32::GUI, ...

The real answer is up to you. The latter is one platform only of
course. At ActiveState we did a similar analysis and decided moving
forward with Tkx as the best overall solution (this was for PDK 7
which introduced UIs to most of the tools).

> > There is also the possibility of the Perl-Tcl/Tk binding that has
> > 100% Perl/Tk compat. There is a part of this already in Vadim's work,
> > he just never went beyond proof of concept because he used a
> > different syntax.
>
> That's Tcl::Tk, right? I'd be delighted to have an easier migration path
> to get the newer Tk goodies. I'd even be willing to help.

Yes, contact Vadim - he is usually responsive and can update you as to
the current status of his experiments.

> > What we ship in ActivePerl (and is used by the PPM UI as well as the
> > Perl Dev Kit UIs) uses Tkx with a single-file tkkit with all the bits
> > and more to do what Perl/Tk offered.
>
> My primary issue with Tkx is a lack of good documentation. "Go read the
> Tcl docs" is fine for people with a Tcl background but rather rough on
> Perl folk, particularly when you're trying to translate everything from
> a language you don't know into an API you don't (yet) understand. Tkx is
> bearable as a migration path from Perl/Tk but unless the documentation
> improves I don't see it gaining traction amongst people who haven't done
> GUI programming in Perl before.

I understand and can only agree. We've talked about and rued the lack
of docs internally as well. It's not an easy task, but I'm sure there
are some ways to mitigate the issue with better "transition" docs.

> In some cases even the Tcl docs are lacking. The PPM GUI appears to make
> use of undocumented features (e.g. the C<-style => 'Toolbutton'> option
> for ttk buttons). The snit stuff is even worse; it doesn't appear to be
> documented at all. In a couple of cases I've used
> C<$w->info('body', 'methodname')> to get the Tcl source in order to
> figure out what a method does, the options it takes, etc.

snit is pretty well documented:

http://docs.activestate.com/activetcl/8.4/tcllib/snit/snit.html
http://docs.activestate.com/activetcl/8.4/tcllib/snit/snitfaq.html

but it really depends on what you are creating with it. It is not
core, but rather convenience. Toolbutton is admittedly
undocumented ... have to change that. This should all be consolidated
in Tk 8.6 (target end of year) which has a new built-in OO system that
is snit-based with extra features. With that a new core megawidget
system will be incorporated that would have full core docs as well.

Jeff

John Cerney

unread,
Jul 15, 2008, 8:36:13 AM7/15/08
to

Jeff Hobbs wrote:
> There is also the possibility of the Perl-Tcl/Tk binding
> that has 100% Perl/Tk compat. There is a part of this already in
> Vadim's work, he just never went beyond proof of concept because he
> used a different syntax.

I have been looking at Vadim's Tcl::Tk module with the intent of
upgrading it to provide 100% perl/tk compatibility.

I think it is possible to provide 100% compatibility, and as a
proof-of-concept, have successfully added support for perl/tk megawidgets.

If perl/tk source won't be updated for tcl/tk 8.5, maybe a update to
Tcl::Tk to be 100% perltk-sytax compatible could be the next perltk
version. I would be willing to help with this effort.

The Tcl::Tk approach would provide syntax compatibility for existing
perltk widgets, and also give people access to the tile widgets and
other native tcl/tk widgets. This could potentially be the best-of-both
worlds approach.

-John

Jack D

unread,
Jul 18, 2008, 12:48:12 AM7/18/08
to
"John Cerney" <j-cerney1Remo...@raytheon.com> wrote in message
news:2R0fk.1$yC...@dfw-service2.ext.ray.com...

Now that is the "best" news I have heard thus far. If you could maintain
perl/Tk syntax and allow support for megawidgets and use the underlying
tcl/tk releases - helloooooo ? Yes!!

I don't know how Tcl::Tk really works but I'm wondering if it would need
"upgrading" upon every release of tcl/tk?

Jack


Jeff Hobbs

unread,
Jul 18, 2008, 2:43:58 AM7/18/08
to
On Jul 17, 9:48 pm, "Jack D" <j...@home.net> wrote:
> Now that is the "best" news I have heard thus far. If you could maintain
> perl/Tk syntax and allow support for megawidgets and use the underlying
> tcl/tk releases - helloooooo ? Yes!!
>
> I don't know how Tcl::Tk really works but I'm wondering if it would need
> "upgrading" upon every release of tcl/tk?

Upgrading is only necessary if core Tcl/Tk fixes are required for
whatever derivative work you create. The same was true for Perl/Tk,
which had to go through the manual translation layer. For Tcl::Tk, it
is simply acquire new Tcl/Tk and go. In ActivePerl, the Tcl/Tk
portion is actually all delivered in one single dll/so file.

Jeff

Michael Carman

unread,
Jul 18, 2008, 9:43:38 PM7/18/08
to
Jeff Hobbs wrote:
> For Tcl::Tk, it is simply acquire new Tcl/Tk and go. In ActivePerl,
> the Tcl/Tk portion is actually all delivered in one single dll/so
> file.

Really? Tcl::Tk isn't available via PPM (Perl 5.10.0 build 1002). I
started to install it manually from CPAN but it died looking for tclsh.
It appears to require a separate Tcl installation. Is there any way to
get it to use the tkkit that Tkx uses?

I don't really care to install Tcl, particularly as my primary
motivation for building GUIs is so that I can distribute my applications
to others and I like to minimize dependencies.

-mjc

Jeff Hobbs

unread,
Jul 19, 2008, 12:52:57 PM7/19/08
to je...@activestate.com

I'll look into Tcl::Tk, but the Tk portion is pure Perl, with all the
C bindings in Tcl, which Tkx also requires. The Tcl module does use
the tkkit, so Tcl::Tk would as well when installed.

Jeff

Reply all
Reply to author
Forward
0 new messages