kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

For the 3D model paths the second example works, hence I would have
assumed it would aslo for for other paths. Maybe that is a better
solution in this case to keep things consistent.

2017-05-31 17:39 GMT+02:00 Cheng Sheng <jeru.sheng@xxxxxxxxx>:
> Hi Nick,
>
> Could you be a little more specific? Do you mean:
>
> "KIPRJMOD/Datasheets/tmp.pdf"? or
> "${KIPRJMOD}/Datasheets/tmp.pdf", or
> "/path/to/my/project/dir/Datasheets/tmp.pdf" when
> KIPRJMOD=/path/to/my/project/dir?
>
> The first two doesn't work because the strings are passed to the browser
> address as is. The third case is not good because if I move the project
> around, the path becomes invalid.
>
> Or none of the cases above is your proposal?
>
> Thanks.
>
> Regards,
> Cheng
>
> On 31 May 2017 at 17:23, Nick Østergaard <oe.nick@xxxxxxxxx> wrote:
>>
>> Does it not work by using the KIPRJMOD as is?
>>
>> 2017-05-31 15:17 GMT+02:00 Cheng Sheng <jeru.sheng@xxxxxxxxx>:
>> > 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 <fabrizio.tappero@xxxxxxxxx>
>> > 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 <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 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
>> >>>
>> >>
>> >
>> >
>> > _______________________________________________
>> > 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
>> >
>
>