[MacPerl-Toolbox] RE: Glue

["Mat Marcus" <mmarcus@Adobe.COM>]

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