kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hi Cheng,

I just tested this patch and it seems to work as advertised without
breaking anything so I am going to commit it unless someone else has any
objections.  For future reference, you might want to us wxUrl[1] to test
for valid URL strings rather than a custom regex.  I would prefer that
you use your name in the AUTHORS.txt file rather than "Google, Inc.".
I'm OK if you add "Google, Inc." after your name and email address.  If
you don't want to include your email address that's fine but you should
get credit for your work even if it is on behalf of the company you work
for.

Thanks,

Wayne

[1]:
http://docs.wxwidgets.org/3.0/classwx_u_r_l.html#a9837df16ff9f8daf91e5569265cfbe60

On 5/31/2017 5:43 PM, Cheng Sheng wrote:
> 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
> <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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 <mailto: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 <mailto: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
>     <mailto: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>
>     >> >>>>> <mailto: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>
>     >> >>>>>     <mailto: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>>
>     >> >>>>> <mailto: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>
>     >> >>>>>         <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>
>     >> >>>>>         <https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>>
>     >> >>>>>         Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >> >>>>>         <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>     >> >>>>>         Unsubscribe :
>     https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     >> >>>>>         <https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>>
>     >> >>>>>         More help   : https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>
>     >> >>>>>         <https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>>
>     >> >>>>>
>     >> >>>>>
>     >> >>>>>
>     >> >>>>
>     >> >>>>
>     >> >>>> --
>     >> >>>> 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>
>     >> >>>
>     >> >>
>     >> >
>     >> >
>     >> > _______________________________________________
>     >> > 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>
>     >> >
>     >
>     >
> 
> 
> 
> 
> _______________________________________________
> 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
>