← Back to team overview

kicad-developers team mailing list archive

Re: Patch: Open Datasheet in Project Dir

 

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


Follow ups

References