Mail Archives: geda-user/2016/01/09/08:40:26
--Apple-Mail=_C8F66C48-F315-4C37-801A-571BC15447CA
Content-Type: multipart/alternative;
boundary="Apple-Mail=_70CE4DDD-4187-47BF-B9A0-18A952141EE8"
--Apple-Mail=_70CE4DDD-4187-47BF-B9A0-18A952141EE8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Jan 9, 2016, at 7:55 AM, Peter Clifton =
(petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com] =
<geda-user AT delorie DOT com> wrote:
> Whether or not this is fully factored in the code or not, from the =
graphical entity point of view these are effectively sub-type =
specialisations of the line primitive, as John has suggested. Whilst it =
would be technically possible to take this as a more "duck typed" =
approach, I'd probably not suggest it.
What I was trying to get at is that I see line drawing style as a =
fundamentally orthogonal issue to line =93type". What we have now is =
hard-wired, except for purely graphical lines. That doesn=92t fit all =
uses. It gets us into unresolvable arguments over thick net segments for =
power versus thin segments for signals. Conventions are good. Defaults =
implementing conventions are good. Hard wiring them is bad.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_70CE4DDD-4187-47BF-B9A0-18A952141EE8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Jan 9, 2016, at 7:55 AM, Peter =
Clifton (<a =
href=3D"mailto:petercjclifton AT googlemail DOT com">petercjclifton AT googlemail DOT co=
m</a>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <<a =
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: =
none; display: inline !important;">Whether or not this is fully factored =
in the code or not, from the graphical entity point of view these are =
effectively sub-type specialisations of the line primitive, as John has =
suggested. Whilst it would be technically possible to take this as a =
more "duck typed" approach, I'd probably not suggest it.</span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"></blockquote><br></div><div>What I =
was trying to get at is that I see line drawing style as a fundamentally =
orthogonal issue to line =93type". What we have now is hard-wired, =
except for purely graphical lines. That doesn=92t fit all uses. It gets =
us into unresolvable arguments over thick net segments for power versus =
thin segments for signals. Conventions are good. Defaults implementing =
conventions are good. Hard wiring them is bad.</div><br><div =
apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><p style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">John Doty<span =
class=3D"Apple-converted-space"> <span =
class=3D"Apple-converted-space"> </span><span =
class=3D"Apple-converted-tab"> <span =
class=3D"Apple-converted-space"> </span></span></span>Noqsi =
Aerospace, Ltd.</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><a href=3D"http://www.noqsi.com/">http://www.noqsi.com/</a></p><p =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica"><a =
href=3D"mailto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a></font></p><br =
class=3D"Apple-interchange-newline"></span>
</div>
<br></body></html>=
--Apple-Mail=_70CE4DDD-4187-47BF-B9A0-18A952141EE8--
--Apple-Mail=_C8F66C48-F315-4C37-801A-571BC15447CA
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWkQ2pAAoJEF1Aj/0UKykR7FwQAKxGctS4jLOZt/rA2Y7tlKFA
xQydTOatMcJN/vpUUfnGiAoni+A2hVXc9Yb5ATnoWhcK9a4FOddMBmE8SbNnY+o/
UMdJxiPOeUXC969hv/0mcHH3sS+owCbipKvhQOlmmXvX1aXORmin7dP9kUkU/OC2
dtlNrhFABuN1otfCaGJ9gFkfdAcpv3Jzcal/MftGYf/tTCx9zJmejPsTixFJY1YS
hgLdlxS/NrK4FHWTOlItTwJMFNM6NPq+DPgom6ANzsbqYpk9NvUOBQx+onWkKSNQ
MWwkD1T4EEq90qfnLKPZzIUgx+7UD+vhNPRxWtm5RoVTqZMAkONhVhf0CvBM3xLK
6htYjQHN7e+7AFCtqrWs1w1Q2lawZDndsGvkzKCVw9V7S3GBhYf+BL96GEzx6NEY
LO+UScD5NwoiyN/v5P70xFIIIzoyYLXDglq25EDOvm+PhYA9BTyiYqh7Z8kYlwBU
Ke8Z8Hrhx5hFMzSsNnxDLlhT9eMzsrsAxJkyfCOojMIrgYxtYkiEB68rHBIoaPdW
9UhGpOtn3X4IMmoWkubBed3jJY4rFGOZDMz4X4btFAZlE7GUt7QvUyZLKC5DS6co
8DG87xVtrO0PHsSBUzQkAMJ3v87gCzbimbWfj3U1qy/PE8zIdc51gRnJQkLNvGTY
UrILm4Mm9PFCvFWwJi7T
=QxKG
-----END PGP SIGNATURE-----
--Apple-Mail=_C8F66C48-F315-4C37-801A-571BC15447CA--
- Raw text -