[Kst] Re: Data Wizard issues (long post !)

[Barth Netterfield]

Thanks for the comments.
Here are my thoughts...

MULTIPLE FILES:
Currently, the kst command line can take a list of files.  
(eg, kst -x 1 -y 2 *.dat). 
The data wizard does not, but this is a fairly straightforward modification I 
think....

As you suggest, on the first page we could make a list of files to read 
(rather than just one). The files read should include the kurledit line, as 
well as the files in the list.

On the second page, the list of valid fields which can be checked are the ones 
which are in common to all files which have been selected.

Then we might add a few more options to the third page.

I would guess not for the next release, but probably this summer.


GENERALIZED ASCII INPUT OPTIONS
-Currently kst data sources have no optional parameters, and no place for 
their UI.  We could consider changing this if we come up with compelling 
reasons.
-To handle gzipped ascii files, once could just make a datasource which 
recognized .gz files, and did the right thing....
-In the current ascii data source, 
	comment lines (eg, starting with #, //, !, c, ;) are ignored
	one can skip an un-commented header by changing the starting frame (this is 
admidedly quite a hack...)
-colums are only refered to by their colum number - there is no prevision to 
parse a header for better names.  This would be an exceedingly format 
specific operation!

PLOT PLACEMENT
We currently have several options in an attempt to anticipate what people will 
really want.  The data wizard should be '1 rule for all vectors'.  If one of 
the options not what one wanted, one has to go use the plotdialog, which is 
reasonably convenient, since we are talking about editing the placement of 
each vector now.  We could consider having one the options in curve placement 
be 'pop up a custom placement tool', but it has to be an alternative method: 
I really want the datawizard to be optimized for the common case, and leave 
the other options to the more specific dialogs.

Thoughts?
cbn


On June 23, 2004 06:31 am, Nicolas.Brisset at eurocopter.com wrote:
> If I may express my personal opinion, I'd also favor changing the embedded
> dialog for at least 2 reasons:
> 1) appearance
> 2) functionality: it would be very nice to provide for simultaneous
> handling of more than one data file, and I think the space used by the
> embedded dialog could be saved and used for a list of selected files and
> their properties. Let me develop that point a bit (long post, you've been
> warned !)...
>
> As I believe the datawizard is an essential part of the user's experience
> with a plotting tool, I think it deserves special care. I have some
> inspiration/experience on that topic, and I'd like to share some thoughts
> with you...
>
> I don't know if you remember a previous post of mine to this list regarding
> gaiw (the "Grace ASCII Import Wizard"), which is an open-source qt-based
> tool I wrote with a couple of other people to complement xmgrace. For more
> information on gaiw, see http://gaiw.sf.net (not completely up-to-date but
> still relevant). As I said before, its coding is ugly (it was my first
> attempt at coding, please be forgiving) but I believe the usability is
> quite good, and a lot of my colleagues use it on a daily basis and like it
> a lot. In fact, most complaints I get relate to Grace's usability !
> Now, I no longer plan to improve gaiw as I believe kst (especially with an
> integrated import wizard) has a lot more potential than Grace, but I'd like
> to see some of its features ported to kst's datawizard.
>
> Before giving more details, I'd like to explain what we typically use gaiw
> for and what the user requirements were:
> 1) quickly load data into xmgrace from any ascii file format
> 2) easily organize curves into plots, with as few restrictions as possible:
> curves in a given plot may come from different files or have different x
> values, and their number is not arbitrarily limited
> 3) comparing data from different files should be specially easy: if you've
> performed 2 experiments with different configurations and recorded the same
> data in both cases, it should be very easy to define plots with data coming
> from the two files (that's the "Common variables" mode in gaiw: e.g. when
> you click on 'VAR1', it creates a plot with 2 curves, VAR1 from file1 and
> VAR1 from file2)
> 4) the plots/curves should be created in xmgrace with sensible defaults
> (line/symbol options and legends).
>
> I attached 3 screenshots of the most recent version of gaiw (not yet
> uploaded on the web site) to give you a better idea of the functionalities.
> As you'll surely notice, a lot of things somehow resemble kst's datawizard.
> It is not a many-page wizard with back/next buttons, but instead has three
> tabs: - (Plot) Definition, where most of the action takes place
> - Plot options, which is used to preset a number of options that might
> otherwise be cumbersome to change afterwards from within Grace
> - File options, which is there so that gaiw can work on basically any
> (possibly compressed) ASCII file.
> By the way, it would be nice if the ASCII datasource allowed to set the
> options in the "ASCII File Format" group: number of header lines, line
> holding field names, optionally line holding units... I've looked at the
> code and it is not obvious where these options could be "plugged in", even
> the code to retrieve field names and units in itself is quite simple.
>
> >From all these options, a lot are linked with Grace usability problems and
> > can
>
> be left out. I think the following are relevant for kst's datawizard (with
> a hint at where I'd integrate them):
> - loading one or more files (first step in the wizard, lineedit+button to
> invoke kfiledialog+table or listview with file list and options, I have a
> precise idea of it and I'll make a .ui mockup in the coming days)
> - organizing curves into windows/plots (second step in the wizard, which
> could be based on a simplified version of gaiw's plot definition tab). By
> querying the list of windows and plots/curves for each window, the list can
> be initialized. Then a couple of buttons allow to add curves in the
> selected plot, a new plot or one per plot. This replaces the current "Curve
> placement" group in the third step of the wizard.
> - basic options (third step in the wizard, lines/symbols +
> auto-differentiate on width, color, style).
>
> I hope you'll be interested in these ideas. Feel free to make comments
> and/or implement these ideas :-) I'll try to prepare a mockup to clarify
> things.
>
> Nicolas
>
> > In fact, I guess I do not like the embedded dialog....  at least for the
> > reasons listed below, and for appearance reasons.  I would prefer it if
> > we can revert...
> >
> > cbn
> >
> > On Tuesday 22 June 2004 2:05 pm, Andrew Walker wrote:
> > > Hi George,
> > >
> > > I'll take a look at these issues. At this point Barth is not sure
> > > if he even likes the appearance of the file dialog embedded in the
> > > data wizard, so it may get ripped out altogether.
> > >
> > > Andrew
> > >
> > > ---------- Original Message ----------------------------------
> > > From: George Staikos <staikos at kde.org>
> > > Date:  Tue, 22 Jun 2004 13:34:19 -0400
> > >
> > > >   There are still some major issues with the embedded file dialog in
> > > > the data wizard.
> > > >
> > > >1) The Next button no longer validates the file, and is always
> > > > available. 2) Selecting directories (for dirfiles, planck databases)
> > > > is not very clean because you have to browse into the directory you
> > > > want, then click "Next" with no file selected.
> > > >3) It's much slower.
> > > >4) It doesn't come up in the right directory for the file that's
> > > > inserted in the Location: lineedit.
> > > >5) It becomes quite inconsistent between the first two pages when you
> > > > select a file (either valid or invalid) and then go back and switch
> > > > to an invalid or valid file respectively.  It's not clear that you're
> > > > using the old data file sometimes because opening the new one failed,
> > > > for instance. 6) The dialog is in remote file mode as well, which is
> > > > incorrect since we don't support that yet.