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=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2XrBdiozadYNADQM77C6z7GrC1mnB+TEml8R+hV7Uok=; b=BzOoPK2cJvDmC32Sj7zsK7MijhrfZdH/Yrmk1mXH++P7qWf2Ewc3r0YWjla3gpeIEQ G4MCCiQkXgmctrUudf8R1OR35Y3cYHovy5OARJFzB0C/C+z/Hn7pV0l+oVxoVyxwNAdS 3MNOmZvPAx9wKwDH3sPYbOwioJ340LemrzH+lD15qYfLJ0NjYaO9nLsblwKtGMm3pCHC YJDjcBqtcf33nLRqsklicHfYgdXW6yLNSgN/Pxeq8kHUiJJxWjnqPNOuZ0hJYp/xRbhp dAQGmACvP5Vb2mz9xTmWYfBtt1xlao9o/j/TeN8nfuewn0yUKoOMh2a6QlNI6XZS4wl0 tHoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=2XrBdiozadYNADQM77C6z7GrC1mnB+TEml8R+hV7Uok=; b=amPj/X70mhqh759JH5z4E4d++ko/9YBOZ7kYPIMWTvjMvdjgJlkuFASdnIajw0tn5I xvtdFUJ/QdKTtvVA/vGnZBwdYD2R7MfZw5xsQ8KDbAx3cfbkqxpoB6Qzh3kq5gcrEP0K 1SZNRGb4JKlRBZvS9JLp+T/q+8Cf8bJqVmK7o1kDhijWjMY7jfZJu3WbI4j6zIq5lJCj K2G/MaK9TF3kF8oukPf/NiQa2QFfeZpffD0Ya9xK149lBBhvhWA79czadnnMr4f9kB2f MEEyiZSj9ujWjvH7cyocYTa8zTqXqEIblS6hSEujYQ9SubIEiH6t32SY4BUYhL2gEexr jNnQ== X-Gm-Message-State: AG10YOTalzNNjChK0NUfXcTx7Kh2Q9oIM8DJSjsXtbCgF4YQsCOrj18yIWAmWHSrfM3kMFZgxEvdeJ9NybKkRw== MIME-Version: 1.0 X-Received: by 10.194.19.164 with SMTP id g4mr1437779wje.120.1453097083220; Sun, 17 Jan 2016 22:04:43 -0800 (PST) Date: Sun, 17 Jan 2016 21:04:43 -0900 Message-ID: Subject: [geda-user] WritePCB() dips into Settings in at least one spot... From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=047d7b5d26c27839ff05299587d6 Reply-To: geda-user AT delorie DOT com --047d7b5d26c27839ff05299587d6 Content-Type: text/plain; charset=UTF-8 WritePCB() takes data almost exclusively from PCB, but it calls WritePCBDataHeader() which stores the value of Settings.DrawGrid. That's the only one I found but I didn't look too carefully yet. So either the file format plugin signatures need to change, or this setting needs to get included in PCBType somehow. From what I've seen so far I favor adding references from PCBType. Then we can at least say that PCBType contains a superset of what actually gets saved in pcb files. There's a somewhat related question of how to handle PCBType generally. It's somewhat messy, sort of a dumping ground for globals. There are a few possible ways to deal with it: 1. Clean it up such that it contains only things that correspond to actual pcb files (i.e. what users are editing), not references to the rtree etc. This is the right way in theory and doesn't require changes the compiler wouldn't catch, but it's still likely to be a huge collision-prone pain 2. Make a new type that does correspond 1-to-1 with the (richest data model) format, and fill it in.before any save operation. This would put the mapping between PCBType and the the richest format in one place. 3. Handle the mapping from PCBType to file on a case-by-case basis for each format I had originally intended to do 2. but now I'm faced with it I prefer 3. We don't want lots of synonymous formats anyway (probably just old and prospective new). If synonymous formats are desirable for some purposes (e.g. SQL) they can be produced externally by translation from the default. And for loading other formats (e.g. KiCAD) the parse would likely involve gap-filling missing PCB-specific data anyway, so the generic method in 2 wouldn't work. So at most the logic would ultimately be duplicated in 2 (old + new) or 3 places (3 if Peter does STEP load/save :). Britton --047d7b5d26c27839ff05299587d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

WritePCB() takes data almost exclusive= ly from PCB, but it calls WritePCBDataHeader() which stores the value of Se= ttings.DrawGrid.=C2=A0 That's the only one I found but I didn't loo= k too carefully yet.

So eith= er the file format plugin signatures need to change, or this setting needs = to get included in PCBType somehow.=C2=A0 From what I've seen so far I = favor adding references from PCBType.=C2=A0 Then we can at least say that P= CBType contains a superset of what actually gets saved in pcb files.
<= div style=3D"">
There's a somewhat related que= stion of how to handle PCBType generally.=C2=A0 It's somewhat messy, so= rt of a dumping ground for globals.=C2=A0 There are a few possible ways to = deal with it:


1.=C2=A0 Clean it up such that it contains only things that cor= respond to actual pcb files (i.e. what users are editing), not references t= o the rtree etc.=C2=A0 This is the right way in theory and doesn't requ= ire changes the compiler wouldn't catch, but it's still likely to b= e a huge collision-prone pain

2.=C2=A0 Make a new type that does correspond 1-to-1 with the (richest da= ta model) format, and fill it in.before any save operation.=C2=A0 This woul= d put the mapping between PCBType and the the richest format in one place.<= /div>

3.=C2=A0 Handle the mapping = from PCBType to file on a case-by-case basis for each format


I had originally= intended to do 2. but now I'm faced with it I prefer 3.=C2=A0 We don&#= 39;t want lots of synonymous formats anyway (probably just old and prospect= ive new).=C2=A0 If synonymous formats are desirable for some purposes (e.g.= SQL) they can be produced externally by translation from the default.=C2= =A0 And for loading other formats (e.g. KiCAD) the parse would likely invol= ve gap-filling missing PCB-specific data anyway, so the generic method in 2= wouldn't work.=C2=A0 So at most the logic would ultimately be duplicat= ed in 2 (old + new) or 3 places (3 if Peter does STEP load/save :).

Britton
--047d7b5d26c27839ff05299587d6--