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.
Post a Comment
Member since:
2005-09-27
Member since:
2006-03-23
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.)
Member since:2009-03-13
Member since:2005-11-18
Member since:2008-08-19
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.
Member since:
2005-07-11
Everytime a big monolithic project breaks up into "separate developed, separately packaged, separately released" modules, everything suffers.
Just look at the mess that is Xorg since they've split into sd/sp/sr modules. Versions are all over the place, not everything is updated to the new APIs/features, not everything works well together, and we're still waiting for everything to catch up.
Or look at the mess that is your typical Linux distribution, where upgrading 1 piece ends up upgrading half the distro, and things still break all over the place.
The nice thing about a monolithic development model is that you know for a fact that all the pieces in a release will be same for everyone who installs it, and that everything works together, all using the same features. And you aren't stuck waiting for module-foo-x.y.z to be released using feature bar-a.b.c before you can run application-Q (which is where a lot of people are when it comes to Xorg).
Member since:2010-06-19
Member since:2009-08-13
Thanks to my typical linux installation upgrading non-monolithicly I end up saving tons of bandwidth, hence megatons of times. And because I save time, my linux box, as a bonus, is more safe on average.
What are the alternatives?
* mega 5GiB update every two months
* update only major apps
* never update
Btw, upgrading half-the-distro on a typical linux installtion typically only happens when upgrading the-whole-distro.
Member since:
2009-06-30
One of the best Qt features is that it is a monolithic toolkit, shipped and tested as a single unit.
It make sense to separate out development tools, documentation, less popular bindings but putting parts of the toolkit (like Qt WebKit) in separate packages is a slippery slope. It make deployment of applications unnecessarily difficult (unless they're bundled with all the needed libraries). Just look what happened to Gtk applications that often copy-paste library code just to avoid excessive dependencies.
Also, please don't partition namespaces too much, especially horizontally. There are already problems caused by the split between QtCore and QtGui (data containers are in QtCore, things to put in them are in QtGui) - with few boundaries like that this is just an annoyance that leads to uglier code, with many - applications may easily become unmanageable.
Member since:
2005-06-29
Member since:2008-08-19
Not entirely right - the GTK family are coming away from the opposite extreme of having too many pieces to the puzzle, by merging some of them into the core - e.g libunique and the dbus-glib bindings merging into glib, libsexy and some of the libgnomeui widgets going into gtk+, etc.
It's a balancing act, really. Monolithic and modular both have advantages, both have disadvantages. The gtk+ folk seem to be finding a happy balance these days, and I guess the same will be true of the next few Qt releases...