Tkinter or wxpython?

[Chris Mellon]

On 8/8/07, Kevin Walzer <kw at codebykevin.com> wrote:
> Chris Mellon wrote:
>
> >> What do you mean here? Things like keyboard accelerators, menu
> >> placement, and so on? Those things are already natively implemented by
> >> Tk, and the developer just needs to invoke them. Sometimes some
> >> conditional code is required for stuff like keyboard accelerators (the
> >> "tk windowingsytem" command is useful for this), but again, it should
> >> Just Work.
> >>
> >> Or am I missing something?
> >>
> >
> > There's conventions for shortcuts and they vary by platform. For
> > example, home/end do different things on a mac vs on windows.
> > Scrollbars interact differently, and menu pulldowns operate
> > differently. To my knowledge, while Tile can replicate the *look* of
> > these things, it does not help with the interaction.
>
> On Windows and Mac, Tk gets the menus correct by default (menu is at the
> top of the screen on the Mac, attached to a window on Windows).

I was actually referring to click-and-hold vs just click. If Tk wraps
the native menu on OS X (it doesn't on Windows) then that'll be taken
care of though. I don't think you can emulate menus on OS X the way
you can on Windows, though, so if they're where they're supposed to be
they're probably native ones.


>The Tk
> scrollbar is native on the Mac; the Tile  scrollbar has problems. On
> Windows, the Tile scrollbar maps to Vista or XP or Win32, depending on
> Windows version. You need to correctly specify the command-accelerator
> in your code (on Windows it's the Control key, on the Mac it's Command),

That's an interesting gap, since Tk gets other more subtle stuff right.

> but assuming you do this, it works fine. I don't use "home" and "end"
> keys myself (I think these are more common on Windows than Mac) so I
> can't speak to that.

Just examples. Text navigation has different conventions on a Mac vs
Windows (or Gtk/KDE). I wouldn't expect Tk to get it right unless it
wrapped the native control (which would give all kinds if neat
benefits like spellcheck, too). Of course, if that's what it decides
to do it will eventually end up being wxPython ;)

>Under Tk, keyboard navigation with the tab key
> generally works as expected on the Mac, and I assume so for Windows as
> well.
>
> The biggest drawback with Tk/Tile on the Mac is that even with Tile
> theming, it's still a bit outdated--Tile hooks into some older API's on
> the Mac that are more compatible with Tk; for instance, the notebook
> tabs look like Jaguar-era tabs (c. 2002). The Tile scrollbar is broken,
> but the Tk one works natively.
>
> Tile on Windows looks pretty darn good--I've played with the Windows
> Inspection Tool Kit, a well-designed Tcl/Tk application on Windows XP
> that uses Tile, and it's indistinguishable from something developed in
> VB or Delphi. (See http://magicsplat.com/wits/screenshot.html). Tile on
> the Mac requires a bit more hackery, but it's quite possible to get
> something looking nearly native (see
> http://www.codebykevin.com/portauthority.html).
>
> As for X, Tk and Tile are more of a mixed bag, because there is simply
> no single standard to target. Standard Tk looks and feels like Motif, as
> you know. Some of the Tile themes under X don't look much better. The
> most popular Tile theme on X is probably Clam, which looks more like a
> modern Gtk Clearlooks-style theme (see
> http://tktable.sourceforge.net/tile/screenshots/demo-clam-unix.png or
> http://www.codebykevin.com/pylocate-tile-x11.png). As far as I know,
> Tk/Tile offers reasonable defaults for X, unless you are looking for
> specfic integration with a particular environment (i.e. Gnome or KDE);
> in that case it's not as acceptable.
>

The situation under *nix is more complex, where you may or may not
have a DE with its own preferred toolkit. I use Gnome, so I expect
(and require) my apps to either use Gtk or fake it well enough that I
can't tell the difference, but I don't judge the strength of a cross
platform toolkit on that.

There are some cases where you just can't do everything in the
toolkit. One of the things that I really like about wxPython from a
cross platform perspective is how easily it lets you tell it to "do
the right thing for this platform". Stock buttons let you have the
right icons under Gtk, but the descriptive labels that OS X expects.
There's a stock button sizer that gets the layout and order of
ok/cancel correct. If you use the stock IDs for your menus, wxPython
will put the about and preferences menus items in the right spot and
give you the correct preferences accelerator on OS X. Stuff like that.

> >
> > Don't think I'm singling out Tk, Gtk has exactly the same problem -
> > you can make the buttons look native, but it doesn't adjust the
> > behavior.
>
> Tk does a better job with platform-specific defaults and behaviors than
> Gtk. When I read complaints about Tk on Windows, it's more on how ugly
> Tk is, not that its menus/keyboard behaviors don't work correctly.
>

Gtk is pretty bad, using it's own dialogs and even it's own painting
model. Tk has some definite lacks, though. I find the menus especially
obnoxious. I'm unusually picky about native integration though.