On Fri, Jul 24, 2009 at 3:06 PM, DJ Delorie<[email protected]> wrote: > >> Well, you have to *use* its scriptability, and not fight against it. > > I don't consider it "scriptable" unless you can invoke the script from > within the tool and have it operate on the live data. You should be > able to, for example, right-click on a menu button and edit the script > it will run, then left-click on it to run it.
I don't really care whether scripting functionality is built in the tool or is not, as long as it seamlessly integrates with it. When the script modifies a design file the tool should update any views of it (I guess that's what you meant by "operate on the live data"). Another issue is what we consider "scripting". For me, scripting is only good for automating the flow, glueing existing functions together so that the user's productivity increases. This is in opposition to plumbing, adding features to the tool, which should be there in first place, because it decreases productivity. >> A specialized internal language is a poor way to get scriptability. > > I don't consider pcb's actions "scripts", more of a batch file. > However, you have to *start* with a solid collection of verbs and > nouns before you can build a scripting system around it. On the gschem side I really like the idea of libgeda. IMHO everything that touches user's data should go there and be wrapped with a clean API. Tools like gschem, netlisters, importers etc should only issue commands/listen to libgeda. Cheers, -r. _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
