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

Re: [MACTCL] Menubutton and Checkbutton width wrong on MacOS X

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

I think if it's possible for Tk to support a widget option consistently across platforms it should do its best to do so.  What is or isn't best programming practice is one thing, but the API is kind of like a contract, that allows cross-platform applications to be written without the need for a lot of if-then's to handle different environments.

This is why when ttk was added, the approach was to provide a more minimal set of configuration options for each widget, to ensure that it could be adhered to for each platform, rather than providing a bigger set of which parts might or might not work in a given environment.


-Adrian



On 2012/11/28, at 11:07, Kevin Walzer <kw...@co...> wrote:

> Hi list,
> 
> On 11/26/12 4:31 PM, Russell E. Owen wrote:
>> 
>> Would it be OK to change Tcl/Tk so that the width option on these
>> widgets actually does specify roughly how many chars could be displayed?
>> Its a simple change, though admittedly one that requires a Mac-specific
>> branch. I guess an obvious question is how widely others are already
>> hacking around this issue. (I assume most users use width=0 and thus
>> don't see this bug).
> 
> I would appreciate others weighing in on this.
> 
> As I've commented to Russell at the bug report, my view is that  what 
> he's seeing is not a bug but simply the platform-specific 
> implementation, i.e. Cocoa may simply calculate text width and render it 
> a bit differently than did Carbon. (Carbon used QuickDraw and then ATSUI 
> for its text rendering, while Cocoa uses CoreText.) If he does not use 
> hard-coded widths then the text displays fine, although it may change 
> the layout of his app.
> 
> My understanding is that it's not considered a best practice in Tk to 
> hard-code text widths and font sizes, because font rendering can vary so 
> widely across platforms: what looks good on one platform may look quite 
> different (and not so good) on another. My limited experience with 
> deploying a Tk app on Windows confirms this.
> 
> I'm reluctant to go against the platform-specific grain and investigate 
> a change that would preserve cross-platform compatibility at the expense 
> of best practices on the specific platform, cf. how other Cocoa-based 
> apps do it. I'm especially reluctant to do so (and not even sure it can 
> be done) given that Russell has found a workaround for his use case.
> 
> Other opinions are welcome.
> 
> Thanks,
> Kevin
> 
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> 
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel: 
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Menubutton and Checkbutton width wrong on MacOS X

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

Hi list,

On 11/26/12 4:31 PM, Russell E. Owen wrote:
>
> Would it be OK to change Tcl/Tk so that the width option on these
> widgets actually does specify roughly how many chars could be displayed?
> Its a simple change, though admittedly one that requires a Mac-specific
> branch. I guess an obvious question is how widely others are already
> hacking around this issue. (I assume most users use width=0 and thus
> don't see this bug).

I would appreciate others weighing in on this.

As I've commented to Russell at the bug report, my view is that  what 
he's seeing is not a bug but simply the platform-specific 
implementation, i.e. Cocoa may simply calculate text width and render it 
a bit differently than did Carbon. (Carbon used QuickDraw and then ATSUI 
for its text rendering, while Cocoa uses CoreText.) If he does not use 
hard-coded widths then the text displays fine, although it may change 
the layout of his app.

My understanding is that it's not considered a best practice in Tk to 
hard-code text widths and font sizes, because font rendering can vary so 
widely across platforms: what looks good on one platform may look quite 
different (and not so good) on another. My limited experience with 
deploying a Tk app on Windows confirms this.

I'm reluctant to go against the platform-specific grain and investigate 
a change that would preserve cross-platform compatibility at the expense 
of best practices on the specific platform, cf. how other Cocoa-based 
apps do it. I'm especially reluctant to do so (and not even sure it can 
be done) given that Russell has found a workaround for his use case.

Other opinions are welcome.

Thanks,
Kevin


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

[MACTCL] Menubutton and Checkbutton width wrong on MacOS X

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

I've reported these as bugs and been told they are best discussed before 
being changed, so here goes:

On MacOS X if one specifies a nonzero width (in chars) for a checkbutton 
or menubutton, the number of chars that will be displayed is far less 
than the width. This is a change from Tcl/Tk 8.4 to 8.5 and I'm very 
confused as to why this occurred and why not fix it?

In Tcl/Tk 8.4 when a widget took a width parameter measured in chars you 
could count on the width showing roughly that many chars. Now in 8.5 you 
cannot. (I have not tried 8.6, but I'll be surprised if it's different 
than 8.5).

This ruined the appearance of much of my application until I hacked 
around it. Fortunately I subclass checkbutton and menubutton so I could 
apply the hack in just one place. But I hate to leave things like that 
in my code.

Would it be OK to change Tcl/Tk so that the width option on these 
widgets actually does specify roughly how many chars could be displayed? 
Its a simple change, though admittedly one that requires a Mac-specific 
branch. I guess an obvious question is how widely others are already 
hacking around this issue. (I assume most users use width=0 and thus 
don't see this bug).

My use case: often I have widgets that can display one of several 
strings. In that case I usually prefer to specify a width sufficient 
that the longest string can be displayed. That way the containing window 
retains its size.

-- Russell

P.S. the bug numbers are:
3580194 for menubutton
not yet reported for checkbutton, given the cold reception to the 
menubutton bug

Re: [MACTCL] Postings being held; any idea why?

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

In article <50A...@co...>,
 Kevin Walzer <kw...@co...> wrote:

> Russell,
> 
> On 11/16/12 2:24 PM, Russell E. Owen wrote:
> > All previous two posts to this mailing list using gmane were both held
> > for moderator approval. (And this one will probably also be held.)
> 
> Which list are you referring to? The only list admin for the Tcl-Mac SF 
> list I'm aware of is Daniel Steffen--at least he's the one listed on the 
> main page.

Tcl-Mac. I am an admin. I handle most of the held postings (which were 
mostly spam until all my postings started being held).

Regards,

-- Russell

Re: [MACTCL] Tk 8.5.13 using functions not supported in OS X 10.5.8

[Jeff H. <je...@ac...>]

On 2012-11-17, at 8:25 AM, Kevin Walzer <kw...@co...> wrote:
> On 11/16/12 11:53 PM, John Gleeson wrote:
>> Has support for 10.5.8 been dropped?
> 
> As an alternative, stick to 8.5.12, which is still based on Carbon and 
> should run fine on 10.5, and 10.4 for that matter.

+1 on sticking to 8.5.12 for 10.5.8 support.  While this wasn't intentional, 10.6 is the last "supported" version of OS X by Apple, and it's hard to keep compat in such cases.

Jeff

Re: [MACTCL] Tk 8.5.13 using functions not supported in OS X 10.5.8

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

On 11/16/12 11:53 PM, John Gleeson wrote:
> Has support for 10.5.8 been dropped?

As an alternative, stick to 8.5.12, which is still based on Carbon and 
should run fine on 10.5, and 10.4 for that matter.

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

Re: [MACTCL] Tk 8.5.13 using functions not supported in OS X 10.5.8

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

On 11/16/12 11:53 PM, John Gleeson wrote:
> The functions
>       NSApplicationPresentationAutoHideDock
> and
>       NSApplicationPresentationAutoHideMenuBar
> used in
>       tk8.5.13/unix/../macosx/tkMacOSXWm.c:6332
> were introduced in OS X 10.6.  I saw the recent thread on the decision
> to drop
> Carbon. I realized it would affect 10.4, but I hoped that 10.5 would
> still be supported.
>
> Has support for 10.5.8 been dropped?


Hmmm. Those API's were added in a recent patch that fixed the fullscreen 
implementation. I didn't realize they were > 10.6.

There's no formal policy to drop 10.5 support, and that's the minimum OS 
version to build Tk-Cocoa, but as Apple is speeding up its OS releases 
(and dropping support for older ones), it's harder to keep up.

I don't think untangling those specific API's is a valid option at this 
point because the fullscreen support was so broken under Cocoa. My best 
advice is if you want to use Cocoa on 10.5, stick with an older 
ActiveState release.

--Kevin


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

[MACTCL] Tk 8.5.13 using functions not supported in OS X 10.5.8

[John G. <jdg...@ma...>]

The functions
     NSApplicationPresentationAutoHideDock
and
     NSApplicationPresentationAutoHideMenuBar
used in
     tk8.5.13/unix/../macosx/tkMacOSXWm.c:6332
were introduced in OS X 10.6.  I saw the recent thread on the decision  
to drop
Carbon. I realized it would affect 10.4, but I hoped that 10.5 would  
still be supported.

Has support for 10.5.8 been dropped?

Re: [MACTCL] Postings being held; any idea why?

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

Russell,

On 11/16/12 2:24 PM, Russell E. Owen wrote:
> All previous two posts to this mailing list using gmane were both held
> for moderator approval. (And this one will probably also be held.)

Which list are you referring to? The only list admin for the Tcl-Mac SF 
list I'm aware of is Daniel Steffen--at least he's the one listed on the 
main page.

--Kevin

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

Re: [MACTCL] Postings being held; any idea why?

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

In article <row...@ne...>,
 "Russell E. Owen" <ro...@uw...> wrote:

> All previous two posts to this mailing list using gmane were both held 
> for moderator approval. (And this one will probably also be held.)
> 
> I am one of the moderators for this group, and the moderator page showed 
> my messages as being from me (a moderator) yet it held them anyway. So 
> it's not as if I was posting from an unrecognized email address.

I forgot this detail. The reason it is being held:
   Post to moderated list

-- Russell

[MACTCL] Postings being held; any idea why?

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

All previous two posts to this mailing list using gmane were both held 
for moderator approval. (And this one will probably also be held.)

I am one of the moderators for this group, and the moderator page showed 
my messages as being from me (a moderator) yet it held them anyway. So 
it's not as if I was posting from an unrecognized email address.

Any idea what's going on? I see very few legitimate postings held -- 
perhaps once a month somebody posts from an unknown email address. So 
this is new and unwelcome behavior.

-- Russell

Re: [MACTCL] menubutton width error

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

In article <row...@ne...>,
 "Russell E. Owen" <ro...@uw...> wrote:

> I'm switching from Tcl/Tk 8.4.x to 8.5.x on MaOS (so I can use modern 
> 64-bit python) and am running into many problems.
> 
> I've been able to find workarounds for most, but not this one (bug #ID 
> 3587262): menubuttons are often shown far too narrow if the size is 
> automatic*. Here is a demonstration:
> 
> tk_optionMenu .om omVar DC1 DC2 DC3
> .om configure -width 3 # -indicatoron 0
> pack .om

Sorry...wrong code (the above demonstrates a bug with manual width that 
is easy to work around and is not affected by font). Here's the code 
showing the bug for the automatic case:

option add "*font" "{Lucida Grande} 12"
menubutton .mb -textvariable var
pack .mb
set var "Normal"

> One oddity is that the display becomes correct if I change the font size 
> (and I can then change it back and it is still right).
> 
> Does anyone know a simple workaround? I fear I'm going to have to assign 
> a callback to the variable and manually set the width based on the 
> content of the var, but I was hoping for something simpler.
...

-- Russell

[MACTCL] menubutton width error

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

I'm switching from Tcl/Tk 8.4.x to 8.5.x on MaOS (so I can use modern 
64-bit python) and am running into many problems.

I've been able to find workarounds for most, but not this one (bug #ID 
3587262): menubuttons are often shown far too narrow if the size is 
automatic*. Here is a demonstration:

tk_optionMenu .om omVar DC1 DC2 DC3
.om configure -width 3 # -indicatoron 0
pack .om

One oddity is that the display becomes correct if I change the font size 
(and I can then change it back and it is still right).

Does anyone know a simple workaround? I fear I'm going to have to assign 
a callback to the variable and manually set the width based on the 
content of the var, but I was hoping for something simpler.

I've seen this on MacOS 10.8 using ActiveState Tcl/Tk 8.5.11 and 8.5.12. 
I understand Tcl/Tk 8.5.13 just came out, but I've not seen an 
ActiveState installer for that yet.

-- Russell

*It is a separate bug #3580194 that the width is too narrow if an 
explicit (nonzero) width is specified. I work around that one by 
increasing the width on aqua, though my workaround will cause very wide 
menus if the bug is ever fixed.

[MACTCL] Giving Mac App Store another try

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

Hi all,

This isn't 100% on topic for the list, so I'll keep it brief: I've 
decided to give the Mac App Store another try, for business reasons: I 
earn enough revenue from my Tcl/Tk apps there that I'm reluctant to give 
that up.

I still have deep reservations about some of the Mac App Store's 
requirements, and Tcl/Tk presents some technical challenges that require 
a good deal of work and jiggering to work through. As I run into and 
resolve those technical issues, I'll discuss what I learn here, in case 
anyone else wants to venture into these waters.

On a related note, I'm now offering consulting services to help 
companies optimize the user experience of their Tcl/Tk apps on the Mac. 
For more information, see http://www.codebykevin.com/consulting.html.

Thanks,
Kevin
-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[MACTCL] Hotel Room Rate Reminder - 19th Annual Tcl/Tk Conference (Tcl'2012)

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

19th Annual Tcl/Tk Conference (Tcl'2012)
http://www.tcl.tk/community/tcl2012/

November 12 - 16, 2012
Sessions:
    National Museum of Health and Medicine Chicago
    175 W. Washington
    Chicago, IL 60602

Rooms:
    Holiday Inn Chicago Mart Plaza
    350 West Mart Center Drive
    Chicago, Illinois, USA

Map/Transport:
    https://maps.google.com/maps/ms?msid=204739899073144451536.0004c144222a9036c99f6&msa=0&ll=41.885266,-87.633734&spn=0.008443,0.018818 
    http://wiki.tcl.tk/28843#pagetoca7e55932


Hello all.

This is a reminder that the offer of reduced rates for rooms at the
conference hotel expires on October 20, i.e. at the end of this week.

	Book Now! (if you haven't already).

And talk to us should you run into trouble with the Hotel claiming to
be sold out already before the deadline.

Of course registration for the Conference is still open at

	http://www.tcl.tk/community/tcl2012/reg.html

To book a room at the conference hotel at reduced rates please follow
the instructions on that page.

Our schedule can be found at

	http://www.tcl.tk/community/tcl2012/schedule.html

Conference Committee

Clif Flynt              Noumena Corp					General Chair, Website Admin
Andreas Kupries         ActiveState Software Inc.			Program Chair
Cyndy Lilagan           Nat. Museum of Health & Medicine, Chicago	Site/Facilities Chair
Arjen Markus            Deltares
Brian Griffin           Mentor Graphics
Donal Fellows           University of Manchester
Gerald Lester           KnG Consulting, LLC
Jeffrey Hobbs           ActiveState Software Inc.
Kevin Kenny             GE Global Research Center
Larry Virden
Mike Doyle              National Museum of Health & Medicine, Chicago
Ron Fox                 NSCL/FRIB Michigan State University
Steve Landers           Digital Smarties

Contact Information     tcl...@go...


Tcl'2012 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

Re: [MACTCL] makefile install target doesn't quite work as it should for wish8.5, loads wrong Tk

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

On 10/12/12 12:02 AM, James Burgess wrote:
> I know nothing of autoconf so I wouldn't know how to fix this properly although the tool that the makefile needs to run  to set this is install_name_tool. "man install_name_tool" will tell all.

The relevant makefile is GNUMakefile in tk/macosx; you may be able to 
hack that to work better. I don't see this issue with trunk, but I've 
never tried it with 8.5 as it's my production build.

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

[MACTCL] makefile install target doesn't quite work as it should for wish8.5, loads wrong Tk

[James B. <jam...@ma...>]

This is a minor annoyance and can be worked around but if you get the fossil head of 8.5 and do this on Lion:

make -C tcl/macosx
make -C tcl/macosx install INSTALL_ROOT=/foo/install
make -C tk/macosx/
make -C tk/macosx install INSTALL_ROOT=/foo/install

The makefiles do not  correctly set the install path in the Wish binary that gets put in /foo/install/Library. Consequently 
if you run the wish in /foo/install/usr/local/bin/wish, that bash script will run the right binary, but the binary will not
find the right Tk dylib. Instead it will load the one that ships with Lion in /System/Library. You can force dyld to do the
right thing with the following (this is a developer convenience, not a deployment strategy):

export DYLD_FRAMEWORK_PATH=/foo/install/Library/Frameworks

I know nothing of autoconf so I wouldn't know how to fix this properly although the tool that the makefile needs to run  to set this is install_name_tool. "man install_name_tool" will tell all.

Cheers,

- James

Re: [MACTCL] Cocoa port git repo?

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

On 10/9/12 5:21 PM, James Burgess wrote:
> in the comments of this thread das refers to a git repo where he did
> some experiments
> because he'd decided Tcl_ServiceAll() wasn't doing what he needed it to.
> Does anyone
> here know what repo and branch he's referring to? Has all this been
> imported into fossil now?

The github repo is Daniel Steffen's own, which he used when initially 
developing the Tk-Cocoa port. He stopped updating it in 2009, I believe, 
and it is now obsolete--everything has since been imported into fossil.

For spits and giggles, here's the relevant link:

https://github.com/das/tcltk/tree/de-carbon-8-5

If you decide to poke around the history notes and find something 
relevant to the event loop question, please share them.

--Kevin

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

[MACTCL] Cocoa port git repo?

[James B. <jam...@ma...>]

I'm back to looking at the event loop issue and now I can read old posts via gmane.
 I see Adrian pointed to this ancient thread:

http://sourceforge.net/tracker/?func=detail&aid=3028676&group_id=12997&atid=112997

in the comments of this thread das refers to a git repo where he did some experiments
because he'd decided Tcl_ServiceAll() wasn't doing what he needed it to. Does anyone
here know what repo and branch he's referring to? Has all this been imported into fossil now?

Cheers,
- James

PS Someone from sourceforge opened a ticket on why their forums don't wrap text...

Re: [MACTCL] Tk 8.5.12.x crashes opening IDLE Preferences menu

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

Hi Ned,

> Who is Neil??

Sorry for the misnomer. :}

>
> I didn't try the core-8-5-branch earlier because it wasn't clear from
> the checkin comments what state the merge was in.  I just did a quick
> build using it and I have the same results as you report.  The IDLE
> Preferences crash is still present ...

I'll have to do a bit more digging to see if I can figure this out. The 
previous mousewheel bug you filed (3520202) didn't seem to be visible in 
Tk, but was exposed somehow by Tkinter's code. Maybe something similar 
is at work here.

>
>>> I've also opened another Tk issue (#3575681) concerning another Cocoa Tk
>>> crasher when using clipboard copy in IDLE, a regression that was
>>> introduced in 8.5.12.0 and only partially fixed in ActiveTcl 8.5.12.1.
>> I think I can conclusively say that this bug is outdated; I can't
>> reproduce the clipboard issue in either Wish or IDLE, build of
>> core-8-5-branch. I've left the bug report open to allow further
>> comments, but it works for me and I will close it soon.
>
> ... and the IDLE clipboard crash is no longer reproducible.
>

OK, I'll close that bug later today.

K


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

Re: [MACTCL] Tk 8.5.12.x crashes opening IDLE Preferences menu

[Ned D. <na...@ac...>]

In article <507...@co...>,
 Kevin Walzer <kw...@co...> wrote:

> Hi Neil,

Who is Neil??
 
> On 10/9/12 5:42 AM, Ned Deily wrote:
> > An update: I've figured out how to build the Cocoa Tk backport from the
> > Fossil repo and after, bisecting of changes, I believe I've isolated the
> > problem to a particular checkin.  I've opened Tk issue #3575664 with the
> > details.  We are seeing a growing number of Python IDLE users reporting
> > this problem.
> >
> > I'd be very interested to know if the ActiveState folks can reproduce
> > the problem using the current tip of the branch and with their build
> > process.  After some discussion of the Python Mac list, Kevin reports he
> > is now able to reproduce the problem with his builds.
> >
> > https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3575664&grou
> > p_id=12997
> 
> Thanks for posting these. As I noted in the bug reports, the branch you 
> are testing against is no longer being used for Tk-Cocoa builds (I 
> should probably close it). Can you try checking out and testing against 
> core-8-5-branch?

I didn't try the core-8-5-branch earlier because it wasn't clear from 
the checkin comments what state the merge was in.  I just did a quick 
build using it and I have the same results as you report.  The IDLE 
Preferences crash is still present ...

> > I've also opened another Tk issue (#3575681) concerning another Cocoa Tk
> > crasher when using clipboard copy in IDLE, a regression that was
> > introduced in 8.5.12.0 and only partially fixed in ActiveTcl 8.5.12.1.
> I think I can conclusively say that this bug is outdated; I can't 
> reproduce the clipboard issue in either Wish or IDLE, build of 
> core-8-5-branch. I've left the bug report open to allow further 
> comments, but it works for me and I will close it soon.

... and the IDLE clipboard crash is no longer reproducible.

-- 
 Ned Deily,
 na...@ac...

Re: [MACTCL] any one else notice the archives on this list are now ridiculously hard to read? CSS change?

[Jon G. <jg...@hi...>]

On Oct 8, 2012, at 8:40 PM, Kevin Walzer <kw...@co...> wrote:

> On 10/8/12 8:26 PM, James Burgess wrote:
>> and I can see anything after midway into my second sentence since it's clipped off. There are no scroll bars. I tried the latest Safari and Firefox on the mac and Firefox on windows all have the same problem. With Chrome on windows I can at least drag-select-scroll to see the clipped text, which works but is awful.
> 
> I think it's a "feature" of SourceForge's website. :-(


SourceForge's archive viewer is wretched. Try

http://dir.gmane.org/gmane.comp.lang.tcl.mac

Re: [MACTCL] Tk 8.5.12.x crashes opening IDLE Preferences menu

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

Hi Neil,

On 10/9/12 5:42 AM, Ned Deily wrote:

>
> An update: I've figured out how to build the Cocoa Tk backport from the
> Fossil repo and after, bisecting of changes, I believe I've isolated the
> problem to a particular checkin.  I've opened Tk issue #3575664 with the
> details.  We are seeing a growing number of Python IDLE users reporting
> this problem.
>
> I'd be very interested to know if the ActiveState folks can reproduce
> the problem using the current tip of the branch and with their build
> process.  After some discussion of the Python Mac list, Kevin reports he
> is now able to reproduce the problem with his builds.
>
> https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3575664&grou
> p_id=12997

Thanks for posting these. As I noted in the bug reports, the branch you 
are testing against is no longer being used for Tk-Cocoa builds (I 
should probably close it). Can you try checking out and testing against 
core-8-5-branch?

The crash you note is present on the Python/Tkinter side in IDLE but I 
cannot reproduce it in Wish/Tk. Very strange.

>
> I've also opened another Tk issue (#3575681) concerning another Cocoa Tk
> crasher when using clipboard copy in IDLE, a regression that was
> introduced in 8.5.12.0 and only partially fixed in ActiveTcl 8.5.12.1.

I think I can conclusively say that this bug is outdated; I can't 
reproduce the clipboard issue in either Wish or IDLE, build of 
core-8-5-branch. I've left the bug report open to allow further 
comments, but it works for me and I will close it soon.

--Kevin


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

Re: [MACTCL] Tk 8.5.12.x crashes opening IDLE Preferences menu

[Ned D. <na...@ac...>]

In article <nad...@ne...>,
 Ned Deily <na...@ac...> wrote:

> Here's another regression with 8.5.12.x.  Using IDLE on OS X from a 
> Python that will link with ActiveTcl 8.5, attempting to open IDLE's 
> Preferences menu, either with the mouse (IDLE -> Preferences) or with 
> the keyboard accelerator (Cmd-`) causes an immediate crash in Tk.

An update: I've figured out how to build the Cocoa Tk backport from the 
Fossil repo and after, bisecting of changes, I believe I've isolated the 
problem to a particular checkin.  I've opened Tk issue #3575664 with the 
details.  We are seeing a growing number of Python IDLE users reporting 
this problem.

I'd be very interested to know if the ActiveState folks can reproduce 
the problem using the current tip of the branch and with their build 
process.  After some discussion of the Python Mac list, Kevin reports he 
is now able to reproduce the problem with his builds.
 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3575664&grou
p_id=12997

I've also opened another Tk issue (#3575681) concerning another Cocoa Tk 
crasher when using clipboard copy in IDLE, a regression that was 
introduced in 8.5.12.0 and only partially fixed in ActiveTcl 8.5.12.1.

https://sourceforge.net/tracker/?func=detail&aid=3575681&group_id=12997&a
tid=112997

-- 
 Ned Deily,
 na...@ac...

Re: [MACTCL] any one else notice the archives on this list are now ridiculously hard to read? CSS change?

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

On 10/8/12 8:26 PM, James Burgess wrote:
> and I can see anything after midway into my second sentence since it's clipped off. There are no scroll bars. I tried the latest Safari and Firefox on the mac and Firefox on windows all have the same problem. With Chrome on windows I can at least drag-select-scroll to see the clipped text, which works but is awful.

I think it's a "feature" of SourceForge's website. :-(

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