On Sep 30, 2010, at 9:21 AM, Tim Edwards wrote: >> I've done cleanups and refactoring of color list handling code, >> including color popups/menus. All that now works, and all of the >> related functions fit in a .cpp file 164 lines long. Obviously, >> everything related to twiddling the colormap is gone, with Qt we >> directly use 32 bit RGBA color. > > Yes, it's good to know that all those low-level graphics handling > problems that I had to solve myself fifteen years ago have finally > been incorporated into the graphics libraries where they belong. > The Tcl/Tk version has a decent color popup window from the Tk > library.
Oh, you mean the one that pops up when you click on "add new color". Over time I'll come up with a better thing that also allows you to take colors away, lets you select everything that has given color, etc. But for now it's OK, and yes I'll switch your Xt color question popup with Qt's color picker. > Another thing I had to struggle with fifteen years ago was the > unavailability of rendered fonts. Thus there is a tremendous amount > of code devoted to the vector-drawn fonts that I would hope could be > replaced by a simple call to a font-rendering engine. The fonts are > the only non-WYSIWYG part of the display view. Then I must be utterly confused. From what I understand, the fonts are treated like everything else and they get spit out to PS as stroked outlines? Or do you use default PostScript fonts and show an approximation on the screen? Obviously I haven't looked at the PS Xcircuit produces yet, so I may be just silly. It'd be very easy to go two-way with fonts, where we embed all used fonts in the circuit file, similarly to embedding them in a PDF. In Qt, getting a path for any font glyph is done in a single function call, and the path is a QPainterPath that has got plenty of computational 2D geometry functionality. See <http://doc.trolltech.com/4.6/qpainterpath.html> BTW, Qt 1.42 was released in 1998, and it was quite capable even if it didn't offer all the painter path goodies available today. So while it wouldn't solve your font issue, it was otherwise a far cry from Xt/Tk, even 12 years ago. > Probably the rendering of rotated and scaled images can also be taken > care of easily with Qt. Likewise, I assume that the Qt RGBA color > visual comes with the ability to draw antialiased lines and polygons. :) The Options menu has an Antialias entry since about a week now. It took maybe 15 lines total to add that, including rcfile reading. I'll move all of the code to use XfPoint instead of the integer XPoint, since Qt's painters can draw better using floating point coordinates. To see how it improves things even without antialiasing, see the concentric circles demo: <http://doc.qt.nokia.com/4.6/painting-concentriccircles.html> Then XfPoint will be moved over to QPointF; at that point I can start moving things over to use Qt's transformation primitive: QTransform. It does everything you had wished for in '93 :) <http://doc.trolltech.com/4.7/qtransform.html> Then a bunch of your transform code will be gone, and it'll be time to move to QGraphicsView. > I tried to make an OpenGL version of xcircuit, but OpenGL is horrible > at doing 2-dimensional line drawings. In the end, it was more trouble > than it was worth. Oh yeah, tessellation-by-hand and such. I've seen that code, it is gone now. In all Qt applications, switching to an OpenGL-based paint engine takes a single command line parameter (-graphicssystem opengl), so doing it is free if one wishes so. You just use QPainter (an abstraction similar to that of graphics/device context and operations on it), like you normally would -- presto. Qt includes native, raster and OpenGL painting engines on most platforms. Embedded Qt supports OpenGL ES! Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
