> >Here is what I am thinking: > > use Mac::App::Finder; > my $f = new Mac::App::Finder; > $f->open('file1', 'R*ch'); # each parameter a scalar > $f->open(['file1', 'file2']); # arrayref for parameter lists > $f->clean_up({window=>'my project'}); # hashref for objects > >Then there are object properties. I am thinking maybe: > > $f->set({show_size=>['false', {window=>'my project'}]}); > >The first list item is the data ('false'), followed by a hashref to a >completely new object. I think it would be better to do the order this way (if I follow what you are trying to say): $f->set(show_size=>[{window=>'my project'},'false'}]); That is, set show size of window 'my project' to false instead of set show size to false of window 'my project'. <snip> #boy it would be neat if I had a faux perlism to use here > >It is pretty clear that this framework will create files with some assembly >required. For instance, there is no easy way in Progress Bar for my >program to know that the parameters in the "make" event correspond to the >properties of the window class. And in the Finder, there is no way for the >program to know the computer event (gestalt) is supposed to get constants >from the 'gsen' enumeration. So I hope to make it easy hook things up >where this program leaves things unplugged. I think easy is a relative term here, but I'm not quibbling the bits. I guess you mean your droplet will produce an output that lists those things that it remained undecided about? And you might have a function/method/scriptlet that would allow one to add definitions/links/plugs? -Jeff Lowrey Systems Programmer Sells Printing Company ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch