Creating a merge request on GitLab is now the only accepted way to contribute to KiCad. Please create a merge request on GitLab so we can evaluate your change.
Cheers, Wayne On 5/20/20 6:51 AM, Nick Østergaard wrote: > Maybe submit it as a MergeRequest on gitlab. > > ons. 20. maj 2020 12.16 skrev Badr Hack&Invent <b...@hackinvent.com > <mailto: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 >> <mailto: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 >> <mailto: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 > <mailto: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
