[Kst] [Bug 215931] New: Make the datawizard faster

[Nicolas Brisset]

https://bugs.kde.org/show_bug.cgi?id=215931

           Summary: Make the datawizard faster
           Product: kst
           Version: 2.0.0_devel
          Platform: unspecified
        OS/Version: MS Windows
            Status: NEW
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: kst at kde.org
        ReportedBy: nicolas.brisset at eurocopter.com


Version:           2.0.0_devel (using unspecified)
Compiler:          mingw delivered with QtCreator 1.1.0
OS:                Windows 32-Bit

When opening the datawizard, in the first steps the data file needs to be
selected and the corresponding datasource created. This is currently suboptimal
and in some circumstances can lead to lots of wasted time. Just try to work
with ASCII files with > 2 million points (which we routinely do, in fact that's
one of the reasons to use kst as very few tools handle such data amounts
sensibly), you'll know what I mean... 

This problem is due to datasources being instantiated too soon:
- when the contents of the lineedit change, including upon opening the wizard
- when the settings change ("Configure..." button)
- when selecting a file in the file requester from the first page (which is
particularly bad if you have single-click settings and only hovering a file
starts the process of looking for an appropriate datasource!)

To improve that situation I think it should work the following way:
1) open the datawizard: restore the last used data file and do nothing more
2) if the user clicks on the file requester to select a different file, open a
standard file dialog and don't try to "validate" the data file at this stage.
After all the user should know what he's doing, and if not he'll come back to
here. It is hard to understand why selecting a file can be so slow, while the
dialog looks like a usual file selection dialog
3) if the user clicks the "Configure" button, only create the datasource's
config dialog with the settings that will be used for that file (i.e. default
settings if the file is not known, otherwise the ones stored in QSettings for
that file). The user should just see the settings and have an option to change
them easily. Upon validating the settings, don't instantiate the datasource
yet: he may wish to change them again!
4) when the user clicks "Next..." on the first page, either grab the existing
datasource for that file, or recreate one if the settings have changed, or
create it if it's a new file. If there is a problem, bring up an error dialog
informing the user that the file can't be read and stay on that page. It is not
a problem, I don't think it is required to activate "Next" only when we are
sure we can read the file (though if we can without a performance penalty it
sure is better, but I don't think that's possible)
5) from there on, proceed as usual

I think this change should be fairly easy to do and would be a great time saver
for some file types (in particular ASCII, but possibly also others)

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.