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

Re: [MACTCL] Ditch built-in first Help menu entry?

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

Sent a reply to Russell and didn’t CC the list.

Basically, define a ::tk::mac::ShowHelp proc instead of adding your own menu item. You can find information about various bits of Tk/Mac wackiness here:

http://www.tcl.tk/man/tcl8.6/TkCmd/tk_mac.htm <http://www.tcl.tk/man/tcl8.6/TkCmd/tk_mac.htm>

Damon


> On Oct 28, 2014, at 11:55 AM, Russell Owen <ro...@uw...> wrote:
> 
> I distribute a cross-platform app that has several help links that I 
> manually add to the Help menu, the first of which is called "<app name> 
> Help". This works fine on all platforms except MacOS, where I see two 
> entries for "<app name> Help", the first of which is shown in a small 
> font (I guess the MacOS default for the help menu) which brings up a 
> dialog saying that this application does not have any help. The second 
> (in the normal menu item font, like all the remaining entries) works as 
> expected.
> 
> My question is: is there some way to eliminate that first help entry? Or 
> is there some way to connect it to my own help (though I'd prefer the 
> first, if it's easy to do).
> 
> -- Russell
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[MACTCL] Ditch built-in first Help menu entry?

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

I distribute a cross-platform app that has several help links that I 
manually add to the Help menu, the first of which is called "<app name> 
Help". This works fine on all platforms except MacOS, where I see two 
entries for "<app name> Help", the first of which is shown in a small 
font (I guess the MacOS default for the help menu) which brings up a 
dialog saying that this application does not have any help. The second 
(in the normal menu item font, like all the remaining entries) works as 
expected.

My question is: is there some way to eliminate that first help entry? Or 
is there some way to connect it to my own help (though I'd prefer the 
first, if it's easy to do).

-- Russell

Re: [MACTCL] unsubscribe ...

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

On 10/25/14, 9:30 AM, Bernhard Rosensteiner wrote:
> Please unsubscribe me from the mactcl list, thanks
>
> best regards
> Bernhard
>

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

[Bernhard R. <bro...@gm...>]

Please unsubscribe me from the mactcl list, thanks

best regards
Bernhard

Re: [MACTCL] Cocoa Tk built for OS X 10.10 fails during initialization

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

On 10/19/14, 9:00 PM, Ned Deily wrote:
> Heads up for OS X 10.10 Yosemite users: if you build a version of Cocoa
> Tk 8.6.x or 8.5.x for OS X 10.10, that is, either on 10.10 or with
> MACOSX_DEPLOYMENT_TARGET=10.10, Tk will abort during initialization with
> the error:
>
>      Mac OS X 10.10000 or later required
>

Just to circle back on this, I've committed a fix for the issue that Ned 
has verified to build on both Yosemite and Mountain Lion. Thanks so much 
to Ned for the helpful and detailed bug report, and the testing.

--Kevin

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

Re: [MACTCL] Cocoa Tk built for OS X 10.10 fails during initialization

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

On 10/19/14, 9:23 PM, Ned Deily wrote:
> Also, you'll see the problem if you use the already released Command
> Line Tools for 10.10 which essentially install the same file as in the
> 10.10 SDK into the conventional system locations, like /usr/include.  In
> any case, Xcode 6.1 with the updated SDK should be publicly available
> with the next 24 hours.

That's good to know. I was going to hold off on investigating any 
Yosemite related bugs until I had the latest bits from our friends in 
Cupertino.

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

Re: [MACTCL] Cocoa Tk built for OS X 10.10 fails during initialization

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

In article <nad...@ne...>,
 Ned Deily <na...@ac...> wrote:
> In article <544...@co...>,
>  Kevin Walzer <kw...@co...> wrote:
> >  From reading about similar reports on the MacPorts list, shouldn't this 
> > be attributed to the fact that Apple hasn't yet shipped the 10.10 SDK? 
> > My guess is that this will be automatically resolved once Xcode 6.1 is 
> > released. Please give the build another try after the new Xcode is out.
> 
> No, I'm using the as-yet unreleased SDK.  It's a real problem.  I had to 
> fix similar problems in Python earlier.

Also, you'll see the problem if you use the already released Command 
Line Tools for 10.10 which essentially install the same file as in the 
10.10 SDK into the conventional system locations, like /usr/include.  In 
any case, Xcode 6.1 with the updated SDK should be publicly available 
with the next 24 hours.

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

Re: [MACTCL] Cocoa Tk built for OS X 10.10 fails during initialization

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

On 10/19/14, 9:18 PM, Ned Deily wrote:
> No, I'm using the as-yet unreleased SDK.  It's a real problem.  I had to
> fix similar problems in Python earlier.

All right, I'll look into it in the coming week. Thanks.

K


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

Re: [MACTCL] Cocoa Tk built for OS X 10.10 fails during initialization

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

In article <544...@co...>,
 Kevin Walzer <kw...@co...> wrote:
>  From reading about similar reports on the MacPorts list, shouldn't this 
> be attributed to the fact that Apple hasn't yet shipped the 10.10 SDK? 
> My guess is that this will be automatically resolved once Xcode 6.1 is 
> released. Please give the build another try after the new Xcode is out.

No, I'm using the as-yet unreleased SDK.  It's a real problem.  I had to 
fix similar problems in Python earlier.

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

Re: [MACTCL] Cocoa Tk built for OS X 10.10 fails during initialization

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

Ned,

On 10/19/14, 9:00 PM, Ned Deily wrote:
> Heads up for OS X 10.10 Yosemite users: if you build a version of Cocoa
> Tk 8.6.x or 8.5.x for OS X 10.10, that is, either on 10.10 or with
> MACOSX_DEPLOYMENT_TARGET=10.10, Tk will abort during initialization with
> the error:
>
>      Mac OS X 10.10000 or later required
>
> The problem is due to an incompatible change in Apple's
> AvailabilityMacros, a change necessary due to the version number moving
> from one ('.9') to two ('.10') digits.

 From reading about similar reports on the MacPorts list, shouldn't this 
be attributed to the fact that Apple hasn't yet shipped the 10.10 SDK? 
My guess is that this will be automatically resolved once Xcode 6.1 is 
released. Please give the build another try after the new Xcode is out.

--Kevin

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

[MACTCL] Cocoa Tk built for OS X 10.10 fails during initialization

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

Heads up for OS X 10.10 Yosemite users: if you build a version of Cocoa 
Tk 8.6.x or 8.5.x for OS X 10.10, that is, either on 10.10 or with 
MACOSX_DEPLOYMENT_TARGET=10.10, Tk will abort during initialization with 
the error:

    Mac OS X 10.10000 or later required

The problem is due to an incompatible change in Apple's 
AvailabilityMacros, a change necessary due to the version number moving 
from one ('.9') to two ('.10') digits.

I've opened a Tk issue about the problem:

    https://core.tcl.tk/tk/tktview?name=1d37c3e166

Note that this doesn't affect those third-party Tk's built on earlier 
versions of OS X, for example ActiveTcl 8.5 and 8.6; the current 
versions of each run OK on 10.10 or, at least, they don't fail with this 
problem.  Also, X11 versions of Tk on OS X are not affected.

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

[MACTCL] 21th Tcl Conference - Registration & Hotel Reminder

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

21'th Annual Tcl/Tk Conference (Tcl'2014)
http://www.tcl.tk/community/tcl2014/

This is a reminder that Registration for the Conference is open and
can be done at

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

Note that the holding period for hotel rooms has passed. To register
for a room, call 1-503-796-3851, speak to Mary Kirchner and mention
the Tcl Conference to receive the reduced rate.

See you in Portland,

Andreas Kupries
Tcl 2014 Program Chair
ActiveState Software Inc.
Vancouver, BC, Canada

Re: [MACTCL] http::get -channel broken in tcl 8.5.16 on MacOS 10.9

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

On 10/9/14 2:49 PM, Kevin Walzer wrote:
> Russell,
>
> On 10/9/14, 3:49 PM, Russell Owen wrote:
>> package require http
>>
>> set outname "saturn.jpg"
>> set url
>> "http://apod.nasa.gov/apod/image/1409/saturnequinox_cassini_7227.jpg"
>> set out [open "temp" w]
>> set token [::http::geturl $url -channel $out]
>> close $out
>
> I see the bug, but have no idea what the problem is--I don't maintain
> the http package and so wouldn't know where to begin debugging it.
>
> Any reason  you are using a Tcl call instead of something from Python,
> cf. urllib?

It is a Tkinter application (naturally) and I want to display the 
progress of the download. Is it possible to safely do this with a Python 
http library? If so, that does sound like the best solution.

For the record: the Tcl community jumped on this bug and fixed it for 
8.5 and 8.6. I was very impressed!

-- Russell

Re: [MACTCL] http::get -channel broken in tcl 8.5.16 on MacOS 10.9

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

Heh, just wanted to say that the bisection points to a checkin made Aug 22
and the ticket has been assigned to the person who made that commit.
Together with a name for the original submitter of the change in
itself it should be possible to get this fixed.

Russel should see all the notification mails directly.


On Thu, Oct 9, 2014 at 3:47 PM, Kevin Walzer <kw...@co...> wrote:
> Andreas,
>
> On 10/9/14, 5:59 PM, Andreas Kupries wrote:
>>
>> The ticket at core is
>>
>> http://core.tcl.tk/tcl/tktview/ed29c4da21f4c0a7858a0f5ae4aae20dd42fc818
>
>
> Thanks for doing more testing and tracking down the regression. I'm sure a
> fix will be committed soon.
>
>
> --Kevin
>
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com



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

21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
Send mail to tcl...@go..., by Sep 8
Registration is open.

Re: [MACTCL] http::get -channel broken in tcl 8.5.16 on MacOS 10.9

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

Andreas,

On 10/9/14, 5:59 PM, Andreas Kupries wrote:
> The ticket at core is
>      http://core.tcl.tk/tcl/tktview/ed29c4da21f4c0a7858a0f5ae4aae20dd42fc818

Thanks for doing more testing and tracking down the regression. I'm sure 
a fix will be committed soon.

--Kevin

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

Re: [MACTCL] http::get -channel broken in tcl 8.5.16 on MacOS 10.9

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

The ticket at core is
    http://core.tcl.tk/tcl/tktview/ed29c4da21f4c0a7858a0f5ae4aae20dd42fc818


On Thu, Oct 9, 2014 at 2:49 PM, Kevin Walzer <kw...@co...> wrote:
> Russell,
>
> On 10/9/14, 3:49 PM, Russell Owen wrote:
>> package require http
>>
>> set outname "saturn.jpg"
>> set url
>> "http://apod.nasa.gov/apod/image/1409/saturnequinox_cassini_7227.jpg"
>> set out [open "temp" w]
>> set token [::http::geturl $url -channel $out]
>> close $out
>
> I see the bug, but have no idea what the problem is--I don't maintain
> the http package and so wouldn't know where to begin debugging it.
>
> Any reason  you are using a Tcl call instead of something from Python,
> cf. urllib?
>
> --Kevin
>
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac



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

21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA --
http://www.tcl.tk/community/tcl2014/
Send mail to tcl...@go..., by Sep 8
Registration is open.

Re: [MACTCL] http::get -channel broken in tcl 8.5.16 on MacOS 10.9

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

Russell,

On 10/9/14, 3:49 PM, Russell Owen wrote:
> package require http
>
> set outname "saturn.jpg"
> set url
> "http://apod.nasa.gov/apod/image/1409/saturnequinox_cassini_7227.jpg"
> set out [open "temp" w]
> set token [::http::geturl $url -channel $out]
> close $out

I see the bug, but have no idea what the problem is--I don't maintain 
the http package and so wouldn't know where to begin debugging it.

Any reason  you are using a Tcl call instead of something from Python, 
cf. urllib?

--Kevin

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

[MACTCL] http::get -channel broken in tcl 8.5.16 on MacOS 10.9

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

The command http::geturl -channel is broken on MacOS 10.9.5 (and likely 
other versions). Transfers fail while writing to the channel with 
"resource temporarily unavailable". Transfers seem to work if -channel 
not specified. I have appended a simple example and posted a bug report
<http://core.tcl.tk/tcl/tktview/ed29c4da21f4c0a7858a0f5ae4aae20dd42fc818>

If anyone knows of a reasonable workaround, that would be great. I can 
almost certainly use a progress callback to manually write the data (and 
thus avoid using a channel) but unless there is some way to purge the 
data from the state array after writing it, that would fail on large 
files. (I see how to read the data, but not purge it.)

8.5.16 does fix the menu crashing bug that prevented me from updating 
past 8.5.11, but unfortunately this new bug is a show-stopper.

-- Russell

package require http

set outname "saturn.jpg"
set url 
"http://apod.nasa.gov/apod/image/1409/saturnequinox_cassini_7227.jpg"
set out [open "temp" w]
set token [::http::geturl $url -channel $out]
close $out
package require http

On MacOS with ActiveState Tcl 8.5.16 I see:
Error in startup script: error reading "sock8": resource temporarily 
unavailable
     while executing
"::http::geturl $url -channel $out"
     invoked from within
"set token [::http::geturl $url -channel $out]"
     (file "tcl http example.tcl" line 6)

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

[Donald G P. <don...@ni...>]

On 09/29/2014 10:58 AM, Will Duquette wrote:
> The second is when popping up modal dialogs such as tk_getOpenFile, where the dialog is truly modal.  I see this case as reasonable, especially given that Tk itself does it.

Tk is known to do foolish things from time to time.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

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

On Sep 25, 2014, at 9:48 AM, Lars Hellström <Lar...@re...> wrote:

> Kevan Hashemi skrev 2014-09-25 16.17:
>> Dear Kevin,
>> 
>> Thank you for all the work you are doing to keep Tk going on MacOS.
>> 
>>> Re-engineering either of these foundational parts of Tcl would, as I
>>> understand it, go far beyond adjusting a platform-specific
>>> implementation of the current API
>> 
>> Indeed it would. But the Tcl event loop has one severe limitation, and I
>> believe it's the one Michiel is referring to. I had to build my own
>> event loop on top of Tcl's, because Tcl's would not do the job.
>> 
>> The problem with Tcl's event loop is that pending "vwaits" are resolved
>> strictly in reverse order of initiation, and "after" events are ignored
>> during an active vwait.
> 
> That sounds very much like a misunderstanding, and also like you're using 
> far-from-recommended programming practices.
> 
> [vwait]s are resolved in reverse order of initialisation, because each is a 
> recursive invokation of the event loop. The first advice on using [vwait] 
> tends to be to avoid that. And [after] events are being serviced during a 
> [vwait], since how else could the following terminate?
> 
> % after 500 {incr epoch}; vwait epoch; set epoch
> 1
> % after 500 {incr epoch}; vwait epoch; set epoch
> 2
> 
> Your premises appear to be flawed.
> 

I'm aware of two canonical uses for vwait:

The first is when a non-event-loop program that needs to enter the event loop for short periods of time; in which case the event loop is not being called recursively.  Presumably this case is not a problem.

The second is when popping up modal dialogs such as tk_getOpenFile, where the dialog is truly modal.  I see this case as reasonable, especially given that Tk itself does it.

Will


> 
> Lars Hellström
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

[Kevan H. <ha...@br...>]

Dear Michiel,

> In the meantime, are there any volunteers to test any
> new event loop code?

Yes, absolutely. I am happy to compile from sources on my MacOS 10.7 
laptop, integrate with my code, and run for day-to-day work in our 
laboratory to see what happens. Right now, I'm still running with TclTk 
10.5.8, which I believe is Carbon-based.

Yours, Kevan


-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://alignment.hep.brandeis.edu/

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

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

Michiel,

On 9/27/14, 5:05 AM, Michiel de Hoon wrote:
>
> I think there is a misunderstanding here. I was referring
> to Cocoa events, not to Tcl events or procedures. In the
> current design, tkProcessEvent is processing Cocoa events
> in the event loop rather than in the callback.

It's just a filter that listens for mouse and keyboard events. That's all.

See below:
------
@implementation TKApplication(TKEvent)
/* TODO: replace by +[addLocalMonitorForEventsMatchingMask ? */
- (NSEvent *)tkProcessEvent:(NSEvent *)theEvent {
#ifdef TK_MAC_DEBUG_EVENTS
     TKLog(@"-[%@(%p) %s] %@", [self class], self, _cmd, theEvent);
#endif
     NSEvent	    *processedEvent = theEvent;
     NSEventType	    type = [theEvent type];
     NSInteger	    subtype;
     NSUInteger	    flags;

     switch ((NSInteger)type) {
     case NSAppKitDefined:
         subtype = [theEvent subtype];

	switch (subtype) {
	case NSApplicationActivatedEventType:
	    break;
	case NSApplicationDeactivatedEventType:
	    break;
	case NSWindowExposedEventType:
	case NSScreenChangedEventType:
	    break;
	case NSWindowMovedEventType:
	    break;
         case NSWindowWillMoveEventType:
             break;

         default:
             break;
	}
	break;
     case NSKeyUp:
     case NSKeyDown:
     case NSFlagsChanged:
	flags = [theEvent modifierFlags];
	processedEvent = [self tkProcessKeyEvent:theEvent];
	break;
     case NSLeftMouseDown:
     case NSLeftMouseUp:
     case NSRightMouseDown:
     case NSRightMouseUp:
     case NSLeftMouseDragged:
     case NSRightMouseDragged:
     case NSMouseMoved:
     case NSMouseEntered:
     case NSMouseExited:
     case NSScrollWheel:
     case NSOtherMouseDown:
     case NSOtherMouseUp:
     case NSOtherMouseDragged:
     case NSTabletPoint:
     case NSTabletProximity:
	processedEvent = [self tkProcessMouseEvent:theEvent];
	break;
#if 0
     case NSSystemDefined:
         subtype = [theEvent subtype];
	break;
     case NSApplicationDefined: {
	id win;
	win = [theEvent window];
	break;
	}
     case NSCursorUpdate:
         break;
#if MAC_OS_X_VERSION_MAX_ALLOWED >= 1060
     case NSEventTypeGesture:
     case NSEventTypeMagnify:
     case NSEventTypeRotate:
     case NSEventTypeSwipe:
     case NSEventTypeBeginGesture:
     case NSEventTypeEndGesture:
         break;
#endif
#endif

     default:
	break;
     }
     return processedEvent;
}
@end
---

> In the meantime, are there any volunteers to test any
> new event loop code? In addition to the Tcl/Tk test suite,
> it would be good to test the code in the real world.

Yes, I would. Test your patch against the sample script submitted with 
the bug report I referenced--it reliably causes the Tcl/Tk event loop to 
hang. That's what I'm looking to address. Let me know when you have 
something to look at.

Thank you,
Kevin

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

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

[Michiel de H. <mjl...@ya...>]

Hi Kevin,

[Michiel]
> Instead, in tkMacOSXNotify.c nextEventMatchingMask is
> overridden (which is an odd thing to do in itself) and now
> calls [NSApp tkProcessEvent:event], thereby processing
> the event in the event loop rather than in the callback.

[Kevin]
> tkProcessEvent is just a wrapper for Cocoa
> event dispatch; it doesn't run any Tcl procedures.
> See tkMacOSXEvent.c.

> Given the data points I've outlined, I don't think that
> changing tkProcessEvent will have any
> useful effect, as it already conforms (as  far as I can
> tell) to your prescription--no actual Tcl events or 
> procedures are executed here.

I think there is a misunderstanding here. I was referring
to Cocoa events, not to Tcl events or procedures. In the
current design, tkProcessEvent is processing Cocoa events
in the event loop rather than in the callback.

> See http://core.tcl.tk/tk/tktview?name=3028676fff
> for discussion by  Daniel Steffen of the
> notifier design.
Thanks for the pointer. Let me try and see if reorganizing
the event loop can fix this bug. If it does, we can discuss
again.

In the meantime, are there any volunteers to test any
new event loop code? In addition to the Tcl/Tk test suite,
it would be good to test the code in the real world.

Thanks,
-Michiel

--------------------------------------------
On Sat, 9/27/14, Kevin Walzer <kw...@co...> wrote:

 Subject: Re: [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of	private API's
 To: "Michiel de Hoon" <mjl...@ya...>, "tc...@li... List" <tc...@li...>, "Tcl Core List" <tcl...@li...>
 Date: Saturday, September 27, 2014, 6:48 AM
 
 Michiel,
 
 On 9/26/14, 10:38 AM, Michiel
 de Hoon wrote:
 > Instead, in
 tkMacOSXNotify.c nextEventMatchingMask is overridden (which
 is an odd thing to do in itself) and now calls [NSApp
 tkProcessEvent:event], thereby processing the event in the
 event loop rather than in the callback.
 
 tkProcessEvent is just a wrapper for Cocoa
 event dispatch; it doesn't 
 run any Tcl
 procedures. See tkMacOSXEvent.c. I suspect it's designed
 
 that way to put everything in one place.
 
 See http://core.tcl.tk/tk/tktview?name=3028676fff
 for discussion by 
 Daniel Steffen of the
 notifier design.
 
 Given the
 data points I've outlined, I don't think that
 changing 
 tkProcessEvent will have any
 useful effect, as it already conforms (as 
 far as I can tell) to your prescription--no
 actual Tcl events or 
 procedures are
 executed here.
 
 --Kevin
 
 -- 
 Kevin Walzer
 Code by Kevin/Mobile Code by Kevin
 http://www.codebykevin.com
 http://www.wtmobilesoftware.com
 

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

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

Michiel,

On 9/26/14, 10:38 AM, Michiel de Hoon wrote:
> Instead, in tkMacOSXNotify.c nextEventMatchingMask is overridden (which is an odd thing to do in itself) and now calls [NSApp tkProcessEvent:event], thereby processing the event in the event loop rather than in the callback.

tkProcessEvent is just a wrapper for Cocoa event dispatch; it doesn't 
run any Tcl procedures. See tkMacOSXEvent.c. I suspect it's designed 
that way to put everything in one place.

See http://core.tcl.tk/tk/tktview?name=3028676fff for discussion by 
Daniel Steffen of the notifier design.

Given the data points I've outlined, I don't think that changing 
tkProcessEvent will have any useful effect, as it already conforms (as 
far as I can tell) to your prescription--no actual Tcl events or 
procedures are executed here.

--Kevin

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

Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

[Michiel de H. <mjl...@ya...>]

Hi Kevin,

Typically in Cocoa the event loop looks something like this:

while (true)
{
    NSEvent* event = [NSApp nextEventMatchingMask: NSAnyEventMask
                                        untilDate: date
                                          inMode: NSDefaultRunLoopMode
                                          dequeue: YES];
    [NSApp sendEvent: event];
}

This event loop waits for events and dispatches them, but does not actually process them; processing the events should be done in the callbacks. Usually you would want to keep the event loop as simple as possible.

Instead, in tkMacOSXNotify.c nextEventMatchingMask is overridden (which is an odd thing to do in itself) and now calls [NSApp tkProcessEvent:event], thereby processing the event in the event loop rather than in the callback.

You will also see in tkMacOSXNotify.c that sendEvent is also being overridden to keep track of its nesting level, and that [NSApp tkProcessEvent:currentEvent] is being called in TkMacOSXEventsCheckProc, thereby again processing an event in the event loop rather than in the callback. The end result is a very complex event loop, which is likely to be fragile.

I would suggest to move the code in tkProcessEvent to the appropriate callback functions, and after that see how much of the complexity of tkMacOSXNotify.c is still needed.

> My understanding is that this is mainly a hook into tclMacOSXNotifier.c, which is quite complex.

Yes. Therefore I think that tclMacOSXNotifier.c should be fixed first, before touching tkMacOSXNotifier.c

Best,
-Michiel



--------------------------------------------
On Thu, 9/25/14, Kevin Walzer <kw...@co...> wrote:

 Subject: Re: [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of	private API's
 To: "Michiel de Hoon" <mjl...@ya...>, "tc...@li... List" <tc...@li...>, "Tcl Core List" <tcl...@li...>
 Date: Thursday, September 25, 2014, 11:38 PM
 
 On 9/25/14, 10:21 AM,
 Michiel de Hoon wrote:
 > The only changes
 would be needed in tclMacOSXNotify.c and in tkMacOSX*.c
 (mainly tkMacOSXNotify.c).
 > Regarding
 threading: I think we agree there. I am suggesting to use
 the event loop instead of a thread to monitor file
 descriptor events.
 
 I'd
 be interested to hear your suggestions for tkMaCOSXNotify.c.
 My 
 understanding is that this is mainly a
 hook into tclMacOSXNotifier.c, 
 which is
 quite complex.
 
 Anything
 involving threading is currently outside my skill set, so I
 
 will defer to those more expert than myself
 on this.
 
 --Kevin
 
 -- 
 Kevin Walzer
 Code by Kevin/Mobile Code by Kevin
 http://www.codebykevin.com
 http://www.wtmobilesoftware.com