[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: [RFC 2/6] Plugin system



On Sat, 2009-01-17 at 11:21 -0600, John Griessen wrote:
> al davis wrote:
> > On Saturday 17 January 2009, John Griessen wrote:
> >> How about when you create a new project, all plugins
> >> available pop up a dialog so you can enable them for the
> >> project or not, then that configuration is added to the
> >> project dir gafrc file.
> > 
> > To put that in perspective ...
> > 
> > In gnucap, which hasn't had plugins for long, there are 193 
> > plugins available, 70 of which are loaded by default.
> 
> Umm... yeah, even fifteen would become a hassle.
> 
> At the least, I'd like local/project-dir configuration
> to determine which compatible group of plugins is loaded,
> so you can copy a project when you want to start anew one
> and reuse settings/plugins it used.
> 
> So if we eventually get a dialog involved it might just be
> choose one of these standard workflows, and get a set of compatible plugins
> loaded.

That fits with my thinking. I'm not sure if I formally proposed anything
before, but have been thinking about the idea of introducing named
workflows. "geda-pcb" might be one.

There are a lot of features I've been waiting to code, some of which
have had their groundwork started already.. but which could not be
implemented in the core of gschem due to flexibility issues.

Once we have a magic way to say "gschem-pcb" workflow on this project
please, there can start to be more magic happening. I could define that
each component should have a "footprint=..." attribute (either in the
schematic, or in the symbol). I can define how I want to call PCB and
bring up a footprint chooser window when filling that attribute.


I have been getting pretty sick and tired lately of people second
guessing how various geda developers (mostly me and Peter B it would
seem) might be trying to take away flexibility within the tools, whilst
all the time we're actually working very hard to extend the
possibilities available in a way which _doesn't_ harm the flexibility
we're all used to.

It is for this very reason that I'm pretty well put off bringing ideas
to fora like geda-user for discussion. I don't mind some technical
discussion about implementation points, or architectural ideas, but I'm
plain fed up of religion and FUD.


Someone I was chatting briefly off-list rather wisely observed
"Unlimited flexibility is quite limited isn't it?", when I was lamenting
the difficulties of how we could add new behaviours in this flexible
gEDA world.

We are rising to the challenge, and would very much appreciate if people
could refrain from objecting when there is a real example of a problem,
rather than as a knee-jerk reaction to a proposal.

All our code repositories are public, available for testing and scrutiny
well before any code hits git HEAD on gpleda.org. Even if it were to be
the case, "git revert" is a tool we use often upon finding regressions.


-- 
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-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user