| ID: | 5697 |
| From: | Nicklas SB Karlsson <nk...@nksb.eu> |
| Date: | Fri, 17 Jun 2022 10:58:16 +0200 |
| Subject: | Re: [pcb-rnd] RFC: project file considerations |
| in-reply-to: | 5684 from rn...@igor2.repo.hu |
SDNP: Is probably not a good idea but local configuration files may override global from project file if needed might be a good idea. Possibility to see somewhere if values are overridden is probably a very good idea. MDPC: Might be a really good idea if restrictions are added to avoid confusion. Possible to descend hierarchy in schematic but opening new file or at least file not part of the hierarchy all files have to be closed first. Possible to descend hierarchy but open file have to close all currently open schematics so that new schematic is top level is probably the least confusing. If opening schematic possibility to see which project file is automatically loaded ought to be a good idea. MDP1: There is a problem to keep project file in sync if sub schematics in hierarchy is added by a source attribute in the symbol. To put top level schematic file name in project file would however work, possible to either open project file or top level schematic automatically loading project file. MDPP: Adding a top level configuration file referencing configuration files for schematic, pcb and possible others might be a good idea. Nicklas Karlsson Den 2022-06-09 kl. 09:01, skrev rnd2@igor2.repo.hu: > Hi all, > > this is going to be a thread about comments on a very specific set of > proposals being implemented in sch-rnd. I am posting it here because it > will affect Ringdove as a whole, including pcb-rnd later. > > This is NOT a write-only thread: please DO READ ALL MATERIAL BEFORE > REPLYING. Please write only if you first invest the time to really > understand the topic. (If you can't afford the time to read the material, > thats' fine, just don't reply then.) > > I am not interested in generic opinions about project files, I am > interested in comments on details of these specific documents. So please > think in the frame of these documents, using the terminology of these > documents - that's the only way to contribute to them. Starting some > random brainstorming from scratch "because it's related" won't add > anything but noise. > > There are two documents that need review and comments. > > First, this one explains all the different ways we could related to > project files (so it's background theory), within certain > assumptions/limitations explained in the abstract: > > http://repo.hu/cgi-bin/pool.cgi?project=sch-rnd-aux&cmd=show&node=prj_archs > > > Then this one, building on the above, explains the implementation and > practical scenarios I am experimenting with in sch-rnd: > > http://repo.hu/cgi-bin/pool.cgi?project=sch-rnd-aux&cmd=show&node=prj_corners > > > > What I am interested in: > > - if any of these specific ideas would conflict with how you already use > your favorite sch editor (in case you consider switching to sch-rnd) > > - if any of these specific ideas would conflict with how you already use > pcb-rnd (in case later I implemnet the same thing pcb-rnd) > > - if there is any trivial, natural feature/scenario missing from the > current design (prj_corners) that _you_ actually need > > - as always, I am interested in YOUR use cases, not in "whatever you can > imagine" or "something that you don't need but could be useful in general > or for someone else" > > > Best regards, > > Igor2 > > > >
Reply subtree:
5697 Re: [pcb-rnd] RFC: project file considerations from Nicklas SB Karlsson <nk...@nksb.eu>