Linked by Thom Holwerda on Tue 26th Oct 2010 15:20 UTC, submitted by diegocg
Qt Recently a project called 'Qt Modularization' was initiated. This is a project that aims to modularize Qt at every level. As you may know already, Qt is currently modularized on the DLL level; each module has its own DLL. However, the project as a whole is still monolithic; all the code is hosted in a single repository, you cannot build a leaf module without building the modules on which it depends. This project aims to change that, so that the modules are hosted in different repositories, with separate maintainers, and modules may have different release schedules.
Permalink for comment 447556
To read all comments associated with this story, please click here.
RE: Think about bindings too!
by Delgarde on Thu 28th Oct 2010 23:42 UTC in reply to "Think about bindings too!"
Member since:

This is really nice, modularization has done wonders to

Slightly related: it may be nice to decrease dependencies as well, in particular reliance on a QApplication or QCoreApplication object being created. I like to use Qt in my C++ software, including libraries. But it is preferable to avoid leaking this to library users, in terms of needing to make a QCoreApplication object.

There's a bit of a balancing act, of course. Gnome have traditionally had the opposite problem - modularisation taken to extreme, with new libraries constantly being added to the stack. Part of their effort in recent years has been to reduce that number by consolidating those libraries - e.g merging various UI classes into gtk, merging a lot of non-UI stuff into glib.

Qt comes from the opposite perspective - almost everything in one immense monolith of a package. I think the happy point for a split would be to break out the tools, break out QtWebKit, and to separate the UI pieces from the non-UI pieces (much like glib and gtk). No need to go overboard on breaking everything into a thousand little packages; just a few key divisions would seem in order.

Reply Parent Score: 3