On Sat, Jan 17, 2009 at 12:21 PM, Koen Deforche <[email protected]> wrote: > Hey Pau, > > 2009/1/17 Pau Garcia i Quiles <[email protected]>: >> Hello, >> >> Trolltech recently announced Qt and Qt Embedded 4.5 (but not Qt >> Extended) will be available under the LGPL 2.1. What are the chances >> Wt moves from Boost to Qt now that a commercial Qt license is not >> required to develop closed-source applications? > > Besides the great news for Qt (and C++) itself, we have been giving > some thought on how this could affect the way Wt is current organized. > >> I know it's a huge change but here are my 2 cents: >> - Boost is slow > > I do not think switching to Qt would result in any perceivable gains: > the things we use from boost are not in the critical paths (the > critical path being the rendering step). > >> - Boost is huge due to extensive templating (Qt Embedded is smaller in >> that regard) > > That is true but I think it is mostly Boost.Signals that contributes > in this way to the size of Wt (since for every combination of types, > new code is instantiated). But I do not think that warrants going back > to a moc approach, since this is the single most criticized design > feature of Qt, which was very defendible at the time but no longer so > given current state of C++ (and compilers).
To moc or not to moc is not really an issue, IMHO. >> - Qt provides lots of features Boost does not even dream of having > > Now that is true -- Qt is without doubt the single library that would > be the most valuable dependency for having in Wt. Although it cannot > replace Boost.Signals in my opinion, it could possibly replace > anything else that we use of boost, and provide many new features: Why can't Qt signals and slots replace Boost.Signals? IMHO Qt signals are better than Boost signals: they can be queued, introspected, can ignore parameters, etc (see http://web.archive.org/web/20070703100120/http://scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html ) > - raster image paint devices for WPainter, > - QSvgRenderer for rendering an SVG file on a WPaintDevice (and > implicitly converting SVG to VML or canvas) > - more unicode transcoding support besides UTF8, > - database access layer, > - application-level networking protocols (email, ...) > - scripting > > It remains the question whether Wt should make the decision to adopt > Qt, or whether we should wrap selected Qt features as an add-on > library that integrates well with Wt (e.g. for some of the features > mentioned) or whether it presents an opportunity for Wt application > developers to leverage Qt features where needed. I can only talk for me but I would like it better if Wt replaced Boost with Qt. I certainly realize it is a risk for Emweb to depend on Nokia. > And, allthough a LGPL license allows closed source applications, it > does prohibit static linking, which still results in a much larger > flash footprint in embedded systems (since static linking allows the > linker to dismiss unused symbols), and this should be kept in mind as > well. No need for dynamic linking. It is generally agreed the LGPL allows static linking as long as you provide the compiled source (i. e. object files) you would need if you were to re-link your application to a newer version of the LGPL library (Qt, in this case). -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
