This part should do what you want. You should still print out the footprint and check it against you actual part, but the footprint should be the one that @opera_night has had success using (although if @opera_night could check the gerber output from this part to make sure I didn’t screw up that would be great!)
Rotary Encoder_new_footprint.fzpz (9.3 KB)
That is what it says, and by and large it is correct (although incomplete). It is possible to make a part from scratch, it is just usually hard and inefficient. A new part has a moduleId which is a hex string (prefix0000_5d6cd844d826943902922aee8f7f7dbe_1 in the case of the current part). You can make one of these yourself, but there are things (such as I think Fritzing version number) buried in it that the code uses to decide what version it should treat the part as sometime, and it must be globally unique in your version of Fritzing (and everyone elses if they want to use your part). I find it better to let parts editor do its thing to create a moduleId it will be happy with with the correct number of pins that I need (so it generates the xml boilerplate, I can do it but it is easier to just have to edit it) and then unzip the resulting fzpz file and edit the underlying files (the fzp file is some boilerplate xml that the parts editor can most easily create although the format is available in the parts fomat document here:
followed by the connector definitions, optionally schematic subpart definitions and optionally bus definitions. Once you know the format of all those it is possible to edit the fzp file and the svg files outside of the parts editor to successfully make a part. To help that along I wrote a python script (available on github) that given the fzp file as input will parse it to check the format is correct (and warn about things I know can go wrong but not break the resulting part and error on things that I know will break the part). There are still things about the fzp file that the code uses that I don’t know about, but I do know some of the secrets (breadboards for instance have a variety of differences from a normal part in the fzp file). As well that script (which has been run against this part to clean it up) also fixes a variety of things that Inkscape does of css compliance that fritzing doesn’t support.
I think this is a QT (Qt being the graphics framework that Fritzing is running on) issue rather than Fritzing (although it could also be a Fritzing issue). I have a develpment environment for the source up and have upgraded from Qt 5.6 that current Fritzing used to the current Qt 5.10 but havn’t run it enough yet to see if there are any fixes that help us on the Qt side. As you may have seen one of the original developers is also trying to redo fritzing as a web app in javascript (which is pretty much the only development activity that I’m aware of).
Peter