kicad-developers team mailing list archive

["Tim Hanson" <tim@...>]

Hi Dick,

Yes, I have been worried about the fact that this may piss a number of
people off. The changes are very significant -- I've modified at
least half of the files in eeschema/. A branch seems like a very
reasonable way to handle this design change, and integrate changes as
I get feedback. I will investigate it, but, of course, I hope that it
will ultimately be used in the distribution, especially given all the
work I've put into it! I'll just keep modifying my branch until there
is overbearing reason to use it (like import gEDA files..)

Concerning 'maintaining' a schematic, that still, to me, seems like
the 'wrong' way to do things. I'm a firm believer that once coded, a
clear, efficient algorithm integrated at the correct place will save
everybody time, and in the process of writing /debugging it, all the
code it touches will be further polished.

As for C/C++, this has left me yearning for a better level.. I have no
problem with C++ used properly, but there /has/ to be a better way to
do this lisp? Ocaml? haskell?

Tim

On Jan 21, 2008 6:00 PM, Dick Hollenbeck <dick@...> wrote:
>
>
>
>
>
>
>
> Tim,
>
> This is a significant design change, and with it you might take home
> some marbles or you might end up on everybody's shit list, depending on
> what it adds and what it breaks. My original thoughts on this I've
> already expressed. I'll briefly restate them here: a feature like this
> could more safely be done by a separate utility which auto generates
> sheets for the stock, unmodified eeschema. The auto generation process
> can be done any way that makes sense, including using a template
> schematic (the one you *maintain* as a circuit designer, and the whole
> point of the discussion is that only one sheet is maintained).
>
> Having said that, there are clearly and certainly other potentially
> excellent paths to the end goal, which stated again is roughly:
> "maintain one sheet, use several sheets like it".
>
> Because your changes are significant, they would require non-trivial
> amounts of time for me to formulate an informed opinion on them.
> Unfortunately I do not want to spend that time now, and it would be
> easier if the code were in a place where we could see it. Maybe you
> could create a branch/tim directory in the svn repository and put your
> changes in there in directories where a person could pull those out and
> have them overwrite the base line working copy. See the subversion
> manual if you have questions. I can envision a partial tree consisting
> of the files that have changed only.
>
> In any case the opinions will eventually roll in, either favorably or
> unfavorably. So you may end up being a hero, I am not saying one way or
> another here. This whole "macro templating" concept can be taken
> further of course, and has been done so in other places in life.
>
>
> > I'm on the gEDA developer list, too, and they do not have this
> > feature; rather than updating the references based in instantiation,
> > they put the path in the netlist. We are, kinda, competing with
> > them.. two free software products still competing! -- this would put
> > us 'ahead' :) (In addition to all the work done on pcbnew.. and the
> > fact we use c++ not vanilla c)
> >
>
> What do we get if we win, or capture the lead? If it was a real
> valuable prize, I might actually begin to feel like I was competing and
> do more. ;-)
>
> Yes, the decision to use C is a curious one. There are folks who
> prefer to program on their hands and knees, or who have never looked up
> off the ground to see what they are doing. And some of those folks will
> tell you they are doing it the "right way", and actually believe it.
> Different strokes....
>
>
> > thanks & sorry about the long email,
> > Tim
> >
> > ps. Dick: I had some look at the visitor design pattern -- it looks
> > cool
>
> It is a "directed visitor design pattern". I have not seen anything
> like it anywhere else. So I am inclined to hereby ordain it the
> "tourist" design pattern, because a tourist vists with a guide, whereas
> what visitor visits is not defined, but in the typicial visitor software
> design pattern it is usually "every destination".
>
> Dick Hollenbeck
> SoftPLC Corporation
> http://softplc.com
>
>
> > and i wanted to try to solve the GetScreen() issue without
> > resorting to a 'virtual BASE_SCREEN*' (as this requires typcasting to
> > any of the derived classes), but, I couldn't come up with any better
> > solutions. :(
> >
> >
>
>