[Date Prev][Date Next][Thread Prev][Thread Next]
[Search]
[Date Index]
[Thread Index]
macperl-toolbox-digest V1 #6
macperl-toolbox-digest Wednesday, March 17 1999 Volume 01 : Number 006
[MacPerl-Toolbox] RE: Glue
[MacPerl-Toolbox] RE: Glue
[MacPerl-Toolbox] Idling
----------------------------------------------------------------------
Date: Mon, 15 Mar 1999 15:10:29 -0800
From: "Mat Marcus" <mmarcus@Adobe.COM>
Subject: [MacPerl-Toolbox] RE: Glue
Chris,
## Mat Marcus wrote:
1) I'm working with apps that use a plug-in architecture. In
these apps some aete information is found in the plugins. If I drag the
main app onto the
glue droplet it extracts a file full of garbage. But if I use an individual
plug-in with an aete it seems to work ok. This happens to me with
CodeWarrior for example.
##
### Chris Nandor replied:
With the latest release of Mac::Glue (from November, I think), the target
app is launched if there an aedt resource is detected. Then an Apple Event
is sent to get the resource data, which should include any plugins. So
this should not be a problem.
###
Right. I've been using the version that is currently on your web site. It
does open the app, but garbage is produced in the resulting Glue.pm file.
Does things work with CodeWarrior for you?
## Mat Marcus wrote:
2) I'm working with a dictionary that makes extensive use of properties. I
can do things in AppleScript that I can't do in perl/Glue. To explain I need
to give you a snippet from the Object Model:
- -- begin object model --
Application
property: Active Window (tag = 'pacw') # this refers to a window (cwin)
object
element: document
Document:
element: Window
Window: (tag = 'cwin')
property: Active Spread (tag = 'pacs') # this refers to a spread (sprd)
object
element: Spread
Spread: (tag = 'sprd')
property: name
- -- end object model --
In AppleScript I can say:
set result to name of ActiveSpread of ActiveWindow
But I can't seem to do this naturally in Glue. What I would like to say is
something like this:
$result = $k2-get(
$k2-p('name', property='active_spread', property='active_window')
)-get();
I believe that this can't work because of Glue::_doObj tries to check that
active_spread is a valid property of the active window at "compile time",
i.e. before the getdata event has been sent. But since the tag for Active
Window is not 'cwin' _doobj() thinks that there's a problem. I would like to
suggest that you drop the "compile time" property validation. Instead you
could build a big flat hash of all the properties upon Glue instantiation.
It might appear that this would risk some name clashes. But I believe that
this is how AppleScript does it. I seem to recall from implementing AE
Object Models in the past that AppleScript puts all tags and strings in one
big global namespace. That is, it gets pretty unhappy if there is not a one
to one mapping between tags and associated strings. Thoughts?
##
### Chris Nandor replied:
Well, not quite right, from what I understand. That is, you can have
multiple strings for each four-char ID. But yes, I believe a four-char ID
has to map back to exactly one "string" for each given application.
So you can type, in Script Editor:
tell app "Finder" to get selection
And "app" will be expanded to "application". But that is not too useful
for our discussion. :)
###
When opening an AppleScript (well Script Editor anyway) will decide on how
to display the "strings" associated with each four-char ID (tag). Pity the
poor dictionary implementor who mistakenly maps two different strings to the
same tag. Anyone opening a script written against this dictionary will find
it difficult to use since AppleScript/ScriptEditor will arbitrarily choose
only one string to use for both properties. Given this behavior my point is
that Glue's power would appear not to be weakened by flattening the "string"
to "four-char ID" mapping into one big hash. Then _doObj could accept
active_spread as a property of active_window. But this is all details. What
I'm after is a more natural port for AppleScripts containing constructs such
as "propertyX of propertyY" where the IDs of property X and Y do not match
those of the associated class.
Thanks for your consideration,
- - Mat
- ------------------
Mat Marcus
mmarcus@adobe.com
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-toolbox-request@macperl.org
------------------------------
Date: Mon, 15 Mar 1999 18:26:29 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: [MacPerl-Toolbox] RE: Glue
I am doing this in macperl-modules, not macperl-toolbox. :)
At 18.10 -0500 1999.03.15, Mat Marcus wrote:
>Right. I've been using the version that is currently on your web site. It
>does open the app, but garbage is produced in the resulting Glue.pm file.
>Does things work with CodeWarrior for you?
I have not done it with CW, but I have had problems with BBEdit. There are
bugs somewhere. But the point is that the design is to do what you want,
to get the plugins and their aete resources. If the implementation is
lacking, that's OK for now. :)
>When opening an AppleScript (well Script Editor anyway) will decide on how
>to display the "strings" associated with each four-char ID (tag). Pity the
>poor dictionary implementor who mistakenly maps two different strings to the
>same tag. Anyone opening a script written against this dictionary will find
>it difficult to use since AppleScript/ScriptEditor will arbitrarily choose
>only one string to use for both properties.
Yep. But sometimes this is wanted, maybe to provide common synonyms. I
was just pointing out that there is not necessarily a one-to-one mapping,
but it could be many-to-one.
>Given this behavior my point is
>that Glue's power would appear not to be weakened by flattening the "string"
>to "four-char ID" mapping into one big hash. Then _doObj could accept
>active_spread as a property of active_window. But this is all details. What
>I'm after is a more natural port for AppleScripts containing constructs such
>as "propertyX of propertyY" where the IDs of property X and Y do not match
>those of the associated class.
I don't know how I will implement it, but this is basically the conclusion
I came to a few days ago. For each glue instance, to have one namespace
for lookups. The whole architecture of this thing may change, so I can't
say what the specific implementation will be yet, but it should do what you
ask.
But ignoring implementation for now, let me ask you and anyone else out
there: should there be one lookup table for everything, or do events have a
separate lookup table? IM: IAC mentions that properties and classes etc.
can have the same name as long as they point to the same ID, but it does
not mention events there.
- --
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-toolbox-request@macperl.org
------------------------------
Date: Mon, 15 Mar 1999 23:04:21 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: [MacPerl-Toolbox] Idling
I think MacPerl needs a better idle function for when sending with
kAEWaitReply. MacPerl just hangs and doesn't really respond to anything.
I don't know how to fix it, but I think it should be fixed. :)
That said, I have found a workaround of sorts. This sets up a handler to
catch all replies sent to MacPerl, and then send with kAEQueueReply. Then
we wait with WaitNextEvent, and we can do what we want while waiting for
the reply.
#!perl -wl
use Mac::AppleEvents::Simple qw(:all);
use Mac::Events;
$Mac::AppleEvents::Simple::SWITCH = 0;
$AppleEvent{"aevt", "ansr"} = \&foo;
$x = build_event(qw(syso ppcb R*ch));
$x->send_event(kAEQueueReply);
WaitNextEvent until $brooklyn;
sub foo {
my($evt, $rep) = @_;
print AEPrint $evt;
print AEPrint $rep;
$brooklyn = 1;
0;
}
- --
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-toolbox-request@macperl.org
------------------------------
End of macperl-toolbox-digest V1 #6
***********************************
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe"
==== to macperl-toolbox-digest-request@macperl.org