Maybe submit it as a MergeRequest on gitlab. ons. 20. maj 2020 12.16 skrev Badr Hack&Invent <b...@hackinvent.com>:
> Hi Wayne, > > Is there any update regarding this patch? > > If there is any thing else to adjust please let me know. > > For information, the plugin is working without any bug since 2018 in my > for :) > > Regards, > > Badr > > Le 2018-10-30 11:07, Badr Hack&Invent a écrit : > > Hi Wayne, > > Did you have a chance to give a look at this patch? > From our side we are using it almost a year now, it works fine. > > Else, I don't know if an equivalent function is now under going in the > version 6? > If so, I will be glad to help in testing. > > Regards, > > Badr > > Le 2017-12-24 15:31, Wayne Stambaugh a écrit : > > Badr, > > Thank you for your patch but we are currently in feature freeze for the > stable 5 release. This patch will have to wait until the stable 5 > version is release and the version 6 development is opened. I'm not > sure exactly when that will happen but I will review your patch then. > > Cheers, > > Wayne > > On 12/24/2017 05:56 AM, Badr Hack&Invent wrote: > > Hi, > Here is a patch to add the remote library management as a plugin. > I added the possibility to specify multiple urls in a single file, it > was useful for our case. > We tested this approach several weeks, it seems fine in term of > performance. > It doesn't support remote zip files as for pcbnew. I can manage to > implement it in a second time. > If this patch is ok I will write a detailed documentation on how to use it. > Regards, > Badr > > > Le 2017-08-14 15:21, Wayne Stambaugh a écrit : > > You could modify the SCH_LEGACY_PLUGIN_CACHE code to handle urls instead > of file names. That way you could hand remote and local files in the > same plugin. wxWidgets has classes to handle urls (wxUrl) and input > streams (wxInputStream) which can be use as the LINE_READER > (INPUTSTREAM_LINE_READER takes a pointer to a wxInputStream object). > The primary drawback to this is performance. Past testing has shown > that wxInputStream has a lot more overhead and is significantly slower > than either our FILE_LINE_READER and std::istream so that is why we > haven't used it anywhere. It is also why I recommended writing a new > plugin. I'm guessing with remote I/O, the wxInputStream performance hit > will be far less noticeable than the remote I/O time. > > Wayne > > On 8/14/2017 3:29 AM, Badr Hack&Invent wrote: > > I see, > I thought it would be better to upgrade SCH_LEGACY_PLUGIN_CACHE to > handle remote libraries seemlessly rather than creating a new plugin. > I will check how to add a new plugin for remote libs without adding > additional actions for the user. > > Badr > > Le 2017-08-14 02:44, Wayne Stambaugh a écrit : > > I think you misunderstood what I was implying. You should not be > looking for a different symbol library header. This is a change that I > would reject since you are effectively changing the library file > format. > What I suggested was that you create new plugin that reads from a > remote url similar to the github plugin used for footprint libraries. > > I also do not like the idea of a separate LoadRemote() method being > added to the SCH_PLUGIN object. There is no reason to add it. All of > the symbol library methods take a wxString which could be a url instead > of a file name. It is not limited to files and up to the plugin > type to > handle it correctly. My preference is that you create a new plugin for > remote files similar in concept to the github plugin. That is the > whole > point of the current plugin interface. Take a look at the board > plugins > to see the preferred method of creating plugins. > > I never really intended for the legacy symbol file format to have > multiple plugins like the kicad board and footprint library file > formats > so I didn't create separate parser and formatter objects like I did > with > the board file formats. Nothing is preventing that from happening with > the current schematic and symbol library file formats. I would not > have > any objection to splitting the parser out of the > SCH_LEGACY_PLUGIN_CACHE > object. I am planning on make the parsers and formatters for the new > schematic and symbol library file format code separate so it can be > used > by any plugin. > > Cheers, > > Wayne > > On 8/13/2017 3:26 PM, Badr Hack&Invent wrote: > > Hi, > > Here in the attachment the patch that add the remote lib retrieval. > > Badr > Le 2017-08-13 17:29, Badr Hack&Invent a écrit : > > Hi, > > Those couple of days I was checking how to update EESCHEMA to add > remote libraries retrieval function. > > Since am familiar with legacy format, I updated the plugin: > SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files. > > The idea was to create a new type of library > EESchema-REMOTELIBRARY (I > put an example in the attachment) > The content of this library is the following: > EESchema-REMOTELIBRARY Version 1.0 > URL https://www.example.com/mylib1.lib > URL https://www.example.com/mylib2.lib > ... > > This lib file is saved localy and specify the path of each remote > library you want to retrieve. > > The updated code seemlessly check the type of the library, if it is > EESchema-LIBRARY it parse it like always, else if it is > EESchema-REMOTELIBRARY it download each remote lib and parse it when > it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY). > > The impacted files are: sch_legacy_plugin.cpp and > sch_legacy_plugin.h > -> I implemented the algo and made some tweeks to use LINE_READER > instead of FILE_LINE_READER as argument to manage to use > STRING_LINE_READER > > I also modified KICAD_CURL_EASY::KICAD_CURL_EASY() to set the option > CURLOPT_SSL_VERIFYHOST to 0 to disable ssl certificate checking in > https requests. This modification is not required, but was useflul > for > our case where our server is behind ssl without certificate on the > domaine, just ip addresses. > > I made a prototype in the attachment, it is woring. > > I don't know if this modification is inline with the arachitecture of > kicad? > > Badr > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp