RE: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?)

> > I have had various of list (and even day job)
> > complaints that perk/Tk
> > "looks old fashioned".
> 
> As far as I know, all of this is being addressed in
> the latest versions of Tk. Now, we should have native
> support on different platforms, and themes are coming.
> So the situation will change.

Actually Tcl/Tk has 'tile', which makes fully native usage of widgets in
many cases; it is not available in perl/Tk yet.

...

> Jeff seemed to imply that the way Perl/Tk is currently
> implemented makes it a slow process to port the latest
> Tk versions to Perl, and that switching to a "Tcl
> bridge", like Python and other languages, will
> simplify this and make the latest Tk versions readily
> available. That would be really cool.

This is exactly what Tcl::Tk CPAN module does: it is a thin bridge between
perl and Tcl/Tk; it provides same functionality that perl/Tk does, but
instead it gives full Tcl/Tk widgets, and this means a magnitude factor more
widgets compared to perl/Tk, with a less overhead. See
http://mini.net/tcl/13208 , where you'll see mentioned items

I complained few years ago that perl/Tk way of embedding Tk is not optimal,
and then people pointed me to Tcl::Tk, and then I switched to Tcl::Tk
entirely, and then become a CPAN maintainer of that module.

> 
> We could also learn from the Perl6 process. If a
> complete re-write is in the horizon, then I'd love to
> see RFC's from the community, followed by a thorough
> consideration process before any coding is even
> attempted.

I beleive perl6 should go Tcl::Tk way for Tcl/Tk.
Like for any other GUI library -- it is not good to import entire GUI lib
into perl extension, like it was done in perltk, it should link to a library

Vadim.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ptk" to [email protected]