I am the system admin for the computers at a public library. The computers all run Linux (Ubuntu 18.04). I have installed Fritzing for use by library patrons. I want to import a collection of parts bins (specifically the AdaFruit collection of parts), but I don’t want to clutter each of the library patron home directory with these parts (it would be a huge waste of disk space). Is it possible to create a common directory with all of these parts (much like the existing /usr/share/fritzing/parts tree contains the core parts, SparkFun, and Arduino parts)? I have downloaded the AdaFruit .fzbz files. How do I contruct this tree in a way the Fritzing will understand and what do I put in $HOME/.config/Fritzing/Fritzing.conf ?
If I understand what you want to do correctly, yes. Download the Adafruit library and unzip it then in Fritzing File->open and browse to the adafuit_Fritzing-Library-master/Fritzing-Library-master directory and click on the fzbz files one at a time. That will load the bin in to the Fritzing core parts bins which is I think what you are trying to do. There will be a copy on each machine though (but not for each user, which is I think what you are trying to avoid) The adafruit bins then show up in the core parts menu as new bins and will appear in searches. Sharing this via NFS for instance I think may be more complex (or more likely impossible) though but I don’t think that is what you are trying to do.
Peter
I’ve already cloned the Adafruit library. I’ve installed the Frizing package via apt-get, so all of core files are under /usr/share/… (and I am using DRBL, /usr is already NFS mounted (read-only to the client machines). I don’t have a GUI on the server (it is a Virtual Machine running Ubuntu 18.04 on a server running CentOS 6 on the bare metal). I would rather NOT put stuff under /usr/share. Instead either /usr/local, or somewhere on /home. Using the bin input function stores things under the user’s own directory (/home/Documents/Fritzing or /home/Fritizing), which is what I want to avoid. I am an old hand at using NFS (even though there seem to be many apps now that don’t like or even support NFS file systems).
OK, I just checked, Using Fritzing->File->Open on a fzbz file is exactly the same as using the Import item on the bin menu. This just imports the parts into the user’s parts space (eg /home/Documents/Fritzing/bins … This is what I want to avoid. Yes, I am doing this as a normal user.
What I would find useful would be a CLI program that lets me “install” (eg properly unpack, updating the paths, etc.) these files to some shared location. It looks like that is not possible, sigh. I did try manually moving the files and hacking the paths in the fzb file, but for some reason I cannot figure out, this does not seem to work.
In general the app is designed to be standalone rather than multi user and many of the paths are hard coded in the source which is part of why this is difficult. The base problem with what you want to do is that the core parts directory (where you really want this to go) is a repo on github and Fritzing expects to be able to download it via git to update it (and gets unhappy if you make changes to it, which is why the changes are put in the user directories which you don’t want). You may be able to make the changes in a local copy of the parts repo but I expect you will then get complaints from the parts updater when it checks for parts updates as the local repo won’t match github’s. Basically at present Fritzing isn’t configured to be able to do this.
Peter
Yeah, this is an unfortunate “feature”… Oh, the parts updater is not going to work – I install Fritzing from a OS package (eg apt-get) and that installs the core parts bins under /usr/share, which is not writable by normal users (and it is actually a RO mounted NFS file system).
At the next parts update you may get error messages then. You can fix that by manually updating the RO repo from the master though (parts updates haven’t been that frequent but one is coming because of development restarting). You might be able to put the Adafruit bins in to the repo and then hide them via .gitignore although I’m not sure of that. I think new bins are currently manually added by the parts maintainer, and it likely isn’t documented though. The good news is development is restarting after dying for several years so a feature request has at least some hope, although probably not in the short term. There have been similar requests from educators over the years, but with development dead there wasn’t much hope. If you do figure out a way do doing it please document it, because others would be interested!
edit: the CircuitPlayground fzb is small (only 4 parts). I’ll poke at it a bit and see if I can figure out how to add it to core since I more or less know what the xml is expecting (although not so much about bins). If I succeed at that, then at least you have a template.
edit1:
Looks like this can be made to work with some effort. As noted I did the Circuit playground bin as it only has 4 parts. I unpacked the fzbz file and moved and renamed the various files as needed (the svg files are in part loader format and need to be in core format). The possible sticking point is that I needed to rebuild the parts database to get it to work. That would mean that you need to be able to run Fritzing either on your server or on an identical machine to generate the parts database and move it on to the server (if you can’t generate it there). You will still have the problem with parts update being unhappy with the local changes, but that will be there anyway. If you would like to try this and figure you can get the database rebuilt I can explain what needs to be done. It probably needs automation (shell, python or perl) to do the renames because there are a lot of them but that should be easy enough.
Peter
I would expect that at some point a new .deb file will show up and ‘apt-get upgrade’ will update the files under /usr/share/fritzing. And I would disable the “check for updates” feature of Fritzing. As a Linux admin, this is the proper way to manage things. Having application updating itself is (in my opinion) wrong. (I know it is the way things work in the MS-Windows world – that most certainly does not make it right.) I really prefer to use O/S package management tools (eg yum/rpm and dpkg/apt-get) to manage installed software on the Linux machines I manage (my own and others). Things generally work better that way.
That will work for the parts repo (although I don’t know of a switch to shut off updates, another feature request), but it won’t do anything for the adafruit repo as it isn’t part of core parts and won’t get added to the repo in an update (and would in fact get wiped out by the update).
Peter
FYI…
I manage only three Mac’s and one Windows XP computers on a system but, 3 or 50 wouldn’t matter:
I placed My_Useful_Parts in a single ‘Shared Folder’ and imported into Fritzing on each machine. Fritzing remembers the location and I haven’t needed to mess with it in two years.
When I add a homemade part (frequently), I save/export the parts bin to same location and import into my machines.
I use a firewall (Little Snitch) to block traffic in/out so auto-updating doesn’t occur.
