X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Injected-Via-Gmane: http://gmane.org/ To: geda-user AT delorie DOT com From: Kai-Martin Knaak Subject: Re: [geda-user] gschem, best size of symbols and text? Date: Sat, 26 Sep 2015 19:12:23 +0200 Lines: 68 Message-ID: References: <1442845842 DOT 2167 DOT 27 DOT camel AT ssalewski DOT de> <1442999974 DOT 23194 DOT 15 DOT camel AT ssalewski DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet AT ger DOT gmane DOT org X-Gmane-NNTP-Posting-Host: a89-182-172-250.net-htp.de User-Agent: KNode/4.14.1 Reply-To: geda-user AT delorie DOT com Stefan Salewski wrote: > Note, text size in relation to symbol graphic is not really an > issue, because it can be arbitrary scaled all the time. But I don't want to rescale text all the time. ;-) > Default grid > size to symbol size is more important. A very fine grid gives us > very many possible positions to put elements and nets, which makes > it "difficult". For gschem, I would use 200 as major grid generally, Hmm. I am ok with the default 100. During schematic capture I never felt like the grid should be more coarse. Design of a symbol is a different issue, though. I often find myself dial down the grid size to be able to move bits and pieces to where they belong. While I think about it, it would be nice to have an accel key to directly switch to the default grid. > but then not both ends of resistors are on grid. This is bound to happen if you work with a larger grind size than the lib was intended to. > Sometimes we need indeed short pins, but > not often. However, these are the annoying cases. > Of course we may generally use short pins, which we > extend with net segments generally. That's what I prefer. Don't like to be forced to put symbols at specific distances. > But that makes editing much work. It is the GUIs job to reduce the load. gschem could use a boost in this direction. "Kissing mode" which starts a net if you try to separate two touching pins is good start. But this concept could benefit from some developer love. It should also work for pin+net and net+pin. > It is much easier to move one resistor, than additional too > short net segments. There is room for improvement of the UI. E.g., press [alt] while dragging might automatically include the first segments which extend the pins of the symbol. And a different modifier to rip the symbol off the nets. > I was thinking about symbols where pin length is adjustable by > attributes, in 100 units. I dunno. Seems to me, connectivity is the job of net lines. Variable pin lengths would muddy the water. If you move a symbol, should the net lines adapt. Or should the pin length adjust itself? Variable pin lengths might present an additional challenge to a converter from other formats. ---<)kaimartin(>---