Re: gEDA-user: Visual cue of zero length pin endpoint
2011/1/27 Kai-Martin Knaak : > Maybe something much simpler: > Define a range of zoom scales, were the cues keep their size relative to > the screen. That way, they'd shrink when zoomed way out. On the other end > of the zoom scale, the cues should never get smaller than the width of a > net. Zoom-dependent scaling is already applied to selection handles and that does not work very well... https://bugs.launchpad.net/geda/+bug/698785 I would keep the unconnected net cues size constant in WORLD coordinates, and selection handles size constant in SCREEN coordinates. -- Krzysztof Kościuszkiewicz "Simplicity is the ultimate sophistication" -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
Peter Clifton wrote: > (Only exceptions being things which don't render to print, such as > selection colours or grab handles). I'd say, pin cues fall into the same category. >> calculate the mean density of markers and dynamically adjust the size to >> some useful value? > > Sounds like a whole host of code to make a marginally better view Maybe something much simpler: Define a range of zoom scales, were the cues keep their size relative to the screen. That way, they'd shrink when zoomed way out. On the other end of the zoom scale, the cues should never get smaller than the width of a net. ---<)kaimartin(>--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
On Wed, 2011-01-26 at 22:23 +0100, Kai-Martin Knaak wrote: > >> While at it: The marker should _not_ scale with zoom. Make this behaviour > >> default, but optional. So the old behavior can be restored. > > > NAK (I think) - so printing works, > > Is printing to postscript hard wired to screen presentation? Our printing is tied to our canvas, which is what our on-screen representation uses. It is not impossible to separate them, but we have otherwise been working towards keeping on-screen rendering and print rendering as identical as possible. (Only exceptions being things which don't render to print, such as selection colours or grab handles). > calculate the mean density of markers and dynamically adjust the size to > some useful value? Sounds like a whole host of code to make a marginally better view than our current implementation. I can't even visualise what difference it would make. Perhaps it would help pinpoint a small number of errors at low zoom though. I'm afraid this might have to fall into the category of "patches welcome". -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
Peter Clifton wrote: >> This eye-catching marker should not print (in postscript). > > The net-end red dot is effectively a DRC overlay warning you have left > something unconnected. I would be inclined to make sure it does print, > otherwise PDF schematics sent to collaborators for review would loose > that important information overlay. Make it an option in the print HID that can be checked in the print dialog. I wouldn't want to force people to touch each and every pin to get rid of the markers in print. I can think of circuits with lots of deliberately open pins. Say, on connectors, or oversized FBGAs. >> While at it: The marker should _not_ scale with zoom. Make this behaviour >> default, but optional. So the old behavior can be restored. > NAK (I think) - so printing works, Is printing to postscript hard wired to screen presentation? > and zooming out doesn't result in forest of red. calculate the mean density of markers and dynamically adjust the size to some useful value? ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
On Mon, 2011-01-24 at 17:16 +0100, Kai-Martin Knaak wrote: > My proposal: > Make all endpoints point-like. There is no point in having a direction > of an endpoint. (pun intended) Put a blob with configurable size and > color at the end of every pin. Make it stand out by default. This is a > cue whose purpose is to be a visible reminder that there is an open end > dangling in the circuit. > > This eye-catching marker should not print (in postscript). The net-end red dot is effectively a DRC overlay warning you have left something unconnected. I would be inclined to make sure it does print, otherwise PDF schematics sent to collaborators for review would loose that important information overlay. > While at it: The marker should _not_ scale with zoom. Make this behaviour > default, but optional. So the old behavior can be restored. NAK (I think) - so printing works, and zooming out doesn't result in a forest of red. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
Krzysztof Kościuszkiewicz wrote: > One proposal would be to reuse endpoint marker of unconnected nets (same > size & shape). > > Another is to keep the current marker for longer pins, and below some > configured length use a box-shaped cue (same as unconnected net). > > Opinions, other proposals? My proposal: Make all endpoints point-like. There is no point in having a direction of an endpoint. (pun intended) Put a blob with configurable size and color at the end of every pin. Make it stand out by default. This is a cue whose purpose is to be a visible reminder that there is an open end dangling in the circuit. This eye-catching marker should not print (in postscript). While at it: The marker should _not_ scale with zoom. Make this behaviour default, but optional. So the old behavior can be restored. ---<)kaimartin(>--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
On Mon, Jan 24, 2011 at 1:36 AM, Peter Clifton wrote: > > I think the consensus is that there is no harm in allowing them, we're > just figuring out the implications for how to draw them properly, and > how it affects other things. How about a square pin of a size comparable to a "solder dot" and color (in dark color scheme) which is: - red when the pin is not connected to any net, - white when it is connected. The latter is to mimic the look&feel of "regular" pins. I'm not particularly attached to the above - anything design is OK as long as pins are easy to see and distinguish from other objects. Cheers, Andrzej ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
On Sun, 2011-01-23 at 17:22 +0100, Stephan Boettcher wrote: > I just made a symbol with 624 zero length pins. Please keep them :-) Since you asked nicely ;) Acutally, this discussion started out from an effort to stop gschem whining about zero length pins, not removing them. I think the consensus is that there is no harm in allowing them, we're just figuring out the implications for how to draw them properly, and how it affects other things. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
Andrzej writes: > On Mon, Jan 24, 2011 at 12:01 AM, Peter Clifton wrote: >> >> libgeda was recently patched to allow zero length pins. Please point me >> at where the documentation says this is invalid, and I'll file a bug >> about getting that changed. > > http://www.geda.seul.org/wiki/geda:file_format_spec#pin > > "You cannot have a zero length pen (the tools will throw them away)." > > The typo in this sentence technically makes it invalid. ;-) Same > requirement exists also for other data types. > >> You are correct there, those driving the zero-length pins change should >> consider whether this is a problem or not, and if so - what do do about >> it! > > It makes sense to extend the spec to cover zero-length pins (IMHO > other shapes should stay non-zero sized) but it would be better if the > spec explicitly said when and for what purposes pin directionality can > be used. In the current version there is no mention of it but since > pins are guaranteed to have a direction, it's not unreasonable to use > this property for all sorts of things. I just made a symbol with 624 zero length pins. Please keep them :-) -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
How about an external filter utility that could remove (with appropriate message) the offending line segments. George On 01/23/2011 10:01 AM, Peter Clifton wrote: On Sun, 2011-01-23 at 23:52 +0900, Andrzej wrote: Krzysztof, I'd like to get opinions on the drawing of visual cues (endpoints) of pins. Curently: This may not be a suggestion you expected, but... how about making the parser stricter and actually remove such shapes (and any other zero-sized objects) before they make their way into libgeda? These shapes violate the gEDA file format spec so if the tool is being sloppy about checking their properties, we will end up with 2 specs - one "official" and one "de facto" (particularly important for authors of third-party tools, as they will have to reproduce all the workarounds in libgeda). libgeda was recently patched to allow zero length pins. Please point me at where the documentation says this is invalid, and I'll file a bug about getting that changed. Visual artifacts in rendered symbols are not the only problem. There might also be other functions that depend on directionality of pins. I vaguely recall that the pin direction is used by gschem for assisted routing of nets in schematics (as a preferred direction of a net connected to the pin). You are correct there, those driving the zero-length pins change should consider whether this is a problem or not, and if so - what do do about it! On cursory inspection, adding preferred net orientation could require a file-format bump to do flexibly. A heuristic could be imagined, but it won't be as easy to get right as it first sounds. ___ geda-user mailing list [1]geda-user@moria.seul.org [2]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:geda-user@moria.seul.org 2. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
On Mon, Jan 24, 2011 at 12:01 AM, Peter Clifton wrote: > > libgeda was recently patched to allow zero length pins. Please point me > at where the documentation says this is invalid, and I'll file a bug > about getting that changed. http://www.geda.seul.org/wiki/geda:file_format_spec#pin "You cannot have a zero length pen (the tools will throw them away)." The typo in this sentence technically makes it invalid. ;-) Same requirement exists also for other data types. > You are correct there, those driving the zero-length pins change should > consider whether this is a problem or not, and if so - what do do about > it! It makes sense to extend the spec to cover zero-length pins (IMHO other shapes should stay non-zero sized) but it would be better if the spec explicitly said when and for what purposes pin directionality can be used. In the current version there is no mention of it but since pins are guaranteed to have a direction, it's not unreasonable to use this property for all sorts of things. Cheers, Andrzej ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
On Sun, 2011-01-23 at 23:52 +0900, Andrzej wrote: > Krzysztof, > > > I'd like to get opinions on the drawing of visual cues (endpoints) of > > pins. Curently: > > This may not be a suggestion you expected, but... how about making the > parser stricter and actually remove such shapes (and any other > zero-sized objects) before they make their way into libgeda? These > shapes violate the gEDA file format spec so if the tool is being > sloppy about checking their properties, we will end up with 2 specs - > one "official" and one "de facto" (particularly important for authors > of third-party tools, as they will have to reproduce all the > workarounds in libgeda). libgeda was recently patched to allow zero length pins. Please point me at where the documentation says this is invalid, and I'll file a bug about getting that changed. > Visual artifacts in rendered symbols are not the only problem. There > might also be other functions that depend on directionality of pins. I > vaguely recall that the pin direction is used by gschem for assisted > routing of nets in schematics (as a preferred direction of a net > connected to the pin). You are correct there, those driving the zero-length pins change should consider whether this is a problem or not, and if so - what do do about it! On cursory inspection, adding preferred net orientation could require a file-format bump to do flexibly. A heuristic could be imagined, but it won't be as easy to get right as it first sounds. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
Krzysztof, > I'd like to get opinions on the drawing of visual cues (endpoints) of > pins. Curently: This may not be a suggestion you expected, but... how about making the parser stricter and actually remove such shapes (and any other zero-sized objects) before they make their way into libgeda? These shapes violate the gEDA file format spec so if the tool is being sloppy about checking their properties, we will end up with 2 specs - one "official" and one "de facto" (particularly important for authors of third-party tools, as they will have to reproduce all the workarounds in libgeda). Visual artifacts in rendered symbols are not the only problem. There might also be other functions that depend on directionality of pins. I vaguely recall that the pin direction is used by gschem for assisted routing of nets in schematics (as a preferred direction of a net connected to the pin). As for the symbol in question (http://launchpadlibrarian.net/62667585/zero-length-pins.png), why not simply use short pins instead of zero-length ones? They can be as short as "1 unit", which is probably even shorter than these fake pins visible on the rendering. Cheers, Andrzej ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Visual cue of zero length pin endpoint
All, I'd like to get opinions on the drawing of visual cues (endpoints) of pins. Curently: * Zero length pins have a short line drawn at endpoint * Pins with rotation other than 0, 90, 180 and 270 have nothing One proposal would be to reuse endpoint marker of unconnected nets (same size & shape). Another is to keep the current marker for longer pins, and below some configured length use a box-shaped cue (same as unconnected net). Opinions, other proposals? Bug report: https://bugs.launchpad.net/geda/+bug/706552 Related discussion: https://bugs.launchpad.net/geda/+bug/705397 -- Krzysztof Kościuszkiewicz "Simplicity is the ultimate sophistication" -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
