[Kst] branches/work/kst/portto4/kst/src

[Adam Treat]

On Monday 24 September 2007, Brisset, Nicolas wrote:
> > * Add a bunch of new widgets so that we can port over the
> > vector dialog for creating new vectors.
> > * ComboxBox ... this is a placeholder for what will
> > eventually be a completion enabled combo.
> > * DataRange ... this is a port of the KstDataRange class
> > * FileRequester ... we no longer have KUrlRequester so this
> > is a replacement.
>
> So, does that mean that we'll soon be able to import actual data from a
> file ? I think this is when it'll start being far more interesting for
> users :-)

Hopefully soon :)

> That also reminds me that I wanted to say I agree with Barth on the fact
> that base datasources classes should provide default implementations as
> much as possible. One of the strengths of kst is that it can read quite

Pure virtual methods provide a mechanism to ensure that plugins implement the 
required necessary parts to make operation of the application smooth and 
intuitive.

In many cases a plugin *has* to re-implement a method for the plugin to work 
*at all*.  Currently, these absolutely necessary methods are not pure 
virtual.  Making them pure virtual will provide a *contract* ensuring that 
the plugins implement at least what is necessary.

I do not intend to make every method pure virtual and demand that every plugin 
implement every feature.  That is not what I'm talking about.

It just makes good sense to enforce a contract so that plugin makers will know 
exactly which parts are required and which parts are optional.  Abstract 
class interfaces are perfect for this.

> a few formats, and adding a new one is fairly easy. If it had been more
> complicated, I probably wouldn't have started with netcdf and CDF (and
> maybe not used kst at all!) considering the little time I had to do it
> and my limited coding skills...

It doesn't have to be complicated.  It just has to be clear.

Adam