Re: gEDA: Comments request

[Werner Hoch <werner_dot_ho-at-NOSPAMgmx_dot_de>]

Hi all,

On Sunday 23 October 2005 12:57, Carlos Nieves Ónega wrote:
>   - Noweb: I don't know anyone who has benefit of using it. If we
> want to change to plain C files, we should convert all noweb comments
> into doxygen (or whatever) comments. I think doxygen will improve
> code documentation too. Is anyone still using noweb? who wants to
> drop noweb? Any volunteers to do the work?

Dropping noweb would be a good idea. 

doxygen would be useful for libgeda. 
Is there a benefit for gschem and gnetlist to have doxygen?

>   - OK/cancel buttons: current GTK and Gnome widgets use to have the
> cancel button on the left, and the ok button on the right.  Gschem
> have them reversed. Recently I implemented the file load/save in
> gschem using the GTK widget, so there's now an inconsistency within
> gschem. To be consistent with all the other apps and Gtk widgets,
> gschem should change the ok/cancel buttons to cancel/ok . Of course,
> using #ifdefs so a virtual windows port will have them like all other
> windows apps: ok/cancel. I don't know people reaction to this change.
> Comments?

I don't really care about the position. 

>   - Unsaved schematics warning when exiting: I always have to read
> the text to know what button I should click on. I think it can be
> improved with Discard/Save/Cancel buttons, and a text explaining the
> situation. 

I have to read the text, too. 

> Since gschem has to deal with multiple pages, there are 
> two
> possibilities: one is to ask opening such a window for every page (I
> don't like it this way), and the other is to put a list of unsaved
> schematics in the window, with a checkbox so the user can choose what
> schematics should be saved. The latter is currently implemented in
> gedit, so maybe you could take a look at it and tell us if you like
> it or not.

I like the possibility with checkbuttons. Maybe I've seen that on 
quanta.

>   - Heavy/light symbols: I don't want to start another never-ending
> discussion on this, so please be kind with your answers and respect
> other people's opinion. For example, I'd like to have only one symbol
> for all NPN transistors. This would be a generic transistor symbol.
> All the real transistor's symbols will use this symbol, and change
> only some properties (pin number ordering, part-number... and even
> footprint, or possible footprints, if we have some standard footprint
> library some day), using attribute inheritance. This situation will
> have the following benefit: I can use a generic transistor when
> drawing the schematic. Later, I choose one real transistor suitable
> for the application, so I have to replace the generic transistor by
> the new one. Using the scheme described, both gattrib or gschem can
> do the replacement: they only have to check if the replacement and
> the generic transistor have the same symbol, and update the
> properties. This scheme will let heavy and light coexist. I know
> there are some different symbols for transistors (npn-1, npn-2, and
> npn-3). People use the one they like more. Using the above scheme,
> the real transistors can use a npn.sym symbol, which can be a link
> (maybe user defined) to one of the available possibilities.

Inheritance is a good idea. How would you implement the pinseq to 
pinnumber assignment?

There would be the following structure:

The device that contains:
  * the generic symbol
  * slotting attributes?
  * optional change of the pin-to-package mapping
  * (add the pin to model mappeing description)
  * adds attributes

>   - Attributes for packaging/automated refdes assignation: currently
> if you want to use an heterogeneus part, you have to assign the same
> refdes to the symbols by hand. I'd prefer to assing some attribute
> which tells gschem/gannotate that those symbols should be in the same
> physical part, and if there can be another symbols automatically
> packaged into that part or not (maybe another attribute). It's like a
> "part set": if two symbols have the same part set, they should have
> the same refdes. Maybe this "part set" attribute can be like a
> description (I won't like it to be just a number, since I want to
> reuse a schematic across projects, and I don't want to track the
> numbers myself) added by the user, and the annotation utility should
> be aware of these special ones.

Sound good and hard to code ;-).

Regards
Werner