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

Ala Qumsieh <[email protected]> writes:
>--- 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.

Well perhaps I should take a look at what they are up to.

>
>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"?

Hmm, I suppose that might not be too bad.
Main downside would be extra memory use and overhead
converting to/from Tcl_Obj/SV (current perl/Tk fakes a Tcl_Obj 
object interface as an SV).

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

Point taken.

>
>> The gtk seems to progressing well on unicode font
>> handling etc.

Probably the most-common complaint is that perl/Tk handling of 
non-westen languages is poor. Hence the XFT work, but without 
something like gtk's "pango" it still isn't very good.

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

I haven't tried Zinc yet.
Tk::Canvas irritates me mainly due to its inability to natively "zoom"
(no transformation matrix). One can fake it by reseting every item's 
coords but that is messy. Also zooming fonts is horrible.
OpenGL is massive overkill for this problem, hence the SVG thought.

>
>We could also learn from the Perl6 process. 

You mean how (not) to get something out quickly ;-)

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

Fair point, but it needs guidance and, for me, it is the coding that is "fun".



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