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 >> > > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
