← Back to team overview

kicad-developers team mailing list archive

Re: SWEET: multisheet schematic concerns

 

*i forgot to write this down but the vantage of doing this is that my
pieces circuits will be modularized as parts by is function and i can reuse
them across all my projects and schematics taking vantage all the awesome
sharing capabilities of the new Distributed Library & EESchema Parts List
Design.

-----------------------------------------------------------------------------------------------

*

*...  The way the project management is done right now is a little big
awkward, IMO.  KiCAD seems to want to generate project files and stuff when
I don't want them.  I am also an Altium Designer user, and I find it's
project management functionality to be pretty sensible, for the most part. *

*
Totally agree. I think the way that kicad handle projects needs attention
and I realy looking forward in propose/make some changes in that in the
future in fact i think that i have something written down right now.

-----------------------------------------------------------------------------------------------

*

*If you don't have anything to do for a couple of hours (days?)*

*
Just some hours =) and i will be reading the discussion through these days.

*

*There is no plan to have separate files for each sheet.  The new design
**will be infinitely more modular than the current design and should
**greatly simplify complex hierarchy code and file format compared to what
**we currently have.  The new design will make it possible to support cut
**and paste and indirectly drag and drop.  Individual files do not make
**the schematic structure more modular.  A superior design does.  Once
**this gets implemented (probably not any time soon), I think it will make
**a lot more sense.*

*
I’m hoping so, and already make some sense to me, because of Ryan says “I
am also an Altium Designer user, and I find it's project management
functionality to be pretty sensible, for the most part.“ it seems that all
my sheets aren’t really part of the same schematic, i think that is because
of i can move stuff around and my all dependencies aren't going with them,
it is ease to copy an sch to another and uses it like and block but not to
maintain an rev or such.

-----------------------------------------------------------------------------------------------

*

*When haven't you been able to copy and paste plain text into and from a
**file?  The new file format design should be modular enough (at least
**that was the design intent) that you could cut and paste any object (not
**just  sheets) to and from a schematic.  This way you are free to use any
**plain text sink or source to copy and paste schematic objects not just
**files.  I'm not planning on reopening the schematic file format
**discussion again since I think the current format is pretty well
**defined.  If memory serves (at my age it sometimes doesn't), the
**separate file issue was discussed (see the link in my previous post).
**If someone else wants to reopen the discussion and has the time to own
**the schematic file format document, I will gladly hand it over.**
**… I'm not planning on reopening the schematic file format
**discussion again since I think the current format is pretty well
**defined …*

*
I see you point, but having an part that adds a sheet to the schematic have
the vantage in not modify too much (or even not) the sch format, because
the will be serving as an nice little abstraction for the off sheet
connectors. But i need a couple of days to answer to you if this
functionality will be supported by file format without any mods, i have to
analyse a bit more deep how this works. I also agree that if we have an
file format already ready and strong enough it will be great not having to
modify it.

*

*...If someone else wants to reopen the discussion and has the time to own
**the schematic file format document, I will gladly hand it over.*

*
I realy not the person to have this responsibility right now given my
inexperience.

-----------------------------------------------------------------------------------------------

*

*Then, put the s-expression files, one for each schematic sheet
***optionally* into a zip file along with other sheets, like Java's
***.jar files, where an entire subsystem can be held ready for multiple
**uses, multiple concurrent uses without edits, with each instantiation
**utilizing different parameters, netnames, and reference designators.
**(Currently the bindings are in the schematic files, making them
**useless for more than one project concurrently.)**
**Then you'd have something:**
***exactly* like the email conversation I had with Jean-Pierre and Wayne
**3 days ago.*

*
Making pieces of circuits like an part will strait solve the concurrently
problem once the snippet (let me call that way) would no longer be in the
one schematic but in the part library, like an part
and having this scheme like you are saying with a local instance of the
snippet will give us the ability to change his components (the ones inside
the sheet just added and linked to the higher sheet component) the way that
the current design needs without modify the library (because the component
is linked to a sheet in the same schematic added when instantiating the
part). Good point yours.

Can you post the link to this conversation? Thanks.

-----------------------------------------------------------------------------------------------

*

*There is none.  SWEET only refers to the s-expression grammar used in
**schematic parts.
**This name does not extend up into the new evolving schematic format.
**I don't know that that format has its own name yet.**
**The SWEET parser and formatter are already written, whereas the the
**new schematic format is still evolving, and therefore the time for
**that software development is nearing readiness for coding.*

*
Thank you for clarify.

*

*Well what Element 14 is doing with Eagle, is to use the scripting
**language as a public description of footprints and schematic parts,
**utilizing the concept that if the script is executed, it generates the
**data object.**
**The boundary between data files and executable files is getting blurry
**in that discussion.**
**It is food for thought, and is a possibility.**
**It was this trail that fooled Microsoft into offering executable email
**messages, however.**
**(Of course email messages should be data files, not executable files,
**regardless of what programming language you are talking about.
**Because the main differentiator there is you receive them from unknown
**sources.)*

*
You have come up with a very good question, maybe embedding executable code
in a library that will be shared makes a big security problem, and is not
that i (and maybe we) want to ‘right now’.

-----------------------------------------------------------------------------------------------

Thanks you guys for the answers, i’m not expecting that many in my first
post where, i'm feeling very welcome \o/, and i’m hope not miss something.*

-- 
Felipe

References