Linked by Thom Holwerda on Tue 26th Oct 2010 15:20 UTC, submitted by diegocg
Thread beginning with comment 447556
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



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.