Re: gEDA: Pushing downinto schematics

[Vollmer Marius <mvo-at-NOSPAMzagadka_dot_ping_dot_de>]

Hi,

I'm totally new to this list, so please excuse me when I appear pretty
ignorant.

Ales Hvezda <ahvezda@seul.org> writes:

> Several random thoughts on this:
> 
> 
> 	- Two types of "components":  modules (which you cannot go into.
> 	  These are the building blocks) and composites (components which 
> 	  you can go into and see the underlying schematic sheets)  Are there
> 	  any other cases?

I wouldn't call the primitives "modules" as that is a too general
term.  "Primitives" might be better.

Or just make the type of a component more general: each component can
decide on its own what is 'in it'.  A schematic component has another
schematic, a 'primitive' component has source code in some HDL, etc.
This system should be as flexible as possible with as few things
hardcoded into gschem as possible.

Hmm, what about "interfaces".  I think interfaces (description of
ports and generics of a component) should get their own names as well,
like "entities" in VHDL.

> 
> 	- I'm going to migrate to the following scheme: (comments?)
> 
> 	  "projects" each have the following directories in them:
> 
> 		...  sym/  sch/  ...

I don't think that "gschem" should dictate a particular directory
structure.  See below.
 
> 	  The idea to use CVS to manage the checkin and checkout of projects
> 	  needs to be thought about as well.

This would be a very nice feature I think.
 
> 	- The concept of a project/design needs to be clearly defined.  
> 	  I consider a project anything that a design needs (schematics, 
>           symbols, simulation models, netlists etc)...  How all this is 
>  	  organized needs to be thought out and decided upon.   

IMO, a drawing tool (which is what gschem really is) should not impose
its own idea of such important things onto the whole system.

We need something like a `project concept', but all tools of the
design environment should be flexible enough to adapt to a very wide
spread variety of such concepts.  No project concept that you might be
able to come up with will satisfy everybody.  So instead of trying to
make everyone happy we should try to not prevent anybody from making
their-selves happy.

I don't like it at all how COSSAP imposes its directory structure on
me and the traumatic capture program can't even *load* schematics that
are not in a very few, very arbitrary places.

> 	- I been thinking about gschem will deal with multi sheet designs:
> 
> 	 	1) allow the user to edit one sheet at a time 
> 		    (only one schematic sheet in memory at all times)
> 		or 
> 
> 	 	2) Have gschem load up and keep all the schematic sheets
> 	  	   in memory.  
> 
> 	  I like the first scheme since it's simpler and you don't have to 
> 	  worry (too much) about not having the latest schematic on disk.

I think people will like 2) much better (me included) and sooner or
later "gschem" will have to provide this option.  Moreover, going for
2) will have some strong implications for the basic design of gschem,
I think, so you should plan for it early on.
 
> 	- misc behavior:  do push in components display in the current window
> 	  or is a new window opened?

All things that have no clear decision should be left for the user to
decide.  So simply have two commands "push" and "push-other-window",
or similar.

cheers,
 Marius