> On 17 Jan 2014, at 12:13, Blasche Alexander <alexander.blas...@digia.com>
> wrote:
>
>
>
> --
> Alex
>
>> On Fri, Jan 17, 2014 at 10:49 AM, Pau Garcia i Quiles <pgqui...@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@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
