kicad-developers team mailing list archive

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