Tk AppleScript implementation

[Philip Aker-3]

As previously mentioned, I've created a new implementation of the Tk  
scripting implementation.

An example of how it works is at :
<http://www.vcn.bc.ca/~philip/Wishbone.zip>

In order to complete it as a backwards compatible snap-in replacement,  
I'd appreciate some discussion on a few particulars of the Tk compile-
time and runtime.

For the Tk.framework/Wish.app developer portion, since a Tk app isn't  
a regular Carbon app, I'm wondering if it would be possible to handle  
the incoming AppleEvents in the ReceiveNextEvent() handler? I know it  
can be done because I've used the technique myself in a Carbon app.  
However that app doesn't have any Tcl/Tk event loop interleaving and  
that could be a consideration. The reason for this request is due to  
the ordering of incoming AppleEvents with respect to the Application  
Carbon event handler. It's roughly this:

ReceiveNextEvent()
AppleEvent PreDispatch handler
Application Carbon event handler
AppleEvent handlers


The main problem is that the name of the ShowPreferences handler  
script ("::tk::mac::ShowPreferences") is _hard-wired_ into the menu  
enabling function of "tkMacOSXEvent.c". This causes a problem with the  
new implementation because it seems to preclude having a new handler  
(with a different namespace and name) which can deal with extra  
parameters. In addition, the problem further exacerbated because  
wherever kHICommandPreferences is snagged in the Carbon event  
handlers, it takes precedence over the AppleEvent handler (as you can  
see by the ordering above).

In the example Wishbone application (which I've rigged to illustrate)  
you should be able to see the problem by first choosing the  
Preferences menu item by the mouse, and then by using the keyboard  
<Command-,> shortcut. There are two results -- by the mouse, as  
expected, the proc is called once. But using the shortcut, it is  
called twice. Finally, using the example script call you can see that  
the expected result is not returned. The different results are logged  
by the app to a file on your desktop called: "WishboneLog.txt".

The way I see it, the problem could be solved with the least amount of  
disruption if the AppleEvents were dispatched directly from the  
ReceiveNextEvent() handler before they got to any Application/Menu/
Window carbon event handlers. How to do it is described the  
CarbonEvents.h header file in the discussion for  
kEventClassAppleEvent. Just to note, there are two different  
techniques used for Leopard and later and pre-Leopard and the new call  
(AEProcessEvent()) is good because it avoids having to use an  
EventRecord. But I don't know all the details of the Tk event handling  
and the implications this would have. Alternately, I believe it could  
be handled in a similar fashion in Carbon event handers by returning  
eventNotHandedErr for kHICommandPreferences so the fallback to the  
AppleEvent would occur. With either of the above implemented, I  
believe it would be possible to have the code in tkMacOSXHLEvents.c do  
the Preferences menu enabling based on it's assessment of whether or  
not a handler for the specific 'aevt/pref' command responds rather  
than having a name hardwired into tkMacOSXEvent.c.

§

For Tk-based application developers you should be able to see the  
difference between the old-style Tk-app scripting dictionary and the  
one illustrated in Wishbone.app by dragging them to the Script Editor  
application. In particular, you should note that the 'open', 'print'  
and 'do script' commands can now accept and process files specified by  
URL. I've also implemented the standard "print settings" record for  
optional input to the 'print' command and would be especially  
interested to hear if anyone thinks it should have some extra members.  
For instance, you'll notice in the AppMain.tcl  
script ::AppleEvent::aevt::pdoc proc where the 'nstexttopdf' cups  
filter is used, I have to specify a PPD. I think it might be better to  
have the PPD able to be specified in the AppleScript call.

Thanks!

Philip Aker
echo astwta@...@nl | tr a-z@. p-za-o.@

Democracy: Two wolves and a sheep voting on lunch.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tcl-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac

[Philip Aker-3]

On 2009-08-15, at 07:12:38, Gerald W. Lester wrote:

Sorry Gerald, I didn't see your post also my Tcl mailbox before I  
posted a direct reply.

> Philip Aker wrote:
>> As previously mentioned, I've created a new implementation of the  
>> Tk  scripting implementation.
>>
>> An example of how it works is at :
>> <http://www.vcn.bc.ca/~philip/Wishbone.zip>
>>
>> In order to complete it as a backwards compatible snap-in  
>> replacement,  I'd appreciate some discussion on a few particulars  
>> of the Tk compile- time and runtime.
>>
>> For the Tk.framework/Wish.app developer portion, since a Tk app  
>> isn't  a regular Carbon app, I'm wondering if it would be possible  
>> to handle  the incoming AppleEvents in the ReceiveNextEvent()  
>> handler?

> I would have expected all the events to be dispatched via the  
> ReceiveNextEvent() handler.

They are, but AppleEvents are not specifically snagged in the  
ReceiveNextEvent() handler. In fact they are not specifically acted on  
anywhere in the 8.7.5 source. They are only invoked via the fall  
through condition to the last choice illustrated in my post (there is  
no PreDispatch AppleEvent handler in the Tk source).


> In your post you talk a lot about Carbon -- will this also work with  
> the newer (Tk 8.6 CVS HEAD at sf.net) Cocoa?

I'm not sure right now because I'm unable to compile a Tk Cocoa  
version. However in the Cocoa Scripting documentation, there is  
specific mention of how to install a general event handler of the type  
implemented in the Wishbone app, so I would expect that the method  
I've used would still be eligible in TkCocoa. In Cocoa scripting,  
under normal circumstances, AppleEvents are targeted directly at a  
specific class instance and handled via an Objective-C category on the  
class. While I don't yet know how TkCocoa relates to NSObects, I'm  
reasonably sure that whatever Daniel has done will be able funnel the  
event to a general type of handler like the one in Wishbone or use  
something similar to the existing per/event handlers.

I assume the 6 required event handlers will be taken care of one way  
or another so it seems it would be primarily the question of how  
TkCocoa application designers could implement custom AppleEvent  
handler procs. There's no question that they will be specified in an  
sdef and handled by a proc so it's only a matter of how slick the  
underlying Cocoa support will be. As you can see in the Wishbone  
application, it's very easy to have custom handlers for simple  
argument list type commands.

In other situations, I've implemented auto-coercion between the basic  
AppleScript object types and Tcl objects. This enables AppleScript  
commands with custom parameters to be handled automatically. However,  
it's not so easy to integrate this type of design into Carbon Tk  
because it relies on Carbon events using Command IDs for widgets  
whereas the Tk Aqua implementation goes out of its way to avoid them.


Philip Aker
echo astwta@...@nl | tr a-z@. p-za-o.@

Democracy: Two wolves and a sheep voting on lunch.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tcl-mac mailing list
tcl-mac@...
https://lists.sourceforge.net/lists/listinfo/tcl-mac