[Pythonmac-SIG] Why is Framework build of Python needed

Kevin Walzer kw at codebykevin.com
Thu May 14 23:46:55 CEST 2009


Christopher Barker wrote:

> 
> I don't think TK does use native widgets -- it certainly didn't used to. 
> It was originally built for X11, and got ported to other platforms by 
> emulating the X11 drawing calls, still drawing its own widgets. I know 
> they've added support for native standard dialogs, like the file dialog, 
> but I think a great deal is still self drawn.
> 
> As opposed to wx, that does use the native widgets wherever possible.

Tk does use an X11 emulation layer for things like window management, 
drawing of graphics (such as polygons on the canvas widget), keyboard 
events, etc., but these functions are all mapped to native API's 
(CoreGraphics, Carbon, etc.).  As well, core widgets such as the menu, 
buttons, scrollbars, etc. are mapped to native API's. In some cases, 
widgets are composites, using platform-native drawing primitives for 
their components but having their behavior implemented at the script level.

> 
>> doesn't even ship with all components that are needed to get a proper 
>> native L&F with Tkinter.
> 
> I think a proper native L&F is simple impossible with Tk

I disagree with this, but it's partly a matter of opinion and partly a 
matter of how much attention the developer pays to platform specifics. 
It's true that out-of-the-box, Tk doesn't look especially native, 
especially if it's an application that has been ported from Windows or 
other Unix platforms. However, with some attention to platform details, 
such as spacing, colors, icons, etc., I think Tk can look pretty good. 
Certainly my own application with a *lot* of Mac-specific tweaking, 
strive to meet platform-specific conventions.

To a lesser degree, this is true of any cross-platform toolkit. I've 
seen some wxPython apps that look awful on the Mac, and some wxWidgets 
wrappings of Mac widgets--such as a combox--don't look correct at all. 
On the other hand, a wxPython app like Editra, which really pays 
attention to the way it's implemented on the Mac, looks great.

> 
> Kevin Walzer wrote:
>> You've done terrific work getting IDLE to work with OS X. A lot of the 
>> work that needs to be done with IDLE modernizing its interface simply 
>> can't be done at a platform-specific level.
> 
> but wouldn't making it more OS-Xish require platform specific 
> modification? Or do you mean the the toolkit itself has to support that 
> level of platform customization?

Some of both. The awful notebook widget that IDLE uses in its 
preferences window  could be swapped out with the more modern themed 
notebook widget that uses Mac-native tabs on OS X. That's toolkit-level 
customization, and it's what Guillhereme has added with his port of ttk 
to the standard library. Platform-specific customization is the kind of 
stuff that Ronald's done with keyboard shortcuts, placement of items in 
the menu, etc.

> 
> Anyway, it's nice to see TK getting attention, particularly on the Mac.

I strongly agree here. I was beginning to look around at different 
toolkits, but when I discovered Tk was being ported to Cocoa, I stopped. 
It means that Tk remains viable on the Mac.

I've posted a bit more about Tk-Cocoa here: 
http://www.codebykevin.com/blosxom.cgi/2009/03/07#tk-cocoa-at-last


> 
> Bill Janssen wrote:
>> Yes, I agree with all that -- anything non-Cocoa isn't "real".
> 
> I think Carbon is still real -- though it is on its way out...
>

I agree with Chris here. If Carbon isn't real, then the Finder isn't 
real, iTunes, etc....but it is definitely on the way out.

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com


More information about the Pythonmac-SIG mailing list