f



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 
> 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 majordomo@lists.stanford.edu

0
Ala
12/6/2005 11:08:05 PM
comp.lang.perl.tk 4721 articles. 0 followers. pharrendorf (19) is leader. Post Follow

0 Replies
821 Views

Similar Articles

[PageSpeed] 11

Reply:

Similar Artilces:

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 ?) #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 ?) #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 ?) #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 ?) #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, ...

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 ?) #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 ?) #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 ?) #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 ?) - comp.lang.perl.tk

Resources last updated: 2/6/2016 5:43:47 AM