[Kst] [Bug 120827] Command line option -f fails for some asciifiles
staikos at kde.org
Mon Jan 30 02:55:33 CET 2006
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
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
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the Kst