> Heavy/light symbols
If you want to display correct pin numbers you need to specify a
package type for some symbols. For example: the LM326-2.5 reference
has two packages --- DIP8 and TO-92 with the following pin
numbers:
Pin Numbers
TO-92 DIP8
Anode 1 4
Cathode 2 8
Adj 3 5
Sometimes it useful to have different sizes of the same symbol. If I
have a schematic containing an LED driver connected to 16 LEDs I would
use a small LED symbol to improve schematic readability. If a
component needs many decoupling capacitors at specific pins (Chipcon
radios) it is useful to use a small capacitor symbol.
Scalable symbols would be nice. Currently I use names like LED.sym,
LED-small.sym, CAP.sym, CAP-small.sym which works fine.
> Autosaving
This sounds like a good idea.
> Noweb
I have found that the CWEB literate programming tool engenders
better documentation. As you write the narrative explaining
each code section you discover improvements. Being able to TeX
and friends in code documentation is also nice.
(* jcl *)
On 10/23/05, Carlos Nieves Ónega <[EMAIL PROTECTED]> wrote:
> Hi all,
> I was talking with Ales yesterday. We want to share some ideas with you
> and get people's thoughts. So please, post your opinion!
>
> - 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?
>
> - 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?
>
> - 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.
> 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.
>
> - 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.
>
> - Heterogeneus parts: this is the hardest thing to code. Using the
> symbol inheritance, we can define a per-slot symbol. The idea is that
> gschem be aware of parts, and part slotting, keeping track of what slots
> are currently used/unused, and changing the symbol if needed when you
> change the slot attribute. I know heterogeneus parts can be used now,
> assigning the same refdes to two different symbols, but I'd like a more
> automated way.
>
> - 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.
>
> - Autosaving: having gschem automatically save every unsaved schematic
> every few minutes (user-defined). gschem can use another filename, like
> #real_name.sch#, like emacs, or real_name.sch~.... These files should be
> deleted when saving the page.
>
> - Autosaving when crashing: I know gschem shouldn't crash but, what if
> it happens some day?. What about automatically saving the schematics
> when crashing? I mean connecting the segfault signal to a function which
> saves the unsaved schematics using filenames like
> #real_name.sch.crashed#, real_name.sch.crashed, (depending on the
> filename chosed for the last point). Gschem should look for these kind
> of files when loading an schematic, and let's the user choose if he
> wants to load this file instead of the normal one.
>
> Cheers,
>
> Carlos
>
>
--
http://www.luciani.org
