[Qt-interest] What is likely to be in Qt 4.8?

[Jason H]

I'm not sure I understand what the gain is if the binaries are "exactly the 
same".

I was imagining:
QtCore (QObject and other datatypes QString, etc.)
 - FileSystem DLLs for platforms
 - Process/Threading DLLs

QtGui
 - Screen DLL per platform
 - Theme DLLs

QtNetwork
 - Networking DLLs
 - SSL DLLs

Kind of how QtSQL just uses a plugin for your database(s)
In this way the "core libraries" form the API, but the implementation is in 
libraries that can be swapped out. Kind of like how the Q* Classes are the 
public interface, but QPrivate* classes are the implementation. Essentially I 
was thinking modularization was (in effect) taking the platform specific 
QPrivate* classes and replacing it with a DLL.

Now, there's not a whole lot of reason in QtCore to do this but it makes more 
sense when working with GUI, WebKit, Declarative, Script and Phonon.

I thought the gains were going to be that I could swap out declaritive for the 
scene graph, the script engine for a different one, webkit with a newer one, 
etc.

But by now I'm confusing myself so I'll stop here.







----- Original Message ----
From: Thiago Macieira <thiago at kde.org>
To: qt-interest at qt.nokia.com
Sent: Wed, February 23, 2011 3:52:12 PM
Subject: Re: [Qt-interest] What is likely to be in Qt 4.8?

On Wednesday, 23 de February de 2011 12:48:16 Jason H wrote:
> Am I wrong to hope that modularization will make most of Qt either modules
> or  plugins?

Yes.

Modularisation will change how the source code organises. The binaries 
produced (the result of the build) is exactly the same as before.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358