[Kst] Re: Benefit vs risk of constant-width columns + GUI proposal

[Peter Kümmel]

On 25.01.2011 12:00, Brisset, Nicolas wrote:
> Hi Peter,
> 
>> It depends on the position of the row. For the 310 MB gyrodata file
> and
>> column 3 the speedup
>> is from 4.0s to 2.5 s. The more right the column is the greater the
>> speedup will be.
> OK, if it's so much, then let's keep it. Especially as 3 columns is
> really little. We routinely have files with many more columns than that!
> 
>> Then the data is not loaded correctly, when such option is enabled we
> must
>> trust the user.
>> To fix this we could add an expensive function which analyzes the data
> and
>> tells the user
>> what for optimizations could be used and sets them for the data.
> Adding an expensive function sounds bad. But do we get a return status
> from atof() when there is an issue (like a ; in the characters, or more
> than one figure sequence)? If so, we should remember it and pop up a
> dialog or output a warning to the log class telling the user that there
> was an issue while loading the data and that he should check his
> settings. If atof() already has that, the overcost of testing the return
> value should be very small. 

Then I would say, when the user doesn't know his data he should not use
same non default functions.

> 
>> Yes, better than the current GUI. I would name "Free width" a bit
>> different, maybe "Width of columns is not predictable"
> I'd suggest "Make no assumption on column width", which sounds a bit

That's good.

> like danger...
> Should I go ahead and commit that, so that you can then adapt the code
> to it? If we do that, we only have to try and keep as much compatibility

Yes, please commit.

> as possible with the old .kst files. That may be a bit tricky and I
> don't think we can achieve 100% compatibility, but at least the most
> common options (whitespace, or custom delimiter) should be reloaded
> correctly. I think at this stage breaking the .kst format is still
> doable, but it's the kind of things we have to be very cautious about.
> !!! Barth, what do you think: would that be a major issue? !!!

Why do you think we break old kst files, the only difference I see is the
changed default comment delimiter, arne't they loaded from the kst file?

And I have the impressen the read code for ascii data is completely broken:

void AsciiSourceConfig::load(const QDomElement& e) {
  // TODO use tags, isn't this code torally buggy, because trings and tags doesn't match?
   QDomNode n = e.firstChild();
   while (!n.isNull()) {
     QDomElement e = n.toElement();
     if (!e.isNull()) {
       if (e.tagName() == "index") {
         if (e.hasAttribute("vector")) {
           _indexVector = e.attribute("vector");
         }
         if (e.hasAttribute("interpretation")) {
           _indexInterpretation = Interpretation(e.attribute("interpretation").toInt());
         }
       } else if (e.tagName() == "comment") {
         if (e.hasAttribute("delimiters")) {
           _delimiters = e.attribute("delimiters").toLatin1();


Isn't this function used when a kst file is loaded? Most tag names are not uptodate.


> 
>> Auto-detecting the column delimiter is a nice idea (with all it's
>> consequences).
>> Postponing it and making a ticket sound good. We could collect there
> all
>> the ideas, and maybe having
>> the new features out there are other new ideas.
> Yes, there are still a couple of other things linked with ASCII which we
> can keep in mind for later (units, ASCII configs, correctly reading time
> in the form hh:mm:ss, auto-detection of delimiters, ...)
> I'll take care of keeping bugzilla up-to-date.
> 
> Nicolas
> 
> 
> Eurocopter Deutschland GmbH
> Sitz der Gesellschaft/Registered Office: Donauwoerth
> Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
> Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
> Geschaeftsfuehrung/Board of Management:
> Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt
> 
> CONFIDENTIALITY NOTICE 
> 
> This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
> If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
> It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 
> 
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
>