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:in-reply-to:references:from:date:message-id:subject:to;
	bh=O094Br4Q77pEjjLxaR+K2lfYJPxaYTQA3r3Nrc9Du74=;
	b=k6PH4+wQznW/agCUlv3BMBUmBMaM/YYozdOGZdBab6vTzRnR1YCIKmfIwPR6wO0WMh
	UM0u6BuJ13wI85OUYF2yOaJR1yW8SdmSJjHIFWtc1lpVhhq16LFYuT3+YEepv3XrZK6r
	28kq5vKAL+umGXrfgTNlrhqMESWGejP7kLIZDXsFIiz0GUFfTFjkHQUoaXYwrK6+xeOV
	ziVQfGC5jSKZysr0Hx7eUCLfu4/tXiS1a6zzMHMskJOsNbCaY8gTJvJE1P5Tbz7P2z3B
	DcogMPWUjDUYiENabVOgd1e1uAGLjV0QC1z2oyIna0MCEdCQUUQxCD2pwDUU1m2x5+Ma
	NoHQ==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=O094Br4Q77pEjjLxaR+K2lfYJPxaYTQA3r3Nrc9Du74=;
	b=P5QDGfwbiJ1iflm0bmC85zLRV+ZF1Pa9ee2JgI62vJHMBaow3JlNiSHef80wEhSQNy
	1Ab4vgMyX/gcMH71oS9ZUW5zGsE4QH5EBD523KP7loq+03XVoeeR6qSzUzuEAclXWSHH
	wPF2UmOiHqq4PS7bVUAiF6ZpQiN39TiJPdspOmOYoiAfn4YM0yKTqNvy2GE+0bWI2Gdb
	gOtg/vjNkuRb4gC/YzuWJLegAI6tuHUkR6V1sCL+3t+t871S4nuq/WNlAyDtoJzx1mOE
	27Xj1Zb4scihrgRtOVXMAxoupNJnThz+wjTTUGJ84aZWOh6KFTggg3SjzUNbc6houzRN
	ODAw==
X-Gm-Message-State:	ALyK8tJTlieXJOpSo+cbLbRnNwY7e8XcRwh6AYNk23DimaDDp4GuD3wtmwfnBj4ZCTkZnqsDVwn/n6Vn8SaPNg==
X-Received:	by 10.31.177.139 with SMTP id a133mr9429943vkf.151.1467799703296;
	Wed, 06 Jul 2016 03:08:23 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<alpine.DEB.2.00.1607060818160.7286@igor2priv>
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1607060818160 DOT 7286 AT igor2priv>
From:	"Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date:	Wed, 6 Jul 2016 12:08:22 +0200
Message-ID:	<CADL2oCXeyjZQ_+UffnzGOkcJgV=5O6ZaoLmYXPCqK3MfwAUoNQ@mail.gmail.com>
Subject:	Re: [geda-user] RFC: project files (pcb-rnd) and multiple pcbs (tabs)
To:	geda-user AT delorie DOT com
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

--001a1142fc0eea9f6e0536f4bfd0
Content-Type: text/plain; charset=UTF-8

Regarding project files it is very useful if information from which files
input for this pcb file came. It might be: *.sch, netlist or other. I guess
*.sch file override information forn netlist then used.

The information is useful both for update and for doucmentation like
generating a silkscreen stamp with file names used to produce it. Without
information from which file information came this have to be done manually.


Nicklas Karlsson


2016-07-06 9:02 GMT+02:00 <gedau AT igor2 DOT repo DOT hu>:

> Hi all,
>
> there's a flamewar-triggering topic: project files. I am trying to make
> non-intrusive, optional project files for pcb-rnd. I'm interested in geda
> user's feedback on my plans. As always, I am determined to carry this out,
> so it's not just yet-another-bike-shedding-thread: whether the thread
> yields useful comments or not, code will be written, and project file
> support will exist (... as it already did for ages, see later). So please
> try to be constructive to make the result better!
>
> As usual: nothing proposed for mainline pcb, geda, gaf, gschem. I am
> interested in pcb.geda/gaf/gschem user opinions to integrate them in the
> pcb-rnd, gsch2pcb-rnd and cschem toolset.
>
> ***
>
> First, how project files can be done without turning them into an Evil
> Tool Of Integration:
>
> A project file is a collection of settings and file names (paths) and
> metadata. It tries to fully or partially describe a project. It binds
> things in one direction: describes what the project consists of, but does
> not tie a given source (pcb, sch, etc) to a single project. In other words,
> it is for remembering how a project can be put together, but it does not
> affect the independency of each source file. Source files can be referenced
> from multiple projects. There can be source files never referenced from any
> project.
>
> A project file is totally optional: if an user feels the need to have a
> project file, he can have one; other users can use the same source files
> manually, totally ignoring any existing project file and complex projects
> can exist without project files.
>
> A project file can be partial: it's a collection of optional extra
> settings/info. When a project file is passed to a tool, any setting that is
> not specified to the tool (e.g. on command line) can be loaded from the
> project file. E.g. it's normal to use a project file to only specify
> library paths and leave input/output file names to a Makefile.
>
> Multiple tools can understand the same project file, but not all tools
> must understand it. Pro: the same settings (e.g. library search path for
> pcb and gsch2pcb) don't need to be specified/maintained in different files
> in parallel. Con: it's obviously impossible to get all existing tools to
> learn a single configuration language. It's not the goal either, see
> extraction/conversion later.
>
> Tools dealing with the project file are required to be able to pick out
> the parts they are interested in and leave unknown parts intact even in a
> load-save cycle. This obviously needs some generic container format. (For
> pcb-rnd my choice is lihata.)
>
> For tools that don't implement support for the project file: smallish
> utilities can be provided that extract parts of the project file and
> generate tool-specific rc, config or porject files.
>
> ***
>
> History
>
> The concept is not new. gsch2pcb had optional project files for ages, but
> they were not generic enough, e.g. library search paths had to be specified
> there and then explained to pcb too. The non-intrusive property has been
> there for ages too: gsch2pcb can work with and without project files.
>
> ***
>
> Motivation
>
> I often have small projects with multiple sch and pcb files and custom
> footprint and/or symbol settings. I don't really like that I need to keep
> multiple config files in sync to get tools work together on the project. If
> the same tools understand eachother's file formats, they should also
> understand some common config. If the way of undestanding file formats is
> through external or semi-external tools (e.g. gnetlist, gsch2pcb), perhaps
> the same way should be applied to the project file. As a programer I care
> about such implementation detail, but as an user I don't.
>
> I don't believe "different tools understanding a common standard" means
> "integration" or is evil by default.
>
> ***
>
> Next, what should go in a project file, and this is where I am especially
> interested in feedback. Please remember that any of these are optional and
> may be partial. A valid project file can even omit all of these and be
> empty (with some minimal header).
>
> 1. settings of tools; pcb-rnd already can read a config tree (as role
> CFR_PROJECT) from a project file. In practice this means any pcb-rnd
> configuration can be changed (weakly or strongly) from a project file. A
> common example is prepending or appending library search paths.
>
> 2. lists of files the project consists of; probably list per type, e.g. a
> list of schematics pages, a list of pcb files. Editors speaking the common
> project file language _optionally_ can load a project file, which at least
> means they can open all input files from one of the lists. As an optional
> extra editors can also load config subtrees from the project file (in
> practice: gsch2pcb-rnd and pcb-rnd load the same config tree from the
> project file so footprint library search path can be common).
>
> 3. metadata: project description, copyright, URLs to the VCS, comments,
> etc.
>
>
> ***
>
> PCB-related question: gschem can deal with multiple pages open, pcb and
> pcb-rnd can have only one file open. Is it worth adding "tabs" to pcb-rnd
> and let it open multiple files?
>
> Or is this a viable alternative: a "switch file" menu; when a project is
> loaded, the first pcb file is presented. The "switch file" menu is almost
> the same as the normal load dialog, but it offers only the pcb files
> referenced from the project file. Switching is still the same operation as
> load pcb, so only one pcb open at a time and you have to save before
> switch. This fake multi-pcb setup works only with project files, when a
> .pcb is loaded explicitly, the project is unloaded, "switdch file" is
> disabled.
>
>
> TIA,
>
> Igor2
>
>

--001a1142fc0eea9f6e0536f4bfd0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Regarding project files it is very useful if information f=
rom which files input for this pcb file came. It might be: *.sch, netlist o=
r other. I guess *.sch file override information forn netlist then used.<di=
v><br></div><div>The information is useful both for update and for doucment=
ation like generating a silkscreen stamp with file names used to produce it=
. Without information from which file information came this have to be done=
 manually.<div><br></div><div><div><div><br></div><div>Nicklas Karlsson</di=
v><div><br></div></div></div></div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">2016-07-06 9:02 GMT+02:00  <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:gedau AT igor2 DOT repo DOT hu" target=3D"_blank">gedau AT igor2 DOT repo DOT hu<=
/a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
there&#39;s a flamewar-triggering topic: project files. I am trying to make=
 non-intrusive, optional project files for pcb-rnd. I&#39;m interested in g=
eda user&#39;s feedback on my plans. As always, I am determined to carry th=
is out, so it&#39;s not just yet-another-bike-shedding-thread: whether the =
thread yields useful comments or not, code will be written, and project fil=
e support will exist (... as it already did for ages, see later). So please=
 try to be constructive to make the result better!<br>
<br>
As usual: nothing proposed for mainline pcb, geda, gaf, gschem. I am intere=
sted in pcb.geda/gaf/gschem user opinions to integrate them in the pcb-rnd,=
 gsch2pcb-rnd and cschem toolset.<br>
<br>
***<br>
<br>
First, how project files can be done without turning them into an Evil Tool=
 Of Integration:<br>
<br>
A project file is a collection of settings and file names (paths) and metad=
ata. It tries to fully or partially describe a project. It binds things in =
one direction: describes what the project consists of, but does not tie a g=
iven source (pcb, sch, etc) to a single project. In other words, it is for =
remembering how a project can be put together, but it does not affect the i=
ndependency of each source file. Source files can be referenced from multip=
le projects. There can be source files never referenced from any project.<b=
r>
<br>
A project file is totally optional: if an user feels the need to have a pro=
ject file, he can have one; other users can use the same source files manua=
lly, totally ignoring any existing project file and complex projects can ex=
ist without project files.<br>
<br>
A project file can be partial: it&#39;s a collection of optional extra sett=
ings/info. When a project file is passed to a tool, any setting that is not=
 specified to the tool (e.g. on command line) can be loaded from the projec=
t file. E.g. it&#39;s normal to use a project file to only specify library =
paths and leave input/output file names to a Makefile.<br>
<br>
Multiple tools can understand the same project file, but not all tools must=
 understand it. Pro: the same settings (e.g. library search path for pcb an=
d gsch2pcb) don&#39;t need to be specified/maintained in different files in=
 parallel. Con: it&#39;s obviously impossible to get all existing tools to =
learn a single configuration language. It&#39;s not the goal either, see ex=
traction/conversion later.<br>
<br>
Tools dealing with the project file are required to be able to pick out<br>
the parts they are interested in and leave unknown parts intact even in a<b=
r>
load-save cycle. This obviously needs some generic container format. (For p=
cb-rnd my choice is lihata.)<br>
<br>
For tools that don&#39;t implement support for the project file: smallish u=
tilities can be provided that extract parts of the project file and generat=
e tool-specific rc, config or porject files.<br>
<br>
***<br>
<br>
History<br>
<br>
The concept is not new. gsch2pcb had optional project files for ages, but t=
hey were not generic enough, e.g. library search paths had to be specified =
there and then explained to pcb too. The non-intrusive property has been th=
ere for ages too: gsch2pcb can work with and without project files.<br>
<br>
***<br>
<br>
Motivation<br>
<br>
I often have small projects with multiple sch and pcb files and custom foot=
print and/or symbol settings. I don&#39;t really like that I need to keep m=
ultiple config files in sync to get tools work together on the project. If =
the same tools understand eachother&#39;s file formats, they should also un=
derstand some common config. If the way of undestanding file formats is thr=
ough external or semi-external tools (e.g. gnetlist, gsch2pcb), perhaps the=
 same way should be applied to the project file. As a programer I care abou=
t such implementation detail, but as an user I don&#39;t.<br>
<br>
I don&#39;t believe &quot;different tools understanding a common standard&q=
uot; means &quot;integration&quot; or is evil by default.<br>
<br>
***<br>
<br>
Next, what should go in a project file, and this is where I am especially i=
nterested in feedback. Please remember that any of these are optional and m=
ay be partial. A valid project file can even omit all of these and be empty=
 (with some minimal header).<br>
<br>
1. settings of tools; pcb-rnd already can read a config tree (as role CFR_P=
ROJECT) from a project file. In practice this means any pcb-rnd configurati=
on can be changed (weakly or strongly) from a project file. A common exampl=
e is prepending or appending library search paths.<br>
<br>
2. lists of files the project consists of; probably list per type, e.g. a l=
ist of schematics pages, a list of pcb files. Editors speaking the common p=
roject file language _optionally_ can load a project file, which at least m=
eans they can open all input files from one of the lists. As an optional ex=
tra editors can also load config subtrees from the project file (in practic=
e: gsch2pcb-rnd and pcb-rnd load the same config tree from the project file=
 so footprint library search path can be common).<br>
<br>
3. metadata: project description, copyright, URLs to the VCS, comments, etc=
.<br>
<br>
<br>
***<br>
<br>
PCB-related question: gschem can deal with multiple pages open, pcb and pcb=
-rnd can have only one file open. Is it worth adding &quot;tabs&quot; to pc=
b-rnd and let it open multiple files?<br>
<br>
Or is this a viable alternative: a &quot;switch file&quot; menu; when a pro=
ject is loaded, the first pcb file is presented. The &quot;switch file&quot=
; menu is almost the same as the normal load dialog, but it offers only the=
 pcb files referenced from the project file. Switching is still the same op=
eration as load pcb, so only one pcb open at a time and you have to save be=
fore switch. This fake multi-pcb setup works only with project files, when =
a .pcb is loaded explicitly, the project is unloaded, &quot;switdch file&qu=
ot; is disabled.<br>
<br>
<br>
TIA,<br>
<br>
Igor2<br>
<br>
</blockquote></div><br></div>

--001a1142fc0eea9f6e0536f4bfd0--

- Raw text -