tcl-mac — Q&A for Tcl on the Macintosh platform

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

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...>]

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

[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] Update on HITheme changes to Tk-Cocoa

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

On 1/21/15 10:11 AM, Kevin Walzer wrote:
> 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?
For what it is worth, I have found third-party artwork that implements 
exactly what I am looking for, Mac-styled scrollbars in the old Aqua and 
graphite styles, and the current iOS-inspired style.

https://addons.mozilla.org/en-US/firefox/addon/ifox-smooth/
https://addons.mozilla.org/en-US/firefox/addon/ifox-graphite/
https://addons.mozilla.org/en-US/firefox/addon/macosx-theme-firefox-4/

All three are licensed under the MPL versions 1.1, which requires that 
any modifications to the components themselves be identified and made 
available, along with a copy of the license, but which extends no such 
obligation to other code surrounding the Mozilla-derived code. As I read 
the license, I see no issue with bundling the artwork with Tk, as long 
as the files are kept separate. My plan is to convert any PNG's to GIF 
format to allow compatibility with Tk 8.5, but otherwise to leave them 
unchanged.

This artwork will allow me to implement ttk-based themed scrollbars for 
Tk-Cocoa, which preserves UI integration and sidesteps the issues I've 
had with native scrollbars.

--Kevin

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

[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

Re: [MACTCL] [TCLCORE] Invitation to submit patches for Tk/Cocoa: I need help

[Andreas K. <and...@ac...>]

Fully agreed.

On Tue, Dec 23, 2014 at 11:07 PM, Will Duquette <wi...@wj...> wrote:
>
> On Dec 23, 2014, at 9:31 PM, Steve Landers <st...@Di...> wrote:
>
>>
>>> On 24 Dec 2014, at 1:09 pm, Kevin Walzer <kw...@co...> wrote:
>>>
>>> And now, after a day of hacking, I've done a couple of commits to trunk
>>> and core-8-5-branch that implement the following Tk/Cocoa improvements:
>> ...
>>> Enjoy these improvements as an early Christmas present.
>>
>> Many thanks Kevin.  Your investment of time and energy is greatly appreciated.
>
> +1
>
>>
>> Steve
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming! The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net
>> _______________________________________________
>> Tcl-mac mailing list
>> tc...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core



-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
and...@ac..., http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

Re: [MACTCL] [TCLCORE] Invitation to submit patches for Tk/Cocoa: I need help

[Will D. <wi...@wj...>]

On Dec 23, 2014, at 9:31 PM, Steve Landers <st...@Di...> wrote:

> 
>> On 24 Dec 2014, at 1:09 pm, Kevin Walzer <kw...@co...> wrote:
>> 
>> And now, after a day of hacking, I've done a couple of commits to trunk 
>> and core-8-5-branch that implement the following Tk/Cocoa improvements:
> ...
>> Enjoy these improvements as an early Christmas present.
> 
> Many thanks Kevin.  Your investment of time and energy is greatly appreciated.

+1

> 
> Steve
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] [TCLCORE] Invitation to submit patches for Tk/Cocoa: I need help

[Steve L. <st...@di...>]

> On 24 Dec 2014, at 1:09 pm, Kevin Walzer <kw...@co...> wrote:
> 
> And now, after a day of hacking, I've done a couple of commits to trunk 
> and core-8-5-branch that implement the following Tk/Cocoa improvements:
...
> Enjoy these improvements as an early Christmas present.

Many thanks Kevin.  Your investment of time and energy is greatly appreciated.

Steve

Re: [MACTCL] [TCLCORE] Invitation to submit patches for Tk/Cocoa: I need help

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

On 12/22/14 9:38 PM, Kevin Walzer wrote:
>> As I noted yesterday, I have run into a wall on trying to address bugs
>> >with the scrollbar in Tk-Cocoa, as reported here by Linus Nyberg:
>> >
>> >https://sourceforge.net/p/tcl/mailman/message/33162978/
>> >
>> >(Linus, by the way, can you please file a bug report at the tracker at
>> >http://core.tcl.tk/tk/reportlist? Thanks.)
>> >
>> >I've also run into a similar wall on trying to address the menubutton
>> >widgets as reported by Russell Owen here:
>> >
>> >http://core.tcl.tk/tk/tktview/7a325ad72cbb6e331fbae3f4116fe112bda698f4
>> >
>> >I am now asking for help from the community in addressing these bugs.
> After taking a bit time to consider an approach to these bugs, I have
> decided to revisit the issues by adding to the ttk package (it currently
> lacks a scrollbar for OS X), and also by borrowing from the ttk approach
> for buttons, etc. This will reduce the amount of work relative to
> re-implementing the button and scrollbar code from scratch. When I have
> more to report and /or test, I will post here.

And now, after a day of hacking, I've done a couple of commits to trunk 
and core-8-5-branch that implement the following Tk/Cocoa improvements:

1. The scrolling flicker issue appears to be gone. I've addressed this 
by implementing custom drawing of the scrollbar that mimics the standard 
Cocoa UI as closely as possible. I do not fully understand why this 
seems to fix the issue that Linus reports, as well as multiple other 
issues that I've observed with "ghosted" scrollbars, but all my tests 
show no issues. The new drawing is supported on 10.7 and above, when the 
new scrollbar style was introduced. I have not tested this on 10.6 and 
below, and do not plan to. Linus, please test the update and I'll close 
the bug if you confirm it works.

2. I've made substantial improvement in how the menubutton is rendered 
during window resizing, which was the basis of Russell's bug report. 
When the menubutton is in a mapped state the flicker is completely gone. 
When unmapped, alas, it still shows up as a "ghost" image, but  the 
flicker is somewhat reduced. I do not know how to resolve this, but I 
will take the substantial improvement here as a win. Russell, please 
test the update and I'll close the bug if you confirm it works.

3. As a happy side effect of the menubutton fix, window performance in 
general seems improved during resizing. I added a couple of method calls 
that defer some redrawing while the window is being resized, and that 
seems to smooth things out a good deal.

I think these fixes are sufficient for now. As you know, I had spent 
some time looking at the possibility of borrowing some of ttk's code in 
rendering buttons, menubuttons, and the like using the HITheme API, but 
integrating that with Cocoa is simply impractical or far more work than 
I wanted to take on. In any case, I think things are now on more solid 
ground after the removal of the private API's, and I'll continue to 
investigate incremental improvements as time and bug reports allow. And 
my earlier invitation to submit patches stands: some of the big 
improvements over the past year are things I could never have come up 
with on my own!

Enjoy these improvements as an early Christmas present.

Happy holidays,
Kevin

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

Re: [MACTCL] [TCLCORE] Invitation to submit patches for Tk/Cocoa: I need help

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

Hi Joe,

On 12/23/14 1:20 PM, Joe English wrote:
> There were ways to work around this mismatch for sliders
> and progress bars, but I never managed to get scrollbars
> working; that's why ttk::scrollbar dispatches to tk::scrollbar
> on OSX.
Thanks for the reminder here. I remember this being an issue back in the 
day, and the compromise (just map to the Tk scrollbar) was effective 
because visually it was already native.

After doing a bit more digging into HITheme, it's likely that I will 
borrow a lot of the ttk C-level code in reivsing the implementation of 
the Mac buttons, menubuttons and scrollbars. Visually HITheme is almost 
identical to the Cocoa widgets. However, I will be adapting this stuff 
to Tk's API, not ttk's. This means that the revised Tk widgets will 
still be as configurable as before, and will not respond to ttk:: commands.

Thanks,
Kevin

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

Re: [MACTCL] [TCLCORE] Invitation to submit patches for Tk/Cocoa: I need help

[Joe E. <jen...@fl...>]

Kevin  Walzer wrote:
>
> After taking a bit time to consider an approach to these bugs, I have
> decided to revisit the issues by adding to the ttk package (it currently
> lacks a scrollbar for OS X), and also by borrowing from the ttk approach
> for buttons, etc. This will reduce the amount of work relative to
> re-implementing the button and scrollbar code from scratch. When I have
> more to report and /or test, I will post here.


Just a heads-up re: ttk::scrollbars on OSX:

There is an impedance mismatch between the way Tile wants to
implement scrollbars and the HITheme API.  The ttk::scrollbar
Tcl bindings expect scrollbars to be composed of multiple
elements, and use [$sb identify element] to determine what to
do on ButtonPress events &c.  HIThemeDrawTrack(), however,
wants to draw the entire scrollbar as a single unit.

Apple provided hit-test routines to determine what part of the
scrollbar is under a given point [*], but the Tile framework
never evolved a mechanism by which that information could
be queried and returned to scripts.

There were ways to work around this mismatch for sliders
and progress bars, but I never managed to get scrollbars
working; that's why ttk::scrollbar dispatches to tk::scrollbar
on OSX.


--Joe English

  jen...@fl...


[*] If I recall correctly.  It appears that all online documentation
related to the OSX Appearance Manger interface has gone into
the Memory Hole.

Re: [MACTCL] Invitation to submit patches for Tk/Cocoa: I need help

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

On 12/21/14 11:51 AM, Kevin Walzer wrote:
> As I noted yesterday, I have run into a wall on trying to address bugs
> with the scrollbar in Tk-Cocoa, as reported here by Linus Nyberg:
>
> https://sourceforge.net/p/tcl/mailman/message/33162978/
>
> (Linus, by the way, can you please file a bug report at the tracker at
> http://core.tcl.tk/tk/reportlist? Thanks.)
>
> I've also run into a similar wall on trying to address the menubutton
> widgets as reported by Russell Owen here:
>
> http://core.tcl.tk/tk/tktview/7a325ad72cbb6e331fbae3f4116fe112bda698f4
>
> I am now asking for help from the community in addressing these bugs.
After taking a bit time to consider an approach to these bugs, I have 
decided to revisit the issues by adding to the ttk package (it currently 
lacks a scrollbar for OS X), and also by borrowing from the ttk approach 
for buttons, etc. This will reduce the amount of work relative to 
re-implementing the button and scrollbar code from scratch. When I have 
more to report and /or test, I will post here.

Wish me luck!

--Kevin

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

[MACTCL] Invitation to submit patches for Tk/Cocoa: I need help

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

Hi all,

As I noted yesterday, I have run into a wall on trying to address bugs 
with the scrollbar in Tk-Cocoa, as reported here by Linus Nyberg:

https://sourceforge.net/p/tcl/mailman/message/33162978/

(Linus, by the way, can you please file a bug report at the tracker at 
http://core.tcl.tk/tk/reportlist? Thanks.)

I've also run into a similar wall on trying to address the menubutton 
widgets as reported by Russell Owen here:

http://core.tcl.tk/tk/tktview/7a325ad72cbb6e331fbae3f4116fe112bda698f4

I am now asking for help from the community in addressing these bugs.

I must be candid: most of the progress that we've made on improving 
Cocoa/Tk over the past few years, particularly in fixing the most 
serious bugs, is the result of patches submitted by developers attacking 
pain points specific to their work. I'm thinking of the language input 
patches submitted by Adrian Robert, the image processing and button 
patches submitted by Marc Culler, and others.

As the de-facto maintainer of Tk/Cocoa, I'm efficient at reviewing and 
applying patches, and occasionally I will go through and fix a bug on my 
own, or can diagnose a fix based on some specific reports. But in the 
majority of cases, I am not able to find solutions to the bug being 
reported. This is frustrating for me, and for you as well. But when 
developers who are smarter and better than me look at something 
specific, the result is often a very helpful patch that really fixes a 
big problem.

So, I'm asking: anyone who can investigate any of these bugs, please do 
so. I promise to review patches in a very timely fashion.

Here is a list of my open bugs at the tracker:

http://core.tcl.tk/tk/rptview?rn=16

I am grateful for any help anyone can provide. I do not believe I can 
make further significant progress on Tk/Cocoa by myself. I'm sorry about 
that, but my skillset is what it is.  I try to compensate for any of my 
own limitations by being responsive and efficient in reviewing 
contributions from others, because it makes no difference to me where 
the improvements come from: I just want the toolkit to get better. I 
know you agree. But this isn't going to happen if I am working by 
myself. I need more contributions from the community.

Thank you,
Kevin

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

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

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

On 12/18/14, 8:03 PM, Kevin Walzer wrote:
> 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.

Well, after spending a few hours on trying to wrangle with the scrolling 
and replacing NSScroller with  HIThemeDrawTrack(), I get an empty 
scrolling trough with no scrollbar that still flickers when a window is 
resized, and which blocks drawing of everything else in the window.

To heck with this. Sorry for the noise.

--Kevin

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

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

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

Hi Adrian,

On 12/19/14, 12:12 AM, Adrian Robert wrote:
> I'm a little confused, since ttk is the "native-looking" alternative with less customizability so I always thought THAT was the option based on native widgets, whereas regular tk widgets were "hand drawn".
That's true, and I did not make an adequate contrast between using 
HITheme and using the ttk API--they are not the same thing. I will 
probably have to repurpose more  code than originally anticipated. 
Replacing NSButton calls with HITheme calls won't change the API at the 
script level, it just changes the rendering engine. It should look 
pretty much identical.
>
> Will the proposed changes result in some elements that previously appeared and felt native to users no longer being so?  Or is it going to result in MORE things looking native?  And a second question, will it result in any changes to the responsiveness of widgets to "configure" settings?  In other words, will there be end-user visible effects (besides fixing bugs of course) and will developers possibly need to adjust their code to compensate?
See above. Swapping out NSButton for HITheme won't affect any of this, 
because I'll be coding against Tk's API, not ttk's.
>
> Finally, are we sure the problems are the fault of the drawing code itself, and not something that would get cleaned up in one fell swoop if the event loop integration problems were solved?
>
That could be, but no solution has presented itself, and isn't likely 
to, so I don't think it's productive to pursue this tack.

Kevin

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

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

[Adrian R. <adr...@gm...>]

Hi,

I'm a little confused, since ttk is the "native-looking" alternative with less customizability so I always thought THAT was the option based on native widgets, whereas regular tk widgets were "hand drawn".

Will the proposed changes result in some elements that previously appeared and felt native to users no longer being so?  Or is it going to result in MORE things looking native?  And a second question, will it result in any changes to the responsiveness of widgets to "configure" settings?  In other words, will there be end-user visible effects (besides fixing bugs of course) and will developers possibly need to adjust their code to compensate?

Finally, are we sure the problems are the fault of the drawing code itself, and not something that would get cleaned up in one fell swoop if the event loop integration problems were solved?

thanks,
Adrian



> On Dec 19, 2014, at 3:21 AM, Will Duquette <wi...@wj...> wrote:
> 
> 
>> On Dec 18, 2014, at 5:03 PM, Kevin Walzer <kw...@co...> wrote:
>> 
>> Hello all,
>> ...
>> 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.
> 
> Kevin,
> 
> In my view, this is the right way to go.  ttk:: shows the way to making widgets look native on any platform, without getting involved with the peculiarities of native widgets; there's no reason the same concepts can't be used for the older widgets (and the code will likely be more stable, simpler, and easier to maintain).
> 
> Will
> 
>> 
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Tcl-mac mailing list
>> tc...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] [tcl-mac-bounces@lists.sourceforge.net: Your message to Tcl-mac awaits moderator approval]

[Larry M. <lm...@mc...>]

Can someone fix it so lm...@mc... == lm...@bi... so I can post to
the list?

Or not, I know I can be annoying :)

----- Forwarded message from tcl...@li... -----

Date: Fri, 19 Dec 2014 02:57:37 +0000
From: tcl...@li...
To: lm...@mc...
Subject: Your message to Tcl-mac awaits moderator approval

Your mail to 'Tcl-mac' with the subject

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

Is being held until the list moderator can review it for approval.

The reason it is being held:

    Post by non-member to a members-only list

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:

    https://lists.sourceforge.net/lists/confirm/tcl-mac/54bcb866637f4adf565c165249bf801334b85db9

----- End forwarded message -----

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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

[Larry M. <lm...@mc...>]

Kevin,

Tk always needs some lovin.  If you are willing to go tackle that then
go you.  BitMover is willing to toss some cash or toys towards the effort.
If anyone (das?  jeff?) is willing to help, we can sprinkle more cash
and toys around.

Contact me off list to get said toys.  Please do so right away, if it
is this year the cash will spend far more freely than after Jan 1.

--lm


On Thu, Dec 18, 2014 at 05:21:48PM -0800, Will Duquette wrote:
> 
> On Dec 18, 2014, at 5:03 PM, Kevin Walzer <kw...@co...> wrote:
> 
> > Hello all,
> > ...
> > 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.
> 
> Kevin,
> 
> In my view, this is the right way to go.  ttk:: shows the way to making widgets look native on any platform, without getting involved with the peculiarities of native widgets; there's no reason the same concepts can't be used for the older widgets (and the code will likely be more stable, simpler, and easier to maintain).
> 
> Will

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

[Will D. <wi...@wj...>]

On Dec 18, 2014, at 5:03 PM, Kevin Walzer <kw...@co...> wrote:

> Hello all,
> ...
> 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.

Kevin,

In my view, this is the right way to go.  ttk:: shows the way to making widgets look native on any platform, without getting involved with the peculiarities of native widgets; there's no reason the same concepts can't be used for the older widgets (and the code will likely be more stable, simpler, and easier to maintain).

Will

> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

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

[Steve L. <st...@di...>]

Hi Kevin,

I can't fault your logic so I would say it is worthwhile if you've got the energy.

It appears that HItheme isn't available on iOS, but I've never considered a Tk port practical, so no loss there (a Tcl port that bridged to the various iOS APIs is different, but another topic). 

Perhaps the only consideration would be trying to make this separate to the existing Cocoa-based Tk, at least till people can confirm the new approach works for them.

So, in summary, it sounds like an approach worth exploring. Thanks for investing your time in it.

Steve

> On 19 Dec 2014, at 9:03 am, Kevin Walzer <kw...@co...> wrote:
> 
> 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
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[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

Re: [MACTCL] Minor bug in Tck/Tk 8.5.17: hidden menubuttons flicker

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

On 12/17/14, 6:43 PM, Linus Nyberg wrote:
> I don’t know if it’s the same root cause, but with the latest Tk code our application suffers badly from similar flickering problems. We have it going on in multiple places. Could be multiple separate causes, or it could be the same cause as Russel’s script. But they’re all new since the removing of the internal Cocoa API calls.
> One problem is that we often create windows (tk frames) with scrollbars in them, and after destroying those windows the scrollbars inside them linger, flickering, whenever you config some other tk widget.
> To replicate, run the script below and then move the mouse inside the window. Then the flicking appears. The (destroyed) scrollbar keeps appearing and disappearing. It seems that the configuring of the button triggers it somehow. Re-sizing the whole window also causes the destroyed scrollbars to appear.

I had seen an error like this in some other contexts, and had committed 
a fix to the scrollbar code which I had thought fixed the issue. I'm 
dismayed these are still cropping up, and am not sure where to look.

It is very frustrating that repeated, ad-hoc fixes are necessary to the 
drawing code.

--Kevin

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

Re: [MACTCL] [TCLCORE] flicker of hidden menubutton: does it happen on linux or windows?

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

On 12/17/14, 9:31 PM, Kevin Walzer wrote:
> Marc Cussler and I did a lot of work this summer on a patch to the
> button widget because it displayed this behavior, flickering and so on.
> I didn't think to look at the menubutton, which is a distinct widget.
> (You can see the difference if you change the menubutton in the sample
> script to a standard button.) I'll take a look and see if I can re-work
> the menubutton with a similar fix.
A fix is proving a bit elusive...there seem to be some different factors 
in how the menubutton is rendered, and I haven't been able to simply 
port the fix from the button widget over.

However: a trivial workaround is to substitute a ttk::menubutton for a 
regular menubutton. No flicker at all. I'm wondering if that would be 
sufficient here?

--Kevin

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

Re: [MACTCL] Minor bug in Tck/Tk 8.5.17: hidden menubuttons flicker

[Linus N. <li...@fa...>]

Hi,

That is a very nice and short test script, Russel.

I don’t know if it’s the same root cause, but with the latest Tk code our application suffers badly from similar flickering problems. We have it going on in multiple places. Could be multiple separate causes, or it could be the same cause as Russel’s script. But they’re all new since the removing of the internal Cocoa API calls.
One problem is that we often create windows (tk frames) with scrollbars in them, and after destroying those windows the scrollbars inside them linger, flickering, whenever you config some other tk widget.
To replicate, run the script below and then move the mouse inside the window. Then the flicking appears. The (destroyed) scrollbar keeps appearing and disappearing. It seems that the configuring of the button triggers it somehow. Re-sizing the whole window also causes the destroyed scrollbars to appear.

#################

proc main {} {
	console show
	wm geometry . 800x600
	frame .f -width 750 -height 550 -bg grey75
	place .f -x 50 -y 50 -anchor nw
	button .f.b -text hello
	place .f.b -x 100 -y 100 -anchor nw
	set w [create_window .f 10 10 300 300]
	update
	destroy $w

	bind all <Motion> {
		.f.b configure -text [clock seconds]
	}
}

proc create_window {parent_w x y width height} {
	set w $parent_w.c_container
	frame $w -bg grey75 -bd 0 -width $width -height $width
	scrollbar $w.vscroll -command "$w.c yview"
	canvas $w.c -highlightthickness 0 -width [expr {$width - 15}] -height [expr {$width}] -relief sunken -bg grey85 -bd 0 -yscrollcommand "$w.vscroll set"
	grid $w.c -padx 1 -pady 1 -row 0 -column 0 -rowspan 1 -columnspan 1 -sticky news
	grid $w.vscroll -padx 1 -pady 1 -row 0 -column 1 -rowspan 1 -columnspan 1 -sticky news

	place $w -x $x -y $y -anchor nw
	return $w
}

after 10 main

#################

Linus


> 17 dec 2014 kl. 18:32 skrev Russell Owen <ro...@uw...>:
> 
> On 12/5/14 4:54 PM, Russell Owen wrote:
>> I have a log window consisting of a Text widget, scroll bar, and various
>> widgets to control the display. Some of of the control widgets are
>> usually hidden, using grid.remove() to remove the parent frame of the
>> widgets.
>> 
>> With Tcl/Tk 8.5.17 on MacOS we see the hidden widgets briefly appear
>> whenever the main frame for this window receives an <Expose> event.
>> Unfortunately such an event occurs whenever a new item is appended to
>> the log (I'm not sure why). New lines can come in quite often, leading
>> to an annoying flicker of the hidden widgets....
> 
> I was able to generate a simple demo script (below) and have posted a 
> bug report 
> <http://core.tcl.tk/tk/tktview/7a325ad72cbb6e331fbae3f4116fe112bda698f4>. My 
> description was a bit wrong: it's not <Expose> events that cause the 
> flicker, but something else that occurs at the same time as the <Expose> 
> event (I have not figured out what). Also, menubuttons flicker but a few 
> other widgets I've tried do not.
> 
> Michiel de Hoon reports seeing the problem in Tcl/Tk 8.6.3.
> 
> I would really appreciate it if somebody could try this on linux (I 
> don't have access to a linux with a new enough Tcl/Tk). That would 
> support or disprove Kevin Walzer's theory that this is caused by 
> removing the private Cocoa API calls from Tk. If Keven is right then 
> we'll likely have to live with it. If it shows up on linux as well then 
> it's more likely worth trying to fix.
> 
> Regards,
> 
> -- Russell
> 
> #!/usr/bin/env wish
> # A simple test case to show flicker of a hidden widget.
> #
> # I see the flicker on MacOS 10.9 using Tcl/Tk 8.5.17, but not some 
> older versions of Tcl/Tk I have tried.
> #
> # To see the flicker:
> # - Run the script
> # - Push the "Hide Wdg" button
> # - Resize the widget, preferably in width; the hidden widget will be 
> shown while resizing
> #
> # Variations:
> # - I first saw the problem with a window that contained a scrolled Text 
> widget (a log window). Every time text was added to the Text widget the 
> hidden widget flickered.
> # - I've used grid_forget and still see the flicker.
> # - I've tried making hidden widget a Label or an Entry instead of a 
> MenuButton and I do NOT see the flicker.
> 
> wm geometry . "200x50"
> menubutton .wdg -text "Wdg"
> grid .wdg -row 0 -column 1
> button .btn -text "Hide Wdg" -command {grid remove .wdg}
> grid .btn -row 0 -column 0
> 
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac