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. Regards, Cheng On May 29, 2017 12:33 PM, "Cheng Sheng" <[email protected]> wrote: On 29 May 2017 at 09:40, Sergey A. Borshch <[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]>> 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] > 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 >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
