← Back to team overview

kicad-developers team mailing list archive

Re: Patch: Open Datasheet in Project Dir

 

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 <jeru.sheng@xxxxxxxxx> wrote:

> 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 <sb-sf@xxxxxxxxxxxxxxxxxxxxx>
> 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" <jeru.sheng@xxxxxxxxx <mailto:
>>> jeru.sheng@xxxxxxxxx>> wrote:
>>>
>>>
>>>
>>>     On 29 May 2017 at 09:40, Sergey A. Borshch <
>>> sb-sf@xxxxxxxxxxxxxxxxxxxxx
>>>     <mailto:sb-sf@xxxxxxxxxxxxxxxxxxxxx>> 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 <
>>> ikletti@xxxxxxxxxxxxxxxx
>>>             <mailto:ikletti@xxxxxxxxxxxxxxxx> <mailto:
>>> ikletti@xxxxxxxxxxxxxxxx
>>>
>>>             <mailto:ikletti@xxxxxxxxxxxxxxxx>>> 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: sb-sf@xxxxxxxxxxxxxxx
>>>         <mailto:sb-sf@xxxxxxxxxxxxxxx>
>>>              SB ELDI ltd. Riga, Latvia
>>>
>>>         _______________________________________________
>>>         Mailing list: https://launchpad.net/~kicad-developers
>>>         <https://launchpad.net/~kicad-developers>
>>>         Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>         <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>         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: sb-sf@xxxxxxxxxxxxxxx
>>     SB ELDI ltd. Riga, Latvia
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>

Follow ups

References