kicad-developers team mailing list archive

[Cheng Sheng <jeru.sheng@xxxxxxxxx>]

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
>