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