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

--- Nick Ing-Simmons <[email protected]> wrote:

> 
> 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.

> Also tracking/converting Tcl/Tk is a pain (and core
> Tk is where 
> most of the "look" comes from).
> 
> So for perl6 (when it comes) I would rather
> write/help-out-with a 
> native perl/XS GUI - perhaps by wrapping gtk2. 

This seems, to me at least, like a very hefty job. I'm
not saying that you/we should shy away from it, but
that we should think about it carefully. At the rate
Perl6 is going, I guess we have a long enough time :)

One thing that was mentioned a few times here, mostly
by Jeff Hobbs, was that Perl/Tk was the only Tk port
that didn't "tie in through Tcl". You also mentioned
in a previous post that Perl/Tk doesn't use Tcl_Obj,
primarily because it was lacking when you starting
working on pTk. Now, to be honest I don't know what
any of this means in detail. But, since Tk is
progressing at a healthy pace, isn't it a better idea
to re-write pTk so as to "tie in through Tcl and use
Tcl_Obj"?

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.

I believe you have done a tremendous job so far, but I
also think that pTk has picked up a lot of cruft over
the years, and perhaps a re-write would be the best
solution. Having spent so much time with Tk has taught
you/us a lot. We know its
strengths/weaknesses/limitations/etc. Switching to a
different GUI toolkit carries the risk of making us
fall into the same traps again.

> The gtk seems to progressing well on unicode font
> handling etc.
> There is at least a "render" library for SVG which
> would be a start
> towards a Canvas replacement and/or we could go 3D
> and use OpenGL 
> (which is usually available somehow these days).

Tk::Zinc has native OpenGL support. It is not a 100%
drop-down replacement for Canvas, but it comes very
close. Also, there was talk about an SVG widget, but
I'm not sure about the status.

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.

--Ala



		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]