kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Regardless of the load times and such, I think an import option vs an open
option is a very good idea, in terms of UI and user-friendliness, even if
no other changes are made.

On Thu, Mar 3, 2016 at 7:59 PM, Tiger12506 <tiger12506@xxxxxxxxx> wrote:

> This email is merely a suggestion.
>
> I would personally approach it by having each plugin determine the file's
> eligibility to be parsed. After all, who can know better than the parser
> author whether or not a file will be successfully parsed by a plugin? I
> would NOT suggest having any assumptions made by the calling code -- one
> email I think hinted that you could read a section of file and then pass in
> a string to the plugin function -- but NO, because who knows how far to
> read in to the file but the author of the plugin? Who knows what encoding
> that file is in? The person in the best position to answer that question is
> the plugin author.
>
> If a plugin writer does not provide an implementation for that function,
> then the base class can do whatever you want it to do -- make an educated
> guess, rely entirely on file types, prompt the user, anything you want.
>
> I doubt that testing file types is going to be your most computationally
> intensive task when loading imported files.
>
> Perhaps the one true answer (lol) is a mixture of the two. Why not order
> the plugins to test against based on the file extension? Though file
> extensions are not the best indicators of a file type, it should narrow it
> down to a couple plugins. Each could open,read a dozen bytes,close in a
> milliseconds.
>
>
> _______________________________________________
> 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
>