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: References: From: "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" Date: Wed, 6 Jul 2016 12:08:22 +0200 Message-ID: Subject: Re: [geda-user] RFC: project files (pcb-rnd) and multiple pcbs (tabs) To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=001a1142fc0eea9f6e0536f4bfd0 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 --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 : > 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
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.
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.


Nicklas Karlsson


2016-07-06 9:02 GMT+02:00 <gedau AT igor2 DOT repo DOT hu<= /a>>:
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 g= eda user's feedback on my plans. As always, I am determined to carry th= is 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 fil= e 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 intere= sted 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 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.
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.

A project file can be partial: it'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'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 an= d 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 ex= traction/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 p= cb-rnd my choice is lihata.)

For tools that don'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.

***

History

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.

***

Motivation

I often have small projects with multiple sch and pcb files and custom foot= print and/or symbol settings. I don'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'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't.

I don't believe "different tools understanding a common standard&q= uot; means "integration" or is evil by default.

***

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).

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.

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).

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 pc= b-rnd and let it open multiple files?

Or is this a viable alternative: a "switch file" menu; when a pro= ject 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 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, "switdch file&qu= ot; is disabled.


TIA,

Igor2


--001a1142fc0eea9f6e0536f4bfd0--