[Development] PROPOSAL: merge #qt-qml and #qt-components to #qt-quick
markg85 at gmail.com
Wed Jun 12 13:39:52 CEST 2013
So then we have #qt-qml and #qt-quick? That's not very ideal i think.
Would it be possible to have #qt-qml somehow "redirect" the user to
#qt-quick? That would probably be best and have all QML stuff
organized in one channel. Also, it makes searching for the right IRC
channel easier since i would also search for *qml* and not *quick*..
Just my 5 cents :)
On Wed, 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. ;-)
>> Development mailing list
>> Development at qt-project.org
> 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
> Development mailing list
> Development at qt-project.org
More information about the Development