[Qt-interest] Suggestions for future Qt versions

[Constantin Makshin]

On Fri, 24 Apr 2009 10:54:35 +0400, Thiago Macieira  
<thiago.macieira at trolltech.com> wrote:
> Constantin Makshin wrote:
>> Suggestion #1
>> -------------
>> Currently on *nix platforms Qt can use zlib version present in the
>> system ("-system-zlib" configuration option), but on Windows it can't
>> because project files don't contain respective settings. Since this is
>> not very convenient to use 2 versions of the same library (one is built
>> into QtCore library and another is in separate DLL), I decided to
>> update Qt project files appropriately.
>>
>> Diff file made against Qt 4.5.1 sources is attached to this message:
>> 1) only Visual C++ compiler is supported;
>> 2) it's assumed that zlib import library has the default name
>> "zlib1.lib".
>
> Hello Constantin
>
> Thanks for the contribution. In order to make your patch acceptable,  
> could you address these issues:
>
>  1) the name zlib1.lib doesn't match what some of the .pro files had
> commented out (libz.lib). Why? When you get the zlib sources and build
> under the default options, without patching, what do you get?
Here is a quote from "win32/DLL_FAQ.txt" file found in zlib source  
package: "ZLIB1.DLL is the official build of zlib as a DLL."
All projects files and makefiles for Windows version of zlib also use this  
name.
And since in MSVC a DLL and its import library [usually] differ in  
extensions only, the LIB file is "zlib1.lib".

>  2) for the patch to be acceptable, it has to address both msvc and  
> mingw.
> It should do win32-msvc* instead of win32. The mingw case (win32-mingw)
> uses probably -lz (for libz.a), but could you find out?
MinGW builds seem to use "libzdll.a" as an import library name.
I couldn't find any Borland C++ project files that build zlib as a dynamic  
library.

So use "-lzdll" for MinGW and "zlib1.lib" for MSVC:
win32-mingw: LIBS += -lzdll
win32-msvc*: LIBS += zlib1.lib

>  3) does the configure.exe accept -system-zlib? If not, it needs to be
> modified (source is in tools/configure) to accept it.
Yes, it does. All I had to modify were these Qt project files.

>> Suggestion #2
>> -------------
>> Both Qt and WebKit have their own implementations of XML, SQLite and
>> SVG. WebKit's JavaScriptCore module also contains PCRE library, which
>> is more or less compatible with Qt's regular expressions. IMHO, such
>> functionality duplication is redundant, so I think it'd be nice to
>> change QWebKit so it'll use functions provided by Qt (QtXml, QtSql and
>> QtSvg modules and QRegExp class).
>
> There's nothing in the QtXml module that WebKit could use. The DOM parser
> and the SAX parser only work for well-formed XML and WebKit has to deal
> with HTML. So WebKit needs its parser anyways.
>
> QtWebKit will offer access to the object tree by the new QWebElement  
> class. Please take a look at current blogs by our developers to see what
> the class will look like. The QDom* classes are inspired by DOM, but
> don't follow it to the letter and even add extensions to it. QtWebKit,
> instead, will offer a much cleaner jQuery-inspired API.
>
> QtSvg also can't be used. The implementation found in Qt is that of SVG
> Tiny 1.2 and we have no plans of going any further. The SVG  
> implementation found in WebKit has full SVG support. And it accounts for
> half of WebKit, whereas QtSvg is the smallest module in Qt.
>
> Finally, SQLite and PCRE: yes, we'd like to make WebKit share the same
> code as Qt. SQLite is a fairly simple case: if it's available in the
> system, it should be used. We can't use the system PCRE because it  
> doesn't support Unicode (last I heard), but we do want to have a more
> powerful regexp engine in Qt. (read: we want, but we don't know how to
> yet)
I fully undestand the complexity of such "conversion", so there won't be  
any complaints from me if things are left in their current state.

And there's another small request:
Wouldn't you change "win32-msvc2005|win32-msvc2008" in  
"mkspecs/features/win32/embed_manifest_*" files to "win32-msvc2*"? This'll  
make life of some people like me (I use different mkspecs for 32-bit and  
64-bit builds) a bit easier and make these options (or however they should  
be called) compatible with future versions of Visual Studio.

-- 
Constantin "Dinosaur" Makshin