| Summary: | Wish for 0.99/1.0: allow datasources to have configuration dialog/settings | ||
|---|---|---|---|
| Product: | [Applications] kst | Reporter: | Nicolas Brisset <nicolas.brisset> |
| Component: | general | Assignee: | George Staikos <staikos> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | netterfield |
| Priority: | HI | ||
| Version: | 1.x | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Solaris | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Nicolas Brisset
2004-07-22 09:19:44 UTC
Already started, almost there. I just need to sort out a layouting issue. I think there is another issue to deal with. The most useful config widget here would be per-source-instance, not per-source, right? That means the config would apply to kstdatasource_ascii(/home/gyrodata.dat), not kstdatasource_ascii(*). In this case, we need to provide config before we load the source, but we don't load the source until after the location in the UI where the config goes. This leads me to believe that the widget it returns will have to have a way to attach the data after it dies, meaning it has to be stored by the caller (Vector dialog, or data wizard presently). This tells me it needs to have a base class. Sound reasonable? I will proceed down this road now, but please respond so I know if it's correct. Yes, each instance needs to have its own options stored in private variables as I may e.g. want to work with 2 ASCII files with different formats simultaneously. It sounds like there are 2 ways to achieve the user interface to pass options to the datasource instance: 1) provide options through a widget from which you have to get the data (does it necessarily have to die before the source is loaded, can't it just be hidden and destroyed later when the data has been read ?) 2) provide options by means of keys in the config file and a separate/stand-alone config dialog to set them 2 things make me think we should favor 2): - we have to store options anyway so that the user does not need to change them as long as he does not use files requiring a same type of datasource with different options (I suppose 99% of the time, a given user will use a same file format) - it would probably make it easier to code as the datasource will know where to look for options and the caller only needs to know how to bring up the options dialog upon user request. How this option dialog is coded (other class needed ?) is another issue taht I leave to you to decide :-) As far as the UI is concerned, we could add a "[Name of datasource] options..." button in the first page of the datawizard that is activated once the file has been selected by the user and the right type of datasource has been found (in other words, the same conditions as for activation of the "Next" button, plus the config widget is not null). We'd probably also have to find a way to add the same kind of button in the vector dialog, though I am not sure it is OK to change options once the vector exists ? Doing it this way means that in the general case the user will proceed through the wizard as he currently does because options are the same as the previous time so he doesn't need to set them. But if he has to load data from a file with special options, he can set them "just in time" before the file is processed (and choose whether to use the new values as new default). Sounds good to me ! On Wednesday 20 October 2004 05:23, Nicolas Brisset wrote: > 11:23 ------- Yes, each instance needs to have its own options stored in > private variables as I may e.g. want to work with 2 ASCII files with > different formats simultaneously. It sounds like there are 2 ways to > achieve the user interface to pass options to the datasource instance: 1) > provide options through a widget from which you have to get the data (does > it necessarily have to die before the source is loaded, can't it just be > hidden and destroyed later when the data has been read ?) 2) provide > options by means of keys in the config file and a separate/stand-alone > config dialog to set them > > 2 things make me think we should favor 2): > - we have to store options anyway so that the user does not need to change > them as long as he does not use files requiring a same type of datasource > with different options (I suppose 99% of the time, a given user will use a > same file format) - it would probably make it easier to code as the > datasource will know where to look for options and the caller only needs to > know how to bring up the options dialog upon user request. How this option > dialog is coded (other class needed ?) is another issue taht I leave to you > to decide :-) Ok let's do it like this then. Dialog is launched and passed a KConfig* to configure itself with, along with the *URL* of the filename it is working on. It will have to use KIO if it isn't a local file, but at this point we don't support that anyway. Later on, the datasource is instantiated and it gets the KConfig* again, which it reads the settings from. This gets us persistence, KIO support, a config dialog, and no messy data passing. Sound like a plan? As far as I understand Chinese (or C++ese for that matter), this sounds good :-) The only thing that's not very clear to me is that your proposal sounds like there's always going to be a config dialog, while I thought it'd be shown only optionally if the user clicks the (new) "Configure [datasource]" button on the first page of the wizard. But maybe that's what you're also saying... Fixed in CVS. One more integration of this is pending. |