On Sep 24, 2010, at 11:55 AM, Chris Albertson wrote: > I hate to say it but very few users care at all the which widget set > the software uses or what it is written it.
Sigh. Qt is an application development framework. The widgets represent a small fraction of Qt's codebase. I'd bet less than 25%, and it gets less and less over time. That's the key word here: framework. It does things you typically need to do when doing any sort of a modern application, in a portable way. Qt's Core module is used for non-GUI application development. From what I recall, a large credit card processing system runs on Qt's Core module, heck -- it predated modularization of Qt into Core/Gui/... modules. It is really trivial to write a simple network server in Qt -- with threads and everything. Portably. Yes, it will run just fine without an X11 DISPLAY. And I do mean it gets rids of lots upon lots of menial code. Here are several cases in point: - image loading: your code only uses QImage, then Qt handles interfacing with whatever image format libraries are out there, it's all out of your way -- how many times do people have to add libjpeg to a build script anyway - directory/path/file access: all done portably, all of platform intricacies are hidden away; no more windows/unix defines in your code; even the OS X/windows/unix newline fiasco is handled transparently for text files - basic 2D computational geometry: how many times do we need to reimplement a bounding box for a 2D polygon, or extracting glyph shape from a Type1/truetype/... font, or handling transformation matrices? - collections: Qt had a stable set of collection classes before the C++ compilers got to a point where STL reliably worked across the board - threading, process management, networking: imagine spawning a child process, or opening a TCP or UDP connection without a single #ifdef in sight, and it works everywhere Qt runs! - internationalization/translations -- Linguist is a free graphical translation tool so that your translators don't need to know anything about programming - string handling: QString does everything you need -- including transcoding between different 8 bit representations (a.k.a. code pages or encodings) - XML parsing/DOM - ECMAscript scripting -- including an embedded IDE with code editor and debugger - multiscreen support -- you can easily have multiple views or even one large schematic view spanning monitors, with trivial amount of code (Qt gives you portable screen lists). You get access to all that simply by linking with Qt, and most of those features can be used in just a few lines of code. The users will care about it, since it will be easy for developers to add new features. If it takes little code to add significant functionality, users will be happy, the pace of development will speed up, ... -- all good things. The biggest deal is that Nokia has way more resources to tweak their code, and they now have a rather robust performance testing framework that weeds out performance regressions. So it is true that xcircuit already has Bezier strokers and bounding boxes and all that implemented. But it's hard to expect us to have resources to tweak all that till world's end, especially as sizes of the designs done in XCircuit will grow. In the meantime, trolls (Qt developers) are doing just that. They have a team keeping it well performing, including on embedded devices with 400MHz clocks and the like. So yes, Qt can bring XCircuit back to working on a reused Pentium II system running not much more than a Linux kernel (without an X server!), if someone wanted to set it up so. This is to preempt the interjection I'm imagining: but but but I can still run Xcircuit on my ages-old Pentium laptop with 800x600 X display running 2.2 kernel. With Qt, you may just be able to do so, while offering a modern feature set to boost. Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
