Hi Peter Clifton, Thank you very much for your reponse to my question on the subject of Attribute API.
I am lumping all the responses I would like to make here, because they are somewhat related to this general subject. On Thu, 08 Nov 2007 04:04:41 -0500, Peter Clifton wrote: >> I'd not considered embedded, but that is a fine idea in general. On the subject of component embedding, here is my humble 2 cents of thought: In small projects, embedding (as defined currently in gEDA) may work well. However, for larger project, IMHO, it may not work well at all. It may not be a fair analogy, but just to illustrate a point: imagine, in a software project, all functions are inline functions, ....., etc. The gEDA gafrc's (component-library ..)s are similar to the <xxxx.h>s, imagine if <xxxx.h>s are not used in a C/C++ project... (continue, by Peter Clifton) >> I'm not sure... I wanted to make some changes anyway, bringing >> net-listing more into libgeda rather than gnetlist. (gnetlist being a >> command line exporter the existing guile backends, + libgeda to do the >> heavy lifting) I hope we all should study the issues of trying to bring "heavy lifting" netlisting feature into libgeda, before doing it. I appreciate your thoughts on this subject. One of the greatest strength of gEDA is its built-in flexibility in accomodating all sorts of diverse problems each netlister has to face. If we are not careful, we might end up limiting gEDA as an excellent EDA tools to support hobbist, students, PCB, SSI, LSI and multimillion transistors VLSI design. I hope I don't sound unappreciative of all the good works and excellent ideas you have contributed for gEDA, my comment here only reflects my humble views on the subjects which might affect gEDA's future. Some of us would be very disappointed if gEDA ends up just like another educational tools only. Best Regards, Paul Tan -----Original Message----- From: Peter Clifton <[EMAIL PROTECTED]> To: geda-dev <[EMAIL PROTECTED]> Sent: Sun, 11 Nov 2007 12:20 pm Subject: gEDA-dev: Notes for the points I wanted to raise at the FreeDog meeting I'm forwarding this here, as its for general consumption. This was basically notes I sent to Peter B on stuff I wanted to bring up at the meeting were I there in person. Steve M, Bernd J, there are some implied / explicit questions regarding your work on gEDA in the text below, regarding where you want to go with it, and whether more could be done to help avoid the various code-bases diverging too much (especially if we're all working towards similar goals). Best wishes, Peter C. -------- Forwarded Message -------- > First of all, please pass on my best wishes to all the gEDA guys you > meet, I'd have like to have gone myself, and will have to try to get out > at some point. > > I guess you'll be wearing different hats when out there, so I think some > sections are in order. You'll be representing CUED's (sometimes limited) > interest in / needs from the project, and both our (sometimes > individual) interests as developers. > > CUED > ==== > > CUED Isn't using gEDA for serious EDA (not yet at least). I've had some > students make nice power converter boards using PCB, and even gEDA + > PCB, however at the point much of the project work is targeted (2nd > year), students are following a multi-disciplinary engineering stream, > and won't necessarily know any more than the basic circuit theory > they've been taught. > > If students at this stage were to be using simulation, it wouldn't be > for intricate analysis of a circuit, it might be to verify their > calculations for a hysteric comparator, trip points etc, and its user > interface should serve to elucidate the ideas of the circuit. Think > gcompris's electric simulation for kiddies > (http://gcompris.net/en-electric), but with opamps! I'm not saying the > students are stupid, but most have almost no practical knowledge of > electronics / EDA tools. > > I think this can be achieved without removing the ability to do more > complex (and manual / scripted, command driven) simulation. One app I'm > often pointed towards, is ktechlab. Its meant mostly for PICs, but has > some simulation support inbuilt. This is just continuous transient > analysis. It is crude, but represents what might be useful for students > at this stage. It would be nice to see this ability in gEDA. More > complex uses would follow on naturally once users have become more > familiar with the the suite. > > Neither of us are working for CUED on gEDA development. I work > demonstrating some labs, in one I've had students using gEDA / PCB to > make boards, and the second year project work, (which CUED did pay us to > hack on gEDA for) has seen very little use. My interests "on behalf of > CUED" mostly relate to my desire to see it used by the students, rather > than some other package I might not like ;) > > > ME > == > > I like gEDA, I think its great.. and selfishly, I want it to continue to > be the de-facto standard for EDA on Linux.. don't want to be using a > non-preferred package on my "non-preferred" operating system. The bigger > the active community (-user and -dev), the more users benefit. > > I enjoy hacking on gEDA. I also use it as an engineer, and it suits my > needs very well. My main goals are to drive it forward to the polished > product it wants to be, where no drawing artifacts are dropped (ever), > and so it feels like the programs are meant to work together on my > desktop. > > My motivators: > Having something to use from my work > Personal satisfaction form hobby coding / problem solving > Positive feedback from the -user / -dev community > Being a part of that community. (friends!) > > Some goals (short term): > A new gEDA into the next stable (long term supported) Ubuntu. > This means 1.2.0 + bug fixes, at the very least. This Ubuntu > has just started its 6 month development -> release cycle. > If a new release could be stabilised, that would also be nice. > Desktop integration shipped (that is menus with icons and MIME > associations for now). Ideally we'll get a better menu top- > level menu category for these sort of programs. > Either way, this MUST work with a composited desktop, meaning > either a back-port of changes to drawing into 1.2.x, or a new > stable 1.4.x release from the development tree. > > Some goals (medium term): > Try out different rendering (cairo, + pango for fonts) > Continue refactoring code to make it more maintainable > GList all linked lists.. this cuts a lot of code out > Polygon (and filled polygon) primitives for better quality > output. > Split up parts library somehow, shipping a core set. > (This is more "I'd like to see" than "I want to do") > > Some goals (long term): > Tighter integration between all the tools > Back-annotation into gschem via a gschem rats-nest + ECO import > of the "truth" from PCB or another program > More file-formats supported for load / save. gEDA should be the > non vendor lock-in option. We should certainly support load / > save of Kicad. Less lock-in should encourage more users to > try gEDA if considering the two packages. > A killer feature might be import / export of some commercial > formats. This requires reverse engineering, and isn't fun. > If we did this, people who'd never consider gEDA either due > to their existing design assets, or that they use commercial > tools would meet us. We might end up being introduced to some > as that program which can import OrCAD, then save to Altium. > > > Some concerns: > If we don't feel as polished, we'll be passed over for others. > If we don't develop more actively, we'll be overtaken by others, > or our various forks. > Forks are bad.. how to drive forwards in the core project? > Can we define what gEDA "is" / "isn't", so that it becomes > clearer what changes are in the right direction? > Steve Meier's fork: > I think there are some nice ideas here. > Does it serve us for this to exist as a separate project? > Can we bring parts of that back into gEDA? > Design?, Implementation? > Would Steve help? > Would Steve switch back to gEDA, or continue with the fork? > Bernd Jendrissek: > If we don't look at his patches, I feel this is rapidly going > to become a fork / unmergable mess like with Patrick B. > When I looked at this before, I wasn't really sure what I > thought. I don't recall much feedback from anyone. > Is there room for all those wanting to develop in radical ways > to continue in the gEDA core? > Is gEDA doing something wrong (or right), causing so many people > to end up forking it? > > YOU > === > > I guess you're the most qualified to discuss this... but I think it > would be good (duh) to bring up the GObject based library you've been > hacking on. To avoid yet another gEDA fork, lets define what the goals > of that (experiment/library) are, that (you / we)'re trying to achieve. > > Lets say it works wonderfully, and the code is beautiful (ignoring > GObject boiler-plate). How do we then take that into gEDA. Would it be > welcome? > > Should we set any voluntary "caps" on development / functionality to > ensure it doesn't evolve into a fork, and instead forces some merging / > contribution back to gEDA? > > I firmly believe that refactoring from A-B is possible. Its lots more > work of course, but avoids the fork switchover. We should aim to keep > the "forked" bit small at any given time, so this can be done in stages. > > Graphical objects, circuit data-structures etc.. can all be done as > separate pieces. The interfaces might be a bit contorted to fit the > existing code, but if we start knowing where to head, this isn't > insurmountable. These kinds of changes will need the support of the gEDA > -dev community, they'll have to agree the direction being taken is a > good one. > > > SUMMARY > ======= > > Long email, lots of different things going on / in our heads. > > I think the most important feedback from the gEDA guys you meet will be, > do they support the direction we're pulling in? Even with every-ones > full support, some of these items will be an up-hill battle requiring a > very significant investment in time. > > I don't want to maintain an EDA suite with a user-base, nor a private > and ever-diverging fork of one. Simply put, I can't devote the time to > this if it's not going to be welcomed. Hard work is OK, but hard work > when it's going to be rejected is no fun. > > I'm not looking for some blanket permission to commit huge changes to > gEDA without the usual testing and review, but if we could consider the > general direction I'd appreciate it. > > A side point... how should we do releases in the mean time if big > changes are being made? > > I was thinking it might be good to do a development release, 1.3.0 for > some testing quite soon (perhaps finishing the backingstore drawing > changes first), then release a 1.4.0 stable version. > > The 1.5.x development series might end up being a long one, and I guess > the option always remains for bug-fix releases on 1.4.x? > > > NB: This email should be enough to keep you busy reading on the > plane ;). Feel free to forward hand copies to the developers... I may > even post it on the -dev list at some point. > > Have fun in the US! > -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev ________________________________________________________________________ Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
