David Hiltz wrote:
>
> > I agree, Tk is still the only option for most serious projects
> > (Win32::GUI is still, after all, a beta); though it still isn't
> > entirely stable, either.
>
> Nothing is.
Yeah, but menubars still aren't handled right (a grid of menu
buttons? *sheesh*), window focus is revoked at odd times, the
option button is really a hack on the Win32 platform (granted
Win32 doesn't really have a native option button, but the
strength of an option button over a dropdown list is lost on me),
and the HTML widget doesn't work right (I get the feeling that
authors of Tk widgets rank Win32 debugging just above VIC-20
debugging).
Don't get me wrong--Tk has a much more complete Event model,
a richer set of options, a larger development community,
and I'm very excited about the Tk::Text::SuperText and
Tk::HTML widgets. Cross-platform is neat, but only
interesting if your primary platform is something other
than Windows; like Java's AWT, all the user cares about is
that it looks wrong, and it's slow.
> > Also, be aware that the Tk widgets are ported from XWindows,
> > and are similar, but not identical, to the familiar Windows
> > controls. Tk also tends to be significantly slower.
>
> Tk is slower but I wouldn't say "significantly".
Populate a Tk::Tree widget and a Win32::GUI::TreeView control,
the difference is definitely significant. Of course, it's
easy to be faster if you only offer a fraction of the
functionality. ;)
But, by using a native library, rather than a port, Win32::GUI
should always be faster. Tk is probably perfectly acceptable
on XWindows, but the widgets are *native* to that shell. On
Win32, it is more like software emulation. And, let's face it,
how many 2D video card accelerators have Tk API calls burned
onto them?
--
Brian Lalonde [EMAIL PROTECTED]
Web Developer/DBA, Technology Services
Spokane Public School District 81
