[Xcircuit-dev] XCircuit and GTK

[R. T. E. <ti...@st...>]

Dear Jeremy,

> Date: Sat, 12 Jan 2002 22:03:23 -0500 (EST)
> From: Jeremy T Braun <jt...@MI...>
> Subject: Gtk and XCircuit...
> To: ti...@ba...
> 
> a while ago I wrote to you about adding (converting?) xcircuit to Gtk
> instead of Xw..
> 
> I've got a fair amount of free time for the rest of january with nothing
> in site to do, so I was wondering if you're still interested in this? (as
> I recall, you weren't sure at the time).
> 
> Thoughts?
> Jeremy

   I have just written a little manifesto for xcircuit, magic, PCB, gEDA,
etc., outlining how they can all fit into the "ScriptEDA" idea
(http://www-cad.eecs.berkeley.edu/~pinhong/scriptEDA).  Read the two papers
from that site first, then read my "manifesto" (which will have to be
tomorrow, because I forgot to upload it yesterday).  In part of the
manifesto, I'm more or less committing myself to allow xcircuit to either
run its own GUI, or relinquish its GUI to a controlling interpreter.
This is going to require that xcircuit's GUI be carefully extracted from
the rest of the program.  Then, implementing another GUI should be
relatively painless.  The question is, is it worth doing a new GUI in
Gtk, or is it better to start building the GUI in Python or Tcl, with
direct calls to Tkinter or Tk?  The first thing to do is to identify
all of the callback functions used by the GUI, and to shred apart the
xcircuit main() routine and put it back together so that it doesn't
directly create any widgits itself.  Then all of the GUI routines that
I wrote myself, like the menu building routine "makesubmenu" and such,
need to be placed in a separate source file, so they can be ignored when
warranted.  Most of this stuff is in "xcircuit.c", but bits and pieces
have ended up spread out all over the source code (for instance, there's
a single call in files.c to XwTextCopyBuffer(), which gets the contents
of the selection buffer, but really ought to call an intermediate routine
which hides the fact that the selection buffer capture is part of the
Xw widget set).  Another problem is that many of the Xw widgets are kept
as global variables.  The main offenders are sitting in xcircuit.c, lines
112 and 114.

   The main problem I see is that I don't know how compatible Gtk is with
Xt---I make a lot of low-level Xt calls, and those will be MUCH harder
to pull out of the code (do "grep Xt *.c" on the source directory and see
what I mean).  That being said, I also admit that the selfsame routines
are the cause of much pain and suffering.  For instance, the timer
functions, implemented with XtAppAddTimeOut(), interact VERY POORLY (to
say the least) with some systems, apparently a window manager problem.
The WM gets the xcircuit timeout confused with the screensaver timeout,
causing the whole screen to go blank when a button is pressed and
occasionally causing server lockup.  But that might not be a good
example, because it could be replaced with the OS signal timer and
bypass the X server altogether.

   Anyway, if that discussion hasn't put you off the idea of rewriting
the XCircuit GUI, then we should start putting together something of an
API which would give some kind of framework for making the core of
xcircuit GUI-independent, then we can divide up the tasks that need to
be done.

   I'm going to CC this email to the xcircuit-dev mailing list, because
it is definitely more than a one-person job (else I would have done it
myself by now), and it is likely more than a two-person job (any other
takers?).  By the way, as mentioned above, I will try to remember to
upload my "ScriptEDA manifesto" tonight, and I will also post that to
all the appropriate mailing lists (gEDA, magic-dev, and xcircuit-dev).

   As I have mentioned to others, but I don't know if it's widely known,
starting next week I will be working Thursdays and Fridays from home,
doing exclusively EDA programming and development related to ScriptEDA.
I'm doing this as an employee of MultiGiG, Ltd., Wellingborough, England,
but they are committed to the idea of "open source", so everything I do
will be under GPL copyright (except for a few minor things related to
their IP about fast clocking structures in VLSI hardware).  My goal this
time is to get essentially everybody who is doing any open-source EDA
tool development on the same project without trying to restrict or
redefine the development direction of any individual project (that is
to say, without offending anybody).  I was quite successful at pulling
together the "magic development team" from disparate parts, and perhaps
I have just become cocky, but I want to attempt the same thing on a
grander scale.

						Regards,
						Tim