[MACTCL] Request for feedback: Re-implement problematic Cocoa widgets

[Kevin W. <kw...@co...>]

Hello all,

I’d like to get some input on some changes that I am mulling to Tk/Cocoa 
that I hope will address the drawing issues, once and for all. I’m 
reaching the conclusion that doing piecemeal fixes on the Cocoa drawing 
code may be a lost cause, I’m extremely frustrated with it, and I want 
to try something different.

The major issues appear to revolve around the Tk widgets that are based 
on actual Cocoa widgets, i.e. NSButton, NSPopUpButton (for menubuttons), 
and NSScroller. Most of Tk/Cocoa is based on drawing Tk-owned widgets 
(text widget, labels, canvas) into a single NSView in a Tk 
window/NSWindow, and these tend not to have many issues with drawing. 
The actual Cocoa-based widgets are more complex because they come with 
their own NSView as a child of the main window's view; this adds a lot 
of overhead and complexity. It’s a deeper hierarchy of drawing, much of 
which is hidden from the public Cocoa API. Removal of the private API 
calls has removed some of the control we have over the drawing of these 
widgets, leading to weird side effect as we’ve seen. As part of my 
testing of one of the sample scripts in an earlier thread, I was rather 
startled to see that replacing a Tk menubutton (based on Cocoa) with a 
ttk::menubutton did not display any flickering. The ttk widgets in Aqua 
are all based on the HITheme API, which, though nominally part of 
Carbon, has not been removed or officially deprecated by Apple; in fact 
it is 64-bit capable. HITheme is strictly a drawing/theming API with no 
widget behavior baked in.

This has led me to consider a different approach to the problem: by 
ripping out the button, menubutton and scrolling code from the Cocoa 
version of Tk and replacing it with HITheme-derived versions. The older 
Carbon code could be a starting point, since the Carbon widgets made a 
lot of use of that code. It might not even be necessary to re-implement 
the Carbon code for buttons, but instead use “interp alias” to point Tk 
to the ttk version of these widgets, perhaps with a wrapper layer in Tcl 
to cover any minor differences in theming or behavior. The biggest 
challenge would probably be to re-implement scrolling using the HITheme 
API, but I suspect a lot of the old Carbon code could be adapted for 
this purpose.

A lot of other cross-platform apps still use HITheme, such as Apache 
OpenOffice; Apple left it as 64-bit because it provide some drawing bits 
that Cocoa simply doesn’t. It also has the virtue of stability; I don’t 
think Apple is touching the code at all, apart from minor visual 
updates, so it would provide fewer moving targets than Cocoa. Tk also 
makes extensive use of HITheme code as part of the ttk widgets, so it is 
proven to work well with Cocoa/Tk. Replacing the more complex 
Cocoa-native widgets with HITheme versions would, I hope, eliminate the 
ugly side-effects that come with removing the private API calls. HITheme 
works at level of abstraction more suited to Tk—that is, low-level 
drawing—and thus wouldn’t have so many moving parts that the private 
Cocoa API calls are required to manage fully.

I'd appreciate feedback on this idea before commencing. I think the goal 
is worthy: the idea here is to simplify the drawing model by putting Tk 
in control of rendering everything into a single NSView/NSWindow, 
without the overhead of additional NSViews associated with the Cocoa 
buttons and scrollbar. It won't solve every problem associated with the 
Cocoa port, especially the event loop, but hopefully it will address the 
worst of the visual artifacts in a sustainable way without requiring 
continuous, ad-hoc fixes.

Thanks,
Kevin

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