f



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

Ala Qumsieh <ala_qumsieh@yahoo.com> writes:
>--- Nick Ing-Simmons <nick@ing-simmons.net> 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 majordomo@lists.stanford.edu

0
Nick
12/8/2005 2:47:22 PM
comp.lang.perl.tk 4721 articles. 0 followers. pharrendorf (19) is leader. Post Follow

1 Replies
614 Views

Similar Articles

[PageSpeed] 47

Nick Ing-Simmons wrote:
> Ala Qumsieh <ala_qumsieh@yahoo.com> writes:
>> --- Nick Ing-Simmons <nick@ing-simmons.net> 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.

Here is a screenshot of a Perl app using Tkx (which builds on
Tcl::Tk):

http://aspn.activestate.com/ASPN/docs/PDK/PerlApp_gui.html

You'd be hard-pressed to say that looks "old fashioned".

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

As Vadim noted, memory usage is actually reduced and speed is
snappier (possibly in part due to reduced mem usage).  I
worked on the Tcl_Obj <> SV bridge to get the highest
efficiency possible.

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

What is missing in Tcl::Tk is full Perl/Tk compatibility.
Vadim reached 80% I believe, but it does need more work to
support Perl/Tk megawidgets and the like.

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

Tk has great unicode handling, without Xft.  IIUC, if you use
Perl 5.8, then Perl/Tk unicode support works fine.  In any
case, Vadim also uses the Tcl::Tk interface with unicode chars
(again, use Perl 5.8+).  In any case, Tk 8.5 (which will have
the native and themable widgets in the core) also has Xft
support on unix.

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

I'm not sure that OpenGL and SVG are really all that far apart
in the overkill department, especially since OpenGL is "native"
on Windows and OS X.  There are various frustrations that the
canvas should be even more powerful, and some ideas to improve
it.  However, most people usually use Zinc or Togl (another
OpenGL binding for Tk) as the full expressive power of OpenGL is
handy to their needs.

-- 
   Jeff Hobbs, The Tk Guy
   http://www.ActiveState.com/, a division of Sophos
0
Jeff
12/9/2005 4:33:56 PM
Reply:

Similar Artilces:

Re: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?)
--- Nick Ing-Simmons <nick@ing-simmons.net> 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 &g...

Re: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #11
It's not a very serious note what i have to say, but in all the shiny glittery new gui's like qt and gtk(2) and wrappers like wx, somehow, i don;t find perl/Tk looking old fashioned looking, as i have seen other people saying in this discussion, if you take a little care of your xresources file. http://www.toneel.demon.nl/codit_screenshot.png Hans -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 p...

RE: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #13
.... > >Pq (Perl with Qt) project. The syntax is perlTk but > >uses Qt. > > Sounds interesting. > Qt is another option. My preference for gtk is mainly biased by > non-western language support - but I haven't looked at Qt recently. as for yet another usage of perl/Tk syntax, quite usabe will be 'ck', so to have curses application within perl. Ck is tcl extension, making character-based console widgets. What is wrong with non-western language support in perl/Tk or tcl/tk, BTW? -++**==--++**==--++**==--++**==--++**==--++**==--++**== Thi...

Re: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #16
Konovalov, Vadim wrote: > <> > What is wrong with non-western language support in perl/Tk or tcl/tk, BTW? For one, it is currently limited to Character encodings, and limited support of Unicode, unless I missed something. There are other aspects to consider for several langauges. Support for special input methods, bidi support for languages that read right-to-left. Support for diacritics and more complex ligatures which suggest on-the-fly transformations as data is input. Some of these things are lofty goals but are being tackled in other GUI toolkits. CJK langu...

Re: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #12
Paul Falbe <paul@cassens.com> writes: >Now seems a good time to mention some work we've been doing >with froglogic.com. I needed to do some programming for PDAs running >Qtopia. Since, I am better programmer in PerlTk then C++/Qt >I commissioned Harri Porten of froglogic.com to build me >perlTk emmulator if you will using the Qt toolkit instead >of Tk. The project is far enough along that I have a 7300+ >Pq (Perl with Qt) project. The syntax is perlTk but >uses Qt. Sounds interesting. Qt is another option. My preference for gtk is mainly bia...

RE: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #10
> Now seems a good time to mention some work we've been doing > with froglogic.com. I needed to do some programming for PDAs running Very interesting for me (as I do some perlce work on perl too) Yor PDA runs Linux, most probably? > Qtopia. Since, I am better programmer in PerlTk then C++/Qt > I commissioned Harri Porten of froglogic.com to build me > perlTk emmulator if you will using the Qt toolkit instead > of Tk. The project is far enough along that I have a 7300+ > Pq (Perl with Qt) project. The syntax is perlTk but > uses Qt. That is the ...

Re: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #14
Hans Jeuken <haje@toneel.demon.nl> writes: >It's not a very serious note what i have to say, >but in all the shiny glittery new gui's like qt and gtk(2) >and wrappers like wx, somehow, i don;t find >perl/Tk looking old fashioned looking, as i have seen >other people saying in this discussion, >if you take a little care of your xresources file. I well thought out set of xresources can help X11 for sure. Windows might be a little more tricky as core tk (as currently ported) aims to use "native look". A VERY simple project would be to ma...

Re: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #15
Nick Ing-Simmons wrote: >Paul Falbe <paul@cassens.com> writes: > > >>Now seems a good time to mention some work we've been doing >>with froglogic.com. I needed to do some programming for PDAs running >>Qtopia. Since, I am better programmer in PerlTk then C++/Qt >>I commissioned Harri Porten of froglogic.com to build me >>perlTk emmulator if you will using the Qt toolkit instead >>of Tk. The project is far enough along that I have a 7300+ >>Pq (Perl with Qt) project. The syntax is perlTk but >>uses Qt. >...

Re: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #17
On Fri, 2005-12-09 at 21:53, Rob Seegel wrote: > Konovalov, Vadim wrote: > > > <> > > What is wrong with non-western language support in perl/Tk or tcl/tk, BTW? > > For one, it is currently limited to Character encodings, and limited > support of Unicode, unless I missed something. There are other aspects > to consider for several langauges. Support for special input methods, > bidi support for languages that read right-to-left. Support for you're right about right-to-left (bidi), thanks for pointing this. I'm not sure about ...

RE: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #18
Vadim Konovalov <vkonovalov@spb.lucent.com> writes: > >What is wrong with non-western language support in perl/Tk or tcl/tk, BTW? 1. Direction support e.g. right to left for Arabic or Hebrew script, and (I think) vertical for Chinese to have a traditional look. 2. Composite characters - while western scripts typically have precomposed accented characters à and digraphs Æ with other scripts these have to be done by kerning accents into right place relative to base character. 3. Context dependant glyphs - Arabic has one code point represented ...

Re: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #5
On Dec 8, 2005, at 12:50 AM, Jack D. wrote: > Although - I would certainly miss > being able to create pure perl/Tk megawidgets. If that could be > kept then > all the better. We have to maintain that capability - it's most awesome! ;) -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 ...

RE: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #6
> > 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 proce...

RE: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #7
> > So for perl6 (when it comes) I would rather > > write/help-out-with a native perl/XS GUI > > I'm echoing the comments of Ala and Steve. I think the best > route is to > somehow tie into the tcl toolkit instead. Although - I would > certainly miss > being able to create pure perl/Tk megawidgets. If that could > be kept then > all the better. I also think that tieing into the tcl toolkit is a good way. Additionally, I want to mention, that its could be possible to use existing pure perl perlTk megawidgets. perlTk megawidgets are b...

RE: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #9
...... > >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). Memory consumption, and execution speed, are all twice better in Tcl::Tk compared to perl/Tk with "overhead" you mentioned. More precisely, me...

Web resources about - Re: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?) #8 - comp.lang.perl.tk

Resources last updated: 2/6/2016 5:38:24 AM