| Summary: | Create a database system for constants | ||
|---|---|---|---|
| Product: | [Applications] kst | Reporter: | Andrew Walker <arwalker> |
| Component: | general | Assignee: | kst |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | ||
| Priority: | VLO | ||
| Version: | 1.x | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Andrew Walker
2004-08-26 00:27:26 UTC
One problem with this is that if some constants are in the database only then the .kst file ceases to be portable. Thus, any constants that are actually used should be located in the .kst file also. Another solution might be to have a cascading combo box, like a cascading menu. This would also help with the fact that there are so many scalars associated with each vector.... How about a filter textfield for the scalar selection widget (like for fields in the Datawizard and objects in the multiple edit widget) to display a subset of the scalars, since constants start with CONST and vector related scalars start with the name of the vector? On Thursday 26 May 2005 13:35, Rick Chern wrote:
> 19:35 ------- How about a filter textfield for the scalar selection widget
> (like for fields in the Datawizard and objects in the multiple edit widget)
> to display a subset of the scalars, since constants start with CONST and
> vector related scalars start with the name of the vector?
That works from the UI, but it doesn't solve the problem in general. For
instance, it causes much longer list construction and iteration from
KstScript. As well, it doesn't allow people to build different databases of
constants for different purposes.
Constants are not useful enough to justify UI complication. |