[Kst] [Bug 120827] Command line option -f fails for some asciifiles

[George Staikos]

On Sunday 29 January 2006 20:41, Ted Kisner wrote:
> On Sunday 29 January 2006 17:01, George Staikos wrote:
> |   I think this is a bad idea.  For instance, a script that tries to check
> | the contents of a file will fail.  I'm also not sure where else we might
> | have a problem as a result of this.  I don't think this patch can go into
> | 1.2.0. Also it introduces a performance penalty for fieldList().
>
> Hmmm, so any other ideas that could be used to fix this issue for 1.2?  If
> we can't fix this regression, then I guess I can just build a patched copy
> for my colleagues that rely on this feature.

  Not off-hand, sorry.

> I can't think of a reliable way to do this without breaking the existing
> datasource API.  Basically the whole interface for querying whether a
> datasource supports a file relies on the datasource being able to determine
> global properties of the file without knowing anything about the start
> frame.

   API changes are not necessarily a problem.  We're using a plugin-key now so 
it shouldn't be too much of a problem.  The only issue is that it forces 
people to change their plugins when they update Kst, but at least they don't 
crash Kst randomly.

> The new ASCII datasource now effectively requires that the number of
> columns in each row of a text file be constant.

  Which is not necessarily good, I agree.

> Perhaps as a stop-gap measure, we could have the datasource scan the first
> 50 lines (or some large-but-not-performance-killing number) of the file and
> take the maximum number of fields as the number for the whole file.  How
> does this sound?

  That sounds better to me, but again, API changes are not disallowed at this 
point.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/