1. Alien formats in schematics/symbols (limitations) Before going into any detail, the single most important thing to understand is: loading alien formats in a schematics editor is totally different from loading them in a pcb editor. In PCB land 90% of the time we try to specify physical things, copper, geometry, and only 10% is about logial structure. Different tools have different data models which each represents the same thing differently, but at the end of the day we have a chance to get all physical things and half of the logical things right. So after loading an alien file in pcb-rnd, you get 90..100% the same thing back (minus the bugs you are going to report and I am going to fix). Unfortunately this is very different in SCH land: 30% of the data is about geometry (the actual drawing) and 70% of data is about the logical structure. We can normally import most of the 30% geometric part fine, but then how different sch editors interpret your attributes vary wildly. So at the end you get some 40..60% of the stuff imported properly in the sense "it works out of the box, without modifications. In other words: after loading any alien format in sch-rnd, you MUST manually go over the WHOLE thing and fix things up. Typically not graphical things, but attributes, differences in assumptions. This is not an sch-rnd thing. This is any sch editor vs. any other sch editor thing. We can go and do some extra attribute conversion attempts, but the yield of the process will never get close to 90%+. Typical example: slotting. Every single sch editor I've seen so far did it totally differently. At the moment the slot map specified in a gschem symbol is not automatically translated into a portmap when you load the file (and especially not into a devmap you probably want to have instead). 2. loading .sch files: howto, tips & tricks We have a pool node on this: http://repo.hu/cgi-bin/pool.cgi?project=sch-rnd-aux&cmd=show&node=io_geda This contains further considerations on what exactly may go wrong during the conversion, plus describes how to set things up so that external symbols are found (in case you forgot to embed them). Just like in pcb-rnd, you do not import, just load gEDA .sch files. 3. symbol loading We also have gEDA symbol loading. You can use file/import/load symbol..., which handles any supported symbol format. Just like with alien footprints in pcb-rnd, you don't need to manually import them either, they load fine, like if they were native. You can simply configure a library search path pointing to a gEDA sym lib dir and all symbols are picked up recursively and are available in the library window (at the moment you need to restart sch-rnd to get the new dir mapped). 4. embedded symbols vs. external lib symbols Rule of thumb: load portable sch files only! That means use gschem or gschlas to embed all symbols so your sch file doesn't depend on gEDA symbol libraries. It is because sch-rnd does NOT try to reproduce the exact ways gEDA searches and loads those symbols: - we do NOT read gafrc or gschemrc or other gEDA config files - we do NOT follow the same search order/algorithm within the libs so if you have redundant sym file names we may pick the wrong one Note: the stock gEDA sym lib does have redundant file names: for example two incompatible symbols are called resistor-1.sym in two different directories. If you put the whole gEDA symlib on library search path and your schematics references resistor-1 without embedding it, sch-rnd may pick the wrong resistor-1. 5. No save support At the moment I don't see any value in spending time on implementing alien save functionality for gEDA formats. Rationale: I think gEDA is literally dead by now: - gschem last commit: 9 months ago - gschem got out from some distros because of the too-old guile dep and also depends on python2 which will be another way it gets uncompilable - PCB last commit: 6 months ago - user community evaporated: in 2022 total 13 mail in 4 threads, from which 1 was an unanswered user support request on PCB and 1 was basically a "I am leaving gEDA, help me port my files" request on gschem (this is on geda-user and geda-help combined) - lepton-eda is active, but without an active ecosystem around, it probably won't get far So all in all, in the highly unlikely situation when a gEDA user needs to load an sch-rnd file, gschem or lepton developers should be asked to write import code or converter.