[Development] Qt 5.3 Feature freeze is coming quite soon...

Kurt Pattyn pattyn.kurt at gmail.com
Fri Jan 17 20:57:50 CET 2014





> On 17 Jan 2014, at 12:13, Blasche Alexander <Alexander.Blasche at digia.com> wrote:
> 
> 
> 
> --
> Alex
> 
>> On Fri, Jan 17, 2014 at 10:49 AM, Pau Garcia i Quiles <pgquiles at elpauer.org>
>> wrote:
>> 
>> 
>>    Hello,
>> 
>>    If it's currently a separate module, which compiles by itself and can be
>> used by itself, why not adding it as an add-on?
>> 
>>    I have started to use Qt on mobile and while 200 more KB is nothing on
>> desktop, on mobile, 200 KB here and 200 KB there is a lot on mobile.
>> 
>>    I think it's best if a pattern is created: the more functionality that can be
>> provided as add-ons, the better (which is in fact what KDE has been doing with
>> the split of kdelibs in KF5: define the dependencies of search add-on, and you are
>> fine to use only this or that).
> 
> I agree with this statement. I fail to see a good reason why it must be joined. Sure there I is a spiritual one but is that really sufficient argument? We have to "burden" just about every Qt user with it. In my opinion it is common if you do something related to browser development but I can also think of plenty of apps which would never require it. Over time these things tend to add up as well (200k here and another 50k and viola you have a lib that's 0.5MB larger).
> 
>>    Yes, I know, I can use the QT_NO_WEBSOCKETS as Simon suggested but
>> wouldn't it be easier if nobody has to care about that? Don't want websockets?
>> Don't use the add-on. Or is there anything fundamental that will be gained by
>> having QtWebsockets be part of QtNetwork and I have missed it?
> 
> Qt's past has shown that such defines have a very short lifetime as virtually nobody compiles the myriads of define combinations.
> 
> Apart from that we create two incompatible versions of the same library. This may work if you have obscure features which really only a minority of users requires but that cannot be said either in this case. 
> 
> If you have your own module you don't have to split the QML code out into a totally different git repo/module either. LBNL the code is already separate. You safe doing the merge and it proved that it doesn't require some deep hidden internals from QtNetwork .
> 
These arguments make complete sense. The mobile use case is a very good example. For embedded devices this shouldn't be a problem, as normally Qt gets built from the sources anyway. Of course, one could always buy a commercial license ;-) (I am not affiliated with Digia).
I proposed the add-on choice as the way to go.

Cheers,
Kurt


> --
> Alex
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list