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.
Thread beginning with comment 447213
To read all comments associated with this story, please click here.
Think about bindings too!
by danieldk on Tue 26th Oct 2010 16:38 UTC
danieldk
Member since:
2005-11-18

This is really nice, modularization has done wonders to X.org.

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.

(I know that many QtCore classes work without, however things like locales break.)

Reply Score: 2

RE: Think about bindings too!
by RshPL on Tue 26th Oct 2010 18:29 in reply to "Think about bindings too!"
RshPL Member since:
2009-03-13

Some things are necessary. You have to remember that Qt needs to rely on the event loop especially for stuff such as network operations and all the other asynchronous stuff.

Reply Parent Score: 1

danieldk Member since:
2005-11-18

Of course, but for some other functionality it should not be necessary (example provided).

Reply Parent Score: 2

RE: Think about bindings too!
by Delgarde on Thu 28th Oct 2010 23:42 in reply to "Think about bindings too!"
Delgarde Member since:
2008-08-19

This is really nice, modularization has done wonders to X.org.

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