tcl-mac

[MACTCL] HITheme buttons committed; scrolling deferred for now

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

Hello all,

I've committed my changes to Tk-Cocoa's button code into trunk and 
core-8-5-branch, switching from Cocoa (NSButton) to an HITheme-based 
implementation. I've done a lot of testing them with the Wish demo, with 
various client apps using Tk, and some hard cases that were triggering 
the serious bugs we were seeing with the previous implementation. The 
HITheme versions do not flicker or bleed through when a window is 
resized or window stackorder is changed. After some trial and error and 
refinement, they also look acceptable in terms of visual display, 
metrics, etc. Any differences are subtle and are not likely to present 
any issue.

I'm committing these now with the aim of getting them into the next 
point releases of Tk. I'm deferring scrolling. The existing 
Cocoa/NSScroller implementation works just fine but shows the same 
issues with flicker and bleeding, ghost images that the NSButton bits 
did. To my surprise, even creating a custom themed scrollbar for Tk/Mac 
is difficult because the Aqua ttk theme omits support for it. Thus, that 
approach is a dead end.

I'm going to continuing working with the HITheme scrolling 
implementation. I have studied the old Carbon implementation and am 
adding some more code from that (with appropriate translations for the 
new API's), and hopefully that will get me closer.

Thanks,
Kevin

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

Re: [MACTCL] [TCLCORE] HITheme buttons committed; scrolling deferred for now

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

Russell,

On 1/26/15 2:57 PM, Russell Owen wrote:
> Users/rowen/Archives/UnixSoftware/tk/unix/../macosx/tkMacOSXButton.c:104:21:
> error: redefinition of 'tkpButtonProcs' with a different type:
Sorry about that, I've pushed a fix--it builds OK on my system. Try 
downloading again. (Are you getting this via Fossil or a Github mirror?)

Kevin

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

Re: [MACTCL] [TCLCORE] HITheme buttons committed; scrolling deferred for now

[Russell O. <ro...@uw...>]

On Jan 26, 2015, at 5:33 PM, Kevin Walzer <kw...@co...> wrote:

> Russell,
> 
> On 1/26/15 2:57 PM, Russell Owen wrote:
>> Users/rowen/Archives/UnixSoftware/tk/unix/../macosx/tkMacOSXButton.c:104:21: 
>> error: redefinition of 'tkpButtonProcs' with a different type:
> Sorry about that, I've pushed a fix--it builds OK on my system. Try downloading again. (Are you getting this via Fossil or a Github mirror?)

You fixed the build issue and the menubutton flicker. Thanks!

However, a new problem does seem to have crept in since 8.5.17 release: I see a roughly 2 second delay before attempting to resize a window has any effect. The delay is between the time I first click and drag the mouse and when the drag has any visible effect. I can quickly click and drag and wait and the window will eventually react and resize as requested. Once the window starts reacting (by resizing), it tracks the mouse very well. This shows up even if I just type “wish” and resize that empty window. Any idea what might be causing this?

— Russell

P.S.  On rereading my original message it came off as far more curt than I intended. I really appreciate all the hard work you have put into making Tcl/Tk work better on the Mac.

Re: [MACTCL] [TCLCORE] HITheme buttons committed; scrolling deferred for now

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

On 1/26/15 11:32 PM, Russell Owen wrote:
> However, a new problem does seem to have crept in since 8.5.17 
> release: I see a roughly 2 second delay before attempting to resize a 
> window has any effect. The delay is between the time I first click and 
> drag the mouse and when the drag has any visible effect. I can quickly 
> click and drag and wait and the window will eventually react and 
> resize as requested. Once the window starts reacting (by resizing), it 
> tracks the mouse very well. This shows up even if I just type “wish” 
> and resize that empty window. Any idea what might be causing this?

Yes--a deliberate design decision to disable drawing during a resize event.

One of the biggest sources of flickering and the other weird side 
effects that appeared after I removed the private API's was resizing--it 
caused all kinds of ugly and unpredictable stuff to happen. Cocoa 
actually provides a lot of fine-grained methods to control how drawing 
appears during window resizing, and I've used some of that to 
essentially hide the redraw stuff until the window is resized, deferring 
screen updates and the rendering of the NSView.

Implementing this behavior has removed a whole class of bugs, of which 
the menubutton flicker was a prime example.

--Kevin

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