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

Adam Treat treat at kde.org
Thu Jun 28 17:02:51 CEST 2007

On Thursday 28 June 2007, Brisset, Nicolas wrote:
> >  int AsciiSource::readFullLine(QFile &file, QByteArray &str) {
> >    str = file.readLine(1000);
> > +  if (str.isEmpty())
> > +    return str.size();
> I've never quite understood why we need that readFullLine(...) method.

Neither do I.  Especially when QIODevice has such nice similar methods...  But 
I don't understand the code well enough to just go through it right now.  
Other bigger fish to fry.

> As far as I understood, the idea was that if kst is given a "wrong"
> ASCII file the first line could become veeeeryyyyy long, so that
> initially only a given (fixed) number of bytes were read. This then led
> to the problem that some people (me :-)) could not read their ASCII data
> files which had *lots* of variables. So in the end we do read the whole
> line... In that case, why not use QTextStream like:
> if ( DataFile-> open( IO_ReadOnly ) ) {
>   QTextStream  TS (DataFile);
>   QString line = TS.readLine();
> ...
> I don't know if that construct still works in Qt4, though... but if we
> can simplify the code for datasources it can only help avoiding errors

I feel like these datasources could stand a good thorough rework.  A lot could 
be done to simplify and make the code more obvious.  Stuff like stop 
referring to variables as 'rc' all over the place and implementing tons of 
methods in the actual header files.

The first thing that needs to be done is to update the testcases as the only 
thing we test right now are ascii and dirfile.  We really should start by 
making rock solid easy to use testcases.

> and makes it easier for people willing to write new ones (Matlab's .MAT
> anyone
> http://www.mathworks.com/access/helpdesk/help/pdf_doc/matlab/matfile_for
> mat.pdf ?)

All in time I guess.


More information about the Kst mailing list