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.
) the new code base being proposed.
or you could be correct.