Create the straight wire, hover the mouse over the middle of wire, hold down the control key, click/drag the wire to create the curve. Doing this near the end of the wire will adjust the curve at that end.
If there are bends in the wire, each segment can be adjusted like that to create more complex curves. See the GND and 5V wires in https://wcrsyyc.github.io/ardx/circ11.html for and example. The Fritzing sketch is there to download.
Hmm, that should be the same 555 I used in core which seems to be the correct part spacing (some of the user generated parts have either offset from the grid or have incorrect spacing issues but most that you find in the parts bin are pretty good). Is your grid perhaps in mm rather than in in the view set grid size window (although that doesn't work out either ...)? If you would save the sketch then upload the resulting fzz file (7th button from the left on the tool bar at the top of the reply window) we can have a look at the parts and see if we can see a problem.
Perhaps one of our Mac users can provide illumination, but I think this is the first case like this that I have heard of. However if .07 is working thats good 
Peter
Both the plug and jack parts in your example Fritzing sketch have a typo in the connector terminal ids.
For the jack, the part fzp file says
layer="breadboard" svgId="connector3pin" terminalId="connector3terminal"
but the breadboard svg says
id="connecotr3terminal"
For the plug, the part fxp file says
layer="schematic" terminalId="connector1terminal"
but the schematic svg says
id="connecotr1terminal"
"ot" should be "to" in both svg file cases.
Ah, that makes things a bit clearer. Unfortunatly I don't know of a way to make cables (there may be one, that I don't know of though) so you are stuck with creating single wires for the cables. However I don't think you need female connectors to do this. A standard 2xX female header (other than that the female header creation code appears to be broken at present) should do this.Iif you add a second set of pins to represent the ends of the connections at the .3 inch spacing with the pins bussed together that should do what you want. The wire from the module connects to the pin of the dual row connector and the pin on the breadboard (which is bussed to the same pin on the connector) connects to the arduino. Female pins are only needed when you want something like the breadboard which doesn't do anything (routing wise) except connect wires together. In your case I think you want to connect wires from the radio module to the 2 row connector, and then connect wires from the breadboard to the arduino (and male connectors will do that). However I think you will need at least the pins in schematic to make the routing work, but if you don't want them to actually show in schematic you should be able to define the pins as fill= none and just not put in the visible connections and everybody should be happy (Fritzing will have invisible pins to route, but they won't actually show on schematic). In the plug case I wanted to make the physical connection clear to new users, and in this case you probably don't. When you finish the entire part as the last step you need to import it to Fritzing (which will quite happily work) then edit it with parts editor and export it as a new part to get it registered with the database with a sequence number (that parts editor will create). If you don't do this the part will load correctly but usually screw up when you try and save the sketch then reload it in to Fritzing as your new part isn't registered in the parts database. Unfortunatly Fritzing is more tolerant on input parsing than on export/ saving parsing and there are several of these gotchas waiting to trip you up on reload (it also doesn't like the px dimension on font-size and will set the font size to 0 when the part is edited for instance).
Peter
Well this is sad, someone posted a helpful link on this thread which has now been removed. I guess I know why, it was a link to alibaba supplier page, maybe selling is not allowed here?
The only problem is, the page had the best product information I have found so far, including dimensions of a pcb footprint with overlap for soldering it was going to be copy paste to inkscape job done. Now I am searching alibaba (not the easiest place to look there is so much stuff) to try and find the page again as I didn't save the link...
What I want is a very small breadboard with pins at the edge that will allow it to sit on top of, and connect to, a regular breadboard. If I create the radio module part correctly, no wires will be needed to add it to the breadboard view. Just like a standard DIP package sits across the centre of a standard breadboard, this would sit on the new breadboard. And make connections to the underlying breadboard, which would then have the usual wires to the the Arduino. And in this case a 3.3volt regulator. The schematic view would (should) have the radio module with (rats nest) connections to the Arduino and voltage regulator. The breadboard wires and both breadboard parts, are just wires, and do not need a schematic representation. At least that is the goal.
Another way to look as this, is as a 'carrier'. A base DIP footprint that connects to a 2 row header.
I'm going to try again starting from a standard breadboard part, and also from a Header 1 part. Once I get a single connection to feed through properly, I can expand it to as many pins and connections as needed.
Maybe I can get a female breadboard pin to connect to another female breadboard pin. The initial failing attempt was putting a male pin at the end of the bus, to connect to the main breadboard.
Yep, sloppy (and part of the reason that I'm working on a python script to check for things like that). In this case it doesn't break though as without the correct terminal id Fritzing defaults to using the pin as the as the connection point so the part still works. If both were misspelled the part would have failed to work.
Peter
Ok found it - or something like it:
going to bookmark this page in case the link is removed (lets see what happens)
Hmm, the pad layout on this one is slightly different than that of the version that adafruit is selling. I suspect that you would need to select your supplier of choice and get their suggested pcb layout to make a proper pcb. I would have though that a 2020 was a standard footprint, but I know very little about smd parts. Perhaps one of our smd experts will comment? As noted before if you start with the 5050 footprint available in core I don't think that will be too difficult a task. All you need to do is reduce the size of the pads (and possibly in this particular case add two pads in the center for gnd and vcc it looks like) which shouldn't be that hard once you identify the package you need of course . As I recall, the person that posted the data sheet made similar posts to several threads and I expect (but don't know ) got deleted as spam as it was nothing to do with Frtizing directly just the data sheets.
Peter
I have a working version, based on a major cut down from TinyBreadboard. Now to see if I can finish the cleanup without breaking it, and see what the difference ends up from the starting broken version. For starters, this still has family Breadboard, which Fritzing treats special. I tried that before too, so there is something more.
i want sensor parts to drawing my 37 project but when i working on fritzing
i do not get all these sensor , i wish someone help me and give me all these part to add them in fritzing library
thanks
this link of my sensor parts : http://www.express.ee/sites/default/files/2015/08_13/37_in_1_sensors_kit_for_arduino.jpg
Breadboard has a variety of special features, one of which is it is on the lowest level with everything else above it. I did what started out as a part but ended up being a fzz (due to performance issues and Fritzing bugs) with subparts for an education board for someone that contains an internal breadboard. I doubt that you want or need breadboard for this, but may not be understanding what you are trying to do entirely. The moduleid field in the fpz is important (along with a variety of things in the tags) to get it working correctly. @steelgoose is the expert on this level of Fritzing (he is where I have learned most of what I know).
Peter
google is your friend. Both adafruit and sparkfun have github repositories of fritzing parts for their products (some, perhaps many? of which aren't in core yet) both of those would be a good place to start. As well the google search "fritzing part device" (where device is replaced by the sensor you want) sometimes turns up a user created part that is available somewhere. Searching in the projects repository on the main Frtizing site will also sometimes find a project that contains an appropriate part that you can use. If all that fails you would be left with making your own part (which isn't all that easy, but assistance is generally available here).
Peter
I found and read that thread when I was trying to create a part with both a bus and subparts. When I ran into the bug that does not allow both in the same part.
I don't really want a breadboard, but i'll use it if that is all that works. A carrier or adapter family would be better. Right now, a 2 pin breadboard is working. Continuing careful cleanup and testing. When ready, I'll try changing the family, and see what happens. I have not found references to the special features and tags associated with breadboards. I've been working from comparisons of part files. I had not notice that there was something special about the module id. I might not actually have a proper breadboard part any more, since I changed that right to start, to a simple guid value.
As far as I know the source is the only documentation for this (and of course steelgoose who I believe has found most of it by experimentation). In general documentation is fairly lacking, but for me at least if the choice is documentation or finishing the code and/or cleaning up bugs I'll take the latter. We can find and document stuff being able to extend and / or fix bugs I'm less sure of ...
Peter
This could get into a religious war with others, but here is my opinion. With nearly 40 years doing programming for context.
RANT ON
For an application / product that has an api (like custom part creation), the documentation is actually part of the product. Missing the information about the rules to follow to use the product is a bug itself. Broken code means an usable app. So does lack of information about the requirements to follow when using it. Some bugs have more or less usable work arounds. Reading the code is a work around for no documentation. It is not a fix or proper alternative. Work arounds do not make either type of bug go away.
A work around that essentially says read the code is of limited usefulness. Even those with the right background are going to need to spend a significant amount of time to be able to use it. About as useful of work around as one that requires specialized knowledge of the internals of the operating system.
There should be some level of documentation before the code is even written. Call is specifications if you like, but what the program is to do better be known before writing the code. When the code is evolving, with no clear pre-defined direction, documentation is even more important. That situation involves a lot of try something, see if it works, back up and try something else. Those paths tried and rejected need to be recorded, to prevent even more wasted time when someone else tries the same failing path.
Code is never truly finished. Given the choice of 100 features that I can not use because there is no information on how to use them, and 50 features that have the documentation to use them, I'll take the 50 plus documentation. If the documentation was being written right along with the code, treated as part of the package being produced, that would probably be more like 80 features. The documentation makes the code easier to write, easier to test.
Extracting usage information by reading the code takes 10 times as long as creating it as the code is written. Doing it afterwards means first learning what the code does, then creating the documentation from that knowledge. Forcing everyone to read the code to get the documentation means that every single person that wants to use those features needs spend that amount of time, for the features they are going to use. Versus the one tenth time needed by the one person writing the code, or better, writing the specifications before the code was written.
That does not mean the programmer needs to produce full detailed, ready to read documentation. It is quite valid to produce very rough content, that is then passed to someone else to clean up and make pretty. With the rough verbiage, it only needs a general knowledge of the application goals, and decent writing skills, to to turn out good documentation for everyone else.
RANT OFF
All true, but as I understand it (and I'm a late comer, so my experience is limited), Fritzing started out as a funded university research project so there may actually be more documentation than has been released. When the funding ran out it got converted in to an open source project I think (based mostly on the paid parts creation service that is available) hoped to be funded by parts creation for some of the commercial vendors (thus the lack of parts creation documentation) as well parts editor isn't yet completed so its possible they were waiting for that to complete before documenting and then funding ran out. There appears (at least to me) to be a good and far reaching plan of how development should have proceeded, but funding died and my sense is that not as much funding as hoped for is coming in from open source and time on the developers part is now lacking (likely because of having to fight for funding for new research projects at the day job). If we want to see Fritizing continue, its up to us to help out documenting what we can and possibly trying to fix bugs in the source (although I'm finding just parts creation to be a challenge ). The part that is here is pretty amazing even in its incomplete and somewhat buggy state. With enough effort you can usually work around the bugs to get it to do something useful to you (at least I can) and the source is available to make it better if you can, both good things as far as I'm concerned.
Peter
Did you actually install the parts and data?
cfranklin@cfranklin-Latitude-D630:~$ sudo apt search fritzing
[sudo] password for cfranklin:
Sorting... Done
Full Text Search... Done
fritzing/zesty,now 0.9.3b+dfsg-4 amd64 [residual-config]
Easy-to-use electronic design software
fritzing-data/zesty,zesty,now 0.9.3b+dfsg-4 all [installed,auto-removable]
Easy-to-use electronic design software (data files)
fritzing-parts/zesty,zesty 0.9.3b-1 all
Easy-to-use electronic design software (parts files)
cfranklin@cfranklin-Latitude-D630:~$ sudo apt-get install fritzing fritzing-data fritzing-parts
Reading package lists... Done
Building dependency tree
Reading state information... Done
fritzing-data is already the newest version (0.9.3b+dfsg-4).
fritzing-data set to manually installed.
The following NEW packages will be installed:
fritzing fritzing-parts
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 9,513 kB/13.1 MB of archives.
After this operation, 151 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://us.archive.ubuntu.com/ubuntu zesty/universe amd64 fritzing-parts all 0.9.3b-1 [9,513 kB]
Fetched 9,513 kB in 5s (1,840 kB/s)
Selecting previously unselected package fritzing.
(Reading database ... 269382 files and directories currently installed.)
Preparing to unpack .../fritzing_0.9.3b+dfsg-4_amd64.deb ...
Unpacking fritzing (0.9.3b+dfsg-4) ...
Selecting previously unselected package fritzing-parts.
Preparing to unpack .../fritzing-parts_0.9.3b-1_all.deb ...
Unpacking fritzing-parts (0.9.3b-1) ...
Processing triggers for mime-support (3.60ubuntu1) ...
Processing triggers for desktop-file-utils (0.23-1ubuntu2) ...
Setting up fritzing (0.9.3b+dfsg-4) ...
Setting up fritzing-parts (0.9.3b-1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Processing triggers for gnome-menus (3.13.3-6ubuntu5) ...
cfranklin@cfranklin-Latitude-D630:~$
I was having issues as well, until I had seen the parts and data packages. The built in GUI software manager doesn't show these.
I wish I had realised this before sending a design to be made. As a result, I now have 3 useless boards. My own fault for not checking properly.
Thanks !!!!!! I really appreciate it.