JFET symbol is weird

[denizzzka]

Where is on this pic source and drain?

Google Image search also don't knows this variant of symbol with short line on the one of inputs.

Proposal:

[in3otd]

...interesting, without thinking I always assumed that the terminal with the short inclined line was the source (indeed it is, I've just checked the source [pun intended]). But I see now that it might not be so clear.
I suspect the symbol is inspired by a well-known commercial simulator, which uses a symmetric symbol with just a small 's' near the source terminal for the JFET.
The symbol you proposed, while nice, cannot be used as we need to keep the devices ports at the same position for backward compatibility (otherwise all the existing schematic using JFET will require to rewire the moved terminal). We could also use a small 's' to indicate the source or put the arrow on the source ( uncommon but another commercial tool does this) .

[denizzzka]

I suspect the symbol is inspired by a well-known commercial simulator, which uses a symmetric symbol

Google says that historically first JFETs did not make the distinction between S and D...

with just a small 's' near the source terminal for the JFET.

...subsequent dirty fix.

The symbol you proposed, while nice, cannot be used as we need to keep the devices ports at the same position for backward compatibility (otherwise all the existing schematic using JFET will require to rewire the moved terminal).

May be it is make sense to add a unique number of component picture with its pinout? I think it is not latest case where scheme symbols proposed to change. Qucs could store and display old and new symbols in this case for easy migration from old symbols.

[denizzzka]

We could also use a small 's' to indicate the source or put the arrow on the source ( uncommon but another commercial tool does this) .

In my opinion, small "S" is better, because it not need to introduce further standards.

[felix-salfelder]

are symbols tied to components? if not, just provide another symbol. if they are (which is what i suspect), it's about time to fix that...

[guitorri]

Symbol of primitives are currently hardcoded in C++. Symbols of subcircuits and library symbols can be customized.

IMHO, we should move everything to plain text libraries of loadable components...

If that ever happens we might as well rethink first the schematic file format and the (now non-existing) internal database.

It should be possible to apply any schema on top of the schematic. Make it look like gEDA, KiCad, or even use ISO or US/EU symbols.
There will always be a discussion of which symbol looks better.
We either stick to one, or enable people to customize at will...

Forward/backward compatibility should not be forgotten. Port mapping might be a bit tricky indeed. We could break the wires and connect by netname if a reroute is too much work... Anyway, topic for another thread.

[in3otd]

FWIW, for me the major drawback in having hardcoded symbols is that I cannot (easily) use the existing components symbols as a starting point for new subcircuit symbols. Trying to replicate symbols with arcs and curves is not so easy by hand... When I need to do that I just hack the subcircuit schematic text file and enter the curves coordinates by hand there. Not by chance the symbol description in the C sources and in the schematic file are very similar and only a little adaptation is needed.

Not sure we should try to have Qucs drawing schematics as other tools, I think it will be better to be export the schematic in other formats and let the other tools import and draw it.

[felix-salfelder]

I think it will be better to be export the schematic in other formats and let the other tools import and draw it.

yes. lets do symbols and components in a more straightforward way. the hard part will be cleaning up what we have right now. see #383 for a starting point.

i think we all agree, except maybe for some details, which are certainly off topic here.