[Date Prev][Date Next][Thread Prev][Thread Next]
[Search]
[Date Index]
[Thread Index]
macperl-modules-digest V1 #9
macperl-modules-digest Wednesday, March 17 1999 Volume 01 : Number 009
[MacPerl-Modules] RE: Glue
[MacPerl-Modules] Re: [MacPerl] Glue
[MacPerl-Modules] Re: [MacPerl-Toolbox] RE: Glue
[MacPerl-Modules] Re: [MacPerl] Glue
----------------------------------------------------------------------
Date: Mon, 15 Mar 1999 18:26:29 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: [MacPerl-Modules] 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-modules-request@macperl.org
------------------------------
Date: Mon, 15 Mar 1999 20:00:56 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: [MacPerl-Modules] Re: [MacPerl] Glue
At 19.23 -0500 1999.03.15, Jim Correia wrote:
>On 3/15/99 at 4:20 PM, Chris Nandor <pudge@pobox.com> wrote:
>
>> 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.
>
>If this is in fact how the logic works, then it is incorrect.
>
>You need to look at the appropriate information in the scripting size
>'scsz' resource.
I did not write the AETE code ... I just remembered some discussion on it.
It appears the scsz resource is used. Although, actually, it just checks
if the resource has a value at all instead of checking just the first byte.
One more thing for the TODO list.
- --
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-modules-request@macperl.org
------------------------------
Date: Mon, 15 Mar 1999 20:28:16 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: [MacPerl-Modules] Re: [MacPerl-Toolbox] RE: Glue
At 18.10 -0500 1999.03.15, Mat Marcus wrote:
>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.
I was playing around with script editor tonight, just for kicks. This
compiles, reocgnizing all terms in the list:
get modal of character {shift down, option down, diacriticals,
application responses}
Of course, it is nonsense. You cannot get "is window modal?" for a
character, and there is no such character as "application responses".
I realized last week that I was doing more work than AppleScript does. It
doesn't do any checking at all, really. So I am not going to. :)
Back to my reading,
- --
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-modules-request@macperl.org
------------------------------
Date: Tue, 16 Mar 1999 15:26:20 -0800
From: John W Baxter <jwblist@olympus.net>
Subject: [MacPerl-Modules] Re: [MacPerl] Glue
At 20:00 -0500 3/15/99, Chris Nandor wrote:
> At 19.23 -0500 1999.03.15, Jim Correia wrote:
>>On 3/15/99 at 4:20 PM, Chris Nandor <pudge@pobox.com> wrote:
>>
>>> 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.
>>
>>If this is in fact how the logic works, then it is incorrect.
>>
>>You need to look at the appropriate information in the scripting size
>>'scsz' resource.
>
> I did not write the AETE code ... I just remembered some discussion on it.
> It appears the scsz resource is used. Although, actually, it just checks
> if the resource has a value at all instead of checking just the first byte.
> One more thing for the TODO list.
>
> --
The "right" way to get the 'aete' from any running application is
probably to send the getAETE message. If the app doesn't handle it
(and does handle unhandled messages properly), the System handler
installed by AppleScript handles it and sends back the 'aete'
resource. [This is what usually happens.]
For a non-running app, the correct bit (I'd have to look it up) in
the 'scsz' resource should be checked for a "demand" that the getAETE
message be sent...if so, the app needs to be launched and the event
sent, otherwise it's ok to dig the 'aete' resource out and use it.
Buried in there is the reason that attempting to compile a tell to an
app on another machine needs to have the app running: AppleScript
doesn't launch apps on remote machines, but it can and does send
getAETE events to them.
--John
- --
John Baxter jwblist@olympus.net Port Ludlow, WA, USA
Give a man a fish and you feed him for a day. Teach him to fish,
and you get rid of him for the weekend.
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
End of macperl-modules-digest V1 #9
***********************************
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe"
==== to macperl-modules-digest-request@macperl.org