[MACTCL] Update on HITheme changes to Tk-Cocoa

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

Hello all,

I've been very busy lately with some big changes to Tk-Cocoa and wanted 
to provide an update, and request some feedback on next steps.

As brief background, last year I removed private Cocoa API drawing calls 
from Tk-Cocoa that greatly improved the drawing performance but meant 
that Tk was running afoul of Apple's developer guidelines, and also that 
Tk apps could not be deployed in an easy fashion to the Mac App Store. 
This resulted in a huge number of latent drawing bugs, and in 
conjunction with other contributors and developers identifying bugs I 
have spent the last few months quashing them in a piecemeal fashion. 
Though I've been able to adjust Tk-Cocoa's drawing code to address some 
of these bugs, many of them are structural: Tk simply can't keep track 
of all the Cocoa views and subviews in a Tk window without resorting to 
the private API calls.

My solution to this has been to re-implement the NSView-based Cocoa 
widgets--buttons, menubuttons, and the scrollbar--with an alternative 
drawing API, HITheme, which is still supported under Cocoa and which is 
the basis of several other Tk widgets, including the entry widget and 
the themed ttk widgets. Because it is a low-level drawing API, HITheme 
does not seem to have the same issues as NSView-based widgets, and so 
re-working the button and menubutton code has eliminated a huge swath of 
issues without substantially changing Tk's native appearance. Working in 
a "hitheme" fossil branch, I've gotten the buttons and menubuttons 
working well, and soon I'll be ready to request some testing on those. 
(An old patch by Revar Desmera, submitted almost 10 years ago, was the 
basis for my work here, and I thank Revar for that patch.)

I'm running into a wall with scrolling, however. I have been able to get 
a native HITheme-based scrollbar to draw in a Tk windows, but I cannot 
get it wired up to Tk's scrolling mechanism. Depending on what I do, the 
scrollbar may move a bit, or not at all, and the Tk scroll window may 
move, or not. On both Windows and the Mac, the scrollbar has 
historically worked by hooking into the native scrolling API's, and then 
using movement in the scrollbar to feed Tcl_DString's to the 
interpreter, which are processed as scrollbar commands. I am not having 
success with this approach; neither the scrollbar nor the scrolled 
window changes.  Another approach is to go the Unix route and apply the 
default scrollbar bindings to the Mac (see library/scrlbar.tcl). This 
handles window scrolling perfectly, but does not drive the scrollbar 
itself.

Before I invite testing of the hitheme branch, I need to resolve 
scrolling one way or another--while the Cocoa-based scrolling works 
perfectly, it produces unacceptable artifacts on Tk redraw (flickering, 
ghost scroll images, etc.), and I consider this unacceptable and broken, 
and thus it has to go. So my question is this: Can anyone take a look at 
my scrollbar code, hack on it, and see if you can help me get it over 
the finish line? I would be very grateful. If no solution to this 
problem presents itself in the near future, then I am contemplating an 
alternative approach: using ttk theming to create a Mac-like scrollbar, 
and then defaulting the standard Mac scrollbar to that implementation. 
(I'd need to create two themes, one with the older blue "Aqua" style, 
and one with the current iOS-style rounded gray bar, depending on OS.)

I realize theming in this fashion is not the way Tk has operated in the 
Mac in the past, but it should present no issues from a drawing 
standpoint, should be reasonably straightforward to implement, and 
should support scrolling as users expect it to work. I am leaning 
strongly to this option, in fact, if no solution to native scrolling 
presents itself in the very near future. I would very much like to bring 
the "active development" phase that has marked Tk-Cocoa for the past six 
months to a close or at least a slowdown, as I have had to postpone many 
other projects to attend to these issues. Once this phase is done, I 
will consider Tk to be sufficiently stabilized with the removal of the 
private API's, and I would expect to see the volume of bug reports go down.

I'd appreciate some feedback on what I've discussed here. The preferred 
feedback would be some code help to get native scrolling wired up. 
Barring that, would a themed-but-non-native scrollbar be an acceptable 
compromise, assuming I can get the look reasonably right?

Thanks,
Kevin

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