Kuba,
> Also, the interface makes some custom choices that make it next to useless
> without
> a three button mouse. Forget using Xcircuit with a trackpad, so far. This
> will have
> to get reworked so that more common man-machine interaction ways are used. A
> good
> assumption is that of a two-button mouse with only left button available
> while dragging.
> This assumption would make Xcircuit work with trackpads on all platforms
> (including MacBooks, a machine I'm on).
I have handled this largely as a matter of key and button bindings. I have
always used 3-button mice and am annoyed with the fact that it is difficult
to get them anymore. Honestly, do people think it's that hard to figure out
how to move three fingers independently? Anyway, invoking xcircuit with
"xcircuit -2" is more compatible with a standard 2-button mouse. Most
functions associated with the middle mouse button are moved to the right
button, and functions associated with the right button are moved to the
escape key.
Personally, I don't even like the "common man-machine interaction" methods,
most of which seems to involve kowtowing to whatever Microsoft implemented
(or Cadence, in the EDA world, which is much, much worse). What I do like
is a key and button binding mechanism that is flexible enough that you can
define whatever method suits you.
XCircuit's interface is largely derived from the "chipmunk" tools "analog"
and "diglog". In my opinion, "analog" was one of the best circuit
simulators ever written, and if there was one program in the world I'd
like to see updated and modernized, that's the one. If you think
xcircuit's code is a mess to look at, you should see "analog"---C code
that was generated by stuffing Pascal through a Pascal-to-C translator.
I shiver every time I look at it.
> At least so far I've shrunk it from 94k lines of C to 32k sloc of C++ and 38k
> sloc of C. The part
> still in C is asg and spiceparser; those will shed a lot of weight by porting
> to C++ but
> that's not for now. I'd hope to keep a shiny, bug-free Xcircuit around 15k
> sloc when all is
> said and done, with perhaps another 10k for asg and spice parser. ASG code
> looks like
> it could be significantly trimmed by doing a proper port to C++, but that'd
> be more of a rewrite,
> really, and I'm not interested in it right now. I'd also have to dig out the
> papers that describe
> how it works.
The ASG code was a nice idea, but there never has been a working version
of it. I spent some time trying to make it compatible with xcircuit,
but it was based on its own fixed integer grid; I rewrote it to make
the coordinate system compatible with xcircuit, and it would just
segfault for reasons that I could not discern. It would be nice to
be able to import netlists and draw them into reasonably readable
schematics, but good luck finding somebody to tackle it. Without the
ASG capability, the spiceparser code is useless, so you're better off
just discarding both (until such time you find somebody willing to
rewrite the SPAR algorithm).
---Tim
+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim) | email: [email protected] |
| Open Circuit Design, Inc. | web: http://opencircuitdesign.com |
| 22815 Timber Creek Lane | phone: (301) 528-5030 |
| Clarksburg, MD 20871-4001 | cell: (240) 401-0616 |
+--------------------------------+-------------------------------------+
_______________________________________________
Xcircuit-dev mailing list
[email protected]
http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
