Summary: | Mechanism to call scripts from the commandline | ||
---|---|---|---|
Product: | [Applications] kst | Reporter: | George Staikos <staikos> |
Component: | scripting | Assignee: | kst |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | ||
Priority: | HI | ||
Version: | 1.x | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
George Staikos
2005-08-08 21:39:48 UTC
Based on discussion on list, the UI should be: Parameters starting with --E are stored as a string, for use by extensions which decide they understand them.. (technically, we do this by pre-parsing argv before passing it off to KCmdLineArgs) eg: kst --Ejs "bolocheck.js -d data.dat -fd filter.dat -f0 1121 -N 20000" + keep checking of kst command line parameters + extension parameter name space is completely isolated ? can extensions report parse errors of their parameters? + third parties can add parameters for their extensions. - no promise that extensions won't introduce parameter name clashes between themselves (but if they only chose to recognise special cases, this should be OK) - the "" bracketed parameter names seem kind of funny. On Monday 05 December 2005 18:33, netterfield@astro.utoronto.ca wrote: > eg: kst --Ejs "bolocheck.js -d data.dat -fd filter.dat -f0 1121 -N 20000" Instead of adding a complex command-line parser inside Kst, why don't we use something similar, but JS based: kst --Ejs "load(bolocheck.js); myBoloCheckScript(\"data.dat\", \"filter.dat\", 1121, 20000);" The extension is responsible to interpret the string as it wishes. The suggested approach for --Ejs looks good. Was already implemented -E "js:loadScript('foo.js')" Change version to 1.x |