2016-03-03 15:40 GMT+01:00 Wayne Stambaugh <[email protected]>: > Are you considering attempting to load a file with each available plugin > until the correct one is found or they all fail? That's not a very > elegant solution. If you only have a few plugins this may be feasible > but what happens when you have 10 or 15 plugins?
10 or 15 plugins are not a lot. All they should do it sort of create a sanity check on weather or not the file is parseable. I think that can be determined quite quickly by the plugin. You usually don't need to parse the whole file. Often you can find a header in the file, that should give you a very strong indication on whether or not it is likely that the file can be read. > This is one of the > reasons the fp-lib-table exists. The fp-lib-table is not just a file > path resolution system. It also handles associating the library (file > or folder of files) type with the correct plugin as well as any optional > parameters the plugin requires to perform it's job. Relying on file > extensions is always going to have it's issues. Unfortunately we are no > closer to a file system with file metadata then we were 30 years ago > when the powers that be figured out the whole file extension concept was > broken. I wouldn't hold my breath on this being fixed anytime soon. > > On 3/2/2016 5:19 AM, Simon Wells wrote: >> Handling multiple plugins would be annoying and probably a whole >> different discussion, but it should really only be an issue when user >> plugins are possible if sanity checks are done properly. And it would >> most like have to be a user setting or i have no idea of a better way >> of doing it >> >> On Wed, Mar 2, 2016 at 10:40 PM, Nick Østergaard <[email protected]> wrote: >>> 2016-03-02 9:21 GMT+01:00 Simon Wells <[email protected]>: >>>> After looking into and discussing >>>> https://bugs.launchpad.net/kicad/+bug/1551628 with nick i am not sure >>>> the filter is the best way of advising kicad of which plugin to use >>>> >>>> I was thinking the best way to solve this would be for each of the >>>> plugins to have a static >>>> "bool CanYouHandleThis" >>>> function (obviously with a better name) and when a file is loaded each >>>> of the plugins are checked to see if they understand the file, >>> >>> Yes, I think this is a proper way to do this. After all, it is the >>> plugin that knows if it can parse the file, so having a >>> CanYouHandleThis to sanity check the file or whatever it does to say, >>> "Yay, I can handle this file!", would be a good idea, it could >>> possibly also be used to do some better error reporting to the user. >>> Say; the user tries to open an eagle v5 .brd file which is not >>> supported, it could possibly detect the version type of the file and >>> import the user that the file he is trying to open is v5 and only v6 >>> is supported for example. >>> >>>> With each of the responses if they are all no, then a error can be >>>> reported, and for any that are yes the loading can then be handed off >>>> to it/them (if dynamic plugins are enabled at some point in the future >>>> (which you would really need some sort of what can you read interface >>>> anyway) then you may get to the point where multiple can handle a >>>> single file) >>> >>> If multiple plugins can handle a file, how would you handle that >>> situation seamlessly? >>> >>>> This would allow the user to not have to set the filter which i am not >>>> sure many people would think as the problem anyway as far as i am >>>> aware its not the normal method for setting what type a file is. And >>>> also move away from blindly trusting extensions >>> >>> Blindly trusting extensions is indeed problematic as we already have seen :) >>> >>>> Thanks >>>> >>>> Simon >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
