kicad-developers team mailing list archive

[Cheng Sheng <jeru.sheng@xxxxxxxxx>]

Thanks, Wayne. See the new attachment with "wxURL" for testing URLs and
updated AUTHORS.txt. Retested that both cases (http://... and
${KIPRJMOD}/...) still work.

Regards,
Cheng

On 5 June 2017 at 20:30, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:

> 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
> >
>
> _______________________________________________
> 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: rev-wayne.patch
Description: Binary data