> 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.
I agree, just that the chosen defaults are so far from everyday human interface guidelines that it makes it almost useless out of the box without referring to the manual first. That's a big no-no when it comes to basic usability. This is a minor rant as changing the defaults is trivial, but nevertheless it has to be done. People are used to certain ways you interact with a 2D drawing space. I can get Adobe Illustrator, MS Paint, Inkscape, GIMP, even old Protel/Orcad, and be productive within minutes. With Xcircuit -- no way. Xcircuit has other usability shortfalls, namely very poor discoverability and no visualization for core concepts. One of the key strengths of Xcircuit, IMHO, is the easy way of going go into and out of objects, including library objects. You'd wish this was visualized: that when you hover over an object, you'd see that it is an object, see how big it is, see the animated blowup when you click on it, etc. This is pretty basic discoverability by the book. A core concept in a system should not be invisible. Another key strength: the parameter system that saves a lot of repetitive, menial work. All conveniently hidden out of sight. I'm kind of a usability freak, so I'll be putting in some works towards that. >> 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). I agree then. This code goes out of my repository. Good riddance. In any case, a GPL-compliant reimplementation should be white-box without peeking into original code. The available papers are good enough to reimplement when time comes for it. Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
