[Development] Modules in qtbase (was: Re: new "debugsupport" module and API)
pattyn.kurt at gmail.com
Tue May 13 08:17:55 CEST 2014
> On 13 May 2014, at 08:01, Knoll Lars <Lars.Knoll at digia.com> wrote:
>> On 12/05/14 22:40, "Thiago Macieira" <thiago.macieira at intel.com> wrote:
>>> Em seg 12 maio 2014, às 19:35:24, Oswald Buddenhagen escreveu:
>>>> On Mon, May 12, 2014 at 08:39:37AM -0700, Thiago Macieira wrote:
>>>>> Em seg 12 maio 2014, às 11:48:21, Ulf Hermann escreveu:
>>>>> The following changes create a debugsupport module with public API
>>>> Please create a new module. This doesn't need to be in qtbase.
>>> given that the two quick implementations will depend on it, it makes
>>> little sense to split it out, given what else is in qtbase.
>> Neither implementation is in qtbase, so I don't see the logic in that
>> argument. Yes, it *can* be in qtbase, but I don't see why it *should* be.
>> I want to hear a reason of why it should.
> Yes, let’s not make qtbase even bigger if we can avoid it. It’s hard
> enough to work with as it is.
>> In that light:
>> QtXml is there for historical reasons: there was code that needed it
>> (including QtDBus). It can probably be moved out now.
>> QtOpenGL and QtConcurrent are also historical and can probably be moved
>> too. Especially since those three aren't getting almost any updates, it
>> sense to do it.
>> QtDBus needs to stay because the XCB plugin needs it for some D-Bus
>> (notifications, the new systray protocol, etc.)
>> The rest of the libraries in qtbase are really base stuff.
> Actually I was thinking about splitting a few more things out. In addition
> to the ones mentioned above, I believe we would benefit from splitting
> QtNetwork out into it’s own module. The reason is that QtNetwork is
> responsible for many of the failing CI runs due to the inherent
> instability on the network tests. Splitting out the module should help
> make many of the qtbase integrations go more smoothly.
This makes sense. Maybe the WebSockets module can be integrated into the network module in that case?
I would also propose to move some code into qtbase: e.g. the matrix classes that are now in QtGui.
> From what I can see nothing else in qtbase (apart from the bearer plugins)
> depends on qtnetwork, so a split should be possible.
> Development mailing list
> Development at qt-project.org
More information about the Development