From: Kevin W. <kw...@co...> - 2015-01-24 16:57:27
|
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 |
From: Kevin W. <kw...@co...> - 2015-01-27 01:34:18
|
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 |
From: Russell O. <ro...@uw...> - 2015-01-27 04:58:34
|
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. |
From: Kevin W. <kw...@co...> - 2015-01-27 11:07:59
|
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 |