[Development] PROPOSAL: merge #qt-qml and #qt-components to #qt-quick

joao morgado joaodeusmorgado at yahoo.com
Wed Jun 12 17:06:43 CEST 2013


What about #qt-quick and #qt-quick-development ? That way I think is clear to the developer the diference between the 2.

João de Deus


________________________________
 De: Bache-Wiig Jens <Jens.Bache-Wiig at digia.com>
Para: Nurmi J-P <jpnurmi at digia.com> 
Cc: "development at qt-project.org" <development at qt-project.org> 
Enviadas: Quarta-feira, 12 de Junho de 2013 13:34
Assunto: Re: [Development] PROPOSAL: merge #qt-qml and #qt-components to	#qt-quick
 


On Jun 12, 2013, at 1:11 PM, Nurmi J-P <jpnurmi at digia.com> wrote:

> On Jun 11, 2013, at 7:39 PM, Laszlo Papp <lpapp at kde.org> wrote:
> 
>> 
>> 
>> 
>> On Tue, Jun 11, 2013 at 8:37 PM, Alan Alpert <416365416c at gmail.com> wrote:
>> On Tue, Jun 11, 2013 at 10:34 AM, Laszlo Papp <lpapp at kde.org> wrote:
>>> On Tue, Jun 11, 2013 at 8:11 PM, Alan Alpert <416365416c at gmail.com> wrote:
>>>> 
>>>> I like the idea. For the average user, I definitely think #qt-quick is
>>>> a better name. It has a much clearer association, due to users
>>>> importing QtQuick and QtQuick.Controls in every file.
>>> 
>>> 
>>> OK, so you want a QtQuick channel, not QML, so dealing with the C++ API as
>>> well, et cetera. I did not get that intention from the initial mail, but
>>> then it is fine. By the way, it is slower to type as it is a few characters
>>> more ... ;) :)
>> 
>> The C++ API does (and has) come up occasionally, even in #qt-qml. But
>> realistically most people use the QML APIs (especially for
>> QtQuick.Controls ;) ).
>> 
>> Size doesn't matter, as everyone should auto-join it :P .
>> 
>>>> 
>>>> And non-quick QML users won't get lost as badly (I once saw a Cascades
>>>> user in
>>>> #qt-qml, and no-one could help him :( . #qt-qnx is a better channel
>>>> for Cascades-QML
>>> 
>>> 
>>> Actually, I think #blackberrydev is even better as Cascades-QML is more
>>> Blackberry specific rather than upstream Qt. My practical experience shows
>>> that, too.
>> 
>> Ah, I'm only on #qt-qnx.
>> 
>>>> 
>>>> I would like to have a separate #qt-qml channel for the language
>>>> issues (which are more working on the language than working with
>>>> anyways), but that's not realistic because users can't always tell the
>>>> difference. So maybe once the new #qt-quick channel is fully
>>>> established and #qt-qml is empty, we can reclaim it. Or the
>>>> language/engine development channel can have a more technical name to
>>>> hide it from the average user. That second channel is less important,
>>>> so it can wait for a later discussion, and QML language development
>>>> chat can always go to #qt-labs until then.
>>> 
>>> 
>>> Yes, that is what I wanted to raise as well, #qt-labs is fine for now IMHO,
>>> I agree.
>> 
>> PS: Perhaps you meant reply-all?
>> 
>> Yes, I did. Apologies. I am still struggling with the new gmail interface at times. ;-)
>> 
>> Cheers,
>> Laszlo 
>> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> Based on the feedback so far, I'd suggest we start with migrating #qt-components to #qt-quick. Jens, do you approve?
> 
> --
> J-P Nurmi
> 

I most certainly do.

jens



_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130612/f199fe35/attachment.html>


More information about the Development mailing list