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>
