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

Re: [MACTCL] Learn to read (was Re: Unsubscribe)

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

Your feedback on the last batch of commits would be welcome.  A lot of work has gone into fixing many issues.  I think it surpasses Carbon now.

> On Feb 21, 2015, at 3:46 PM, Steve A <ste...@gm...> wrote:
> 
> Maybe this is an idiots-only list nowadays... All the sane people
> having given up on the broken Tk Cocoa ?
> 
> Sorry for being so rude.
> 
>> On Sun, Feb 22, 2015 at 12:35 AM, Uwe Koloska <ml...@ko...> wrote:
>>> Am 21.02.2015 um 07:57 schrieb Steve A:
>>> That is now the second or third time i have tried that link.
>> 
>> And why don't you follow what's written on the page behind the link?
>> 
>> To give you a hint: The relevant text for you begins with "To
>> unsubscribe from Tcl-mac, ..."
>> 
>>> Please unsubscribe me manually.
>> 
>> If you want to pay the hourly rate ;-)
>> 
>> This is a self-service mailing list!
>> 
>> Uwe
>> 
>> ------------------------------------------------------------------------------
>> 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=190641631&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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Learn to read (was Re: Unsubscribe)

[Steve A <ste...@gm...>]

Maybe this is an idiots-only list nowadays... All the sane people
having given up on the broken Tk Cocoa ?

Sorry for being so rude.

On Sun, Feb 22, 2015 at 12:35 AM, Uwe Koloska <ml...@ko...> wrote:
> Am 21.02.2015 um 07:57 schrieb Steve A:
>> That is now the second or third time i have tried that link.
>
> And why don't you follow what's written on the page behind the link?
>
> To give you a hint: The relevant text for you begins with "To
> unsubscribe from Tcl-mac, ..."
>
>> Please unsubscribe me manually.
>
> If you want to pay the hourly rate ;-)
>
> This is a self-service mailing list!
>
> Uwe
>
> ------------------------------------------------------------------------------
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] Learn to read (was Re: Unsubscribe)

[Uwe K. <ml...@ko...>]

Am 21.02.2015 um 07:57 schrieb Steve A:
> That is now the second or third time i have tried that link.

And why don't you follow what's written on the page behind the link?

To give you a hint: The relevant text for you begins with "To
unsubscribe from Tcl-mac, ..."

> Please unsubscribe me manually.

If you want to pay the hourly rate ;-)

This is a self-service mailing list!

Uwe

Re: [MACTCL] Unsubscribe

[Steve A <ste...@gm...>]

That is now the second or third time i have tried that link.
Please unsubscribe me manually.

S.A.

On Thu, Feb 19, 2015 at 2:14 AM, Kevin  Walzer <kw...@co...> wrote:
> On 2/17/15 3:08 AM, Steve A wrote:
>> Is your unsubscribe on manual ? Please unsubscribe me.
>>
>> ------------------------------------------------------------------------------
>> 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=190641631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Tcl-mac mailing list
>> tc...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>>
> Unsubscribe instructions are here:
>
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
> --
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] Final report on Tk-Cocoa 2.0

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

Hello all,

With a lot of testing from Linus Nyberg, Russell Owen, Torsten Reincke, 
and Marc Culler, and a good deal of code assistance from Marc, I've been 
able to do some smoothing out of some final rough edges with the major 
implementation changes of Tk-Cocoa, and I think it's time to declare 
that project complete.

After I announced the initial commits a few weeks ago, these folks 
invested a lot of time building, working with, and providing me feedback 
on the changes, and the issues revolved around a couple common issues:

1. The button metrics were a bit off--buttons were too large, too much 
padding, and so on.
2. My effort to address flicker during window resizing caused a lot of 
disruption, both to user expectations (the window resize was not 
displayed, by design) and stability (it crashed a lot).

After some additional work on my part, more user feedback, and some 
helpful patches, recent commits have achieved the following:

1. Button metrics now work as expected.
2. We've put live resizing back in, to make sure Tk remains consistent 
with user expectations, and still managed to eliminate the worst of the 
flicker that was evident when I first removed the private API's, without 
crashes.

There may still be a few loose ends (Torsten reported a minor UI glitch 
with scrollbars that does not impede functionality, and there is some 
subtle flicker at times during window resizing), but it's my view that 
Tk-Cocoa is now as stable and performant as it was before the private 
API's were removed, if not more so, and it achieves this outcome while 
remaining consistent with user expectations for window display and app 
performance--in short, Tk-Cocoa remains a good citizen on OS X. 
Additionally, a very good side effect of the improvements in drawing 
performance and stability is that the underlying issues with event loop 
integration seem reduced. That core issue has not been solved and may 
never be, but the simplifying of drawing and event processing seems to 
have relieved a good deal of pressure on the overall event loop, which 
is no small improvement.

I think the new Tk-Cocoa is ready for a stable release in both 8.6 and 
8.5, and users should see significant improvements once that happens.

Thanks to all for their input, assistance, and encouragement.

Best,
Kevin

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

Re: [MACTCL] [TCLCORE] Update on buttons

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

Hi Russell,

On 2/19/15 7:23 PM, Russell Owen wrote:
> With this fix for font metrics appearance of radiobutton and checkbutton
> is spectacularly better on my MacOS system. Button sizes are now correct
> for a variety of text labels, which has not been true for a long time. I
> am very pleased!
Thanks for the good words. Credit for the metrics improvements goes to 
Marc Culler, who has provided many essential patches on this project.
>
> Two remaining issues I observe:
> - -bd (borderwidth) is ignored by checkbutton and radiobutton on MacOS,
> though it is obeyed on unix.
> - a checkbutton or radiobutton with only an icon (indicatoron=0 and no
> text) shows no visible difference between being checked or unchecked.
> The frame that should be present (and is present for buttons with text
> and for all buttons on unix) is missing. The obvious workaround would be
> to manually specify a borderwidth, but that is ignored due to the first
> bug mentioned.
>
>
Here is where we are getting into some areas where Mac buttons simply 
work differently than Unix buttons because they are natively rendered. 
To my knowledge Mac buttons--Carbon, Cocoa or HITheme--have never 
honored some configuration flags, such as border width, background, etc. 
There simply isn't a way to configure some things when the native API is 
used. I don't have a comprehensive list, but some of it is documented 
informally at the wiki or in the Tcl-Mac archives. (The same is likely 
true of Windows.)

There are solutions for how to show a selected state for checkbuttons 
and radiobuttons with images. If you want to leave indicatoron=0, then 
consider setting the -selectimage flag--using a different image or 
bitmap when the state is selected. The Wish demo has an example of this, 
and you can probably find simple code examples online.

--Kevin

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

Re: [MACTCL] [TCLCORE] Update on buttons

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

On 2/19/15 3:07 PM, Russell Owen wrote:
> This sounds great and I would love to try it out. Unfortunately I get a
> build error when I try to build the 8.5 branch of tk (log appended). I
> am using the github mirror and the last commit to tk was:

Jan Nijtmans fixed this (sorry it keeps cropping up).

Try downloading and building again.

--Kevin

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

Re: [MACTCL] Unsubscribe

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

On 2/17/15 3:08 AM, Steve A wrote:
> Is your unsubscribe on manual ? Please unsubscribe me.
>
> ------------------------------------------------------------------------------
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>
Unsubscribe instructions are here:

https://lists.sourceforge.net/lists/listinfo/tcl-mac

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

[MACTCL] Unsubscribe

[Steve A <ste...@gm...>]

Is your unsubscribe on manual ? Please unsubscribe me.

Re: [MACTCL] Tk-Cocoa 2.0

[Torsten B. <be...@ty...>]

Dear Kevin,

no, it is not a functional bug. Everything is working as far as I can tell, and I can surely understand that you do not want to spend time on a visual „glitch“. I am always inclined to try and make it perfect ;-)

Torsten

> Torsten,
> 
> On 2/16/15 2:33 AM, Torsten Berg wrote:
>> Then, the bug occurs again (you do not even need the 3rd line). So, only when both vertical AND horizontal scrollbars are present, it is exposed. It does also NOT show up when just resizing (= enlarging) the window and keeping the mouse pointer outside the vertical scrollbar area. But as soon as you move the pointer into the vertical scrollbar area, the trough collapses (but of course only when you have a horizontal scrollbar at the same time. E.g. having two vertical scrollbars does not show the bug). I hope this helps to track the problem down …
> OK, I see the issue when the horizontal scrollbar is added.
> 
> However, we still haven't addressed the core part of my question to you:
> Is this a cosmetic or functional bug?
> 
> Is scrolling hindered in some way because of this issue, or is it just a
> visual glitch? All of my testing indicates that it is visual: yes, it
> looks a little funny, but the scrollbar appears when required and
> scrolling is not hindered, nor is the overall layout of a window hindered.
> 
> I have less time at present to work on Tk, so I am prioritizing
> functional bugs: If this issue messes up layout somehow (as radio and
> checkbutton metrics still do), or if it causes a consistent crash, as
> the resizing did, then that gets focus.
> 
> Cosmetic bugs are much lower priority. The scrollbar does not get darker
> when it is pressed; that's possible to implement in HITheme, but
> figuring out the right place to toggle the pressed/not-pressed state is
> tricky, and I decided not to spend further time on it. What we have is
> good enough. Similarly, checkbuttons with an "indiatoron" state look
> very different than standard checkbuttons; they are rendered using a
> Unix-style layout. It's ugly, but there's no easy way to show that
> natively, so I left it as is. It's good enough.
> 
> This bug is falling into the cosmetic category for me, and as such, I am
> not likely to spend much time on it unless my reading of the situation
> is wrong.
> 
> --Kevin
> 
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 

Re: [MACTCL] Update on buttons

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

On 2/16/15 4:54 PM, Damon Courtney wrote:
> [info patchlevel] says 8.6.1, but we may have gotten something that was a HEAD pull from somewhere in between releases. I�m not actually sure. Did that work ever make it into a tagged release, or is it still only available in Fossil?
8.6.3 should work. K

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

Re: [MACTCL] Update on buttons

[Damon C. <da...@tc...>]

[info patchlevel] says 8.6.1, but we may have gotten something that was a HEAD pull from somewhere in between releases. I’m not actually sure. Did that work ever make it into a tagged release, or is it still only available in Fossil?


> On Feb 16, 2015, at 3:41 PM, Kevin Walzer <kw...@co...> wrote:
> 
> On 2/16/15 4:32 PM, Damon Courtney wrote:
>> The biggest problem I’ve run into on the Mac these days is dealing with PNGs with alpha channels. Drawing images on the Mac doesn’t seem to render the alpha channels properly, and they just end up as 100% opacity. At least from what I can tell. Does anyone know what I’m talking about?
> That bug was fixed last year, AFAIR; another set of extensive patches courtesy of Marc Culler. What version of Tcl/Tk/OSX are you running?
> 
> Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 

Re: [MACTCL] Update on buttons

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

On 2/16/15 4:32 PM, Damon Courtney wrote:
> The biggest problem I’ve run into on the Mac these days is dealing with PNGs with alpha channels. Drawing images on the Mac doesn’t seem to render the alpha channels properly, and they just end up as 100% opacity. At least from what I can tell. Does anyone know what I’m talking about?
That bug was fixed last year, AFAIR; another set of extensive patches 
courtesy of Marc Culler. What version of Tcl/Tk/OSX are you running?

Kevin

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

Re: [MACTCL] Update on buttons

[Damon C. <da...@tc...>]

The biggest problem I’ve run into on the Mac these days is dealing with PNGs with alpha channels. Drawing images on the Mac doesn’t seem to render the alpha channels properly, and they just end up as 100% opacity. At least from what I can tell. Does anyone know what I’m talking about?

Great work on all the drawing code, everyone. We might just get there yet. :)

Damon


> On Feb 16, 2015, at 3:15 PM, Kevin Walzer <kw...@co...> wrote:
> 
> Hello all,
> 
> Marc Culler has graciously submitted a patch that cleans up the button 
> metrics in HITheme on Cocoa; I've tested it via the Tk demo that comes 
> with Wish, and everything looks as it should--the same as it did under 
> Carbon and nearly indistinguishable from Cocoa. His patch simplfied the 
> geometry layout and removed a lot of special-casing I had put in.
> 
> Marc also submitted a smaller patch that tweaks the layout of ttk 
> notebook tabs so they look consistent with Cocoa notebooks under Yosemite.
> 
> Thanks to Marc for his work! I think we can declare the button updates 
> complete at this point.
> 
> All best,
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] Update on buttons

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

Hello all,

Marc Culler has graciously submitted a patch that cleans up the button 
metrics in HITheme on Cocoa; I've tested it via the Tk demo that comes 
with Wish, and everything looks as it should--the same as it did under 
Carbon and nearly indistinguishable from Cocoa. His patch simplfied the 
geometry layout and removed a lot of special-casing I had put in.

Marc also submitted a smaller patch that tweaks the layout of ttk 
notebook tabs so they look consistent with Cocoa notebooks under Yosemite.

Thanks to Marc for his work! I think we can declare the button updates 
complete at this point.

All best,
Kevin

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

Re: [MACTCL] Tk-Cocoa 2.0

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

Torsten,

On 2/16/15 2:33 AM, Torsten Berg wrote:
> Then, the bug occurs again (you do not even need the 3rd line). So, only when both vertical AND horizontal scrollbars are present, it is exposed. It does also NOT show up when just resizing (= enlarging) the window and keeping the mouse pointer outside the vertical scrollbar area. But as soon as you move the pointer into the vertical scrollbar area, the trough collapses (but of course only when you have a horizontal scrollbar at the same time. E.g. having two vertical scrollbars does not show the bug). I hope this helps to track the problem down …
OK, I see the issue when the horizontal scrollbar is added.

However, we still haven't addressed the core part of my question to you: 
Is this a cosmetic or functional bug?

Is scrolling hindered in some way because of this issue, or is it just a 
visual glitch? All of my testing indicates that it is visual: yes, it 
looks a little funny, but the scrollbar appears when required and 
scrolling is not hindered, nor is the overall layout of a window hindered.

I have less time at present to work on Tk, so I am prioritizing 
functional bugs: If this issue messes up layout somehow (as radio and 
checkbutton metrics still do), or if it causes a consistent crash, as 
the resizing did, then that gets focus.

Cosmetic bugs are much lower priority. The scrollbar does not get darker 
when it is pressed; that's possible to implement in HITheme, but 
figuring out the right place to toggle the pressed/not-pressed state is 
tricky, and I decided not to spend further time on it. What we have is 
good enough. Similarly, checkbuttons with an "indiatoron" state look 
very different than standard checkbuttons; they are rendered using a 
Unix-style layout. It's ugly, but there's no easy way to show that 
natively, so I left it as is. It's good enough.

This bug is falling into the cosmetic category for me, and as such, I am 
not likely to spend much time on it unless my reading of the situation 
is wrong.

--Kevin

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

Re: [MACTCL] Tk-Cocoa 2.0

[Torsten B. <be...@ty...>]

Hi Kevin,

I can reproduce that your example works. We do not need the vars and grid ding at all, you are right. I just more or less copied the relevant part of the code from my application. Now, just add these 3 lines to sour example:

ttk::scrollbar .f.scrollx -orient horizontal -command [list .f.list xview]
pack .f.scrollx -side bottom -fill x
.f.list configure -xscrollcommand [list .f.scrollx set]

Then, the bug occurs again (you do not even need the 3rd line). So, only when both vertical AND horizontal scrollbars are present, it is exposed. It does also NOT show up when just resizing (= enlarging) the window and keeping the mouse pointer outside the vertical scrollbar area. But as soon as you move the pointer into the vertical scrollbar area, the trough collapses (but of course only when you have a horizontal scrollbar at the same time. E.g. having two vertical scrollbars does not show the bug). I hope this helps to track the problem down …

Regards, Torsten

Am 16.02.2015 um 04:13 schrieb Kevin Walzer <kw...@co...>:

> Hi Torsten,
> 
> Glad resizing no longer crashes your app. :-)
> 
> On 2/15/15 6:06 PM, Torsten Berg wrote:
>> But there is another thing. When the vertical scrollbar is in the �empty� state, i.e. the content is not so large that scrolling is enabled and the gray bar is not shown, then it seems the widget collapses into a small quadrate as if ignoring any -sticky or -fill options. Try to run this script displaying a listbox with vertical and horizontal scrollbar attached:
> I saw  what you have described during the development of the new scroll 
> implementation. During those times it seemed that the system couldn't 
> correctly calculate the bounds of the scrollbar and so shrank to that 
> minimal rect.
> 
> I'm a bit surprised to see it now. I can certainly say that it does not 
> show up in other cases where the entire view is visibile, thus not 
> requiring a scrollbar; the scroll trough is drawn correctly, without 
> scrollbar. For instance, if I rewrite the code you presented as a simple 
> UI with a listbox and a scrollbar packed in a frame, the scrollbar 
> renders as expected. The example you presented, with all of its gridding 
> and vars and child widgets, was so complicated that I didn't understand 
> what it was, originally.
> 
> I can't say exactly what it causing the issue in your example; the 
> HITheme scrollbar was so difficult to implement that I am not likely to 
> dig into what is, essentially, a cosmetic issue. Even in your example, 
> the scrollbar comes back as required if the window is resized. And the 
> issue is not evident at all if you use a simpler layout.
> 
> My own example is below for your reference. --Kevin
> 
> frame .f
> pack .f -fill both -expand yes
> 
> listbox .f.list
> pack .f.list -fill both -expand yes -side left
> 
> 
> ttk::scrollbar .f.scroll -command [list .f.list yview]
> pack .f.scroll -side right -fill y -expand no
> 
> .f.list configure -yscrollcommand [list .f.scroll set]
> 
> # insert some data:
> for {set i 0} {$i < 20} {incr i} {.f.list insert end $i}
> 
> -- 
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Tk-Cocoa 2.0

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

Hi Torsten,

Glad resizing no longer crashes your app. :-)

On 2/15/15 6:06 PM, Torsten Berg wrote:
> But there is another thing. When the vertical scrollbar is in the �empty� state, i.e. the content is not so large that scrolling is enabled and the gray bar is not shown, then it seems the widget collapses into a small quadrate as if ignoring any -sticky or -fill options. Try to run this script displaying a listbox with vertical and horizontal scrollbar attached:
I saw  what you have described during the development of the new scroll 
implementation. During those times it seemed that the system couldn't 
correctly calculate the bounds of the scrollbar and so shrank to that 
minimal rect.

I'm a bit surprised to see it now. I can certainly say that it does not 
show up in other cases where the entire view is visibile, thus not 
requiring a scrollbar; the scroll trough is drawn correctly, without 
scrollbar. For instance, if I rewrite the code you presented as a simple 
UI with a listbox and a scrollbar packed in a frame, the scrollbar 
renders as expected. The example you presented, with all of its gridding 
and vars and child widgets, was so complicated that I didn't understand 
what it was, originally.

I can't say exactly what it causing the issue in your example; the 
HITheme scrollbar was so difficult to implement that I am not likely to 
dig into what is, essentially, a cosmetic issue. Even in your example, 
the scrollbar comes back as required if the window is resized. And the 
issue is not evident at all if you use a simpler layout.

My own example is below for your reference. --Kevin

frame .f
pack .f -fill both -expand yes

listbox .f.list
pack .f.list -fill both -expand yes -side left


ttk::scrollbar .f.scroll -command [list .f.list yview]
pack .f.scroll -side right -fill y -expand no

.f.list configure -yscrollcommand [list .f.scroll set]

# insert some data:
for {set i 0} {$i < 20} {incr i} {.f.list insert end $i}

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

Re: [MACTCL] Tk-Cocoa 2.0

[Torsten B. <be...@ty...>]

Dear Kevin,

thanks, yes this fixes the issue. I cannot crash the application any longer. That’s good! Now, I just see some visual artifacts when making a window larger. Some kind of black marks that are left behind from the lower right corner of the window when I slowly make the window larger and wait for the window to resize and then continue dragging. But that is OK as long as the app does not crash!

But there is another thing. When the vertical scrollbar is in the „empty“ state, i.e. the content is not so large that scrolling is enabled and the gray bar is not shown, then it seems the widget collapses into a small quadrate as if ignoring any -sticky or -fill options. Try to run this script displaying a listbox with vertical and horizontal scrollbar attached:

set parent .f
frame $parent -relief flat -borderwidth 1 -background #a8a8a8

# upper left:
set win $parent.ctrl
listbox $win -relief flat -borderwidth 0

# lower left:
ttk::scrollbar $parent.sx -orient horizontal	-command [list $win xview]
grid $parent.sx -column 0 -row 1 -sticky ew
$win configure -xscrollcommand [list $parent.sx set]

# upper right:
ttk::scrollbar $parent.sy -orient vertical -command [list $win yview]
grid $parent.sy -column 1 -row 0 -sticky ns
$win configure -yscrollcommand [list $parent.sy set]

# lower right:
frame $parent.lr -background #fafafa
grid $parent.lr -column 1 -row 1 -sticky news

# Arrange child widget in the parent frame:
grid $win -column 0 -row 0 -sticky nsew
grid columnconfigure $parent 0 -weight 1
grid rowconfigure $parent 0 -weight 1
pack $parent -fill both -expand yes

# insert some data:
for {set i 0} {$i < 20} {incr i} {$win insert end $i}


Initially, everything seems ok, the vertical scrollbar is there and is functional. But when making the window longer than the content of the twenty rows, the vertical scrollbar area changes its appearance and the scrollbar trough collapses to a small area in the middle of the vertical scrollbar. Is that reproducible at your end?

As for the sharp corners of the main window, you are right, this is nothing major and I didn’t intend to make you „fix“ this. I just thought you might know where to look for such a thing and I could try myself with my limited knowledge to the complex structure of the Tk code.

Torsten

> I think I've fixed the issue: I was doing multiple calls to 
> NSDisableScreenUpdates() and NSEnableScreenUpdates(), as well as setting 
> the state of the main NSView to hidden, during resize events--once 
> during the actual resize event, and also during the notification of the 
> resize event. It was the NSNotification call that seemed to be clogging 
> the event loop and causing the crash; removing those calls, but leaving 
> them during the resize, preserves the smoothness I was striving for, but 
> doesn't trigger any crashes in my testing. (I was testing this using the 
> TkChat app I maintain, which I was able to crash consistently when 
> resizing it quickly.)
> 
> See if the new commits help the issue on your end.

Re: [MACTCL] Tk-Cocoa 2.0

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

I’m not seeing any hangs in this version (but I didn’t in the previous version, either).

— Russell

On Feb 13, 2015, at 5:29 PM, Kevin Walzer <kw...@co...> wrote:

> Hi Russell and Torsten,
> 
> On 2/13/15 7:25 PM, Russell Owen wrote:
>> 
>>>> It seems it could have something to do with timing. If the application has enough time to adjust, then OK, but if the change is �too radical� or just too quick (too many events in a short time?), then the crash occurs. This is reproducible in 9 out of 10 times.
>>> It's setting window visibility to false and disabling screen updates, so
>>> it may not be able to keep up with a rapid stream of events. I may just
>>> have to take that out and leave a bit of flicker during resize--it will
>>> still be reduced because of the other changes I've made. I'll report
>>> back soon.
>> 
>> I personally would rather have the flicker than the delay in the start of resizing. But either way works and it is your call, since you are doing the work!
>> 
>> I realize a null result isn't much help but I tried rapidly resizing some windows on my system (MacOS X 10.9.5 using the 8.5 branch of tcl/tk checked out earlier today) and I have not been able to induce a crash. That's with a plain wish window and with two applications I wrote.
>> 
> 
> I think I've fixed the issue: I was doing multiple calls to NSDisableScreenUpdates() and NSEnableScreenUpdates(), as well as setting the state of the main NSView to hidden, during resize events--once during the actual resize event, and also during the notification of the resize event. It was the NSNotification call that seemed to be clogging the event loop and causing the crash; removing those calls, but leaving them during the resize, preserves the smoothness I was striving for, but doesn't trigger any crashes in my testing. (I was testing this using the TkChat app I maintain, which I was able to crash consistently when resizing it quickly.)
> 
> See if the new commits help the issue on your end.
> 
> Thanks,
> Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 

Re: [MACTCL] Tk-Cocoa 2.0

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

Hi Russell and Torsten,

On 2/13/15 7:25 PM, Russell Owen wrote:
>
>>> It seems it could have something to do with timing. If the 
>>> application has enough time to adjust, then OK, but if the change is 
>>> �too radical� or just too quick (too many events in a short time?), 
>>> then the crash occurs. This is reproducible in 9 out of 10 times.
>> It's setting window visibility to false and disabling screen updates, so
>> it may not be able to keep up with a rapid stream of events. I may just
>> have to take that out and leave a bit of flicker during resize--it will
>> still be reduced because of the other changes I've made. I'll report
>> back soon.
>
> I personally would rather have the flicker than the delay in the start 
> of resizing. But either way works and it is your call, since you are 
> doing the work!
>
> I realize a null result isn't much help but I tried rapidly resizing 
> some windows on my system (MacOS X 10.9.5 using the 8.5 branch of 
> tcl/tk checked out earlier today) and I have not been able to induce a 
> crash. That's with a plain wish window and with two applications I wrote.
>

I think I've fixed the issue: I was doing multiple calls to 
NSDisableScreenUpdates() and NSEnableScreenUpdates(), as well as setting 
the state of the main NSView to hidden, during resize events--once 
during the actual resize event, and also during the notification of the 
resize event. It was the NSNotification call that seemed to be clogging 
the event loop and causing the crash; removing those calls, but leaving 
them during the resize, preserves the smoothness I was striving for, but 
doesn't trigger any crashes in my testing. (I was testing this using the 
TkChat app I maintain, which I was able to crash consistently when 
resizing it quickly.)

See if the new commits help the issue on your end.

Thanks,
Kevin

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

Re: [MACTCL] Tk-Cocoa 2.0

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

Hi Torsten,

Thanks for the feedback.

On 2/13/15 2:49 AM, Torsten Berg wrote:
>
> When I resize the window slowly, even holding down the mouse button on a spot for a while, then moving on, everything is OK. After waiting for some fraction of a second, the window will even resize (while still holding the mouse button pressed) and resize more or less smoothly while dragging the mouse further across the screen. From your description, however, I would have expected it not to resize at all until the mouse button is released.
>
> But when I do the resize very quickly, moving the mouse fast across the screen, the application will crash, leaving this behind:
> (using a 32bit wish 8.6.3 embedded build on OS X 10.9.5)
I've seen this in one or two instances; since you are reproducing it 
consistently it's obviously not just some random glitch. (I thought the 
problem was just on my system.) I suspect it's a result of the resize 
code I put in; I'll take a look and see if removing it solves the crash.
> It seems it could have something to do with timing. If the application has enough time to adjust, then OK, but if the change is �too radical� or just too quick (too many events in a short time?), then the crash occurs. This is reproducible in 9 out of 10 times.
It's setting window visibility to false and disabling screen updates, so 
it may not be able to keep up with a rapid stream of events. I may just 
have to take that out and leave a bit of flicker during resize--it will 
still be reduced because of the other changes I've made. I'll report 
back soon.

>
> Another thing I noticed. The main window is having the rounded corners at the top side, but the bottom side has sharp corners, not looking like the typical Cocoa window (this is not new though, I observed this in older wish versions too). However, when doing the resizing of the main window, the corners turn into rounded ones and when the mouse button is released, the corners turn sharp again. Any idea what that may be caused by? It seems, Tk or the underlying Cocoa is drawing the window correctly, but then someone is drawing a sharp corner on top afterwards. Where could I look to find out how to remove this behavior?

No idea about this; I think I've seen it too, but IMO it is a minor 
visual artifact that I will probably not have time to address.

I'll report back when I have something updated to test.

--Kevin

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

Re: [MACTCL] Tk-Cocoa 2.0

[Torsten B. <be...@ty...>]

Dear Kevin,

this is really great and a big „thank you“ for these improvements! I didn’t work with the intermediate versions showing the flickering and ghost images, but with the current trunk all looks to me like it did before, so I cannot easily spot the subtle visual differences that would be there.

The only thing I do observe is a mysterious crash when resizing the main window of the application that I am currently developing. I cannot reproduce this with a blank wish window (without any widgets inside) or with just one widget, though.

When I resize the window slowly, even holding down the mouse button on a spot for a while, then moving on, everything is OK. After waiting for some fraction of a second, the window will even resize (while still holding the mouse button pressed) and resize more or less smoothly while dragging the mouse further across the screen. From your description, however, I would have expected it not to resize at all until the mouse button is released.

But when I do the resize very quickly, moving the mouse fast across the screen, the application will crash, leaving this behind:
(using a 32bit wish 8.6.3 embedded build on OS X 10.9.5)

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000010000020

VM Regions Near 0x10000020:
    MALLOC_LARGE           00000000075bb000-000000000765c000 [  644K] rw-/rwx SM=PRV  
--> 
    __TEXT                 000000008feee000-000000008ff21000 [  204K] r-x/rwx SM=COW  /usr/lib/dyld

Application Specific Information:
objc_msgSend() selector name: release


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib               	0x9915c4a7 objc_msgSend + 23
1   com.apple.AppKit              	0x97a7336a -[NSBitmapGraphicsContext dealloc] + 38
2   libobjc.A.dylib               	0x991725ef -[NSObject release] + 47
3   libobjc.A.dylib               	0x9915e497 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 527
4   com.apple.CoreFoundation      	0x9559991f _CFAutoreleasePoolPop + 47
5   com.apple.Foundation          	0x98615c24 -[NSAutoreleasePool drain] + 122
6   com.apple.AppKit              	0x9835438d -[NSWindow(NSWindowResizing) _resizeWithEvent:] + 668
7   com.apple.AppKit              	0x98133112 -[NSTitledFrame resizeWithEvent:] + 43
8   com.apple.AppKit              	0x97c70176 -[NSTitledFrame mouseDown:] + 217
9   com.apple.AppKit              	0x97c6ff27 -[NSThemeFrame mouseDown:] + 212
10  com.apple.AppKit              	0x97b80a9d -[NSWindow sendEvent:] + 11953
11  com.apple.AppKit              	0x97b1c91d -[NSApplication sendEvent:] + 4034
12  Tk                            	0x000da148 0x8000 + 860488
13  Tk                            	0x000da555 0x8000 + 861525
14  Tcl                           	0x001fe99c Tcl_DoOneEvent + 308
15  Tk                            	0x0001ec0d Tk_MainLoop + 41
16  Tk                            	0x0002cba6 Tk_MainEx + 2038
17  wish-aqua8.6                  	0x000044c3 0x1000 + 13507
18  wish-aqua8.6                  	0x00004451 0x1000 + 13393

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x93578992 kevent64 + 10
1   libdispatch.dylib             	0x97172899 _dispatch_mgr_invoke + 238
2   libdispatch.dylib             	0x97172532 _dispatch_mgr_thread + 52

Thread 2:
0   libsystem_kernel.dylib        	0x93578046 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x93f33dcf _pthread_wqthread + 372
2   libsystem_pthread.dylib       	0x93f37cce start_wqthread + 30

Thread 3:
0   libsystem_kernel.dylib        	0x93578046 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x93f33dcf _pthread_wqthread + 372
2   libsystem_pthread.dylib       	0x93f37cce start_wqthread + 30

Thread 4:
0   libsystem_kernel.dylib        	0x93578046 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x93f33dcf _pthread_wqthread + 372
2   libsystem_pthread.dylib       	0x93f37cce start_wqthread + 30

Thread 5:
0   libsystem_kernel.dylib        	0x93577ace __select + 10
1   Tcl                           	0x0024d2e4 0x13d000 + 1114852
2   libsystem_pthread.dylib       	0x93f325fb _pthread_body + 144
3   libsystem_pthread.dylib       	0x93f32485 _pthread_start + 130
4   libsystem_pthread.dylib       	0x93f37cf2 thread_start + 34

Thread 6:
0   libsystem_kernel.dylib        	0x93572f7a mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x9357216c mach_msg + 68
2   com.apple.CoreFoundation      	0x955d5bf9 __CFRunLoopServiceMachPort + 169
3   com.apple.CoreFoundation      	0x955d51d1 __CFRunLoopRun + 1393
4   com.apple.CoreFoundation      	0x955d49ea CFRunLoopRunSpecific + 394
5   com.apple.CoreFoundation      	0x955d484b CFRunLoopRunInMode + 123
6   com.apple.AppKit              	0x97b18b88 _NSEventThread + 283
7   libsystem_pthread.dylib       	0x93f325fb _pthread_body + 144
8   libsystem_pthread.dylib       	0x93f32485 _pthread_start + 130
9   libsystem_pthread.dylib       	0x93f37cf2 thread_start + 34

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x0213a1d0  ebx: 0x98615bb8  ecx: 0x99178167  edx: 0x10000000
  edi: 0x0213aac0  esi: 0x97a73351  ebp: 0xbfffeee8  esp: 0xbfffeec8
   ss: 0x00000023  efl: 0x00010202  eip: 0x9915c4a7   cs: 0x0000001b
   ds: 0x00000023   es: 0x00000023   fs: 0x00000000   gs: 0x0000000f
  cr2: 0x10000020
  
Logical CPU:     3
Error Code:      0x00000004
Trap Number:     14


It seems it could have something to do with timing. If the application has enough time to adjust, then OK, but if the change is „too radical“ or just too quick (too many events in a short time?), then the crash occurs. This is reproducible in 9 out of 10 times.

Another thing I noticed. The main window is having the rounded corners at the top side, but the bottom side has sharp corners, not looking like the typical Cocoa window (this is not new though, I observed this in older wish versions too). However, when doing the resizing of the main window, the corners turn into rounded ones and when the mouse button is released, the corners turn sharp again. Any idea what that may be caused by? It seems, Tk or the underlying Cocoa is drawing the window correctly, but then someone is drawing a sharp corner on top afterwards. Where could I look to find out how to remove this behavior?

Torsten


> Hi all,
> 
> Just a quick note to let you know I have committed the last of my 
> HITheme work in Tk-Cocoa to trunk and core-8-5-branch; initial reports 
> suggest that these changes address many of the serious bugs that folks 
> have reported in recent months, especially since I removed the private 
> Cocoa API's last summer.
> 
> With these commits, this phase of major, active development on Tk/Cocoa 
> is done. There have been enough changes over the past year that I don't 
> feel unjustified in referring to this iteration as "Tk-Cocoa 2.0." I've 
> posted a blog entry here that goes into more detail on the history, the 
> technical issues, and what these changes mean:
> 
> http://www.codebykevin.com/blosxom.cgi/2015/01/30#tk-cocoa-2.0
> 
> I think Tk-Cocoa is now improved. Thanks to all who have provided 
> feedback, bug reports, patches, and encouragement.
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
> 
> 
> ------------------------------------------------------------------------------
> 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] Tk-Cocoa 2.0

[Will D. <wil...@gm...>]

Thank you, Kevin!
On Fri, Jan 30, 2015 at 8:06 PM Kevin Walzer <kw...@co...> wrote:

> Hi all,
>
> Just a quick note to let you know I have committed the last of my
> HITheme work in Tk-Cocoa to trunk and core-8-5-branch; initial reports
> suggest that these changes address many of the serious bugs that folks
> have reported in recent months, especially since I removed the private
> Cocoa API's last summer.
>
> With these commits, this phase of major, active development on Tk/Cocoa
> is done. There have been enough changes over the past year that I don't
> feel unjustified in referring to this iteration as "Tk-Cocoa 2.0." I've
> posted a blog entry here that goes into more detail on the history, the
> technical issues, and what these changes mean:
>
> http://www.codebykevin.com/blosxom.cgi/2015/01/30#tk-cocoa-2.0
>
> I think Tk-Cocoa is now improved. Thanks to all who have provided
> feedback, bug reports, patches, and encouragement.
>
> --Kevin
>
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
>
>
> ------------------------------------------------------------
> ------------------
> 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
>

[MACTCL] Tk-Cocoa 2.0

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

Hi all,

Just a quick note to let you know I have committed the last of my 
HITheme work in Tk-Cocoa to trunk and core-8-5-branch; initial reports 
suggest that these changes address many of the serious bugs that folks 
have reported in recent months, especially since I removed the private 
Cocoa API's last summer.

With these commits, this phase of major, active development on Tk/Cocoa 
is done. There have been enough changes over the past year that I don't 
feel unjustified in referring to this iteration as "Tk-Cocoa 2.0." I've 
posted a blog entry here that goes into more detail on the history, the 
technical issues, and what these changes mean:

http://www.codebykevin.com/blosxom.cgi/2015/01/30#tk-cocoa-2.0

I think Tk-Cocoa is now improved. Thanks to all who have provided 
feedback, bug reports, patches, and encouragement.

--Kevin

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