Does it not work by using the KIPRJMOD as is? 2017-05-31 15:17 GMT+02:00 Cheng Sheng <[email protected]>: > Thanks, Fabrizio. It's good to know such info that is not mentioned in the > doc. I'm indeed quite new to contributing code here. > > Regards, > Cheng > > On 31 May 2017 at 13:06, Fabrizio Tappero <[email protected]> > wrote: >> >> Hi Cheng, >> >> Don't worry you are doing just fine. >> >> Whenever somebody submits a patch, he does exactly what you did. Normally >> it takes some days for the patch to get submitted because in these days >> several people express opinions and feedback, as in your case. >> >> If nobody is against it and if the patch is useful for KiCad, the patch is >> applied to the main repo in few days. A gentle reminder is a good way to >> communicate with people with kicad repo writing rights. >> >> I hope you will submit more stuff. Contributing can be quite a rewarding >> experience, I think. Just remember that the dev. community decides what goes >> in and what stays out. And normally common good is paramount. >> >> cheers >> Fabrizio >> >> >> >> >> >> >> >> On Wed, May 31, 2017 at 11:49 AM, Cheng Sheng <[email protected]> >> wrote: >>> >>> okay, thanks for the info, Sergey. >>> >>> Don't find any explicit rule on how to select reviewers on the how to >>> contribute 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 >>> >> > > > _______________________________________________ > 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
