Home > Archive > PerlTk > January 2005 > Any thoughts on the Tcl::Tk bridge?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Any thoughts on the Tcl::Tk bridge?
|
|
| Rob Seegel 2005-01-05, 3:58 pm |
| I realize that this is Perl/Tk mailing list, and that it's probably been
quiet due to the holidays, but there really hasn't been a whole lot said
about the Tcl::Tk work currently underway -- even on their mailing list.
I've got mixed feelings about it, and I haven't really made up my mind
about it, yet.
On one hand, it seems like a good thing to reduce the turnaround time
needed to take advantage of not only the latest Tk version, but also
other Tcl/Tk packages, such as BWidgets, but on the other hand, I'm not
wild about maintaining a Tcl/Tk distribution in addition to the Perl
one, and ensuring it any other related packages are up to date and in sync.
A nice thing about the Perl/Tk widgets, is that most of the bindings and
some additional behavior was done directly in Perl. These modules served
as useful examples of how other modules might be coded. It's how I
started learning. I don't relish the thought of these modules being
written in Tcl. I initially started out learning Tcl years ago, not
because I liked Tcl, but because I found it useful in quickly building
user interfaces. I preferred Perl, and didn't look back when I found
that Tk had been ported to Perl. This isn't a knock on Tcl, it's just a
preference.
Has anyone else done much with it, yet?
Rob
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 majordomo@lists.stanford.edu
| |
| Vadim Konovalov 2005-01-06, 3:59 pm |
| > On one hand, it seems like a good thing to reduce the turnaround time
> needed to take advantage of not only the latest Tk version, but also
> other Tcl/Tk packages, such as BWidgets, but on the other hand, I'm not
to look at another points, please see URL http://mini.net/tcl/13208
which covers Tcl::Tk module specific compared to perlTk
> wild about maintaining a Tcl/Tk distribution in addition to the Perl
> one, and ensuring it any other related packages are up to date and in sync.
it appears to be easy: you can have entire Tcl/Tk installation (with
Tix, Bwidgets, and everything else) within any of your directory (within
directory where Tcl::Tk module is, for example)
All you need is to just point one of configuration variables
I'll provide details if needed.
I have a technique to have all Tcl/Tk inside single ZIP and so to have
excellent moveable distribution, I can share this technique as well
(within Tcl::Tk mailing list, to be on-topic)
>
> A nice thing about the Perl/Tk widgets, is that most of the bindings and
> some additional behavior was done directly in Perl. These modules served
> as useful examples of how other modules might be coded. It's how I
> started learning. I don't relish the thought of these modules being
> written in Tcl. I initially started out learning Tcl years ago, not
good point -- to learn by example.
Perl/Tk widgets are not currently supported by Tcl::Tk, but:
- it looks like there are strong plans to it: see
http://sourceforge.net/mailarchive/...msg_id=10360308
- on the real life, I feel more comfortable with bigger library of
Tcl/Tk megawidgets, it fulfills most of my requirements. To make an
analogy, Perl does not allow inline assembler, however C does. Does it
mean C is better? :) For me, perl allows more and I rarely go to C
level...
> because I liked Tcl, but because I found it useful in quickly building
> user interfaces. I preferred Perl, and didn't look back when I found
> that Tk had been ported to Perl. This isn't a knock on Tcl, it's just a
> preference.
>
> Has anyone else done much with it, yet?
For me, I now have both perlTk and Tcl::Tk installed, but more and more
I use Tcl::Tk, just because I have what I had before and additionaly
some other powerful techniques.
See for example
http://www.vkonovalov.ru/vtcl-usage...I_for_Perl.html
On the other side, when using Tcl::Tk, one must be prepared to some
surprises, which are hopefully not hard to solve.
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.
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 majordomo@lists.stanford.edu
| |
| sigzero@gmail.com 2005-01-08, 3:57 am |
|
Vadim Konovalov wrote:
time[color=darkred]
also[color=darkred]
not[color=darkred]
>
> to look at another points, please see URL http://mini.net/tcl/13208
> which covers Tcl::Tk module specific compared to perlTk
>
>
Perl[color=darkred]
in sync.[color=darkred]
>
> it appears to be easy: you can have entire Tcl/Tk installation (with
> Tix, Bwidgets, and everything else) within any of your directory
(within
> directory where Tcl::Tk module is, for example)
> All you need is to just point one of configuration variables
> I'll provide details if needed.
>
> I have a technique to have all Tcl/Tk inside single ZIP and so to
have
> excellent moveable distribution, I can share this technique as well
> (within Tcl::Tk mailing list, to be on-topic)
>
>
bindings and[color=darkred]
served[color=darkred]
[color=darkred]
[color=darkred]
>
> good point -- to learn by example.
>
> Perl/Tk widgets are not currently supported by Tcl::Tk, but:
> - it looks like there are strong plans to it: see
> http://sourceforge.net/mailarchive/...msg_id=10360308
> - on the real life, I feel more comfortable with bigger library of
> Tcl/Tk megawidgets, it fulfills most of my requirements. To make an
> analogy, Perl does not allow inline assembler, however C does. Does
it
> mean C is better? :) For me, perl allows more and I rarely go to C
> level...
>
building[color=darkred]
found[color=darkred]
just a[color=darkred]
>
> For me, I now have both perlTk and Tcl::Tk installed, but more and
more
> I use Tcl::Tk, just because I have what I had before and additionaly
> some other powerful techniques.
>
> See for example
>
http://www.vkonovalov.ru/vtcl-usage...I_for_Perl.html
>
> On the other side, when using Tcl::Tk, one must be prepared to some
> surprises, which are hopefully not hard to solve.
>
> 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.
>
>
> Vadim.
>
I wish Perl/TK would move lock, stock and barrel over to Tcl::Tk.
Robert
|
|
|
|
|