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
