Re: gEDA-user: Parts DB API

[Levente <leventelist@xxxxxxxxx>]

peter@xxxxxxxxxxxxx wrote:

Hi Peter,


I have a few thoughts on this topic, but maybe they are not quite answers to
your questions.

I've been thinking about this topic while I was in Stuttgart in the summer.
What I did is a database structure, and a simple command line application,
that connects to the database, and lets you select a single component. After
that, you must copy paste the footprint, etc... information from the command
line tool, into gschem. This process should be inside gschem.

I wanted to do that, but, to be honest, I have zero knowledge of gschem
internals. I've tried to figure things out, but failed. I think we should have
in rc files specification to database server(s), and a relative simple GUI to
chouse components. You mentioned that you want to have the same UI. I think it
is pretty hard to have the same UI for a file chooser and a DB client. I think
it would be just fine to have another tab in the component selector window
named "part database".

The symbol files should be as light as possible, and we should make them heavy
by adding information coming from the database.

Here is my component chooser:

http://logonex.eu/cgi-bin/viewvc/viewvc.cgi/pskel/

And the database again:

http://logonex.eu/phpmyadmin/index.php

user: guest
no password


Sorry, if I am too boaring... just my EUR 0.02.


Levente


> Hi folks,
> 
> There has been an interesting discussion about parts databases and the
> gschem component library.
> 
> What I would quite like to do is to implement something similar to what
> has been described, especially since I have found a major bug which only
> (yet another) serious component library API change will fix.
> 
> I would very much like some help with the design though, because I'm
> actually not very well at the moment and working on gEDA is quite hard
> going.  Also, I wouldn't like to spend weeks working on something and have
> people turn around and say, "No, that's not what we wanted, it was
> <something entirely different>!"  So I'd very much like you to tell me:
> 
> - What you want the interface in gschem to look like (i.e. sketches, not
> carefully wrought descriptions in elaborate prose).  I would like
> engineers to be presented with the same UI no matter what the backend
> looks like.
> 
> - What you want the API to be able to do (requirements).
> 
> - How you want the API to be implemented.  Loadable modules?  Scheme
> functions?
> 
> However, there are some important caveats:
> 
> - All the current ways of specifying libraries must still be valid
> (although I imagine it would be possible to implement them _via_ a new
> mechanism if necessary).  The old libraries must be accessible through the
> new mechanism in a non-crappy way.
> 
> - Magic needs to be kept to a minimum, as we've too much already in libgeda.
> 
> I'm not going to write a line of code until some specifications are nailed
> down.  Likewise, I'm not going to accept patches which don't come with
> some sort of written explanation as to why it won't need to be rewritten
> in six months' time, and I encourage other maintainers not to either.
> 
> My preference is for most if not all of the system to be implemented in
> Scheme, with libgeda presenting a straightforward API for querying the
> system from C programs.  In fact, I would very much like to see much of
> what comprises the current component library system moved from C code to
> Scheme if possible.
> 
> Finally, although this discussion probably belongs on -dev, I think it
> should stay here because this is where most of the existing debate on the
> subject has taken place.
> 
> I'm here, I'm reading the mail, I'm interested.  You have ideas.  Let's
> write a spec and get it working.
> 
>                                    Peter
> 
> 
> 
> 
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
> 

-- 
Levente
http://web.interware.hu/lekovacs



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user