| 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 First Reported In: | 1.x | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented 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 |