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 <[email protected]> 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 <[email protected]>: > > 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 <[email protected]> wrote: > >> > >> Does it not work by using the KIPRJMOD as is? > >> > >> 2017-05-31 15:17 GMT+02:00 Cheng Sheng <[email protected]>: > >> > 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 <[email protected] > > > >> > 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 <[email protected]> > >> >> 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 > >> >>> <[email protected]> > >> >>> 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" <[email protected] > >> >>>>> <mailto:[email protected]>> wrote: > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> On 29 May 2017 at 09:40, Sergey A. Borshch > >> >>>>> <[email protected] > >> >>>>> <mailto:[email protected]>> 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 > >> >>>>> <[email protected] > >> >>>>> <mailto:[email protected]> > >> >>>>> <mailto:[email protected] > >> >>>>> > >> >>>>> <mailto:[email protected]>>> 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: > >> >>>>> [email protected] > >> >>>>> <mailto:[email protected]> > >> >>>>> SB ELDI ltd. Riga, Latvia > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> Mailing list: https://launchpad.net/~kicad-developers > >> >>>>> <https://launchpad.net/~kicad-developers> > >> >>>>> Post to : [email protected] > >> >>>>> <mailto:[email protected]> > >> >>>>> 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: [email protected] > >> >>>> SB ELDI ltd. Riga, Latvia > >> >>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> Mailing list: https://launchpad.net/~kicad-developers > >> >>> Post to : [email protected] > >> >>> Unsubscribe : https://launchpad.net/~kicad-developers > >> >>> More help : https://help.launchpad.net/ListHelp > >> >>> > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Mailing list: https://launchpad.net/~kicad-developers > >> > Post to : [email protected] > >> > Unsubscribe : https://launchpad.net/~kicad-developers > >> > More help : https://help.launchpad.net/ListHelp > >> > > > > > >
env-var.patch
Description: Binary data
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
