On Sep 24, 2010, at 9:48 AM, Lewske Wada wrote: > Kuba Ober wrote : >> xcircuit was written in C. The language is inherently less expressive >> than C++, and >> even more so compared to C++ with a introspecting preprocessor (moc). Moc -- >> meta object compiler -- >> reads the C++ headers of classes deriving from QObject in your project, and >> generates static classes >> that document the signals and slots QObjects. > > Are you actually rewriting the all in C++, or just leaving the core as is > and making up the interface to Qt using C++?
Both. First I have to get it up and running using the Qt gui, ensure it won't use any Unix/Posix APIs for file access, process management, etc. That way it will work on Windows and elsewhere, while still using the C core merely compiled using a C++ compiler. I have already renamed all .c files to .cpp (with exception of some external libraries) -- this had to be done since right now xcWidget and similar types are all C++ class pointers, so the code that depends on those wouldn't really work as I don't want them to be opaque. Then I hope to do a public alpha release -- something that'd preserve the functionality of 3.6/3.7 compiled without Tcl/Tk. Maybe. We'll see how the code comes along. Maybe I will go straight to C++ porting. I don't have a clear feel here. There will come time to port pretty much everything else to C++/Qt. Examples: - circuit elements (in file elements.c) will be C++ classes that can serialize/deserialize to a QDataStream for binary or postscript storage/retrieval - bbox and transformations will be had by inheriting QGraphicsItem -- this way the elements can be trivially made interactive, too - stringelements can be repaced by Qt's rich text api, that way a lot of menial code can be culled - state machines (QStateMachine) will be used to describe user interface behavior - C++/Qt collections will be used in place of naked C -- say QLinkedList is a no-cost C++ doubly linked list - Qt's font system can be used to obtain paths (strokes) for arbitrary glyphs in a platform-independent manner, thus local system fonts can be easily converted to XCircuit fonts - QPainterPath can be used to deal with 2D computational geometry -- this takes care of all of the primitive stroking code, queries (intersections, clipping), fill polygons at given resolution, etc. Again, lots of code would vanish from XCircuit. I believe that QGraphicsItem/QGraphicsScene is a nice abstraction for items that can be potentially manipulated by the end user. At that point adding basic javascript scripting using webkit's engine (bundled with Qt) is a few hundred lines of code exposing the scene items, since everything else is already provided for by Qt scripting engine. That includes a built-in IDE with code editor and debugger! That's the power of Qt. Adding python, without a debug GUI, is a similar endeavor, using pythonqt. Both can be available at the same time with no performance hit. I might be wrong, by my goal is to show that by using a high level application framework we can save lots of development effort. And by lots I mean this: when I'm done doing the full Qt port (GUI+architecture), the code will have less than 40% of original size, measured by sloccount <http://www.dwheeler.com/sloccount/>. Obviously I won't know how accurate my prediction is before I'm done. To be fair, I'd do the comparison with all the tcl/tk and win32 bits removed before taking the reference SLOC, as that's really dead code -- I'm porting from Xt, after all. Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
