gEDA-dev: Random comments consolidated

[Ales Hvezda <ahvezda-at-NOSPAMseul_dot_org>]

Ack!  I slip away from the 'net/project for a few days and I come back to
several flame fests.  Gah, can't we all just get along... :)

Some comments in random order.

* I'm obviously way way way swamped by my inbox and you people are not
  helping with all these "discussions"... :-)  I have read all the
  messages and patches people have sent me.

* Tomaz,  Thanks for experiment with cairo and gschem.  Neat experiment.
  And thanks for reporting the results.  I, too, have looked at cairo
  (and other advanced rendering libraries).   Unfortunately, gschem
  isn't anywhere ready to go down that path, mainly due to the rather
  lack luster performance you observed (I've seen similar results; all
  due to how gschem has setup its rendering pipeline-- poorly).  Also,
  I like all the patches you sent in, please don't let any of the harsh
  responses deter you in any way.

* Stuart, cairo is coming as an additional dependency for gtk+ 2.6.x.
  External dependencies are a fact of life.  And you have heard me say 
  this before, my experience (as a developer) has been that they are a
  good thing and overall they (gtk+, guile, glib, etc...) work quite well.

* gEDA/gaf and friends will stay at gtk+ 2.4.x for a while longer.

* Statically linking (particularly with something as complex as gtk+)
  and expecting it to work _reliably_ on a wide range of Linux systems is
  dead in the water.  Klik is a little bit more than just static linking
  and I think it's a neat idea but if this (gEDA klik) is to get anywhere,
  somebody else needs to maintain it.

* Igor2, your chroot distribution is pretty cool.  A little big, but 
  cool never the less.  I bet it could be trimmed down significantly.

* A while ago, I created a "universal" binary distribution of gEDA/gaf
  and it worked on everything from RH 7.3 to current systems.  The last
  attempt measured in at about 10Megs (tar.bz2).  Would this be accepted
  by the community, I'm doubtful.  I don't run foreign binaries on my box
  and I really don't want to encourage/propagate such dangerous behavior.

* If anybody wants to know the *EXACT* and complete set of dependencies
  required to build gEDA/gaf (all the way starting at a basic and ancient
  X11R6 system), just let me know.

* Dan, "maybe send them in private.  I'm not sure what Ales feels about it."
  I'm okay with large attachments, as long as they are somewhat compressed.
  It's nice when attachments make it into the mailing lists archives.

* Bob, I'm not sure how well WINE will perform.  I personally prefer native
  executables, however, I am quite curious to hear well things really
  run under WINE.

* PeterC, as for your refactoring of the libgeda/gschem data structures, 
  I'm all for it, however, there are a couple requirements that must be met
  before I will accept any such patch.  #1  Non-gui programs must be
  able to create a toplevel object and subsequent underlying structures
  without requiring the init of the gui (gtk+) libraries.  gnetlist is a
  prime example of this.  I'm not sure by reading your last few e-mails
  if this requirement is met.

  Also I'm a little concerned by your statement: 

	"... where I can nolonger assume TOPLEVEL->page_current
	     points at the correct page to be working with ... "

  TOPLEVEL->page_current always points to the current page (now).
  We will have to have a discussion via irc to hash out all these changes.
  In the mean-time, please send me a non-ascii art diagram of the changes
  you want to make.  Thank you.
   
  Further more, requirement #2, any code refactor must be coordinated. 
  There are now three developers (Carlos, Patrick, and yourself) who want
  to make non-trivial changes and I want to minimize any toe stepping.
  I haven't decided how I'm going to handle this just yet (funny,
  this has never been a problem in the past, only because the number of
  developers at any one time has been small :).  It all really depends
  on who is ready to go first (_AFTER_ I get a snapshot out the door).

* PeterB, "I am really shocked by how much gschem-specific stuff there
  is in libgeda."  If I was looking at the division between gschem
  and libgeda, I, too, would be quite shocked, but it's all historical.
  libgeda/gschem grew organically and sometimes the wrong fertilizer
  was used.  Feel free to blame me. :)  On the other hand, I'm all for
  refactoring as long as the result is better than the previous and
  works as well as or better than the previous.

* PeterB, I've always been hesitant to emphasis (as the info has already
  been published) on how to build the full mingw version of gEDA/gaf, only
  because that would greatly (and I mean _greatly_) increase the support
  burden the developers are already under.  Also, gschem is not a Windows
  program and I don't want people to download it and then send pointless
  flames (those tend to distract as evident by the past few days) to
  the mailing list.  We can discuss this off list.

								-Ales



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