X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h=
	content-transfer-encoding:content-type:date:from:in-reply-to
	:message-id:mime-version:references:subject:to:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm3; bh=qKnS60wEoqC6p99C4MEYhX8sXh8V8
	YI8P/FaPGnXPS4=; b=twPZrJKL62V+cuW+M8MWPSipNl/VaK1ZIkcZBrrw2HZMD
	VNP51a0i+frnrzxVRCprFr7Ye7suiYFl7jO+9FFqm7kCJ62M4oC9dbbpXsrtylpE
	HdBcwBHxaCKV3SrfJe5xH8qbofwg328RnGsQXT2HXPQL1LT03RH/SbpV6Y7guJYF
	UZyJqx57uZxyFvsDj04CzF2dRdySgDRBf87O8PFtnSCLxreY9MX/8mAh78zoZu3G
	VBXD4GKpFnSzMmBTdI5ZILvzfrd3N9tr061DRErPlbJosVGI5vE/LSr3AXjNEmJM
	7sZQRIhaIQWwfFEgHRGgpRQP1GIk1eSRPakDRKTSQ==
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=content-transfer-encoding:content-type
	:date:from:in-reply-to:message-id:mime-version:references
	:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=qKnS60
	wEoqC6p99C4MEYhX8sXh8V8YI8P/FaPGnXPS4=; b=Tgc7ow3yP693jVmXwaRFfZ
	pMxgr8qP8S7JeHiRU4TiAF46rbHyga9EV0MkLhOgsWamkTvP2PrJWjcipPD9SMMI
	BYnY+AdU9L7IUBpilAB7Nu7fO1v3su4vuSv10+I8oAFehbUWnemqFG1IOHMni6zS
	vOC5SY1syc2s7HL6j/NQN0UVvBGmylMJpQrDpgJxzruqT2fVJw5ycVppKe54MpLp
	7bWcnWhtkC441r1YfFQj7C4s95HsGYEbWQB0S7jr7IGsNLA9Wni4ha0HRuHFZY5m
	NjODVHwMyVr9EcSvyiIHQTW5GvRWjzBdNxpydvtZL2fCirhuSMKx/zTPfZBRK4QQ
	==
X-ME-Proxy: <xmx:cSBMWyOcUrw_ZTIjHWX-_IwITvGGZmM2BKiYovzaHm_mbpfrfZ2TYg>
    <xmx:cSBMW-41ktmVZB2b8eJPsyiqa-tnk7O3V3fFX1-b3ZaOVxdAug7alg>
    <xmx:cSBMWw1I4wSKoPa8RD_Rh7P5aVmHkdgzLfj50sqqUvw2I-fnsIVxAA>
    <xmx:cSBMW_ZGFZeTEOMjuBayHv5zyKhP38CFawRcvV1bBuyYF-DBJwztwQ>
    <xmx:cSBMW4DtLAzQD4CTHOrrSzzKqmQ6c3ht8JJTzgkABHU3esJriUGVog>
    <xmx:cSBMW2etsKYJ3FLlHbN-BJ9wdzxaZM0riJfx3-Ev55Dtvg8uYigWlA>
X-ME-Sender: <xms:cSBMW3MRMSArX1u06ZerbbOEidcaCfDjwKLIzeAEy2TpwR65sdy0eg>
Message-Id: <1531715697.1096438.1441803448.4E8C0EE4@webmail.messagingengine.com>
From: "Edward Hennessy (ehennes+oss AT fastmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_153171569710964380"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-957169fa
In-Reply-To: <20180712172330.33B1B8420410@turkos.aspodata.se>
Subject: Re: [geda-user] adventures using arrows (for documentation),
 or cross my lines
Date: Sun, 15 Jul 2018 21:34:57 -0700
References: <20180702125528 DOT D32CF81F76FE AT turkos DOT aspodata DOT se>
 <alpine DOT DEB DOT 2 DOT 20 DOT 1807121541330 DOT 1780 AT nimbus>
 <20180712172330 DOT 33B1B8420410 AT turkos DOT aspodata DOT se>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

This is a multi-part message in MIME format.

--_----------=_153171569710964380
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

On Thu, Jul 12, 2018, at 10:23 AM, karl AT aspodata DOT se wrote:
> I.e. everybody (other than Ed) uses filled paths with a line "width"
> of 0, and they use it for arrow tips.
>=20
> Filled arrow case definitely gain by having width =3D 0 =3D> actual width
> =3D> 0 so that the arrow tip doesn't go too far.
>=20
> I'd like filled paths with width to have a width of 0, and to
> be able to> have round line join style.
>=20
> So we could ask Edward for his opinion. Ed, what is your take
> on this ?
Not sure the width of zero change will impact my CAD library, since my
paths have a width of greater than zero. Users with a path of zero in
their CAD library will have the appearance of their symbols change
(Unless it also switches off the version of the file, as Roland
suggested).
1. Adding a new line type of =E2=80=9CINVISIBLE=E2=80=9D does not change th=
e appearance
   of older files when opened with a new version. A old version opening
   a newer file will encounter an error. The implementation is probably
   the fewest developer hours.
2. Adjusting the line width for a new meaning without switching off the
   file version will change the appearance of older files. Older and
   newer software can load the same files, but the appearance is
   different. This implementation would be about the same developer
   hours as item 1.
3. Adjusting the line width of zero for a new meaning, and switching off
   the file version to keep the appearance the same, would be ok.
   Backwards and forward compatibility would have some idiosyncrasies.
   Not sure how it would work when editing a newer schematic that
   references an older symbol in a CAD library. This implementation
   would require more developer hours.
4. Adding a new object would be the best fix. All older files would keep
   the same appearance. Loading a new file with the new object in an old
   version would result in an error. The show/hide line could be broken
   out into a separate boolean variable, which would be much better
   software design. GUI property inspectors could switch of the object
   type, so a newer version of the software could edit an older file and
   not break compatibility with the an older program loading the file.
   This implementation would require a large number of developer hours.
Other items include:

a. Developer time needs to be taken into account -- We can=E2=80=99t just a=
sk
   them to essentially donate their time. We also need to appreciate
   their time. With contract engineering, if an engineer does not charge
   enough, the customer will not respect their time. They are charging
   zero and getting zero respect. We should find a way to keep
   developers that donate their time.
b. I=E2=80=99ve seen schematics that provide limited harnessing and/or
   mechanical drawings. We should attempt to keep the shapes/objects as
   flexible as possible.
c. Always consider forward and backwards compatibility for the file
   formats -- I know it creates ugly logic. But, I think the
   compatibility is more important than pristine or ideal logic.
d. I think the line width of zero should be deprecated. A user editing a
   schematic on their screen and sees a 72dpi or 100dpi line width is
   expecting something similar on the engineering print. Except, on a
   400 dpi laser printer, the line is almost invisible. It does not
   follow any WYSIWYG doctrine. Could be fixed with adding minimum line
   width to the configuration. So the casual user gets WYSIWYG, but an
   expert can override the setting.
Ed

--_----------=_153171569710964380
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"

<!DOCTYPE html>
<html>
<head>
<title></title>
<style type=3D"text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
</head>
<body><div>On Thu, Jul 12, 2018, at 10:23 AM, <a href=3D"mailto:karl AT aspoda=
ta.se">karl AT aspodata DOT se</a> wrote:<br></div>
<blockquote type=3D"cite"><div>I.e. everybody (other than Ed) uses filled p=
aths with a line "width"<br></div>
<div>of 0, and they use it for arrow tips.<br></div>
<div><br></div>
<div>Filled arrow case definitely gain by having width =3D 0 =3D&gt; actual=
 width =3D<br></div>
<div>0 so that the arrow tip doesn't go too far.<br></div>
<div><br></div>
<div>I'd like filled paths with width to have a width of 0, and to be able =
to<br></div>
<div>have round line join style.<br></div>
<div><br></div>
<div>So we could ask Edward for his opinion. Ed, what is your take on this =
?<br></div>
</blockquote><div><br></div>
<div>Not sure the width of zero change will impact my CAD library, since
 my paths have a width of greater than zero. Users with a path of zero=20
in their CAD library will have the appearance of their symbols change=20
(Unless it also switches off the version of the file, as Roland=20
suggested).<br></div>
<div><br></div>
<div>1. Adding a new line type of =E2=80=9CINVISIBLE=E2=80=9D does not chan=
ge the=20
appearance of older files when opened with a new version. A old version=20
opening a newer file will encounter an error. The implementation is=20
probably the fewest developer hours.<br></div>
<div><br></div>
<div>2. Adjusting the line width for a new meaning without switching off
 the file version will change the appearance of older files. Older and=20
newer software can load the same files, but the appearance is different.
 This implementation would be about the same developer hours as item 1.<br>=
</div>
<div><br></div>
<div>3. Adjusting the line width of zero for a new meaning, and=20
switching off the file version to keep the appearance the same, would be
 ok. Backwards and forward compatibility would have some idiosyncrasies.
 Not sure how it would work when editing a newer schematic that=20
references an older symbol in a CAD library. This implementation would=20
require more developer hours.<br></div>
<div><br></div>
<div>4. Adding a new object would be the best fix. All older files would
 keep the same appearance. Loading a new file with the new object in an=20
old version would result in an error. The show/hide line could be broken
 out into a separate boolean variable, which would be much better=20
software design. GUI property inspectors could switch of the object=20
type, so a newer version of the software could edit an older file and=20
not break compatibility with the an older program loading the file. This
 implementation would require a large number of developer hours.<br></div>
<div><br></div>
<div>Other items include:<br></div>
<div><br></div>
<div>a. Developer time needs to be taken into account -- We can=E2=80=99t j=
ust=20
ask them to essentially donate their time. We also need to appreciate=20
their time. With contract engineering, if an engineer does not charge=20
enough, the customer will not respect their time. They are charging zero
 and getting zero respect. We should find a way to keep developers that=20
donate their time.<br></div>
<div><br></div>
<div>b. I=E2=80=99ve seen schematics that provide limited harnessing and/or=
=20
mechanical drawings. We should attempt to keep the shapes/objects as=20
flexible as possible.<br></div>
<div><br></div>
<div>c. Always consider forward and backwards compatibility for the file
 formats -- I know it creates ugly logic. But, I think the compatibility
 is more important than pristine or ideal logic.<br></div>
<div><br></div>
<div>d. I think the line width of zero should be deprecated. A user=20
editing a schematic on their screen and sees a 72dpi or 100dpi line=20
width is expecting something similar on the engineering print. Except,=20
on a 400 dpi laser printer, the line is almost invisible. It does not=20
follow any WYSIWYG doctrine. Could be fixed with adding minimum line=20
width to the configuration. So the casual user gets WYSIWYG, but an=20
expert can override the setting.<br></div>
<div><br></div>
<div>Ed<br></div>
</body>
</html>

--_----------=_153171569710964380--