okay, thanks for the info, Sergey. Don't find any explicit rule on how to select reviewers on the how to contribute <http://kicad-pcb.org/contribute/developers/> page. So cc Jean-Pierre because you did a lot of commits recently. Let me know or reassign if there's some duty partitioning. Thanks.
Regards, Cheng On 31 May 2017 at 11:01, Sergey A. Borshch <[email protected]> wrote: > On 31.05.2017 10:57, Cheng Sheng wrote: > >> So is there any conclusion on this patch like it will be accepted or >> rejected or needs some improvement? >> >> Sergey, are you a patch reviewer who can commit to the repo, or I need to >> add someone explicitly? Thanks. >> > No, I'm just a user who wanted to share it's point of view. > > Regards, >> Cheng >> >> On May 29, 2017 12:33 PM, "Cheng Sheng" <[email protected] <mailto: >> [email protected]>> wrote: >> >> >> >> On 29 May 2017 at 09:40, Sergey A. Borshch < >> [email protected] >> <mailto:[email protected]>> wrote: >> >> On 28.05.2017 23:49, Cheng Sheng wrote: >> >> I myself prefer storing all files specific to the project >> within the >> project directory, including datasheets, components, adjusted >> footprints and scripts. This way makes things easier when I >> copy the >> project around. After all, I don't mind disk space waste on a >> few >> duplicated datasheets; they don't take much space. >> >> Ok, what is your workflow? You choose component, pick it from >> library >> into schematics and then manually copy it's datasheet (from >> where?) into >> the project folder to make it available from schematics? >> >> I'm not a professional on electronics so I don't (want/bother to) >> maintain a >> centralized collection of datasheets. Instead, when I select >> components, I >> do parametric search on digikey/mouser/whatever, then check >> datasheets on >> the website, download to project dir if chosen. >> >> >> I have my library and my project both under version control >> system, so I >> use latest, exactly the same (with all latest error fixes) >> library and >> latest, most actual datasheets in every project. But I always can >> easily >> revert library repository to state it was when project was >> finished. >> >> I admire your patience and professionalism. I see your spirit to >> reuse as >> many things as possible. Shared library has its reuse benefit. Of >> course, >> also has its downsides. Eg., I don't necessarily remember how the >> shared >> libraries are setup one year after I finish a project or after I move >> to a >> new machine. So I prefer each project to be as self-containing as >> possible. >> >> Of course, putting everything inside the project also has its >> downsides, >> maybe even more than your proposed shared library approach. But I >> suppose >> this is just personal preferences. Unless there's a strong reason why >> my >> personal preference is terrible (that it is worse than a "standard >> approach" >> in ALL aspects) or by following this preference my patch makes the >> software >> terrible, it shouldn't be forbidden, right? >> >> >> There is "Archive library" option in eeschema File menu, which >> extract >> from library all components used in project. It can be extended to >> extract datasheets as well if it doesn't do it right now. >> >> hm... Am I missing some compile options? I don't see such an option in >> eevschema. Instead, only an "Archive Current Project" item in the >> project >> window. >> >> Anyway, even if datasheet extraction is added to "Archive library", >> you'll >> still need a way to open a relative datasheet unless the archiving >> leaves an >> absolute path (which seems unlikely the case, by guessing). >> >> >> >> If the direction of move by the patch makes some other >> workflow >> styles harder to optimize in the future, please let me know. >> I don't >> mind alternative proposals that can fulfill more workflow >> types. >> What I wrote is just a "shortest-path" I can see based on my >> own >> workflow. >> >> Regards, >> Cheng >> >> On 28 May 2017 at 20:53, Ingo Kletti < >> [email protected] >> <mailto:[email protected]> <mailto: >> [email protected] >> >> <mailto:[email protected]>>> wrote: >> >> Am 28.05.2017 um 18:47 schrieb Sergey A. Borshch: >> >> On 28.05.2017 14:35, Cheng Sheng wrote: >> >> So I made a patch to resolve the path before it >> is >> passed to >> "wxLaunchDefaultBrowser()". If it looks like a >> URL or >> is an absolute >> path, doesn't do anything; but if it is a >> relative >> path, append >> "${KIPRJMOD}" to it. >> >> Are you storing all datasheets in every project? I >> think >> it's better to >> keep one copy per library, so path must be relative >> to >> library location. >> >> >> Don't know about the OP, but from past experience it is >> wise to >> store the >> datasheet for the different components tpgether with the >> project files. That >> way you always have the specs available that your design >> is >> based on. >> >> So a relative path makes sense depending on the use case >> and >> workflow. >> >> Regards, >> >> Ingo >> >> -- >> Regards, >> Sergey A. Borshch mailto: [email protected] >> <mailto:[email protected]> >> SB ELDI ltd. Riga, Latvia >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> <https://launchpad.net/~kicad-developers> >> Post to : [email protected] >> <mailto:[email protected]> >> Unsubscribe : https://launchpad.net/~kicad-developers >> <https://launchpad.net/~kicad-developers> >> More help : https://help.launchpad.net/ListHelp >> <https://help.launchpad.net/ListHelp> >> >> >> >> > > -- > Regards, > Sergey A. Borshch mailto: [email protected] > SB ELDI ltd. Riga, Latvia >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
