This is what it does but you shouldn’t ever be opening those folders so you shouldn’t know they exist. If you want just the SVG to edit you should open the parts editor, go to the view you want to export and then go to the file menu and export as SVG. You can then import it after you make changes in the same way. No need to ever open the fritzing folders.
Yes in the parts bin area the first export is export the entire bin and the one near the bottom is export part. I am sure the translation is the source of this issue.
Is this a file you have created or edited the SVG manually? I find those files break things. Try exporting something from the first section of the core parts like a resistor SVG to see if it works. If it doesn’t work that is a serious bug since it is the same svg exporter used to export screen shots and svg files for home etching.
While obviously since I’m not them and I don’t know for sure I would expect that is a lower priority for limited time than making the code work. That may be an area where we of less skill in code development can help if we choose to. If you are familiar with how parts go together you can likely document it and the developers likely don’t need the documentation and are focused on developing the code. Manpower willing to donate time is what Fritzing needs most. There is more than enough work for anyone willing to help.
This one is actually a bug in parts editor (which I have a fix for). If you edit a part, click export as new part then export the new part from the mine parts bin and exit Fritzing, it will not actually delete the part created by parts editor. If you then try and reload the exported fzpz file (without doing anything to it outside of Fritzing) you will get the “already a part with that name” error (even though there is no such part showing in the bin that you could delete). When parts editor creates the new part, it currently does not register the files with the main window that will delete the files when you say don’t save on exit. Since parts editor doesn’t delete the files and mainwindow.cpp doesn’t know about them, the files stay in the bin and you can no longer load that part again until you manually remove them (which you can’t do from fritzing because internally they aren’t completely there). That said, I think this is now a dead end and effort should go in to the new project. Reading between the lines (and from stuff I’ve seen elsewhere, and thus maybe incorrect ), I think Qt in the new project is being replaced by html5. The reason I think that is there is a white paper on the Qt site about why Qt is better than html5 which tells me that at least some of the Qt functionality is available in html5. As noted, I’m ignorant and could be wrong here.
No, schematic must have the same number of pins as bb and pcb views or the part won’t work. You can (as you did in the linkone board) stack the pins on top of each other (which I don’t like) but you must have all the pins for the part to work correctly (unless you do some manual editing in the fzp file and know what you are doing). This is what causes the part to be entirely red when loaded, pins now assigned. That is usually how I start a new part, by editing either the generic IC and changing it to the number of pins I need or doing the same with a generic header. Then all the necessary connectors for the part are in the xml and I can edit the svg and put the pins where I need them.
Yes it is likely a bug. I must have discovered that long ago and put it on the list and forgotten it. To export a part from parts editor I edit the part then save it as a new part (which puts it in the mine parts bin with the bug noted above) and then right click on the part in the parts bin and click export part which writes the fzpz file to the file of my choice outside Fritzing. I then unzip that modify the svgs and reload the part (after deleting the left over files from the bug in the user directory) to Fritzing to check it.
I think there is also a time optimization scenario, ie put your time where it best accelerates FZ.
If it’s a part that a lot of people are going to need then yes make it perfect. If it’s a part no one will want short-cut the complicated time consuming BB view.
I made this GM MAP sensor, and since hardly anyone will want it I just got a pic and ‘Trace to Bitmap’ in INK and added some contacts. For the 10 people that download it it will do just fine.
I think this technique is great it is just to bad that they are not allowed in Frtzing core parts because of how much larger the files are compared to SVG files.
The size of the BB svg is dependant on how many scans you select in Trace to Bitmap - I think it creates 1 path per scan -, so maybe that can be optimised to cut it down.
I can’t see there ever being a proper situation where you would export a part and then import the same part. If you just exported the SVG you want to edit and then import the edited SVG this would never happen. Again this is a situation where trying to not use the editor provided to you to edit the files causes more problems.
Also for Fritzing to recognize changes in the parts bins you must restart Fritzing and it will ask if you want to save the changes. I am not sure it this solves the issue created by reimporting an existing part that you have just deleted but it may. But again if you didn’t create the problem by trying to circumvent the editors function you wouldn’t need a work around. If I want to replace a part I will just change the SVGs and metadata of that part or create a new part and then delete the old.
Sorry if I sound negative, that is not my intent and everyone should continue doing things the way they are most comfortable as that is what I advocate. People should be able to work the way they are most productive rather than be forced to do things as someone else says it should be done.
While it isn’t why I do it usually, backup is one. Exporting the part saves a copy in a directory not controlled by Fritzing which means I can restore Fritzing from a clean install then import the new parts from my backup if I need to. Another reason would be too many parts cluttering up the bins, so export the ones you aren’t using right now. If export doesn’t have a use then it shouldn’t exist. Given that it exists it should not corrupt the Fritzing state in such a way that you can not do anything except manually clear files. As I said I have a fix that registers the part files with the file deletion mechanism which does cause the files to be deleted if you say yes delete the files and will then let you reload it as it should, so I think it really is a bug.
Nope. The sequence is edit the part, save as new part, export part, shutdown Fritzing. At this point the shutdown asks if you want to save the new mine parts. Answer no don’t save the parts and it will not in fact remove the files in the user directory for the new part, it will remove the part in the database I believe as it is not in the mine parts bin on reload. When you restart Fritzing and try and load the part you will get the “part already exists” message because the files exist in the My Documents directory, but since Fritzing doesn’t have the part in the database you can’t delete it (because Fritzing doesn’t know it exists to delete I think because some of the references, just not all of them have been deleted). As I said this isn’t to do with editing the files outside only exporting a part and not saving the mine parts bin copy. I suspect if you say yes save the part, on reload you will be able to delete it successfully because the reload will populate the database correctly (but I can’t say that I’ve tried this either).
It asks if you want to save the changes to the bin not to save the parts. If you say no then you are telling it not to save the changes which include things like deleting parts. You need to say yes so it saves the changes.
But you also say reasons for exporting files is to as backup and in that case you would not have the issue of it saying they are already exist because you are restoring things.
You also mention the clutter but for that you create new bins and sort your parts in bins. At that point you export entire bins to backup your parts and make restoring easier.
But my point was more that it is your actions that create the issue. If you didn’t save as a new part, export, delete and try and import again it wouldn’t be an issue and you may not even be aware the possibility of creating un-importable parts existed. If you simply used the editor as intended this bug would only come up maybe once a year at most. I can’t say I have had the issue except when you have edited one of my files manually and gave it back and it wasn’t importable. If you had imported the part, made changes in the editor, saved the changes and exported it Fritzing would have advanced the unique number (it does this every time you save the part in the editor) and that would allow it to be imported. But since you unzipped it, made changes and rezipped the file it was incompatible.
Sorry if that feels a little personal. It was not my intent to make anyone feel bad I just get frustrated seeing people making their lives harder when they could avoid the issues in the first place.
You can’t really win assigning pins either way. If you have a lot of pins it’s a lot of work doing it in the actual svg phase, yet if you do it in FZ Edit and you have to mod a svg after the pins are assigned, everything is buried so deep in groups it’s hell to go back in and change stuff. If they could solve the multiple superfluous groups problem FZ Edit would be way quicker.
You just press “ctrl shift g” in Inkscape until it is ungrouped back to the named groups (ie. copper0, silkscreen). It gets rid of the groups and preserves the pin assignments.
It is a bit tricky because it deselects the group in the XML dialogue so it looks like nothing is selected, but thankfully it stays selected in the drawing so it groups back in one shot.
I think at this point, since the current code base seems to be pretty much dead, our best bet is to decide how we would like things to be in future and try and try and influence (preferably by helping develop ) the new code base being proposed.
Agreed, especially on the board / shield parts like the arduino ones. I haven’t finished mine because there are tons of them and I do rather prefer pin assignment through svg labels.
Well, I will keep an eye on the new JS API since I know how to code on javascript but also keep practicing on parts creation since it is fun (and rewarding).
That is a good plan. I think the new version should still use (or at least use) current parts so new parts will work on both the current version and the new version. As far as I can see the Qt code is probably a dead issue and we should be focusing on the new code (I still haven’t yet figured out how to run it).
I’m fairly sure it is just an API that allows you to use Java to access Fritzing parts. It currently doesn’t really do anything on its own as far as I understand it.
It seems more of an idea by someone more familiar with Java than with C++ and QT trying to get people involved in porting Fritzing to web technologies. Like tens of thousands of projects on Github it may not go anywhere.
I myself will be concentrating my efforts on the current Fritzing application as it works and if we abandon it you will only ensure it dies.
That is very possible, as I know next to nothing about javascript (which, thank god, is different than java which is a performance pig due to garbage collection). From what I see of the stuff I needed to install, looks to be light weight (and therefore in theory fast, in practice we will see) but it is implied that this is a parts viewer of some kind and its extremely possible I just don’t know what I’m doing. I guess we will see if the folks writing it reply to the various posts. The code snippet in the readme.md file appears to make a server of some kind (a similar one I found on stackoverflow creates a server that outputs a “Hello World” web page successfully), but for me the code snippet errors out before starting, possibly due to something I’m not doing so I have some feeling it may do something if I knew how or you could be correct.
I think concentrating on fixing up the parts repository is worth doing and there is certainly lots to clean up about that. It is much less clear to me that there is much purpose in trying to improve the Qt based code as it looks like (as it has for some time) development interest in that code base has died. I’m an outsider and a relatively new user, el-j as far as I know was a key member of the original team and I expect he has a lot better idea than any of us of the chance of the Qt code going forward and it doesn’t seem that he sees much chance of that from his posts. I guess time will tell.
The API is important and what the program will be built upon but it is far from a interactive program. He does say they have built a parts viewer using the API and the following post by paulvollmer says if you want to try it out to contact them and they will add you to the hidden private repo so you can alpha test it before it goes public.
Since there wasn’t a common agreement between us, I will just edit the main post with the current tips I have been using for my parts design on Inkscape.
I am using Windows OS in case it is a bug.
), I think Qt in the new project is being replaced by html5. The reason I think that is there is a white paper on the Qt site about why Qt is better than html5 which tells me that at least some of the Qt functionality is available in html5. As noted, I’m ignorant and could be wrong here.
) the new code base being proposed.