Submitted by 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.
OK, maybe this would mean a decent module dedicated for Linux only, takind advantage of X.org, Cinerama etc. Althought is premature to take any conclusion.
I like where this is going. Qt may very well be my goto framework for native apps in the future.
If I didn’t require the Adobe products, I’d probably switch from the Mac to KDE for my primary workstation.
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.)
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.
Of course, but for some other functionality it should not be necessary (example provided).
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.
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).
Rose-tinted glasses much? X.org has brought a rapidity to development that xfree86 never saw. The current problems with X have little to do with modularisation but mostly with trying to fix all the bugs created by the move to DRI2 and by moving half the server to the kernel, while also the same-old problem of trying to get recent video hardware to run on an open stack.
So what, you’re just blatantly full of shit? Okay, carry on.
Except most people aren’t building X modules from git devel. X.org has discreet releases but even if they didn’t, distributions would still take care to ensure that their ddx/dri/server/etc combinations were sound.
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.
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.
This is one thing the GTK+ (glib, gobject, cairo, pango, gio, gvfs, etc) folks got right and I’m glad Qt is following suit.
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…