Re: Any thoughts on the Tcl::Tk bridge?

>What kind of surprises? (hmm - if you knew what they were, then they
>wouldn't be surprises)
>
>  
>

by this I mean concrete thing.
namely, sometimes Tcl::Tk interpreter function returns in scalar context 
different thing compared to array context.

this usually does not surprise perl programmer, but in Tcl::Tk context 
sometimes you get something that c ould differ on what you expect.
When you write
$result = $widget->method(-someting=>'fluffy');
this roughly translates to.
$result = $interp->Eval(".widgetpath method -something fluffy");
and this usually works as expected.
However sometimes $result is another widget, and you need another wrap of
$my_widget = $interp->widget($result);
Additionally, when Tcl/Tk returns a list of something, then it sometimes 
should be interpreted differently than support layer guesses.

But those are really rare cases and could easily be controlled, and 
probably subject to different mailing list.
(however while searching list archives I found some Malcolm's postings 
related to his modules Tcl and Tcl::Tk here, on ptk list)

But, arguing from other side, I once again claim that finding widget 
misbehaviour with perl+Tcl::Tk is much easier compared to perlTk.
This is my own expereince, and I can show my argumentation on this point 
in more details, if you wish.

>>To finalize a bit, take a look how Ruby and Python do Tk GUI. 
>>They do it via Tcl, just like Tcl::Tk does.
>>My feelings is by this way you can get more in less efforts.
>>    
>>
>
>This sounds too good to be true. Do you mean we can use *any* tcl widget but
>still use *only* perl?
>
yes. you do not need to go into Tcl/Tk syntax.
But I need to explain a bit in more detail here.
Suppose you have some complicated Tcl/Tk widget with tricky interface.
In order to realize how to deal with it from Perl, Tcl/Tk knowledge 
could be required sometimes.
So you call an expert who understands both sides, and after that, once 
widget's behaviour was understood, he can explain how to use that widget 
in Perl-only way for people without any Tcl/Tk knowledge.
After proper documentation will be written, it could be understood by 
perl-only afterwards.
No Tcl/Tk coding, just documentation

On the other side, very few people really understands entire perlTk.
Can you tell me how to use -name option from perldoc Tk::options manual? 
pathname? You can not assign those randomly, only by some rules, those 
are assigned internally using some rules, those are hierarchically and 
rarely used. Can you explain by which rules those are assigned? Going 
that deep, will do things more complex. Going same way in Tcl::Tk will 
help you understanding widget mechanics, w/o complexity.


> Will the polishing of this module mark the beginning
>of the end for perl/Tk?
>
Tcl::Tk was not intended to mark beginning of the end for perl/Tk. I 
started using such another approach because I did not found some 
important for me features in perlTk.


> While tcl widgets are many and some quite unique -
>I'm sure that there are composite widgets being coded all the time. Will
>  
>
>Tcl::Tk will also allow us to create composite widgets using perl?
>
>  
>
Actually there is a way to do composite widgets using perl right now, 
but this is not properly documented.
(By this I mean - Tcl::Tk is pure-perl and it *does* some widgets, which 
are composite, e.g.Scrolled)

Still, undecided which way of creating pure-perl widgets will be 
"official", but, as I already pointed out, there are strong plans on it 
at http://sourceforge.net/mailarchive/message.php?msg_id=10360308

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]