kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

2016-03-03 18:20 GMT+01:00 jp charras <jp.charras@xxxxxxxxxx>:
> Le 03/03/2016 17:30, Simon Wells a écrit :
>> Yeah, not loading the whole file. It would be a static function in
>> each plugin that just sort of tests a wee bit,
>> binary != xml != sexpr != (whatever the old kicad format is) and each
>> of those could be differentiated easily with 200 bytes. Most binary
>> ones will also have magic in them for identification anyway.
>>
>> as far as i can tell it could be done 3 ways
>>
>> - by passing the file (which would most likely be slowest due to
>> open/closing of the file for each plugin
>> - an arbitary arbitary amount of data read into an array/string and
>> then passed to each saying do you understand this much.... (this would
>> work 99% of the time) unless it came down to very small changes and a
>> very crappy file format that didn't have versioning early/at all.
>> - memory map and pass the file that way to each importer plugin, this
>> would most likely be the most complicated solution, but would most
>> likely be one of the more accurate, and one of the most efficient,
>> however depending on file size this could cause problems (although
>> just like the former it could be limited to something reasonable).
>> This also wouldn't require reloading the file for the real board load
>> so shouldn't add any additional time to file load.
>>
>> If we still use extensions i still think we need something like this
>> due to things like the eagle/old-kicad format's in which case the same
>> thing could be used but an additional field could be parsed to
>> CanYouHandleThis(FILE, HINT) with the hint being the extension, or
>> even overloaded to give multiple choices
>
>
> What is the interest to spend time to try to automatically guess the plugin?

Usability.

> Pcbnew is not a board viewer.
> Importing a board is a bit more tricky than opening images in a image
> viewer like Irfanview.

Maybe, and then what? I mean, the job is done in the plugin.

> Currently there are 2 plugins importers, and it is unlikely we have more
> importers soon.
> (In other words, we have a bit of time to find the best solution before
> 10 or 15 plugins are available.)

So we can still just a brute force approach instead of the user
manually selecting.

> Currently the plugin selection is made from the file extension.
> This is for me enough for now.

I don't like this very much. This is way too error prone, and when you
select a wrong filter you are thrown a very cryptic error about some
place in the file that the parser did not understand.

This error is not helpfull at all for a user that is not aware of the
syntax of the format he is trying to import.

> Be sure other imports are not necessary made by just a new plugin.
> For instance Altium board files (which are basic ascii files) are not
> directly readable.
> The bundle which contains them must be expanded (similar to a zip file
> which must be dezipped)

You can still determine that the file is a zip file, and then unzip
and make some checks on what comes out of this if needed. As mentioned
by Simon earlier, the file extension could be used as a hint to narrow
down the possible formats that it should test.

> Currently, when using the file extension one can argue the old kicad
> board files and the Eagle files having the same extension, the extension
> does not works as criteria, and reading the beginning of the file is needed.
>
> This is absolutely false.
>
> The issue is just created by the fact importing a file and opening a
> kicad board file is made using the *same* menu item, and therefore a
> .brd file can be a kicad file or a Eagle file.

I don't agree with this, I am sure it is possible to add this
intelligence in the plugins. I can't even specify that I want to open
an eagle file to pcbnew on the commandline. It makes more sense to me
to have a generic open item as we have now.

> I am thinking 2 separate menu items:
> one for opening a kicad board file
> and
> one *other* to import files
> will fix this issue and moreover will be more easy to use (no need to
> select a file filter, the file filter being a filter to open kicad
> files, and an other filter to import non Kicad files).
>
> And the cost to add an import menu item is zilch.
>

When implemented, I don't see any cost in performing theese sanity
checks on the files that need parse. Optionally some better error
handling can be made to inform the user what exactly might be the
problem. For example if a user tries to open an older and unsupported
eagle file, then if the sanity checker was made to support it, it
could also detect that this is an older version of the eagle format,
and then tell the user that this is v2 or whatever of the format and
is not supported. And it could tell the user that it needs v6, for
exmple.

>
> --
> Jean-Pierre CHARRAS
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp