gEDA-dev: gschem modifications

[Stuart Brorson]

A couple more thoughts about the component database manager:

*  Please write it using *only* vanilla GTK 2.4, say (or whatever is
required for gschem).  One of the  biggest problems we face when
supporting gEDA is the problem of external dependencies.  Even the
common WxGTK GUI set has caused problems for a number of users,
despite the fact that though my poor, feeble installer tries to
install it for you.  

Any time you need another .so to build something, you end up causing
some subset of users a real PITA since they can't -- for whatever
obscure reason -- get things configured correctly to build.
Therefore, it's best to write your app with a minimal dependency
footprint, no matter how many nifty widgets are offered by the latest
version of GTK or whatever.  Please use what's already required for
gEDA rather than enlarging the number of dependencies. 

By the way, this is not an invitation to explain why your favorite
package installer will magically fix the dependency problem.  Please
keep in mind that most newbies aren't ready for using yum, apt-get, or
whatever.  Unless, of course, you are volunteering to use it to build
a gEDA Suite CD which will supersceed the simple, build-from-source
one we already have.     

*  Please don't make any changes which would prohibit gschem -- or
anything else -- from running and working without the database
manager.  Since many users won't want to deal with installing and
maintaining a database like MySQL or PostGRES, they won't want to be
locked out of using gEDA if they don't want to have the database
running.  Also, the more I think about it, the more uncertain I am
that I would want the Install CD to deal with configuring somebody's
database.  Therefore, the Installer may just build the database
manager, and force the user to do the config.  Or I may make the
Installer not build gmanager (or whatever its ultimately called) at
all to prevent user problems.

In any event, please keep in mind that many users won't want to deal
with a database, and will probably continue to get their parts from
the symbol libs and annotate them by hand (or using gattrib).

*  If possible, it would be nice if any component database manager
could interface to two types of component libraries:  1.  a text based
one similar to the one we already have, and 2.  a client/server
database system.  This might obviate the point I made above.

I don't mean to sound too tart w.r.t. the dependency issue, so I
apologize in advance if I sound that way.  But this is a significant
issue for both newbies -- who find all kinds of ways to misconfigure
their systems so nothing builds or works -- as well as oldbies like
me -- whose systems have lots of strange cruft hanging around which
sometimes causes unexpected build problems.

Cheers,

Stuart