Home > Archive > PerlTk > December 2005 > Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?)
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 |
Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?)
|
|
| Nick Ing-Simmons 2005-12-06, 7:02 pm |
|
I have had various of list (and even day job) complaints that perk/Tk
"looks old fashioned".
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.
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).
There is an existing Gtk2 perl module, but I haven't tried it yet, and
of course it has a different API.
(A quick read suggests it is lower level than perl/Tk, but I may be doing it
an injustice. But if true and it does not get horribly messy perhaps
we can fake perl/Tk API on top.)
Have any of you tried perl/Gtk2?
Do you prefer gtk2 "look"? - e.g. Gimp / inkscript etc.
(Does gtk2 work on Mac?)
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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
| |
| Dean Arnold 2005-12-06, 7:02 pm |
| Nick Ing-Simmons wrote:
> I have had various of list (and even day job) complaints that perk/Tk
> "looks old fashioned".
>
> 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.
>
> 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).
>
> There is an existing Gtk2 perl module, but I haven't tried it yet, and
> of course it has a different API.
> (A quick read suggests it is lower level than perl/Tk, but I may be doing it
> an injustice. But if true and it does not get horribly messy perhaps
> we can fake perl/Tk API on top.)
>
Just a couple thoughts:
1) Perhaps a quick survey of which Tk (and pTk) widgets look
a bit dated might be of value. Its possible that just a few
widget changes might improve things signficantly (hence, my
current attempts at a simple solution for buttons and notebooks).
The only other widget (behavior, actually) which I consider very
dated is the D&D images; and maybe some of the system bitmaps for
cursors, error dialogs, etc. A few other areas (e.g., image rendering)
could use better i/f's and maybe a few features (e.g., better support
for transparent colors in widgets, maybe an alpha channel capability)
2) I haven't used gtk2, but did some research for Win32 and haven't
been convinced its ready on that platform yet, nor am I certain
the GIMP/Gtk community is going to give Win32 any priority. Which maybe
fine for many Perl/Tk users, but may exclude 90% of desktops.
3) Have you considered the browser based alternatves ? (Forgive
the buzzwords) People are doing some amazing things w/ AJAX,
and with the availablity of XUL and/or XAML (or whatever MSFT
is calling Avalon these days), the browser seems to be the direction
everyone is headed. I believe a sourceforge project was formed
to provide a Perl/Tk API mapping to XUL, but I don't think it went
anywhere. Being able to port my pTk apps into full browser based
versions would be a significant leap, and (in theory) most of
the low-level issues could be blissfully ignored (ie writing
some XML and Javascript, rather than lots of C/C++).
Regards,
Dean Arnold
Presicient Corp.
| |
| Ala Qumsieh 2005-12-06, 7:02 pm |
| --- 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  .
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
| |
| Dean Arnold 2005-12-06, 7:02 pm |
| Dean Arnold wrote:
> 3) Have you considered the browser based alternatves ? (Forgive
> the buzzwords) People are doing some amazing things w/ AJAX,
> and with the availablity of XUL and/or XAML (or whatever MSFT
> is calling Avalon these days), the browser seems to be the direction
> everyone is headed.
Followup: for an idea whats possible w/ Javascript + XUL, see
http://www.hacksrus.com/~ginda/venk...an-20030427.gif
(Venkman is a Javascript debugger (IDE, actually) for Mozilla/Firefox
browsers)
Lots more screenshots at
http://www.hacksrus.com/~ginda/venkman/screenshots
- Dean
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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
| |
| Robert Hicks 2005-12-06, 9:57 pm |
| If you are going to "throw out" Tk at Perl6 then I would much rather
you throw your time against wxPerl and help out that project. That
would give you Linux/OSX/Windows plus wxGlade as a UI builder. I have
used wxPerl in some small apps and it works very well plus Wx has a lot
of good widgets plus native L&F.
If you are going to keep Tk, then I would recommend using Tcl::Tk so
that Perl gets all the changes to Tk right away.
I do not believe that gtk2 works on OSX unless you have X11 installed.
I do not know how many people install the X11 stuff. I personally know
of zero people who have.
My .02
Robert
| |
| Dean Arnold 2005-12-07, 3:59 am |
| Dean Arnold wrote:
> Dean Arnold wrote:
>
>
> Followup: for an idea whats possible w/ Javascript + XUL, see
>
> http://www.hacksrus.com/~ginda/venk...an-20030427.gif
>
> (Venkman is a Javascript debugger (IDE, actually) for Mozilla/Firefox
> browsers)
>
> Lots more screenshots at
>
> http://www.hacksrus.com/~ginda/venkman/screenshots
>
> - Dean
>
And one last example I just stumbled on this evening:
http://qooxdoo.oss.schlund.de/
- Dean
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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
| |
|
| 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".
>
> Also tracking/converting Tcl/Tk is a pain (and core Tk is where
> most of the "look" comes from).
Tcl/Tk has themes now, and the support folks I know (not personally,
but over the years have electronically known them) and their Tcl/Tk
support is first rate. The API is simple and clean and well
documented. I'd say just hooking into Tcl/Tk like other languages do
is a reasonable cousre, a course that has the best chance of re-using
all the mega-widgets, programs, miscellaneous code and documentation
that already exists.
Steve
--
@_=map{eval"100${_}"}split/!/,'/5!*2!+$]!/10+$]';use Tk;$m=tkinit;$t='just an'.
'other perl hacker';$z='createText';$c=$m->Canvas(-wi,$_[1],-he,25)->grid;$c->$
z(@_[2,3],-te,$t,-fi,'gray50');$c->$z($_[2]-$],$_[3]-$],-te,$t);$m->bind('<En'.
'ter>',sub{$y=int(rand($m->screenheight));$m->geometry("+$y+$y")});MainLoop;
| |
| Jack D. 2005-12-08, 3:57 am |
| > -----Original Message-----
> From: owner-ptk@lists.Stanford.EDU
> [mailto:owner-ptk@lists.Stanford.EDU] On Behalf Of Nick Ing-Simmons
> Sent: December 6, 2005 1:51 PM
> To: ptk@lists.Stanford.EDU
> Subject: Tk's lack of "chrome" (prompted by Re: Tk::FunkyButton ?)
>
>
> I have had various of list (and even day job) complaints that
> perk/Tk "looks old fashioned".
>
> 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
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.
Jack
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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
| |
| Steve Lidie 2005-12-08, 7:58 am |
|
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
| |
| Konovalov, Vadim 2005-12-08, 7:12 pm |
| > > I have had various of list (and even day job)
>
> 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 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 .
This is exactly what Tcl::Tk CPAN module does: it is a thin bridge between
perl and Tcl/Tk; it provides same functionality that perl/Tk does, but
instead it gives full Tcl/Tk widgets, and this means a magnitude factor more
widgets compared to perl/Tk, with a less overhead. See
http://mini.net/tcl/13208 , where you'll see mentioned items
I complained few years ago that perl/Tk way of embedding Tk is not optimal,
and then people pointed me to Tcl::Tk, and then I switched to Tcl::Tk
entirely, and then become a CPAN maintainer of that module.
>
> 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.
I beleive perl6 should go Tcl::Tk way for Tcl/Tk.
Like for any other GUI library -- it is not good to import entire GUI lib
into perl extension, like it was done in perltk, it should link to a library
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
| |
| Konovalov, Vadim 2005-12-08, 7:12 pm |
| > > So for perl6 (when it comes) I would rather
>
> 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 based on Tix, and (I tried this) it is usable when
you have Tcl/Tk with tix. (but requires some efforts to implement many edge
cases)
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
| |
| Nick Ing-Simmons 2005-12-08, 7:12 pm |
| Ala Qumsieh <ala_qumsieh@yahoo.com> writes:
>--- Nick Ing-Simmons <nick@ing-simmons.net> wrote:
>
>
>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 .
>
>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.
>
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.
[color=darkred]
>
>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
| |
| Konovalov, Vadim 2005-12-08, 7:12 pm |
| ......
>
> 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, memory
wins were lost somewhere in perl/Tk complexity.
See http://perlmonks.org/?node_id=426089
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
| |
| Konovalov, Vadim 2005-12-08, 7:12 pm |
| > 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 point: perl/Tk invented rather convenient syntax, which is
widely understood, and books about it are written. It has some dark sides,
but it has many brilliant points.
The underlying library - it could be Qt, or Tcl/Tk
[...]
> By using Slaven's perl 5.005 arm binary everything fits
> nicely on our PDA.
could you please add some details on these binaries?
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
| |
| Robert Hicks 2005-12-08, 7:12 pm |
| Why wait for Perl6 to use Tcl::Tk? If the benefits are less overhead,
more widgets and probably faster execution without losing the Perl/Tk
way of doing things.
Sounds like a win, win, win situation!
Robert
| |
| Hans Jeuken 2005-12-08, 7:12 pm |
| 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 ptk" to majordomo@lists.stanford.edu
| |
| Nick Ing-Simmons 2005-12-09, 7:15 pm |
| 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 biased by
non-western language support - but I haven't looked at Qt recently.
>A couple of widgets have a few extension needed
>for use on a PDA and we added a "Sketch" widget
>so I could capture signatures quickly. And we implent the ability
>to have round Buttons to save screen space. Pq is far from
>complete but you can do some interesting things
>on your Qtopia/Opie powered PDA. As soon as Harri
>makes a web page for downloading I'll post how to get code.
>By using Slaven's perl 5.005 arm binary everything fits
>nicely on our PDA.
>
>-Paul Falbe
> Cassens Transprt
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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
| |
| Konovalov, Vadim 2005-12-09, 7:15 pm |
| ....
>
> 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?
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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
| |
| Nick Ing-Simmons 2005-12-09, 7:15 pm |
| 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 make them the perl/Tk
compiled-in-defaults
>
>http://www.toneel.demon.nl/codit_screenshot.png
Pink isn't my colour ;-)
>
>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 ptk" to majordomo@lists.stanford.edu
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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
| |
| Jeff Hobbs 2005-12-09, 7:15 pm |
| Hans Jeuken wrote:
> 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
Without worrying about "native" widgets, it is possible to
improve on the existing Tk look by adjusting the Xdefaults
for Tk. This example is for Tcl/Tk, but applies to Perl/Tk
just as well:
http://wiki.tcl.tk/gtklook
These are easy to change in the default set as well. The
reason that the Tcl/Tk folks have been reluctant to do this
is due to backwards compatibility - even at the UI level.
To adjust the core defaults would throw off UIs that use
place for geometry management. At the same time, work has
been progressing on the native and themable widget sets to
really improve things.
--
Jeff Hobbs, The Tk Guy
http://www.ActiveState.com/, a division of Sophos
| |
| Jeff Hobbs 2005-12-09, 7:15 pm |
| Nick Ing-Simmons wrote:
> Ala Qumsieh <ala_qumsieh@yahoo.com> writes:
>
> 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/do...erlApp_gui.html
You'd be hard-pressed to say that looks "old fashioned".
>
> 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.
>
>
> 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.
>
> 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.
>
> 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
| |
| Jeff Hobbs 2005-12-09, 7:15 pm |
| Jack D. wrote:
> 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.
There is nothing about using Tcl::Tk that would remove your
ability to create pure Perl/Tk megawidgets. You would just
have access to creating them in both environments.
--
Jeff Hobbs, The Tk Guy
http://www.ActiveState.com/, a division of Sophos
| |
| Rob Seegel 2005-12-09, 7:15 pm |
| Nick Ing-Simmons wrote:
>Paul Falbe <paul@cassens.com> writes:
>
>
>
>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.
>
>
I have to admit I'm a little biased towards Qt myself. I prefer it's
API, and it has decent
I18N support. There may be some licensing concerns using it however. It
carries a dual
license, which allows free use within Open source efforts, but carries
another license for
commercial efforts. I should point out that I don't personally find this
unreasonable - the
Trolltech has every right to make money from their product which they
support very well, IMO.
I do realize that for some, this could be a problem.
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
| |
| Rob Seegel 2005-12-09, 7:15 pm |
| 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 languages have their
own challenges as well.
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-12-09, 7:15 pm |
| On Fri, 2005-12-09 at 21:53, Rob Seegel wrote:
> Konovalov, Vadim wrote:
>
>
> 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 all other your points: IMHO current Unicode in Perl
is quite strong; I use Unicode often (I am non-English who uses far-east
sometimes:)
> 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 languages have their
> own challenges as well.
Indeed, it seems reasonable for complicated i18n to be have a large
support library.
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
| |
| Nick Ing-Simmons 2005-12-10, 7:12 pm |
| 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
by different glyphs for initial/medial/final.
Gtk's pango was designed for this - a quick google
shows up http://lwn.net/2001/features/OLS/pdf/pdf/pango.pdf
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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
| |
| Vorxion 2005-12-12, 7:13 pm |
| In article <20051206205127.30207.17@llama.ing-simmons.net>, Nick Ing-Simmons wrote:
>
>I have had various of list (and even day job) complaints that perk/Tk
>"looks old fashioned".
I personally -like- the fact that there's no chrome BS, no native look
switching, etc--that the biggest difference cross-platform is what the
checkboxes and scrollbars look like.
>So for perl6 (when it comes) I would rather write/help-out-with a
>native perl/XS GUI - perhaps by wrapping gtk2.
Dear God, no, please don't use gtk2. Having run some GTK apps
(gtk-gnutella comes to mind), I can say with firsthand knowledge that gtk2
is -incredibly- slow, and not ready for prime-time for any application that
needs speed. If you've had complaints (and I know you have, I've seen them
here) about Tk being too slow, wait until you try gtk2. Everyone I've
talked to that develops in C that uses gtk says use v1, not v2, because the
speed on 2 is just horrible unless you have an absolute killer system, if
you have lots of events going through.
When gtk1-built gtk-gnutella will work for days with no issues, and
gtk2-built gtk-gnutella becomes unusable in under 15min because the UI
becomes non-responsive, there are performance issues. And that's the
-only- difference is which version it's built against.
>Do you prefer gtk2 "look"? - e.g. Gimp / inkscript etc.
GIMP looked fine. I've used other gtk apps. It's okay. It's nothing I'd
write home about. I prefer Tk's utilitarian look and feel. I'm one of
those programmers that goes for content over glitz though.
--
Vorxion - Founder of the knocking-shop of the mind.
"You have it, you sell it, you've still got it--what's the difference?"
--Diana Trent, "Waiting for God", on why a modelling agency is really a
knocking-shop. Applied by me to the field of consulting. :)
The Sci-Fi fan's solution to debt: Reverse the polarity on your charge card.
|
|
|
|
|