kicad-developers team mailing list archive

[Cheng Sheng <jeru.sheng@xxxxxxxxx>]

I see. This is also doable. I updated the patch to resolve env vars instead
of relative path. Now "${KIPRJMOD}/Datasheets/tmp.pdf" will work. Thanks
for the suggestion.

Regards,
Cheng

On 31 May 2017 at 20:53, Nick Østergaard <oe.nick@xxxxxxxxx> wrote:

> 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
> >> >
> >
> >
>

Attachment: env-var.patch
Description: Binary data