Re: [Development] Qbs development

[NIkolai Marchenko]

Tbf, the only vote that's needed is to make you the official maintainer.
The only reason this situation even exists is seemingly because while
Christian +2'd your patch, he didn't override -2 from Ossi while it was
said above he could. Regardless of who is right in this situation, that he
didn't lift the blocking vote with his power which made it spill here in
such a nasty manner is unhealthy.

On Thu, Sep 16, 2021 at 8:55 PM Иван Комиссаров  wrote:

> I believe there were several other cases, both in gerrit and discord.
> I think, we should proceed with a formal vote.
>
> Ivan
>
> 16 сент. 2021 г., в 14:50, David Skoland  написал(а):
>
> 
>
> On 15 Sep 2021, at 16:52, Oswald Buddenhagen 
> wrote:
> your arrogance, dismissiveness, and cynicism are duly noted, as usual.
>
>
> I believe this constitutes a personal attack, which is in violation of the
> Qt Code of Conduct:
> http://quips-qt-io.herokuapp.com/quip-0012-Code-of-Conduct.html (Paragraph:
> Be respectful)
>
> Cheers,
>
> David Skoland
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Commercial LTS Qt 5.15.4 released

[NIkolai Marchenko]

The problem with kde maintaining this is that people who are switching to
newer qt versions can no longer expect fixes done to this branch to exist
in the newer qt. So bugs that have been closed by the community may
reappear again in actual Qt as TQTC deems them irrelevant.

On Thu, May 13, 2021 at 1:03 PM Kevin Kofler via Development <
development@qt-project.org> wrote:

> Jason H wrote:
> > This has forced me to reconsider Qt as essentially closed source, I will
> > be brushing up on my web dev skills and just going electron/cordova in
> the
> > future. I wonder what this means for KDE. They probably have enough
> > infrastructure to weather this storm, but the average person will just
> > choose HTML5, the vast majority already do. I'm regretting having
> endorsed
> > this library in the past.
>
> KDE is maintaining their own 5.15 branches, e.g.:
> https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15
>
> Kevin Kofler
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt6 repo

[NIkolai Marchenko]

that's ... kinda what you're supposed to avoid... at least as far as I
understand the convo earlier. so that two major versions aren't pushed to
the same repo confusing people.

On Wed, Jan 13, 2021 at 3:04 PM Allan Sandfeld Jensen 
wrote:

> On Mittwoch, 13. Januar 2021 13:01:30 CET NIkolai Marchenko wrote:
> > except when qt7 comes you'll be stuck with versionless qt6 branch that
> you
> > wouldn't be able to move to qt7 because of aforementioned dependency
> > breakages.
> >
> Why not? It would just be a new branch in the same repo
>
> Best regards
> Allan
>
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt6 repo

[NIkolai Marchenko]

except when qt7 comes you'll be stuck with versionless qt6 branch that you
wouldn't be able to move to qt7 because of aforementioned dependency
breakages.

On Wed, Jan 13, 2021 at 2:59 PM Tor Arne Vestbø 
wrote:

> >
> > On 13 Jan 2021, at 12:38, Allan Sandfeld Jensen 
> wrote:
> >
> > On Mittwoch, 13. Januar 2021 12:31:50 CET Eric Lemanisser wrote:
> >> that's the obvious choice, if it was not already used by qt4.
> >>
> > Then rename the qt4 repo, it is not actively maintained anymore and only
> > stored for history. We couldn't do that when creating qt5 as it was
> still
> > actively maintained and would break a lot of checkouts, but we could do
> it
> > now.
>
> I agree, that seems like the easiest and most future-proof solution.
>
> Cheers,
> Tor Arne
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

[NIkolai Marchenko]

wow, this title is so completely incorrect and taken out of context.

On Wed, Jan 6, 2021 at 4:15 PM Vlad Stelmahovsky 
wrote:

> you guys getting "famous":
> https://www.theregister.com/2021/01/05/qt_lts_goes_commercial_only/
>
> On Wed, Jan 6, 2021 at 12:15 PM Volker Hilsheimer 
> wrote:
>
>> > On 5 Jan 2021, at 21:18, Max Paperno  wrote:
>> >
>> > On 1/5/2021 1:02 PM, Adam Light wrote:
>> >> On Tue, Jan 5, 2021 at 7:56 AM Volker Hilsheimer <
>> volker.hilshei...@qt.io > wrote:
>> >>Apart from that: is Qt 5.15.2 really so broken that people can’t use
>> >>it without getting more patches?
>> >> I can't speak to 5.15 as we decided not to upgrade since it's not a
>> real LTS release (we do not believe we are eligible to purchase a
>> commercial license), but the minor fixes that come later in LTS releases
>> (5.9 and 5.12) have often fixed problems our users have reported in our
>> application, particularly on macOS. Due to behavior changes in different Qt
>> minor versions (again, primarily on macOS), we typically change the Qt
>> minor version only when we release a new major version of our application
>> (~every 2-3 years).
>> >> LTS releases have been critical in our successful use of Qt, and I am
>> not sure what will happen moving forward.
>> >> Adam
>> >
>> > Hear, hear.  Stuck on 5.12 here.
>> >
>> > Working on OS projects, commercial is not even an option, and resources
>> (e.g. for testing/fixing on every new Qt release) are very limited (read:
>> one person often does everything). E.g. testing one app on 5.14.1 yielded 3
>> breaking Qt issues which had to be fixed upstream, and mostly didn't make
>> it into .2 either. LTS (after like a .3 or so update) is the only way to go
>> IMHO, the others are for testing/playing.
>> >
>> > I'm so sick of "scheduled releases come hell or high water" in the
>> programming world (in general, not just Qt).  The quality is (usually)
>> crap.  Once upon a time this release quality was called
>> Alpha/Beta/Preview/NFP (not for production).  Qt6 has literally been called
>> as being "primarily" for testing/feedback.  That's a new major release
>> now?  /further rant aborted
>> >
>> > Sorry, I'm only passionate about it because I love what Qt does and I
>> love when it does it well and consistently.  Everyone who's helped make it
>> that way is my hero, thank you!
>> >
>> > -Max
>>
>>
>> Hi Max and Adam,
>>
>>
>> What can do better to avoid such regressions from making it into a
>> release, or preferably into the code, in the first place? Nobody, not even
>> the Qt Company management :P *wants* to release crappy quality on time.
>>
>> What we know about those bugs is that they passed all code reviews, and
>> didn’t get caught by any of the thousands of tests we run for every change
>> on half a dozen platforms. And we know that the only way they were
>> discovered is real users testing real applications against the released
>> version of Qt.
>>
>> So, what we have is clearly not good enough, but if the last 15 years of
>> writing unit tests etc hasn’t gotten us to a better place, then maybe “more
>> of the same” can’t be the only strategy.
>>
>> Is your experience that we release stuff “come hell or high water" in
>> spite of severe bugs being reported during beta testing? We do spend a lot
>> of time triaging incoming bug reports, and a severe enough bug can always
>> block a release.
>>
>> Or do we not discover the issues until the .0 release because few people
>> test the pre-releases? That seems to be supported by the data we have about
>> downloads and general activity in response to pre-releases.
>>
>>
>> Volker
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>
>
> --
> Best regards,
> Vlad
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Long-lived P1 issues

[NIkolai Marchenko]

> Currently, there are 1175 open P1 issues in the QTBUG project.  583 of
those issues had that priority set more than one year ago,

I am not saying no one ever fixes those, but given the premise of this
thread. The "promise" of every PX description is certainly broken enough
_in general_ that my rewording is more accurate than official one.


On Fri, Dec 4, 2020 at 11:11 AM Joerg Bornemann 
wrote:

> On 12/4/20 5:42 AM, NIkolai Marchenko wrote:
>
> > Let's be honest with your users:
> > P0: almost sure to block a release.
> > P1: We will act on it if the maintainer is in the mood some day when
> > it's still fresh
> > P2: We will fix it, maybe
> > P3: thank you for informing us.
>
> That's neither helpful nor true. I certainly fixed many P3s in the past
> - if not for recreational purposes, because I was working in the
> respective area anyways.
>
> For issues that are low priority but hard to fix however... well as in
> every project: bad luck.
>
>
> Cheers,
>
> Joerg
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Long-lived P1 issues

[NIkolai Marchenko]

Let's be honest with your users:
P0: almost sure to block a release.
P1: We will act on it if the maintainer is in the mood some day when it's
still fresh
P2: We will fix it, maybe
P3: thank you for informing us.



> I suggest to simplify P3, P4 descriptions though to
>>
>>   P2: Important, should be fixed.
>>   P3: Should be fixed.
>>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


On Fri, Dec 4, 2020 at 7:27 AM Jason McDonald  wrote:

>
> On Fri, 4 Dec 2020 at 02:09, Kai Köhne  wrote:
>
>> > Was there any outcome from this discussion? Like, re-evaluating priority
>> > levels and what they mean in terms of release blockers?
>>
>
> I note that the number of open P1's has dropped from 1175 to 1063.  Some
> of that decline has been from genuine P1's getting fixed for Qt 6, some is
> due to maintainers doing some housekeeping, and I have closed a handful
> while sifting through the older half of the Needs More Info bugs.
>
> Thank you to everyone who has contributed so far.
>
> There was no consensus, however, so I've put this on the backburner until
> I can finish reading through the rest of the NMI bugs and the Testlib
> backlog, which will take me into the new year.
>
> When I'm done with those tasks, perhaps I can find one or two maintainers
> who wouldn't mind a little help to straighten out their module's backlog in
> exchange for educating me about their module.  (Warning: I can only commit
> to a maximum of ten hours per week for the foreseeable future.)
>
> Personally, I don't have a problem with the definitions of the priority
> levels.  The only change I'd suggest is to make it explicit that the
> availability of an easy workaround should generally cause the priority of a
> bug to drop down one step.
>
> What I'm seeing in Jira suggests that collectively we just aren't very
> strict about sticking to those definitions.  I've seen some cases where P1
> has been set to indicate that "this bug really annoys me" rather than "this
> bug seriously disrupts my work".  I also see cases where the reporter set
> the priority themselves.  Back in the Nokia days, we had separate Severity
> and Priority fields so that Jira could show both the level of disruption
> experienced by the reporter and the urgency for a fix set by the
> maintainer.  I'm afraid that I can't remember why we merged those fields.
>
> I don't think there was any sort of decision or consensus. Which means we
>> keep working with the status quo, as documented in
>> https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?#PriorityLevels
>>
>> I suggest to simplify P3, P4 descriptions though to
>>
>>   P2: Important, should be fixed.
>>   P3: Should be fixed.
>>
>> (the mentioning that they don't block a release probably stems from a
>> time where P1 meant blocking the release. This is not the case anymore, so
>> what's the point in highlighting that a P2, P3 doesn't block a release?).
>>
>
> I think that would be a good change.  P1's blocking a release only made
> sense back in the days where we could only manage one release every three
> or four months.
>
> Cheers,
> --
> Jason
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Long live QBS plugin for VSCode

[NIkolai Marchenko]

Hm, I might try using it. I've been seriously annoyed by qt creator
recently but as I use qbs I didn't really have an alternative.
I will give my feedback when I get to it.

On Thu, Oct 22, 2020 at 5:39 PM Denis Shienkov 
wrote:

> Hi developers,
>
> Recently, I have started the plugin for the VS Code that support the QBS:
>
> * https://github.com/denis-shienkov/vscode-qbs
>
> Right now I have released the developer pre-view release v0.0.5:
>
> * https://github.com/denis-shienkov/vscode-qbs/releases/tag/v0.0.5
>
> Right now this plugin support the following features:
>
> * It is possible to open the QBS project folder.
> * It is possible to choose the desired active QBS project file in this
> folder.
> * It is possible to choose the QBS buil profile to build the active
> project.
> * It is possible to choose the QBS buil configuration to build the active
> project.
> * It is possible to choose the product to build (or all products).
> * It is possible to choose the product to run.
> * It is possible to choose the product to debug.
> * It is possible to change some QBS options in the plugin settings.
> * It automatically support the intelli sense highliting for the C/C++
> sources.
>
> At least, I have successfully compiled the QtCreatoe and the QBS using this
> plugin. Also, it is possible to debug the sources.
>
> All desired documentation about usage of VS Code can be found in
> official VS Code site. And for the QBS plugin you can look on the
> Readme.md files (and on the small documentation in /docs folder).
>
> I hope someone is interested in this and helps in the development
> of this plugin. ))
>
> Best regards,
> Denis
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Important recent changes in QList

[NIkolai Marchenko]

Since we're apparently heading to QVector being an alias to QList as
opposed to what was a previous proposed solution. Can someone please
elaborate on what breakages we can expect to happen in the old code with
this paradigm shift? It seems like there's *almost* been a huge break with
erasing behaviour. What else to expect?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Important recent changes in QList/QString/QByteArray

[NIkolai Marchenko]

>   This is the difference between QList and std::vector.
You are aliasing QVector into a QList if I understand it correctly. This
means a major compatibility break in a ton of code. Unless QVector also
worked like that which I doubt was the case.

On Wed, Sep 2, 2020 at 3:53 PM Andrei Golubev  wrote:

> > Interesting. I'm curious what sort of repacking happens on erase
> >
> > The iterators before or after may be invalidated. Exactly which of the
> two (before or after) is going to happen depends on the position of the
> to-be-erased range with regards to the position of the full range.
>
> I don't quite understand why a vector erase would invalidate vector
> elements before the erased position.
>
> This is the difference between QList and std::vector.
>
> > the element storage wouldn't necessarily be at the beginning of the
> > allocated block;
> > in that approach, a pop_front would merely bump the begin, and erase
> > still wouldn't
> > invalidate anything before the erased position.
> >
> > I guess you mean "erase still wouldn't invalidate anything after the
> erased position".
>
> No. I mean "before", not "after". That's how std::vector works. An
> erase is a shrinking operation
> that keeps everything before the erased position untouched and
> left-shifts everything after it. If you
> want a prepend optimization, you can get it without changing the way
> erase works and what the
> invalidation guarantees of erase are, so I'd like to understand what
> in our implementation strategy
> necessitates this change to those guarantees.
>
> I do not have use cases at hand so cannot really back up my words by
> evidence. The erase strategy with invalidation either "before" or "after"
> is the strategy of Qt 5 QList. Similar thing is done with Qt 6 QList
> (a.k.a. QVector). Indeed, it's not aligned with std::vector::erase().
>
> >But this is effectively undefined (or implementation-specific, as you
> wish) and may change in future if we discover a more performing strategy.
> Again, any exceptions should be documented. Please do not assume any
> specific behavior otherwise.
>
> This seems like a potentially quite significant compatibility break,
> that chopping a vector invalidates all references
> and iterators to parts of the vector that the chopping didn't touch before.
>
>
> --
> Best Regards,
> Andrei
>
> --
> *From:* Ville Voutilainen 
> *Sent:* Wednesday, September 2, 2020 3:28 PM
> *To:* Andrei Golubev 
> *Cc:* Giuseppe D'Angelo ;
> development@qt-project.org ; Ville
> Voutilainen 
> *Subject:* Re: [Development] Important recent changes in
> QList/QString/QByteArray
>
> On Wed, 2 Sep 2020 at 15:19, Andrei Golubev  wrote:
> > Ville:
> >
> > Interesting. I'm curious what sort of repacking happens on erase
> >
> > The iterators before or after may be invalidated. Exactly which of the
> two (before or after) is going to happen depends on the position of the
> to-be-erased range with regards to the position of the full range.
>
> I don't quite understand why a vector erase would invalidate vector
> elements before the erased position.
>
> > the element storage wouldn't necessarily be at the beginning of the
> > allocated block;
> > in that approach, a pop_front would merely bump the begin, and erase
> > still wouldn't
> > invalidate anything before the erased position.
> >
> > I guess you mean "erase still wouldn't invalidate anything after the
> erased position".
>
> No. I mean "before", not "after". That's how std::vector works. An
> erase is a shrinking operation
> that keeps everything before the erased position untouched and
> left-shifts everything after it. If you
> want a prepend optimization, you can get it without changing the way
> erase works and what the
> invalidation guarantees of erase are, so I'd like to understand what
> in our implementation strategy
> necessitates this change to those guarantees.
>
> >But this is effectively undefined (or implementation-specific, as you
> wish) and may change in future if we discover a more performing strategy.
> Again, any exceptions should be documented. Please do not assume any
> specific behavior otherwise.
>
> This seems like a potentially quite significant compatibility break,
> that chopping a vector invalidates all references
> and iterators to parts of the vector that the chopping didn't touch before.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Important recent changes in QList/QString/QByteArray

[NIkolai Marchenko]

> There's no violation. Your code was incorrect in the past, it just
happened to work.
I have to remind you about the Qt5.5 and the QDebug behaviour change that
had to be rolled back because of the backlash.
This has ramifications way bigger than a simple logging breakage.
If a mission critical application triggers a bug because of the code that
worked previously but is UB then, you're going to have a massive reputation
hit on Qt as a whole.
This also goes completely contrary to the goal of making the switch to qt6
painless.

On Tue, Sep 1, 2020 at 8:35 PM Thiago Macieira 
wrote:

> On Tuesday, 1 September 2020 09:05:48 PDT NIkolai Marchenko wrote:
> > Wait what? The switch to Qt6 was supposed to become a painless process
> yet
> > you're introducing important and hard to notice in real code changes that
> > can result in undefined behaviour?
> > What? WHAT?!
>
> There's no violation. Your code was incorrect in the past, it just
> happened to
> work.
>
> Assume any and all non-const function will invalidate iterators.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Important recent changes in QList/QString/QByteArray

[NIkolai Marchenko]

>  A more subtle issue concerns the users of QVector.
Wait what? The switch to Qt6 was supposed to become a painless process yet
you're introducing important and hard to notice in real code changes that
can result in undefined behaviour?
What? WHAT?!

On Tue, Sep 1, 2020 at 6:58 PM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:

> Hi,
>
> Thanks for the heads up!
>
> Il 31/08/20 13:50, Andrei Golubev ha scritto:
> > The invalidation existed before for cases when a container could detach
> > (due to copy-on-write) or reallocate (due to growing or squeezing).
>
> This sounds incorrect? Which invalidation did happen due to COW?
>
> > Now
> > this is also true for non-detaching, non-reallocating modifying
> operations.
>
> So, now, formally, std::sort(v.begin(), v.end()) risks undefined
> behavior? E.g. begin() returns the begin iterator without touching
> anything, but end() decides to invalidate all the iterators.
>
> Yes, I assume that in practice begin() would already invalidate, and
> end() wouldn't, so it would work, but I'm asking what's formal model
> now. Is there a way to know that the next non-const call is going to
> invalidate everything?
>
>
> Side question, does anyone see a problem with begin() / data() / etc. no
> longer be noexcept O(1) operations?
>
>
> Thanks,
>
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[NIkolai Marchenko]

>  But if the majority thinks that the class name is burned
Majority of whom? I am fairly certain most Qt developers either didn't know
about QList controversy or didn't care about it enough to consider it in
their code.
The only people who care are ones in this mailing list most likely. Imo.

On Fri, Apr 24, 2020 at 7:36 PM Joerg Bornemann 
wrote:

> On 4/24/20 18:10, Giuseppe D'Angelo via Development wrote:
> > On 4/24/20 8:57 AM, Joerg Bornemann wrote:
> >>
> >> Alternatively, proposal 3 (aka "do almost nothing"):
> >>   template  class QVector { implementation }
> >>   template  using QList = QVector;
> >>
> >> No deprecation of QVector.
> >> No replacement of QList with QVector in our API.
> >>
> >> Rationale: QList is our default sequential container, and in Qt6 we just
> >> change its implementation.
> >
> > Could you please argument a bit more? In particular:
> >
> > * Is it OK to live with a mixup of containers in the APIs? What's the
> > downside in terms of consistency, teachability, learning, etc.?
>
> No, IMO it's not OK to have a mix of QVector/QList in our public APIs.
> Most of the time the user is interested in the fact that they have to
> pass or get sequence of items. Be it QVector, QList or something else.
>
> We should settle on one type and use it consistently.
> Historically, QList was this general purpose container.
>
> > * If I'm adding a new function, what would the coding guideline be,
> > take/return QList or QVector? Why?
>
> Use the agreed-on general purpose container of Qt. If you use another
> container, have a good reason.
> Why? Consistency.
>
> > * What's the reason against the replacement? It's not worth it in terms
> > of manpower, or another guideline?
>
> I'm not strongly against the replacement. I'm strongly against the
> deprecation. If QList==QVector I really don't care about the
> replacement. But I, personally, wouldn't invest in changing every
> occurrence of QList to QVector. I really don't see the benefit.
>
> IMHO, we can keep using QList. The only thing we have to do is to
> communicate the fact that QList's implementation has been fixed/adjusted
> to current requirements for Qt6. But if the majority thinks that the
> class name is burned, so be it. Use QVector in the API and replace like
> there's no tomorrow. But don't deprecate QList or QVector as this will
> be a heavy burden for projects migrating from Qt5 to 6 or projects that
> - God forbid - support both versions.
>
>
> Stay healthy,
>
> Joerg
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Thank you for qScopeGuard

[NIkolai Marchenko]

it's definitely neat, but it's nothing that you can't do with pure c++
though. It's just qt's native implementation of score guard pattern. Tbh I
didn't even know it existed because I use my own scope guarder class.

On Fri, Feb 21, 2020 at 4:33 PM Henry Skoglund  wrote:

> Hi, just want to thank whoever worked to implement qScopeGuard (in
> 5.12), it was a perfect gift from heaven today :-)
>
> I'm writing a LOB app with heavy database munging, and want to show the
> user an hourglass cursor while munging/waiting for MS SQLServer.
> However my functions have lots of exits due to bad weather etc. and I
> dreaded pasting a restore-mouse-cursor call everywhere. Googled a bit
> and now I use this 2-line magic at the top of my functions:
> ...
>  qApp->setOverrideCursor(Qt::WaitCursor);
>  auto restoreCursor = qScopeGuard([] {
> qApp->restoreOverrideCursor(); });
> ...
>
> Before I discovered Qt I spent 20 years in MFC purgatory, but now I've
> seen the light!
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

I personally want a goal oriented fundraiser model. Like "revamp
qtwidgets", "do a round of serious bugfixes in qml" etc

On Thu, Jan 30, 2020 at 1:23 AM Matthew Woehlke 
wrote:

> On 29/01/2020 17.13, Konstantin Shegunov wrote:
> > On Wed, Jan 29, 2020 at 11:55 PM Matthew Woehlke wrote:
> >> We need more open-source-meets-kickstarter...
> >
> > ehm, Patreon?
>
> Aside from issues with Patreon's reputation, there's a reason I wrote
> "kickstarter". I can't think of any instance where I've seen tangible
> rewards for supporting *an open source project* via Patreon. Conversely,
> Kickstarter offers *specific* rewards of the payee's choice, and often
> involves some sort of public "thank you" (which I don't think I've
> *ever* seen with Patreon).
>
> Besides, I was thinking more along the lines of something that could
> integrate with other OSS tools (e.g. GitHub).
>
> I want a "proud sponsors" page. I want to be able to offer bounties for
> specific bugs or feature requests. (IOW, read the rest of my previous
> message that you didn't quote.)
>
> --
> Matthew
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

>  You have absolutely no information on how elastic the Qt commercial
price is, so kindly don't speculate on what price would be good.

Let me pipe in about what people think of Qt's licensing model. I won't
call names but I've been contacted just today by someone who has been
legally bullied by Qt's sales team into purchasing a license for a case
that is completely non obvious. This person is of the opinion that even
using Qt's LGPL license is completely unsafe as it's totally grey area and
claiming that TQtC searches people working with qt on Linkedin and bullies
their companies.

These are not my words, I have no proof, but this is what I got in PMs
today from someone I haven't even talked to before. I am simply passing
along their opinion.

My own opinion: Qt's licensing is super non-obvious and super non-friendly
and the more i learn about it the less desire I have to ever suggest
expanding on LGPL in our company with Qt's business offerings.

On Wed, Jan 29, 2020 at 11:58 PM Thiago Macieira 
wrote:

> On Wednesday, 29 January 2020 00:25:22 PST Filippo Cucchetto wrote:
> > Qt should find a good balance between licensing costs and investors.
> > Taking JetBrains as an example of similar (profitable) company you can
> see
> > that for a single developer all their tools suite costs 600 euros yearly
> > decreasing to 400 after 3 years. I think that's a fair price even for a
> > framework like Qt.
>
> Just because it seems like a good price for you doesn't mean it's a good
> price. Reducing the licence price to one tenth what it is today could mean
> the
> revenues for the company reduce to one tenth too, which means the
> development
> team might need to reduce to around one tenth what it is. For a licence
> one
> tenth what it is today, you have to prove that sales would be ten times
> bigger
> or more. Do you have such proof?
>
> You have absolutely no information on how elastic the Qt commercial price
> is,
> so kindly don't speculate on what price would be good. The only entity
> that is
> close to having that information is the one doing Qt sales in the first
> place
> and even then I don't know they know very well.
>
> > Furthermore i think that current LGPL users could be more
> > willing to buy a commercial company once a good price for them is
> available
> > (at that point i would simply turn Qt dual licensing GPL or Commerical
> > period).
>
> No, they aren't. Just see that someone else posted on this thread that
> they
> were paying for a year and then decided to stop doing so because they
> weren't
> using the licence or support. That's the big issue: why keep paying for
> something you're also getting for free? Companies don't pay out of the
> goodness of their hearts.
>
> > Another point is that a great framework like Qt need some big investors
> > that are willing to use Qt for their ecosystem. We don't have big
> > informations onthis
> > area but maybe the partnership with LG or with one or more company in the
> > automotive field can give a stable flow of cash.
>
> What makes you think that the automotive field isn't exactly the worst
> field,
> using Qt in a large set of devices and not contributing code nor paying
> for
> commercial?
>
> And how do you convince them to pay more? You have to give them something
> they
> want and wouldn't otherwise get for free. Like a release supported for a
> big
> number of years. At least for the automotive industry, allergic to the
> (L)GPLv3 as it is, there's one other: the incentive of a licence that
> doesn't
> have the TiVo clause.
>
> > In conclusion a 400 euro per developer/year is a nice spot for converting
> > most LGPL users to Commercial.
>
> Conclusion based on opinion, not data. Sorry, this is not how it works.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

>   Won't someone please step up and do it for us?"

Which is why I don't understand how the proposed model is supposed to help
TQtC and the community.
A lot of stuff they are dropping for opensource users will simply move to
less trusted and perhaps less stable sources but will still be perfectly
available which means the "lure" of the new commercial license is
completely moot for overwhelming majority of developers. The moment those
less trusted sources will turn out actually being malicious the backlash
will hit Qt as a whole. Removing these things doesn't matter in the end and
has the potential to make the company look even worse than these changes
look now.

The things that matter is the LTS (will hurt Qt more than opensource users,
imo) and the fact almost every new thing that happens in Qt recently
happens to be paywalled instead of LGPL.
Instead of doing what they are doing, they should rethink the cost of their
low/mid tier licenses to encourage wider adoption and seek crowdfunding.


On Tue, Jan 28, 2020 at 6:42 PM Matthew Woehlke 
wrote:

> On 28/01/2020 01.37, Benjamin TERRIER wrote:
> > You might have missed the info because it is in the blog post, but not in
> > Lars email:
> >
> > There will be no more open source offline installer.
>
> Correction: there will be no offline installer *provided by TQtC*.
>
> Like Nikolai¹, what I expect to happen is that some third party will
> start repackaging Qt, and will become the de facto binary provider.
>
> Honestly, the first thing that went through my head when I read the blog
> was an image of someone at TQtC thinking: "Making binary installers is
> just so *hard*. We really don't want to do it any more. Won't
> someone please step up and do it for us?"
>
> (¹
> https://lists.qt-project.org/pipermail/development/2020-January/038343.html
> )
>
> --
> Matthew
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

Also, they really should do this all for LGPL licenses only. It makes no
sense to enforce all these restrictions on the projects that don't generate
any revenue at all. The model isn't realistic not only for small
businesses, it actively punishes open source development where the people
involved in it for sure can't afford the license fees.

On Tue, Jan 28, 2020 at 2:02 PM ekke  wrote:

> Am 28.01.20 um 11:14 schrieb coroberti .:
> > On Tue, Jan 28, 2020 at 11:55 AM Konstantin Shegunov
> >  wrote:
> >> 
> >>
> >>> The third change is that The Qt Company will in the future also offer
> a lower priced product for small businesses. That small business product is
> btw not limited to mobile like the one Digia had some years ago, but covers
> all of Qt for Device Creation.
> >>
> >> I see a couple of issues here. Firstly, 100k/year *turnover* isn't a
> small business, that's a nano-company (i.e. 1-2 devs max) and if they're
> providing a device alongside the software that 100k is going to be eaten in
> no time. Notice we are not talking profit here, but raw revenue. Whoever
> from sales came up with that number, really did a botched up job with it.
> On that note, even if we accept that it's applicable, the straightforward
> math shows you want to bill 0.5% - 2.5% of the total turnover, so while
> this sounds good initially it really isn't that shiny when you crunch the
> numbers. That offering is stillborn from my point of view.
> > Agree with Konstantin that the definition of a small business isn't
> realistic.
> > The realistic one is up to 5 developers and up 500k/year USD sales.
> >
> > ...
> >
> > So, hello, Qt-company, and consider to make something really friendly
> > for small businesses ...
>
> +1 Konstantin and coroberti
>
> I'm only a single mobile app developer and for me it is ok with 100k and
> $499/year
>
> but I know many developers from small businesses (2-5 devs) and it's
> really not realistic to think they have less 100k sales total per year ;-)
>
> coroberti's idea (up 500k sales per year) covers the target (StartUp,
> Small Business) much better and is something making it easier to
> motivate mobile app devs to use Qt instead of Flutter, Xamarin, React or
> so.
>
> please rethink your definition of StartUp / SmallBusiness to make this
> license a success for Qt
>
> ekke
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

You know what bothers me the most about all this? Qt is becoming your
average AAA game developer. They are essentially selling us time savers.
Most of the attached value of the commercial license isn't something that
is inherent to the license but stuff that everyone can do anyway, just with
a (quite) annoying bit of unnecessary effort. They are selling us the
solution to the problem they are the ones creating in the first place. None
of the stuff in the new enforced license is something TQtC aren't going to
do anyway, they are just paywalling it now. Does it sound stupidly
familiar and echoing the Jim Sterling to anyone else?

Login requirement: Spend time entering your credentials.
No offline packages: Spend time compiling qt for your offline system.
No LTS support: spend time finding a decent fork of the otherwise LTS
branch, optionally for community to spend time maintaining it.

All of the above is perfectly possible to do without paying, just very
annoying. Exactly the model of recent AAA games and mobile game offerings.
And Qt isn't even doing it right to boot: you don't sell a solution to the
problem that users can solve themselves. Alternative Qt packagers will
emerge immediately, same as alternative stability branch,

To further nail the similarity to the companies like Bethesda: they have
even backtracked on the "no microtransactions" promises, or to be precise
"no login required for installer" promises. AND tried to cover it up only
to realize it's archived so they can't. Well done, TQtC, well done indeed.



On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:

> Hi all,
>
> The Qt Company has done some adjustments to the Qt will be offered in the
> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020
> .
>
> The change consists of three parts.
>
> One is a change in policy regarding the LTS releases, where the LTS part
> of a release is in the future going to be restricted to commercial
> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
> into dev first. Backporting bug fixes is something that the Qt Company will
> take care of for these LTS branches. We’ve seen over the past that LTS
> support is something mainly required by large companies, and should
> hopefully help us get some more commercial support for developing Qt
> further.
>
> The second change is that a Qt Account will be in the future required for
> binary packages. Source code will continue to be available as currently.
> This will simplify distribution and integration with the Marketplace. In
> addition, we want open source users to contribute to Qt or the Qt
> ecosystem. Doing so is only possible with a valid Qt Account (Jira, code
> review and the forums all require a Qt Account).
>
> The third change is that The Qt Company will in the future also offer a
> lower priced product for small businesses. That small business product is
> btw not limited to mobile like the one Digia had some years ago, but covers
> all of Qt for Device Creation.
>
> None of these changes should affect how Qt is being developed. There won’t
> be any changes to Open Governance or the open development model.
>
> Best regards,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

There will be no offline installer for non paying people. That is the
hurdle. Did you even read the actual blog post?

On Tue, Jan 28, 2020 at 5:22 AM Thiago Macieira 
wrote:

> On segunda-feira, 27 de janeiro de 2020 14:47:46 PST NIkolai Marchenko
> wrote:
> > Assuming we have a VM that is restricted to connecting to the internet,
> we
> > previously could dump the installer there and install Qt.
> > Now, we need to have an intermediary PC with the same OS to first install
> > the binaries via online installer and then copy those binary files to
> that
> > first VM.
> >
> > This is an extraneous and completely artificial step for absolutely no
> > reason other than TQtC paywalling them, which is ridiculous.
>
> Previously, you anonymously downloaded the offline installer from another
> machine, then copied it over to the VM, and installed there.
>
> Now you're going to download the offline installer from another machine
> after
> typing your password, then copy over to the VM and install there.
>
> What's the hurdle?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

Assuming we have a VM that is restricted to connecting to the internet, we
previously could dump the installer there and install Qt.
Now, we need to have an intermediary PC with the same OS to first install
the binaries via online installer and then copy those binary files to that
first VM.

This is an extraneous and completely artificial step for absolutely no
reason other than TQtC paywalling them, which is ridiculous.

On Tue, Jan 28, 2020 at 12:46 AM Thiago Macieira 
wrote:

> On segunda-feira, 27 de janeiro de 2020 08:36:58 PST NIkolai Marchenko
> wrote:
> > Now every machine that needs qt libraries needs to be connected to the
> > internet if it doesn't pay. No expections.
> > This is a completely ridiculous bullshit move.
>
> Sorry, Nikolai, but WTF are you talking about?
>
> What does having to be connected have to do with anything? Previously, you
> didn't need a password to download, now you do. Either way, to *download*
> you
> need to be connected to the Internet.
>
> If the VM isn't connected, then it assumes it is getting the files from
> somewhere else, like a network share or the host machine. Why can't you
> download there and then copy over the same way you do today? Use the
> password
> to download the binary from another machine, then copy over.
>
> And if you can get files there, you can get a small .txt file with the
> password there.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

> It is cheaper and faster to make your own offline installer.
Honestly, if we think into the future it looks like compiling qt is too
straightforward and doesn't incentivise commercial licenses enough. So the
next big thing will be to make compiling qt an "evolving experience" with
flags and possible buildsystems changing from version to version
(hello cmake). Then, some part of a build will require to input online
credentials to work. And so on. Because clearly removing offline installer
will just make people go "okay, it's super annoying but I can create
binaries myself" instead of "okay, it's super annoying, let's pay qt"

On Mon, Jan 27, 2020 at 7:49 PM Benjamin TERRIER 
wrote:

> I've had a Qt account for years, it doesn't change that I do not want to
> use it to download a Qt version.
>
> It is obvious that that in the world that we live today having an account
>> for a service is not a blocker for people in general.
>>
>
> Qt users are not "people in general", they are software developers and
> they understand that this is an artificial barrier.
> I hope all software developers understand that they should not need an
> authenticated access to download public tars of an open source project.
>
> we believe that we provide value to our users through the installer and
>> the Qt Marketplace to justify the Qt Account.
>>
>
> Do all Qt users have value in the Qt Marketplace?
> For open source user, I am pretty sure the answer is no.
> For commercial/company users, I doubt all developers need access to the
> marketplace.
>
> What does the installer brings now that was not their in 2015 ?
> Nothing. So it was a bad idea in 2015, and still is a bad idea.
>
> On a more general note. It seems you are trying to make money by taking
> feature from the open source versions (like the offline installer).
> What you take really hurts the usage of open source users and hurts the Qt
> community.
> But at the same time I am not sure these small features will justify
> buying a license that  cost several thousand dollars per seat.
> Especially when company that want to move from open source to commercial
> have to pay a prohibitive retroactive license fee.
> It is cheaper and faster to make your own offline installer.
>
> Le lun. 27 janv. 2020 à 17:25, Tuukka Turunen  a
> écrit :
>
>>
>> Hi,
>>
>> Well, quite many things have changed since 2015. One important item is
>> that almost one million users have already voluntarily created (and
>> verified) themselves a Qt account.
>>
>> See the FAQ (linked from the blog post):
>>
>> “Q: Will requiring the Qt Account drive away all Qt users?
>> A: We have had the Qt Account as an option for over 4 years, and during
>> that time there has been already nearly a million people who have
>> registered and verified their Qt Account. It is obvious that that in the
>> world that we live today having an account for a service is not a blocker
>> for people in general. Everyone has the option of building Qt from sources
>> if they do not like the installer, but we believe that we provide value to
>> our users through the installer and the Qt Marketplace to justify the Qt
>> Account.“
>>
>> Yours,
>>
>> Tuukka
>>
>> --
>> *Lähettäjä:* Development  käyttäjän
>> Benjamin TERRIER  puolesta
>> *Lähetetty:* maanantaina, tammikuuta 27, 2020 6:03 ip.
>> *Vastaanottaja:* Qt development mailing list
>> *Aihe:* Re: [Development] Changes to Qt offering
>>
>> Quoting The Qt Company itslef:
>>
>> Thanks for your feedback to the new online installer asking for a Qt
>>> Account signup. We have evaluated the feedback received via the blog,
>>> various discussion forums, irc and other channels. Based on all these
>>> comments and discussions with our partners we realize that this was not our
>>> finest moment.
>>> Preventing the growth and usage of Qt in the open source community is
>>> not what we want to happen. We did already see a nice jump in the number of
>>> Qt Accounts,
>>> but it was never our intention to make our valued community and
>>> contributors upset with us or stop using and contributing to Qt.
>>> *We clearly ill-calculated how asking for a Qt Account with the online
>>> installer would make our users feel*. A mistake. Sincere apologies.
>>>
>> [...]
>>> *We do hope that this eases your concerns, and that we can continue with
>>> your trust*.
>>>
>>>
>>>
>>> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

Literally this whole thing could be: "we're making a cheaper offering for
small teams" and see where it goes. Instead it's one wholesome " you!"
package to the community at large.

On Mon, Jan 27, 2020 at 7:55 PM Florian Bruhin  wrote:

> Hey,
>
> On Mon, Jan 27, 2020 at 04:00:48PM +, Tuukka Turunen wrote:
> > After the change every release of Qt will look like a non-lts release for
> > open-source users. Think of Qt 5.14 as an example. It was released in
> > December. Today it received the first patch release. There will be more
> > before next feature release is out. For open-source user Qt 5.15 will
> look
> > just like Qt 5.14 does.
>
> Except that the next release after Qt 5.15 won't be 5.16 but Qt 6.
>
> How does the transition story for open source projects look there? If the
> (security) support for Qt 5.15 is dropped as soon as Qt 6 is released, does
> that mean projects would have to migrate immediately? What if they are
> using
> third-party libraries which need to be migrated first?
>
> I'm aware that Qt 5 -> Qt 6 is supposed to be a manageable change (and
> smaller
> than 3 -> 4 or 4 -> 5). But still, expecting projects to essentially have
> migrated before Qt 6 is released isn't exactly realistic...
>
> Am I missing something there?
>
> Florian
>
> --
> m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org
>https://bruhin.software/ |
> https://github.com/sponsors/The-Compiler/
>GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
>  I love long mails! | https://email.is-not-s.ms/
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

>  A: We have had the Qt Account as an option for over 4 years, and during
that time there has been already nearly a million people who have
registered and verified their Qt Account.
And how many of them use these accounts to download qt, eh? I bet you they
only use the acc to login to bugtracker and develop qt.
No one wants to enter credentials to reinstal qt. Period.

On Mon, Jan 27, 2020 at 7:39 PM NIkolai Marchenko 
wrote:

>  > and the offline installer will become available to commercial
> licensees only
> Not to mention "free qt binaries installer" will become a third party
> thing like, immediately.
>
> On Mon, Jan 27, 2020 at 7:37 PM Benjamin TERRIER 
> wrote:
>
>> My understanding of the agreement between The Qt Company and the KDE Free
>> Qt Foundation is that if the Qt Company
>> releases a commercial Qt version without releasing the corresponding
>> open-source version within 12 months, the ownership of Qt will be
>> transferred
>> to the KDE Free Qt Foundation under a BSD license. (section 3.(ii)).
>>
>> I am pretty sure a source only release would be enough. So I bet that the
>> LTS branches will be public, but we will not have a binary release through
>> the installer.
>>
>> Le lun. 27 janv. 2020 à 17:17, Bogdan Vatra via Development <
>> development@qt-project.org> a écrit :
>>
>>> Hi Lars,
>>>
>>> În ziua de luni, 27 ianuarie 2020, la 16:34:44 EET, Lars Knoll a scris:
>>> > Hi all,
>>> [...]
>>> >
>>> > One is a change in policy regarding the LTS releases, where the LTS
>>> part of
>>> > a release is in the future going to be restricted to commercial
>>> customers.
>>> > All bug fixes will (as agreed on the Qt Contributor Summit) go into dev
>>> > first.
>>>
>>>   I was at the Qt Contributor Summit, and I can swear that I not heard
>>> anything about LTS being restricted to commercial customers...
>>>
>>> Just to be crystal clear, will you close also the branches?
>>> What will happen if I want to fix something in one of these LTS branches?
>>>
>>> > Backporting bug fixes is something that the Qt Company will take
>>> > care of for these LTS branches. We’ve seen over the past that LTS
>>> support
>>> > is something mainly required by large companies, and should hopefully
>>> help
>>> > us get some more commercial support for developing Qt further.
>>>
>>> I bet you the following scenario will happen soon:
>>> - someone will fork Qt LTS (most probably immediately after you closed
>>> these
>>> branches, if not even sooner)
>>> - the community will continue to support that fork as it's open, with
>>> improvements, bug fixes, security patches, etc.
>>> - you'll not get these patches as they are not contributed via your
>>> gerrit...
>>>
>>>
>>> > None of these changes should affect how Qt is being developed. There
>>> won’t
>>> > be any changes to Open Governance or the open development model.
>>>
>>>  If the qt5 branches will NOT be closed, then yes, you are right, if
>>> they will
>>> be closed then, I'm afraid, your statement can't stand...
>>>
>>> Cheers,
>>> BogDan.
>>>
>>>
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> https://lists.qt-project.org/listinfo/development
>>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

 > and the offline installer will become available to commercial licensees
only
Not to mention "free qt binaries installer" will become a third party thing
like, immediately.

On Mon, Jan 27, 2020 at 7:37 PM Benjamin TERRIER 
wrote:

> My understanding of the agreement between The Qt Company and the KDE Free
> Qt Foundation is that if the Qt Company
> releases a commercial Qt version without releasing the corresponding
> open-source version within 12 months, the ownership of Qt will be
> transferred
> to the KDE Free Qt Foundation under a BSD license. (section 3.(ii)).
>
> I am pretty sure a source only release would be enough. So I bet that the
> LTS branches will be public, but we will not have a binary release through
> the installer.
>
> Le lun. 27 janv. 2020 à 17:17, Bogdan Vatra via Development <
> development@qt-project.org> a écrit :
>
>> Hi Lars,
>>
>> În ziua de luni, 27 ianuarie 2020, la 16:34:44 EET, Lars Knoll a scris:
>> > Hi all,
>> [...]
>> >
>> > One is a change in policy regarding the LTS releases, where the LTS
>> part of
>> > a release is in the future going to be restricted to commercial
>> customers.
>> > All bug fixes will (as agreed on the Qt Contributor Summit) go into dev
>> > first.
>>
>>   I was at the Qt Contributor Summit, and I can swear that I not heard
>> anything about LTS being restricted to commercial customers...
>>
>> Just to be crystal clear, will you close also the branches?
>> What will happen if I want to fix something in one of these LTS branches?
>>
>> > Backporting bug fixes is something that the Qt Company will take
>> > care of for these LTS branches. We’ve seen over the past that LTS
>> support
>> > is something mainly required by large companies, and should hopefully
>> help
>> > us get some more commercial support for developing Qt further.
>>
>> I bet you the following scenario will happen soon:
>> - someone will fork Qt LTS (most probably immediately after you closed
>> these
>> branches, if not even sooner)
>> - the community will continue to support that fork as it's open, with
>> improvements, bug fixes, security patches, etc.
>> - you'll not get these patches as they are not contributed via your
>> gerrit...
>>
>>
>> > None of these changes should affect how Qt is being developed. There
>> won’t
>> > be any changes to Open Governance or the open development model.
>>
>>  If the qt5 branches will NOT be closed, then yes, you are right, if they
>> will
>> be closed then, I'm afraid, your statement can't stand...
>>
>> Cheers,
>> BogDan.
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

>  having an account for a service is not a blocker for people in general.
Unless they are on a VM and entering the password for said account is an
absolute annoyance.

Also, I would like to raise a more important change:
> and the offline installer will become available to commercial licensees
only

Now every machine that needs qt libraries needs to be connected to the
internet if it doesn't pay. No expections.
This is a completely ridiculous bullshit move.

On Mon, Jan 27, 2020 at 7:34 PM Tuukka Turunen  wrote:

>
> Hi,
>
> Well, quite many things have changed since 2015. One important item is
> that almost one million users have already voluntarily created (and
> verified) themselves a Qt account.
>
> See the FAQ (linked from the blog post):
>
> “Q: Will requiring the Qt Account drive away all Qt users?
> A: We have had the Qt Account as an option for over 4 years, and during
> that time there has been already nearly a million people who have
> registered and verified their Qt Account. It is obvious that that in the
> world that we live today having an account for a service is not a blocker
> for people in general. Everyone has the option of building Qt from sources
> if they do not like the installer, but we believe that we provide value to
> our users through the installer and the Qt Marketplace to justify the Qt
> Account.“
>
> Yours,
>
> Tuukka
>
> --
> *Lähettäjä:* Development  käyttäjän
> Benjamin TERRIER  puolesta
> *Lähetetty:* maanantaina, tammikuuta 27, 2020 6:03 ip.
> *Vastaanottaja:* Qt development mailing list
> *Aihe:* Re: [Development] Changes to Qt offering
>
> Quoting The Qt Company itslef:
>
> Thanks for your feedback to the new online installer asking for a Qt
>> Account signup. We have evaluated the feedback received via the blog,
>> various discussion forums, irc and other channels. Based on all these
>> comments and discussions with our partners we realize that this was not our
>> finest moment.
>> Preventing the growth and usage of Qt in the open source community is not
>> what we want to happen. We did already see a nice jump in the number of Qt
>> Accounts,
>> but it was never our intention to make our valued community and
>> contributors upset with us or stop using and contributing to Qt.
>> *We clearly ill-calculated how asking for a Qt Account with the online
>> installer would make our users feel*. A mistake. Sincere apologies.
>>
> [...]
>> *We do hope that this eases your concerns, and that we can continue with
>> your trust*.
>>
>>
>>
>> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>>
>
>  So apparently the trust of the QT community os nt a concern anymore...
>
> Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko 
> a écrit :
>
>> I am afraid I do not have other words for this model than : absolutely
>> disgusting and a complete dick move. Especially login requirement for
>> binaries.
>> I don't even understand how distros are now supposed to keep qt code safe
>> since constantly pushing qt version up is recipe for problems and there
>> will be no critical bugfixes to branches that distros were stabilized at.
>>
>>
>> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>>
>>> Hi all,
>>>
>>> The Qt Company has done some adjustments to the Qt will be offered in
>>> the future. Please check out
>>> https://www.qt.io/blog/qt-offering-changes-2020 .
>>>
>>> The change consists of three parts.
>>>
>>> One is a change in policy regarding the LTS releases, where the LTS part
>>> of a release is in the future going to be restricted to commercial
>>> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
>>> into dev first. Backporting bug fixes is something that the Qt Company will
>>> take care of for these LTS branches. We’ve seen over the past that LTS
>>> support is something mainly required by large companies, and should
>>> hopefully help us get some more commercial support for developing Qt
>>> further.
>>>
>>> The second change is that a Qt Account will be in the future required
>>> for binary packages. Source code will continue to be available as
>>> currently. This will simplify distribution and integration with the
>>> Marketplace. In addition, we want open source users to contribute to Qt or
>>> the Qt ecosystem. Doing so is only possible with a valid Qt Account (Jira,
>>> code review and the forums all require a Qt Account).
>>>
>>> The third change is that T

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

>  None of these changes should affect how Qt is being developed. There
won’t be any changes to Open Governance or the open development model.
But there will likely be changes to the desire of people to develop.
Imagine an opensource contributor making a security fix who knows other
opensource users on older branches aren't going to receive it and there is
no way for him to push it there.

On Mon, Jan 27, 2020 at 7:11 PM NIkolai Marchenko 
wrote:

> Just this change in general reads: "We're going to annoy and inconvenience
> as much users as possible so that they buy our stuff"
>
> On Mon, Jan 27, 2020 at 7:09 PM NIkolai Marchenko 
> wrote:
>
>> > The second change is that a Qt Account will be in the future required
>> for binary packages.
>>
>> I would like to raise a serious security issue with this change.
>> Oftentimes, you need qt binaries within a VM. Also, oftentimes, VM is
>> stubborn and refuses to accept pastes.
>> This means people will use much simpler passwords for their Qt accounts,
>> possibly similar passwords with their other stuff so that they don't have
>> to remember too much.
>> All because QtC is a dick and restricts binary downloads for no valid
>> reason at all.
>>
>> On Mon, Jan 27, 2020 at 7:01 PM Benjamin TERRIER 
>> wrote:
>>
>>> Quoting The Qt Company itslef:
>>>
>>> Thanks for your feedback to the new online installer asking for a Qt
>>>> Account signup. We have evaluated the feedback received via the blog,
>>>> various discussion forums, irc and other channels. Based on all these
>>>> comments and discussions with our partners we realize that this was not our
>>>> finest moment.
>>>> Preventing the growth and usage of Qt in the open source community is
>>>> not what we want to happen. We did already see a nice jump in the number of
>>>> Qt Accounts,
>>>> but it was never our intention to make our valued community and
>>>> contributors upset with us or stop using and contributing to Qt.
>>>> *We clearly ill-calculated how asking for a Qt Account with the online
>>>> installer would make our users feel*. A mistake. Sincere apologies.
>>>>
>>> [...]
>>>> *We do hope that this eases your concerns, and that we can continue
>>>> with your trust*.
>>>>
>>>>
>>>>
>>>> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>>>>
>>>
>>>  So apparently the trust of the QT community os nt a concern anymore...
>>>
>>> Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko <
>>> enmarantis...@gmail.com> a écrit :
>>>
>>>> I am afraid I do not have other words for this model than : absolutely
>>>> disgusting and a complete dick move. Especially login requirement for
>>>> binaries.
>>>> I don't even understand how distros are now supposed to keep qt code
>>>> safe since constantly pushing qt version up is recipe for problems and
>>>> there will be no critical bugfixes to branches that distros were stabilized
>>>> at.
>>>>
>>>>
>>>> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> The Qt Company has done some adjustments to the Qt will be offered in
>>>>> the future. Please check out
>>>>> https://www.qt.io/blog/qt-offering-changes-2020 .
>>>>>
>>>>> The change consists of three parts.
>>>>>
>>>>> One is a change in policy regarding the LTS releases, where the LTS
>>>>> part of a release is in the future going to be restricted to commercial
>>>>> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
>>>>> into dev first. Backporting bug fixes is something that the Qt Company 
>>>>> will
>>>>> take care of for these LTS branches. We’ve seen over the past that LTS
>>>>> support is something mainly required by large companies, and should
>>>>> hopefully help us get some more commercial support for developing Qt
>>>>> further.
>>>>>
>>>>> The second change is that a Qt Account will be in the future required
>>>>> for binary packages. Source code will continue to be available as
>>>>> currently. This will simplify distribution and integration with the
>>>>> Marketplace. In addition, we want open source users to contri

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

Just this change in general reads: "We're going to annoy and inconvenience
as much users as possible so that they buy our stuff"

On Mon, Jan 27, 2020 at 7:09 PM NIkolai Marchenko 
wrote:

> > The second change is that a Qt Account will be in the future required
> for binary packages.
>
> I would like to raise a serious security issue with this change.
> Oftentimes, you need qt binaries within a VM. Also, oftentimes, VM is
> stubborn and refuses to accept pastes.
> This means people will use much simpler passwords for their Qt accounts,
> possibly similar passwords with their other stuff so that they don't have
> to remember too much.
> All because QtC is a dick and restricts binary downloads for no valid
> reason at all.
>
> On Mon, Jan 27, 2020 at 7:01 PM Benjamin TERRIER 
> wrote:
>
>> Quoting The Qt Company itslef:
>>
>> Thanks for your feedback to the new online installer asking for a Qt
>>> Account signup. We have evaluated the feedback received via the blog,
>>> various discussion forums, irc and other channels. Based on all these
>>> comments and discussions with our partners we realize that this was not our
>>> finest moment.
>>> Preventing the growth and usage of Qt in the open source community is
>>> not what we want to happen. We did already see a nice jump in the number of
>>> Qt Accounts,
>>> but it was never our intention to make our valued community and
>>> contributors upset with us or stop using and contributing to Qt.
>>> *We clearly ill-calculated how asking for a Qt Account with the online
>>> installer would make our users feel*. A mistake. Sincere apologies.
>>>
>> [...]
>>> *We do hope that this eases your concerns, and that we can continue with
>>> your trust*.
>>>
>>>
>>>
>>> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>>>
>>
>>  So apparently the trust of the QT community os nt a concern anymore...
>>
>> Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko 
>> a écrit :
>>
>>> I am afraid I do not have other words for this model than : absolutely
>>> disgusting and a complete dick move. Especially login requirement for
>>> binaries.
>>> I don't even understand how distros are now supposed to keep qt code
>>> safe since constantly pushing qt version up is recipe for problems and
>>> there will be no critical bugfixes to branches that distros were stabilized
>>> at.
>>>
>>>
>>> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>>>
>>>> Hi all,
>>>>
>>>> The Qt Company has done some adjustments to the Qt will be offered in
>>>> the future. Please check out
>>>> https://www.qt.io/blog/qt-offering-changes-2020 .
>>>>
>>>> The change consists of three parts.
>>>>
>>>> One is a change in policy regarding the LTS releases, where the LTS
>>>> part of a release is in the future going to be restricted to commercial
>>>> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
>>>> into dev first. Backporting bug fixes is something that the Qt Company will
>>>> take care of for these LTS branches. We’ve seen over the past that LTS
>>>> support is something mainly required by large companies, and should
>>>> hopefully help us get some more commercial support for developing Qt
>>>> further.
>>>>
>>>> The second change is that a Qt Account will be in the future required
>>>> for binary packages. Source code will continue to be available as
>>>> currently. This will simplify distribution and integration with the
>>>> Marketplace. In addition, we want open source users to contribute to Qt or
>>>> the Qt ecosystem. Doing so is only possible with a valid Qt Account (Jira,
>>>> code review and the forums all require a Qt Account).
>>>>
>>>> The third change is that The Qt Company will in the future also offer a
>>>> lower priced product for small businesses. That small business product is
>>>> btw not limited to mobile like the one Digia had some years ago, but covers
>>>> all of Qt for Device Creation.
>>>>
>>>> None of these changes should affect how Qt is being developed. There
>>>> won’t be any changes to Open Governance or the open development model.
>>>>
>>>> Best regards,
>>>> Lars
>>>>
>>>> ___
>>>> Development mailing list
>>>> Development@qt-project.org
>>>> https://lists.qt-project.org/listinfo/development
>>>>
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> https://lists.qt-project.org/listinfo/development
>>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

> The second change is that a Qt Account will be in the future required for
binary packages.

I would like to raise a serious security issue with this change.
Oftentimes, you need qt binaries within a VM. Also, oftentimes, VM is
stubborn and refuses to accept pastes.
This means people will use much simpler passwords for their Qt accounts,
possibly similar passwords with their other stuff so that they don't have
to remember too much.
All because QtC is a dick and restricts binary downloads for no valid
reason at all.

On Mon, Jan 27, 2020 at 7:01 PM Benjamin TERRIER 
wrote:

> Quoting The Qt Company itslef:
>
> Thanks for your feedback to the new online installer asking for a Qt
>> Account signup. We have evaluated the feedback received via the blog,
>> various discussion forums, irc and other channels. Based on all these
>> comments and discussions with our partners we realize that this was not our
>> finest moment.
>> Preventing the growth and usage of Qt in the open source community is not
>> what we want to happen. We did already see a nice jump in the number of Qt
>> Accounts,
>> but it was never our intention to make our valued community and
>> contributors upset with us or stop using and contributing to Qt.
>> *We clearly ill-calculated how asking for a Qt Account with the online
>> installer would make our users feel*. A mistake. Sincere apologies.
>>
> [...]
>> *We do hope that this eases your concerns, and that we can continue with
>> your trust*.
>>
>>
>>
>> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>>
>
>  So apparently the trust of the QT community os nt a concern anymore...
>
> Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko 
> a écrit :
>
>> I am afraid I do not have other words for this model than : absolutely
>> disgusting and a complete dick move. Especially login requirement for
>> binaries.
>> I don't even understand how distros are now supposed to keep qt code safe
>> since constantly pushing qt version up is recipe for problems and there
>> will be no critical bugfixes to branches that distros were stabilized at.
>>
>>
>> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>>
>>> Hi all,
>>>
>>> The Qt Company has done some adjustments to the Qt will be offered in
>>> the future. Please check out
>>> https://www.qt.io/blog/qt-offering-changes-2020 .
>>>
>>> The change consists of three parts.
>>>
>>> One is a change in policy regarding the LTS releases, where the LTS part
>>> of a release is in the future going to be restricted to commercial
>>> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
>>> into dev first. Backporting bug fixes is something that the Qt Company will
>>> take care of for these LTS branches. We’ve seen over the past that LTS
>>> support is something mainly required by large companies, and should
>>> hopefully help us get some more commercial support for developing Qt
>>> further.
>>>
>>> The second change is that a Qt Account will be in the future required
>>> for binary packages. Source code will continue to be available as
>>> currently. This will simplify distribution and integration with the
>>> Marketplace. In addition, we want open source users to contribute to Qt or
>>> the Qt ecosystem. Doing so is only possible with a valid Qt Account (Jira,
>>> code review and the forums all require a Qt Account).
>>>
>>> The third change is that The Qt Company will in the future also offer a
>>> lower priced product for small businesses. That small business product is
>>> btw not limited to mobile like the one Digia had some years ago, but covers
>>> all of Qt for Device Creation.
>>>
>>> None of these changes should affect how Qt is being developed. There
>>> won’t be any changes to Open Governance or the open development model.
>>>
>>> Best regards,
>>> Lars
>>>
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> https://lists.qt-project.org/listinfo/development
>>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

>  I expect security fixes
but that's basically what an LTS is ... isn't it?

On Mon, Jan 27, 2020 at 6:33 PM Ville Voutilainen <
ville.voutilai...@gmail.com> wrote:

> On Mon, 27 Jan 2020 at 17:27, NIkolai Marchenko 
> wrote:
> >
> > >  they will be available 12 months after their commercial release
> >
> > That's 12 months for cybercriminals to exploit already fixed
> vulnerabilities in open source distros...
>
> I expect security fixes to be made available to everyone, licensed
> customer or not. Whether my expectation is correct
> remains to be seen.
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

>  they will be available 12 months after their commercial release

That's 12 months for cybercriminals to exploit already fixed
vulnerabilities in open source distros...

On Mon, Jan 27, 2020 at 6:23 PM Ville Voutilainen <
ville.voutilai...@gmail.com> wrote:

> On Mon, 27 Jan 2020 at 16:52, coroberti .  wrote:
> >
> > Dear Lars,
> > What about sources of LTS versions? Could they be still available?
>
> As far as I understand things, the KDE Free Qt Foundation agreement
> ensures that they will be available
> 12 months after their commercial release. The blog entry doesn't seem
> to mention this point.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

I understand the reasoning for this change but it effectively ruins the
spirit of open-source~ness of qt while technically leaving it intact.
Technically

On Mon, Jan 27, 2020 at 5:41 PM NIkolai Marchenko 
wrote:

> I am afraid I do not have other words for this model than : absolutely
> disgusting and a complete dick move. Especially login requirement for
> binaries.
> I don't even understand how distros are now supposed to keep qt code safe
> since constantly pushing qt version up is recipe for problems and there
> will be no critical bugfixes to branches that distros were stabilized at.
>
>
> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>
>> Hi all,
>>
>> The Qt Company has done some adjustments to the Qt will be offered in the
>> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020
>> .
>>
>> The change consists of three parts.
>>
>> One is a change in policy regarding the LTS releases, where the LTS part
>> of a release is in the future going to be restricted to commercial
>> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
>> into dev first. Backporting bug fixes is something that the Qt Company will
>> take care of for these LTS branches. We’ve seen over the past that LTS
>> support is something mainly required by large companies, and should
>> hopefully help us get some more commercial support for developing Qt
>> further.
>>
>> The second change is that a Qt Account will be in the future required for
>> binary packages. Source code will continue to be available as currently.
>> This will simplify distribution and integration with the Marketplace. In
>> addition, we want open source users to contribute to Qt or the Qt
>> ecosystem. Doing so is only possible with a valid Qt Account (Jira, code
>> review and the forums all require a Qt Account).
>>
>> The third change is that The Qt Company will in the future also offer a
>> lower priced product for small businesses. That small business product is
>> btw not limited to mobile like the one Digia had some years ago, but covers
>> all of Qt for Device Creation.
>>
>> None of these changes should affect how Qt is being developed. There
>> won’t be any changes to Open Governance or the open development model.
>>
>> Best regards,
>> Lars
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[NIkolai Marchenko]

I am afraid I do not have other words for this model than : absolutely
disgusting and a complete dick move. Especially login requirement for
binaries.
I don't even understand how distros are now supposed to keep qt code safe
since constantly pushing qt version up is recipe for problems and there
will be no critical bugfixes to branches that distros were stabilized at.


On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:

> Hi all,
>
> The Qt Company has done some adjustments to the Qt will be offered in the
> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020
> .
>
> The change consists of three parts.
>
> One is a change in policy regarding the LTS releases, where the LTS part
> of a release is in the future going to be restricted to commercial
> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
> into dev first. Backporting bug fixes is something that the Qt Company will
> take care of for these LTS branches. We’ve seen over the past that LTS
> support is something mainly required by large companies, and should
> hopefully help us get some more commercial support for developing Qt
> further.
>
> The second change is that a Qt Account will be in the future required for
> binary packages. Source code will continue to be available as currently.
> This will simplify distribution and integration with the Marketplace. In
> addition, we want open source users to contribute to Qt or the Qt
> ecosystem. Doing so is only possible with a valid Qt Account (Jira, code
> review and the forums all require a Qt Account).
>
> The third change is that The Qt Company will in the future also offer a
> lower priced product for small businesses. That small business product is
> btw not limited to mobile like the one Digia had some years ago, but covers
> all of Qt for Device Creation.
>
> None of these changes should affect how Qt is being developed. There won’t
> be any changes to Open Governance or the open development model.
>
> Best regards,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Two-digit dates: what century should we use ?

[NIkolai Marchenko]

>  If you want to make it easier for people to implement their
interpretation of 2-digit years, you could add an (optional) explicit
window to the QDate::fromString API?
that would actually be very appreciated

On Wed, Nov 6, 2019 at 11:46 AM Eike Ziller  wrote:

> It sounds to me like any automatically chosen base for 2-digit years will
> be wrong depending on use case.
> For some applications, only the past is relevant.
> For some applications, dates N years into the future are relevant.
> If we choose any N for a window, that can be wrong for some application.
> Even if the format is Qt::SystemLocaleShortDate, we do not know if that
> refers to the “current date”.
> Even if the round trip is made correct for QDate::currentDate(), it will
> be wrong for other dates.
> API that behaves differently depending on current date becomes difficult
> to test.
>
> If you want to make it easier for people to implement their interpretation
> of 2-digit years, you could add an (optional) explicit window to the
> QDate::fromString API?
>
> Br, Eike
>
> > On Nov 5, 2019, at 14:44, Edward Welbourne 
> wrote:
> >
> > Hi all,
> >
> > Prompted by [0], I'm looking at what century to use for years, when the
> > text being read is expected to be in a "short format" that only includes
> > two digits.
> > * [0] https://bugreports.qt.io/browse/QTBUG-74323
> >
> > tl;dr - how do folk feel about (in Qt 6) a century-wide window, ending a
> > decade or three ahead of QDate::currentDate(), and placing any two-digit
> > year in that range ?
> >
> > Before anyone says "Don't Do That" (or "why would anyone use two-digit
> > years after the mess of y2k ?"), bear in mind that CLDR (the Unicode
> > consortium's common locale data repository, on which QLocale's data is
> > based) provides short date formats, many of which use two-digit years.
> >
> > We currently fail to round-trip dates via such formats because 1900 is
> > used as default year when no year is specified and (thus) 19 is used as
> > default century number when only the later digits are (understood to be)
> > specified.  As we get further into the twenty-hundreds (as it were), this
> > shall grow to be an increasing jarring flaw in date format handling.
> >
> > I'm considering changing that: since it's a material behaviour change,
> > it clearly needs to happen as part of Qt 6, which at least gives me a
> > few months to discuss it and see what folk think is a better plan than
> > what we have.
> >
> > It's notable that ECMAScript's Date constructor adds 1900 to any year
> > number from 0 through 99 (even if supplied as one of a sequence of
> > integer arguments, not a string), causing problems for the
> > representation of dates from 1 BCE through 99 CE.  (I must remember to
> > tease my friend on the ECMA 262 committee about that - his excuse will
> > be that it was copied from an early version of Java, I suspect - and see
> > if he can coax them into changing it.)  Likewise, C's struct tm (used by
> > mktime and friends) has a 1900 offset on its year number: that's
> > probably never going to change, perverse as it is and shall increasingly
> > be.
> >
> > Folk still talk about "The fifties" and mean the 1950s; probably
> > likewise the forties, thirties and even twenties.  That last, at least,
> > shall soon be something of a problem.  Folk can see more of the past
> > than of the future, so perhaps it's not much of a surprise that common
> > nomenclature reserves short phrases for the past at the expense of the
> > future: "The sixties" shall be in the past for a few decades yet, I
> > think.  So rather than having a default century, and maybe changing it
> > abruptly to 20 at some point in the next fifty years, I think it would
> > be better to have two-digit years coerced into a century-wide window
> > about the (forever moving) present.
> >
> > Perhaps we should make that a narrower window and treat roughly a decade
> > near the wrap-around as error - e.g. using 1945--2035 as our year range,
> > with two-digit years 36 through 44 treated as undecodable.
> >
> > The question then arises: what year-range should we use ?
> >
> > Two things I'm fairly sure should be true are:
> > * the current year (i.e. QDate::currentDate().year(), naturally) should
> >  be included in the range;
> > * the range should be contiguous.
> >
> > So the interesting questions are:
> > * how far into the past and future should the range reach ?
> > * how wide a buffer (if any) should we leave ?
> >
> > If we don't have a buffer, my inclination is to put the transition date
> > at a decade boundary, e.g. 49 -> 2049 but 50 -> 1950, as this shall feel
> > less perverse to most folk than having a mid-decade transition such as
> > 44 -> 2044 but 45 -> 1945.  However, with a buffer, this problem goes
> > away, as there aren't adjacent two-digit numbers that map to wildly
> > different years; instead, the intervening numbers that aren't handled
> > make the discontinuity seem more sensible.  In 

Re: [Development] Two-digit dates: what century should we use ?

[NIkolai Marchenko]

I would like to point out that every codebase that has two work with double
digits is so full of assumptions about what to do with those that by
changing the behaviour you will undoubtedly break stuff.
I know because I am working with one (aviation traffic).

It's not so much a discouragement from doing it (otherwise qt will still
use 90s base in 2100) as a warning of what to expect

On Tue, Nov 5, 2019 at 4:46 PM Edward Welbourne 
wrote:

> Hi all,
>
> Prompted by [0], I'm looking at what century to use for years, when the
> text being read is expected to be in a "short format" that only includes
> two digits.
> * [0] https://bugreports.qt.io/browse/QTBUG-74323
>
> tl;dr - how do folk feel about (in Qt 6) a century-wide window, ending a
> decade or three ahead of QDate::currentDate(), and placing any two-digit
> year in that range ?
>
> Before anyone says "Don't Do That" (or "why would anyone use two-digit
> years after the mess of y2k ?"), bear in mind that CLDR (the Unicode
> consortium's common locale data repository, on which QLocale's data is
> based) provides short date formats, many of which use two-digit years.
>
> We currently fail to round-trip dates via such formats because 1900 is
> used as default year when no year is specified and (thus) 19 is used as
> default century number when only the later digits are (understood to be)
> specified.  As we get further into the twenty-hundreds (as it were), this
> shall grow to be an increasing jarring flaw in date format handling.
>
> I'm considering changing that: since it's a material behaviour change,
> it clearly needs to happen as part of Qt 6, which at least gives me a
> few months to discuss it and see what folk think is a better plan than
> what we have.
>
> It's notable that ECMAScript's Date constructor adds 1900 to any year
> number from 0 through 99 (even if supplied as one of a sequence of
> integer arguments, not a string), causing problems for the
> representation of dates from 1 BCE through 99 CE.  (I must remember to
> tease my friend on the ECMA 262 committee about that - his excuse will
> be that it was copied from an early version of Java, I suspect - and see
> if he can coax them into changing it.)  Likewise, C's struct tm (used by
> mktime and friends) has a 1900 offset on its year number: that's
> probably never going to change, perverse as it is and shall increasingly
> be.
>
> Folk still talk about "The fifties" and mean the 1950s; probably
> likewise the forties, thirties and even twenties.  That last, at least,
> shall soon be something of a problem.  Folk can see more of the past
> than of the future, so perhaps it's not much of a surprise that common
> nomenclature reserves short phrases for the past at the expense of the
> future: "The sixties" shall be in the past for a few decades yet, I
> think.  So rather than having a default century, and maybe changing it
> abruptly to 20 at some point in the next fifty years, I think it would
> be better to have two-digit years coerced into a century-wide window
> about the (forever moving) present.
>
> Perhaps we should make that a narrower window and treat roughly a decade
> near the wrap-around as error - e.g. using 1945--2035 as our year range,
> with two-digit years 36 through 44 treated as undecodable.
>
> The question then arises: what year-range should we use ?
>
> Two things I'm fairly sure should be true are:
> * the current year (i.e. QDate::currentDate().year(), naturally) should
>   be included in the range;
> * the range should be contiguous.
>
> So the interesting questions are:
> * how far into the past and future should the range reach ?
> * how wide a buffer (if any) should we leave ?
>
> If we don't have a buffer, my inclination is to put the transition date
> at a decade boundary, e.g. 49 -> 2049 but 50 -> 1950, as this shall feel
> less perverse to most folk than having a mid-decade transition such as
> 44 -> 2044 but 45 -> 1945.  However, with a buffer, this problem goes
> away, as there aren't adjacent two-digit numbers that map to wildly
> different years; instead, the intervening numbers that aren't handled
> make the discontinuity seem more sensible.  In principle a one year
> buffer would suffice, but I'm inclined to make the gap a decade long, or
> more, if we have one.
>
> If QDate::currentDate().year() is C and (C / 10) * 10 is D, either of
> these ranges strikes me as better than the 1900--1999 that we're
> currently using:
> * D -70 <= year < D+30 (all two-digit values handled)
> * C -65 <= year <= C +25 (othet two-digit values rejected)
>
> So, to my questions:
> * Does anyone want to make the case for keeping 1900--1999 as range ?
> * Has anyone a better suggestion for how to chose a rolling range ?
> * Should we have a buffer ?  If so, how wide ?
> * How far into the past and future should the range reach ?
>
> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> 

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

[NIkolai Marchenko]

>  Note: DO NOT use -static with MSVC 2017.
Can you provide the link to the bug in question? I've seen you mention it
several times and I am curious.

On Thu, Aug 22, 2019 at 12:58 AM Thiago Macieira 
wrote:

> On Wednesday, 21 August 2019 13:26:48 PDT Henry Skoglund wrote:
> > I thought Qt required /MD, but maybe I am an /MT ignoramus, if Qt can be
> > happily built using /MT then that would beat MinGW, since such an .exe
> > wouldn't then even require msvcrt.dll.
>
> It can be. That's what the -static-runtime option to configure does
> (additional to -static).
>
> Note: DO NOT use -static with MSVC 2017.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maybe add some kind of accessible pipeline for QSettings serialization in Qt6?

[NIkolai Marchenko]

No, we want to completely forego the qt way of storing settings.
Fully custom class that won't interact with qsettings and won't have
qvarianthash behind the storage.

On Tue, Jul 9, 2019 at 6:16 PM Konstantin Tokarev  wrote:

>
>
> 09.07.2019, 18:12, "NIkolai Marchenko" :
> > We (at our company) realy, REALLY don't like qsettings for a multitude
> of reasons but are forced to deal with it because the details of how UI
> types are saved are hidden deep in the qt's implementation and are subject
> to any kind of changes qt wants.
> >
> > What we would really like is to have functions for all of this that hide
> implementation but do expose the inputs/outputs of how settings of Qt's
> classes are saved and loaded so that we can feed those into a separate
> settings class to be stored and managed externally.
> >
> > Can it be done with Qt6?
>
> Do you mean https://doc.qt.io/qt-5/qsettings.html#registerFormat or
> something else?
>
> --
> Regards,
> Konstantin
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Maybe add some kind of accessible pipeline for QSettings serialization in Qt6?

[NIkolai Marchenko]

We (at our company) realy, REALLY don't like qsettings for a multitude of
reasons but are forced to deal with it because the details of how UI types
are saved are hidden deep in the qt's implementation and are subject to any
kind of changes qt wants.

What we would really like is to have functions for all of this that hide
implementation but do expose the inputs/outputs of how settings of Qt's
classes are saved and loaded so that we can feed those into a separate
settings class to be stored and managed externally.

Can it be done with Qt6?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[NIkolai Marchenko]

> So far nobody has stepped up to attempt to replace the mo
https://github.com/woboq/verdigris   not quite true

On Thu, May 30, 2019 at 9:59 PM Simon Hausmann  wrote:

> So far nobody has stepped up to attempt to replace the moc, so I doubt
> that it will be replaced in Qt 6.
>
> Simon
>
> > On 30. May 2019, at 20:46, Konstantin Tokarev  wrote:
> >
> >
> >
> > 30.05.2019, 21:18, "Thiago Macieira" :
> >> On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development
> >> wrote:
> >>> 2) should QRegExp stay in bootstrap? I have no idea of what's happening
> >>> regarding to that in Qt 6.
> >>
> >> Bootstrap needs to go away in Qt 6.
> >
> > Does it mean that moc will be reimplemented to avoid using Qt classes?
> >
> > --
> > Regards,
> > Konstantin
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

One change that is relatively painless but will set things for the later
reintroduction of QList as a proper class would be with Qt6 force rename
QList instances to Qt5SupportList.
Note that if it's done at the same time as removal of QList from Qt
interfaces entirely, then it's a simple pass of batch rename and then
replugging into Qt interfaces with actual correct classes.

The benefits of this are:
1) QList is officially deprecated and discouraged by its very name
2) Usercode that doesn't interface with Qt systems needs not be changed
outside the rename which can be fully automatic instead of on case by case
instance.
3) Come Qt7 QList can be reintroduced with an entirely different
implementation (because losing that name forever seems excessive)

On Fri, May 24, 2019 at 2:23 PM Konstantin Tokarev 
wrote:

>
>
> 24.05.2019, 13:32, "Konstantin Tokarev" :
> > 24.05.2019, 13:06, "NIkolai Marchenko" :
> >>  All of the back and forth on this issue recently and over the years
> really make want to ask this question:
> >>
> >>  Is the promise of SC worth all the potenital pitfalls? There seems to
> be no end to the discussion with every solution requiriring hair rising
> compromises.
> >>  Is it _really_ that impossible to just remove QLIst entirely and force
> user to choose form a range of classes each tailored for the specific
> scenario that QList tried to cover?
> >>
> >>  As it is, it seems like we're rapidly heading to a nightmarish
> scenario worse than any SC breakage, where users will have to looks for
> problems in a perfectly compiling code.
> >>
> >>  Is the gordian knot of full SC really possible to unravel or is it
> time to axe it?
> >
> > If we remove QList, users with thousands of occurrences of QList in code
> base will likely do
> > mechanical replacement s/QList/QVector/g, or use the same template alias
> as it was proposed
> > earlier in this thread.
> >
> > To axe this problem, automatic clang-based porting tool is needed. Such
> tool would analyze
> > context and do a replacement of QList to QVector in places where it's
> least likely to introduce
> > issues, e.g. where QList is used with movable types which are not larger
> than void*, or where
> > QList is used as a local variable and it's possible to prove that
> references or iterators pointing
> > to this local QList members are never used after QList modification.
> >
> > If users end up with little manual work, it's more likely that they will
> carefully analyze all remaining
> > cases.
>
> Actually, clazy provides related checks "inefficient-qlist". I think
> following plan can work:
>
> 1. Implement opposite "replace-efficient-qlist-to-qvector" check in clazy
> which finds QList
> where sizeof(T) <= sizeof(void*) and T is movable, and allows automatic
> replacement with QVector
>
> 2. Apply this transformation to all public and private Qt APIs, and
> refrain from QList replacements
> in places which are not sanctioned by tool.
>
> 3. Implement clazy check "inefficient-qvector-insert" which warns when
> prepend/push_front and
> insert into middle are used with QVector.
>
> Algorithm of porting to Qt 6 could be:
>
> 1. Run inefficient-qvector-insert over code base and store results
> 2. Apply replace-efficient-qlist-to-qvector to whole code base
> 3. Run inefficient-qvector-insert again and make a diff with step 1, and
> suggest user to check
> these cases carefully for possible reference issues and performance
> regressions
>
> Results:
> 1. Do a big chunk of worldwide QList elemination without compatibility
> hacks and with relatively
> low risk
> 2. Users should finally get the message that QList is not the go-to
> container preferred in most cases.
>
> Porting other part of QList usages can be delayed to Qt7.
>
> --
> Regards,
> Konstantin
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

All of the back and forth on this issue recently and over the years really
make want to ask this question:

Is the promise of SC worth all the potenital pitfalls? There seems to be no
end to the discussion with every solution requiriring hair rising
compromises.
Is it _really_ that impossible to just remove QLIst entirely and force user
to choose form a range of classes each tailored for the specific scenario
that QList tried to cover?

As it is, it seems like we're rapidly heading to a nightmarish scenario
worse than any SC breakage, where users will have to looks for problems in
a perfectly compiling code.

Is the gordian knot of full SC really possible to unravel or is it time to
axe it?



On Fri, May 24, 2019 at 12:04 PM Lars Knoll  wrote:

> > On 24 May 2019, at 10:19, Mutz, Marc via Development <
> development@qt-project.org> wrote:
> >
> > On 2019-05-24 09:35, Lars Knoll wrote:
> >>> On 23 May 2019, at 13:26, Mutz, Marc via Development <
> development@qt-project.org> wrote:
> > [...]
> >>> You said that QList should vanish from Qt API. So we don't care. We'll
> have that switch to make QList _be_ QVector for ese of porting, but as a
> template alias. There's your zero-copy conversion :) That leaves users. And
> I repeat: I'd leave QList alone (as QArrayList, possibly with always
> IndirectLayout), and just have implicit deprecated conversions between
> QArrayList and QVector. You shouldn't care about performance of unported
> code: It's easy to target both Qt 5 and Qt 6 if you use auto for receiving
> from Qt API. For sending to Qt API, it's a bit more tricky. You need to
> ifdef or live with the implicit conversion in a Qt 6 build, but it's not
> something that we should optimize for. Really. Don’t.
> >> Sorry, but no. Larger performance regressions that are not really
> >> visible/cought at compile time can be as large a headache to our users
> >> as the non stable references to data in the container.
> >
> > Sorry, you're comparing apples and oranges, iow: a performance issue
> with a correctness issue. You cannot weigh them against each other. We need
> to ensure that user code stays correct _first_, fast _second_. The first
> rule of optimisation: Don't do it. The second rule: Don't do it _yet_.
> Write correct code first, optimize later. You can't turn that around. It'd
> send a catastrophic signal to Qt users.
>
> Yes, both are different things. But for a user moving from Qt 5 to Qt 6,
> it mainly matters how he is affected by this.
>
> And there might be quite a few people who will never hit the problem with
> stability of references (because storing a reference to a member of the
> list is not that common), but they will be seeing performance issues
> because of the implicit (and hidden) conversion.
>
> >
> > Here's how I see it: performance problems show up in testing, and are
> easily identified by a profiler, a tool that is available on every platform
> and everyone knows how to use it. Stability of references problems are
> found, if at all, by memory sanitizers, something that much less people
> will be familiar with, and, crucially, might hide in less-well tested code.
> >
> >> I’d argue that it might cause the larger amount of problems as keeping
> >> references to data in the container is something that’s not used very
> >> often. But *everybody* will have tons of conversions between QList and
> >> QVector with your plan for unported code. IMO that’s just as bad.
> >
> > I disagree. See above. I'd like to add, if I may be so bold, that seeing
> just how widespread unintended detaches are _even in Qt code_, are you
> _actually_ going to tell me that copying a QVector into a QList is going to
> be _noticeable_? It has O(detach) complexity. Yes, in the 5% of code, it
> might get slower (if there wasn't an unintended detach to begin with), but
> as I said: it's easily identified with the simplest of tools: a profiler,
> and in normal testing. The correctness issue may be hiding in the 95% that
> is less well maintained.
>
> Profilers help with real hot spots. They don’t really help a lot if those
> things are spread all over your code base.
> >
> > Please tell me that I misunderstood you and that you are _not_ going to
> prefer to optimize for speed of _unported_ code, sacrificing correctness of
> the same?
>
> You conveniently didn’t quote the first part of my answer. I didn’t say
> that. I said I really want to ensure that we get a zero copy conversion
> between QList and QVector where this doesn’t imply (possible) incorrectness
> in the code. That’s the case for all types that are smaller than a pointer
> and movable.
>
> Lars
>
> >
> > Please?
> >
> > Thanks,
> > Marc
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> 

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

True. I am just trying to provide alternative view. I am perhaps
overexaggerating a bit, but I still think this is something that needs to
be considered.
And yeah, QList=QArrayList should definitely be a default setting

On Wed, May 22, 2019 at 9:00 PM Giuseppe D'Angelo 
wrote:

> Il 22/05/19 19:29, NIkolai Marchenko ha scritto:
> > I do not see how this addresses the issue. You are pushing the decision
> > to use the compile switch or not on the same userbase who couldn't be
> > bothered to port away from qlist in the first place.
> > You are essenitally asking: "Are you sure you aren't using qlist in
> > specific ways?"
> > And the likely answer in the end will be "Eh, ps ... hehehe"
> >
> > People will use the "faster" non compatible compilation switch and
> > *will* break their code. It won't be Qt's fault but it *will* be
> > perceived as such.
>
> This is highly debatable. Sure, there's lots of cargo cult mentality in
> the software industry, and this could be used to shift the blame on Qt.
> On the other hand there's only so much we can do in terms of warning
> users about the consequences of flipping the switch in their _pre
> existing_ code base.
>
> (Switch that I'd like to keep in the QList=QArrayList by default.)
>
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

Ugh, apparently I answered to Lars directly instead of the whole ML >_< See
below

I do not see how this addresses the issue. You are pushing the decision to
use the compile switch or not on the same userbase who couldn't be bothered
to port away from qlist in the first place.
You are essenitally asking: "Are you sure you aren't using qlist in
specific ways?"
And the likely answer in the end will be "Eh, ps ... hehehe"

People will use the "faster" non compatible compilation switch and *will*
break their code. It won't be Qt's fault but it *will* be perceived as such.



On Wed, May 22, 2019 at 4:50 PM Lars Knoll  wrote:

> Let’s conclude the topic of QList. I do see the concern about silent
> source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
>
> 1. Rename QList to QArrayList and make QList an alias to QArrayList
> 2. Move QStringList and QByteArrayList over to inherit from QVector (that
> should be source compatible)
> 3. Rename QStringList to QStringVector (keep QStringList as a
> compatibility name), same for QBAList
> 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64)
> and Foo is movable. I’m intentionally not using sizeof(void *) here, as
> types with sizes between 4 and 8 bytes would not have stable references in
> cross platform code, so I do not believe lots of code would assume that (or
> it would have broken on 64 bit).
> 5. Add a compile time switch that allows mapping QList completely to
> QVector or to a compatibility mode where QLists of large/non movable types
> are mapped to QArrayList
> 6. For now we don’t yet want to explicitly change all our API that uses
> QList to use QVector (as that would make merging from dev a pain, let’s do
> that later this year). But to test that everything we have works with
> QVector, we’ll set the compile switch to default to mapping to QVector.
> 7. Make the implementation of QArrayList fully inline and deprecate the
> class.
>
> Let me know if there are any major concerns with this plan. It should give
> us a good compromise, where we can move all of Qt over to QVector and test
> things early, as well as providing a compatibility mode for our users
> (slower but won’t silently break).
>
> Cheers,
> Lars
>
> > On 21 May 2019, at 10:38, Giuseppe D'Angelo via Development <
> development@qt-project.org> wrote:
> >
> > Il 21/05/19 10:30, Konstantin Shegunov ha scritto:
> >> That's a hard one. Especially since very few could keep in their brain
> a list of the sizes of each and every one class from Qt. It also differs
> depending on architecture.
> >
> > I know. That's my point: we can't just break this level of source
> compatibility.
> >
> > Thanks,
> >
> > --
> > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> > KDAB (France) S.A.S., a KDAB Group company
> > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> > KDAB - The Qt, C++ and OpenGL Experts
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

This rather nicely proves my point. Jason isn't even new to this list and
he didn't realize the problems.
No, community as a whole did _not _ have "years and years" to port away
from QList

On Mon, May 20, 2019 at 6:07 PM Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> > QList is just a linked list
>
> you're in for a rude awakening :-) https://doc.qt.io/qt-5/qlist.html
>
> On Mon, May 20, 2019 at 5:03 PM Jason H  wrote:
>
>>
>> > Ok, QList as an alias for QVector takes care of the technical issues I
>> > have with using inheritance. It doesn't address my concerns regarding
>> > breaking QList behaviour. What purpose is served to call something QList
>> > that is in fact a QVector? Please spell it out for me, as I don't see
>> > it.
>>
>> My understanding is that QVector requires contiguous memory, consuming a
>> giant block for all the items in the list. QList is just a linked list.
>> QVector will fail sooner when memory fragmentation is a problem. I would
>> expect systems with long-running processes and limited RAM (i.e. embedded,
>> a Raspberry Pi, phone, etc) to encounter this sooner than other systems,
>> especially when the size of each object is large. (You could always just
>> store pointers though)
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

For the record: I would also prefer QList to vanish from Qt's interfaces
rather than change its meaning everywhere it's used.
Better have explicit porting than subtle hard to track bugs.

On Mon, May 20, 2019 at 3:41 PM Mutz, Marc via Development <
development@qt-project.org> wrote:

> Hi Lars,
>
> I'm on record for claiming QList needs to die, and I work for a company
> that still makes part of its living by porting Qt 3 apps to Qt 4 (and
> 5). So I should be celebrating if you create more potential work for
> KDAB, but I'm actually ok with keeping QList.
>
> Provided it vanishes from each and every Qt API.
>
> Whether to call it Q5List or QArrayList or continue with QList doesn't
> matter. Actually, I'd err on keeping QList, to minimize porting. What I
> want to avoid is to break user code silently. Asan is a runtime-checker,
> the code must actually be exercised, which is trivial for QToolBox but
> might be problematic if it's in, say, error handling code. And you
> rightfully pointed out that it's very hard for a static checker to find
> cases where reference stability is used. Not impossible, but hard.
>
> I want to understand what problems you see with keeping QList as-is with
> deprecated implicit conversions to and from QVector, assuming all Qt API
> that uses QList is ported to QVector.
>
> The way I see it:
>
> Given:
> * QList stays as-is
> * No Qt API takes or returns QList anymore, but QVector
> * QList implicitly converts to QVector, and vice versa
> * These implicit conversions are marked as deprecated
>
> Pros:
> * Old (user) code doesn't silently change the meaning
> * Old (user) code continues to work, lets users port at their own
> leisure
> * Receiving objects can be done with auto variables for optimal
> performance
>or with QList for old code.
> * Users passing QLists into Qt APIs enjoy the implicit conversion to
> QVector
>+ This might be slow, but you say yourself that speed doesn't matter
>  for 95% of the code and it's easier to find and fix slow code in
>  the 5% than it is to find a silent reference stability breakage in
>  the 95%.
>
> Cons:
> * Unported code will get penalized by the implicit conversions from and
> to QList
>+ But using the 95/5-argument here, again: it's easier to find where
> the app
>  got slower in the 5% than to find a bug in the 95%.
>
> The pros far, far outweigh the cons. I'd very much like to know in which
> aspects inheriting QList from QVector fares better than this proposal.
>
> My fear is that QList : QVector will lead to some of Qt's APIs
> continuing to use QList, which would lock Qt into QList for another
> major release cycle and only postpone the inevitable QList removal.
> C++11 gave us the tools to make this transition now much smoother than
> it could have been done in Qt 4->5. Inheriting QList from QVector is
> both technically wrong (value classes inheriting each other) and just
> serves to confuse users (is it still ok to use QList? Is it now suddenly
> ok after it wasn't in Qt 5? What do to if I target both Qt 5 and Qt 6?).
>
> Touché on the QStringView reference :)
>
> Thanks,
> Marc
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

That's not equal to directly discouraging the use of qlist. Especially
since they have different interfaces.
That's "blah blah blah, if you are interested in details blah blah blah"

I've read it, not everyone did, I am sure of it. And it's not equal to
directly stating: "if you continue using qlist you are going to have a bad
time (tm) come Qt6"


On Mon, May 20, 2019 at 3:02 PM Иван Комиссаров  wrote:

> https://doc.qt.io/qt-5/qlist.html#details
>
>
>- QVector <https://doc.qt.io/qt-5/qvector.html> should be your default
>first choice. QVector <https://doc.qt.io/qt-5/qvector.html> will
>usually give better performance than QList
><https://doc.qt.io/qt-5/qlist.html>, because QVector
><https://doc.qt.io/qt-5/qvector.html> always stores its items
>sequentially in memory, where QList <https://doc.qt.io/qt-5/qlist.html>
>will allocate its items on the heap unless sizeof(T) <= sizeof(void*) and
>T has been declared to be either a Q_MOVABLE_TYPE or a Q_PRIMITIVE_TYPE
> using Q_DECLARE_TYPEINFO
><https://doc.qt.io/qt-5/qtglobal.html#Q_DECLARE_TYPEINFO>. See the Pros
>and Cons of Using QList
><http://marcmutz.wordpress.com/effective-qt/containers/#containers-qlist> 
> for
>an explanation.
>
>
> Иван Комиссаров
>
> 20 мая 2019 г., в 13:40, NIkolai Marchenko 
> написал(а):
>
> And on the matter of "you should have read all the discussions so you had
> years to port away from QList"
>
> I am sorry, what? QList was never indicated as deprecated or somehow
> undesirable in Qt docs far as I know and not every developer actively reads
> these topics.
> Moreover with all the discussions that were going on about "somehow saving
> the user the pain for Qt6" I am sure a lot of ppl who *knew* still didn't
> bother.
>
> This *really* is not something I expected being thrown around as a serious
> argument here.
>
> On Mon, May 20, 2019 at 2:18 PM NIkolai Marchenko 
> wrote:
>
>> I was speaking strictly of the cases where users already have auto used
>> in their code _expecting it to signify owning container_.
>> Imagine if they expect ownership in these cases. If the actual owning
>> container that exists somewhere else somehow goes out of scope
>> when the user expected to own it for a while (but declared it as auto)
>> you are introducing nasty bugs while maintaining SC.
>>
>> On Mon, May 20, 2019 at 12:35 PM Edward Welbourne 
>> wrote:
>>
>>> On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov 
>>> wrote:
>>> >>   If a user needs a regular container, range might be simply assigned
>>> to it.
>>>
>>> NIkolai Marchenko (16 May 2019 20:38) replied
>>> > It depends on what you expect the average usecase to be.
>>> > If we assume that a regular container is generally more used then you
>>> are preventing ppl from "almost always auto"
>>>
>>> First: I don't believe we've committed to "almost always auto" as a Qt
>>> coding style (it leaves the reader to work out what everything is, which
>>> I - as a reviewer - really don't like).  Being explicit about what type
>>> of container you want to use has its virtues (albeit, as Marc points
>>> out, auto's ambiguity is good when the API is in flux).
>>>
>>> Second: if we return a container, the API designer has to decide which
>>> type of container to return, which forces the caller to do a conversion
>>> if that wasn't the type they wanted.  Returning a range lets the caller
>>> chose how to store the values.
>>>
>>> However, that's only a win if the supplier wasn't already holding the
>>> values in a container, which CoW lets us return cheaply.
>>>
>>> The win (assuming C++ ranges work enough like python generators) comes
>>> when you're traversing some population of things and selecting some to
>>> return, while skipping the rest; classically that might be implemented
>>> as a traversal with a call-back object to act on each item; but a range
>>> lets the caller just iterate over the results found, turning the
>>> call-back's code into a loop's body, which is far easier to follow; or
>>> collecting the results into a container of the caller's choosing.
>>>
>>> Eddy.
>>>
>> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

And on the matter of "you should have read all the discussions so you had
years to port away from QList"

I am sorry, what? QList was never indicated as deprecated or somehow
undesirable in Qt docs far as I know and not every developer actively reads
these topics.
Moreover with all the discussions that were going on about "somehow saving
the user the pain for Qt6" I am sure a lot of ppl who *knew* still didn't
bother.

This *really* is not something I expected being thrown around as a serious
argument here.

On Mon, May 20, 2019 at 2:18 PM NIkolai Marchenko 
wrote:

> I was speaking strictly of the cases where users already have auto used in
> their code _expecting it to signify owning container_.
> Imagine if they expect ownership in these cases. If the actual owning
> container that exists somewhere else somehow goes out of scope
> when the user expected to own it for a while (but declared it as auto) you
> are introducing nasty bugs while maintaining SC.
>
> On Mon, May 20, 2019 at 12:35 PM Edward Welbourne 
> wrote:
>
>> On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov 
>> wrote:
>> >>   If a user needs a regular container, range might be simply assigned
>> to it.
>>
>> NIkolai Marchenko (16 May 2019 20:38) replied
>> > It depends on what you expect the average usecase to be.
>> > If we assume that a regular container is generally more used then you
>> are preventing ppl from "almost always auto"
>>
>> First: I don't believe we've committed to "almost always auto" as a Qt
>> coding style (it leaves the reader to work out what everything is, which
>> I - as a reviewer - really don't like).  Being explicit about what type
>> of container you want to use has its virtues (albeit, as Marc points
>> out, auto's ambiguity is good when the API is in flux).
>>
>> Second: if we return a container, the API designer has to decide which
>> type of container to return, which forces the caller to do a conversion
>> if that wasn't the type they wanted.  Returning a range lets the caller
>> chose how to store the values.
>>
>> However, that's only a win if the supplier wasn't already holding the
>> values in a container, which CoW lets us return cheaply.
>>
>> The win (assuming C++ ranges work enough like python generators) comes
>> when you're traversing some population of things and selecting some to
>> return, while skipping the rest; classically that might be implemented
>> as a traversal with a call-back object to act on each item; but a range
>> lets the caller just iterate over the results found, turning the
>> call-back's code into a loop's body, which is far easier to follow; or
>> collecting the results into a container of the caller's choosing.
>>
>> Eddy.
>>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

I was speaking strictly of the cases where users already have auto used in
their code _expecting it to signify owning container_.
Imagine if they expect ownership in these cases. If the actual owning
container that exists somewhere else somehow goes out of scope
when the user expected to own it for a while (but declared it as auto) you
are introducing nasty bugs while maintaining SC.

On Mon, May 20, 2019 at 12:35 PM Edward Welbourne 
wrote:

> On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov 
> wrote:
> >>   If a user needs a regular container, range might be simply assigned
> to it.
>
> NIkolai Marchenko (16 May 2019 20:38) replied
> > It depends on what you expect the average usecase to be.
> > If we assume that a regular container is generally more used then you
> are preventing ppl from "almost always auto"
>
> First: I don't believe we've committed to "almost always auto" as a Qt
> coding style (it leaves the reader to work out what everything is, which
> I - as a reviewer - really don't like).  Being explicit about what type
> of container you want to use has its virtues (albeit, as Marc points
> out, auto's ambiguity is good when the API is in flux).
>
> Second: if we return a container, the API designer has to decide which
> type of container to return, which forces the caller to do a conversion
> if that wasn't the type they wanted.  Returning a range lets the caller
> chose how to store the values.
>
> However, that's only a win if the supplier wasn't already holding the
> values in a container, which CoW lets us return cheaply.
>
> The win (assuming C++ ranges work enough like python generators) comes
> when you're traversing some population of things and selecting some to
> return, while skipping the rest; classically that might be implemented
> as a traversal with a call-back object to act on each item; but a range
> lets the caller just iterate over the results found, turning the
> call-back's code into a loop's body, which is far easier to follow; or
> collecting the results into a container of the caller's choosing.
>
> Eddy.
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

>   If a user needs a regular container, range might be simply assigned to
it.
It depends on what you expect the average usecase to be.
If we assume that a regular container is generally more used then you are
preventing ppl from "almost always auto"

On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov 
wrote:

> Going forward, we should be looking into removing more and more owning
> containers from the interface and replace them with views. The standard is
> working on a solution for the stale reference problem, and by the time Qt 7
> comes around, it will be hopefully widely available.
>
>
> This is good direction. But I would suggest something based on ranges
> (accepted for C++ 20 and there is already ranges-v3 on github or ranges in
> boost). What we should return in our API is lazy range object. This is
> actually a sort of view or chain of nested views with some conditions. If a
> user needs a regular container, range might be simply assigned to it.
>
> --
> Best Regards,
>
> Fanaskov Vitaly
> Senior Software Engineer
>
> The Qt Company / Qt Quick and Widgets Team
>
> On 16 May 2019, at 15:05, Mutz, Marc via Development <
> development@qt-project.org> wrote:
>
> Hi Lars,
>
> On 2018-11-02 08:51, Lars Knoll wrote:
>
> I believe I have a solution to get rid of QList without breaking SC in
> any major way. See https://codereview.qt-project.org/#/c/242199/ and
> the following changes.
>
> [...]
>
> So to re-iterate: We will not break SC in major ways. The goal is to
> make porting from Qt 5.x to 6 as easy as possible.
>
>
> It's technically SC alright, but silently breaking the reference stability
> user code may rely on should be a complete no-no, considering how reluctant
> Qt has been since the Qt 3->4 port with disruptive changes. I welcome the
> openness to rethink the necessity of some of the plumbing infrastructure,
> but it appears that you have come out far on the other side on this one.
>
> As I said a few years ago, QList in Qt 5 should have a warning if it keeps
> reference stability (iow: if it's not already behaviour- if not
> structure-compatible with QVector), indicting very strongly that by Qt 6,
> this use-case will be gone. Then port all of Qt's own code away from QList,
> either to QVector, or, say, std::vector, like in QToolBox (
> https://codereview.qt-project.org/261943), which is a case where a user
> that actually relies on the implicit reference-stability guarantee of
> current QList, then deprecate QList.
>
> Back then I suggested to rename QList to QArrayList and have QList be a
> deprecated template alias for _either_ QArrayList or QVector, depending on
> whether Q5List would keep references stable or not.
>
> Please don't make QList an unconditional alias for QVector. You are
> silently breaking Qt code (cf. QToolBox) along with an unknown amount of
> Qt-user's code. Make the break non-silent.
>
> I understand the desire to keep old code working that was written against
> Qt 5. But to me, the better solution would be to have the Qt 6 API
> explicitly return QVector and have implicit, but deprecated, conversions
> between QList and QVector. The priority should be to not break code. It
> should not be a priority to have unported code enjoy optimal speed. An
> actual copy on implicit QVector -> QList conversion is acceptable, IMO,
> since the solution for codebases targeting both Qt 5 and 6 is simple: use
> an auto variable.
>
> Going forward, we should be looking into removing more and more owning
> containers from the interface and replace them with views. The standard is
> working on a solution for the stale reference problem, and by the time Qt 7
> comes around, it will be hopefully widely available.
>
> Thanks for considering,
> Marc
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] FP calculations and stability in Qt

[NIkolai Marchenko]

>  I ended up using "proper" geometry processing library for the "model"
and used Qt to do the rendering (the view).

Somehow I get the feeling you just saved me a ton of headaches in the
future :) thx

On Sun, May 12, 2019 at 1:50 PM Christian Gagneraud 
wrote:

> On Sun, 12 May 2019 at 20:26, Konstantin Shegunov 
> wrote:
> >
> > Hi,
> > I'd want to clear the context out of the way, so this is the bug[1] that
> got me thinking.
> > I appreciate that we want to keep external dependencies to a minimum,
> and for a good reason, but can we talk about how feasible it is to pull
> something (or parts of it) in Qt, even if only internally, to facilitate
> stable fp calculation.
> >
> > I've seen some complaints (on the forums mostly) about the stability of
> the transformations Qt supplies, generally unfounded, however it'd be nice
> if we can solve this with generality. I realize Qt is no math library and
> support the idea to drop most of the global functions that dealt with math,
> in the end they're already in the STL. However, as it is, we have some
> linear algebra done (internally mostly), so I think it'd be nice to have
> that done "correctly" for the user.
> >
>
> I use to think that Qt could do a better job about FP
> precision/stability, but i had to realise that i was using Qt in a way
> that it was not designed for.
> For example, I tried to use QPainterPath, QLineF, QRectF, ... to do
> geometry processing. And i can tell you that QPainterPath is all but
> stable when it comes to small values. Highly zoomed-in QGraphicsView
> based geometry object yields crazy artifacts.
> I then turned on specialised library, Qt is a GUI toolkit, and is
> optimised for painting. Qt takes all opportunities to be fast and
> efficient in that context, and that includes being "mathematically"
> imprecised, painting is all about pixels at the end of the day.
> Who cares where exactly a line intersect a polygon, if all you need to
> know is if you need to paint a pixel black or red.
>
> To summarise:
> I ended up using "proper" geometry processing library for the "model"
> and used Qt to do the rendering (the view).
> It came at a cost, but in the long term was a big win.
>
> Chris
>
> > I'd appreciate feelings and opinions on the matter, as I'm but one
> person and my view is rather limited.
> >
> > [1]: https://bugreports.qt.io/browse/QTBUG-75146
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.13.0 Beta2 released

[NIkolai Marchenko]

you are using gmail so it's trivially simple to set up a filter that will
automatically junk all the mail from this mailing list

On Tue, Apr 16, 2019 at 8:33 PM Ashley Sibille  wrote:

> Hi Everyone
>
> I have unsubscribed twice and still receive emails- can someone advise?
> thank you!
>
> On Tue, Apr 16, 2019 at 3:47 AM Jani Heikkinen 
> wrote:
>
>>
>> Hi all,
>>
>> We have published Qt 5.13 beta2 today. As earlier you can get it via
>> online installer. Delta to beta1 attached.
>>
>> Please test the packages now & report all findings to Jira. Also make
>> sure all release blockers can be found from release blocker list (
>> https://bugreports.qt.io/issues/?filter=20625). It is really time to
>> test the packages now; plan is to release Qt 5.13.0 final ~mid May 2019.
>>
>> br,
>> Jani Heikkinen
>> Release Manager___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>
>
> --
> all the best,
>
> ashley
> www.ashleysibille.com
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QStringLiteral is broken(ish) on MSVC (compiler bug?)

[NIkolai Marchenko]

I've posted about this issue (I think) on slack a bit earlier, see
https://cpplang.slack.com/archives/C29936TQC/p154989901601

On Thu, Mar 14, 2019 at 11:51 PM Matthew Woehlke 
wrote:

> While working on some modernization of my application — in particular,
> converting some UTF-8 literals to use QStringLiteral — I noticed a
> concerning compiler warning:
>
>   warning C4566: character represented by universal-character-name
>   '\u' cannot be represented in the current code page (1252)
>
> After doing some testing, it turns out that, given code like
> QStringLiteral("\u269E \U0001f387 \u269F"), MSVC is indeed butchering
> the string.
>
> Further investigation shows that the problem seems to be with the
> implementation of QStringLiteral. In particular, it appears that the
> preprocessor initially sees just the raw string literal without the 'u'
> prefix, butchers it, then later "promotes" it to a UTF-16 literal, but
> by then the damage has been done.
>
> While this absolutely feels like a compiler bug, it's an *awful* big
> gotcha that probably should be documented. Also, is there anything that
> Qt can do to work around it? (I know these sorts of macro expansions can
> be tricksy...)
>
> Note: and the *local* work-around is apparently to include the 'u'
> prefix on my own literal; apparently doubling it (`uu"stuff"`) is okay.
>
> --
> Matthew
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Go's "defer" statement for C++/Qt

[NIkolai Marchenko]

oh... it's already in qt. I've been doing it with my own class all this
time.

On Thu, Mar 7, 2019 at 8:10 PM Tor Arne Vestbø 
wrote:

> https://doc.qt.io/qt-5/qscopeguard.html 
>
> Tor Arne
>
> > On 7 Mar 2019, at 18:01, Volker Hilsheimer 
> wrote:
> >
> > Ahoy,
> >
> > In what little development I’ve done in golang, I appreciated the
> “defer” statement as a means to write cleaner code. Basically, defer
> schedules a statement for execution when the stack unwinds.
> >
> > https://tour.golang.org/flowcontrol/12
> >
> > We have several specialized helper classes in Qt for similar purposes,
> f.ex QMutexLocker and friends, or the internal QBoolBlocker [1]. Seeing the
> various specialized classes we have, I thought that something generic in Qt
> could be useful to have (although our specialised classes provide some
> additional convenience and/or logic).
> >
> > So, I pushed a few lines code to
> >
> > https://git.qt.io/vohilshe/qt_defer
> >
> > Would like to hear what you think.
> >
> > Perhaps someone can find ways to make this more elegant without
> introducing tons of preprocessor/macro shenanigans, or perhaps even without
> depending on C++17's implicit template argument deduction (without enabling
> C++17 in the config this doesn't build for me, even though I don’t use auto
> in the template paramter list).
> >
> >
> > Cheers,
> > Volker
> >
> >
> > [1] which was requested to be made public in
> https://bugreports.qt.io/browse/QTBUG-38575
> >
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] forcing libxkbcommon to be present in the system makes newer Qt unusable on older linux distros

[NIkolai Marchenko]

 - [QTBUG-65503] Removed xkbcommon from bundled sources. This library is
   present on all supported platforms. The minimal required version now is
   0.5.0.


The change above makes updating Qt a gargantuan task for Centos 6 at least.

Building xkbcommon there requires meson (which centos 6 doesn't have)

and python 3.5 (same). And the library doesn't provide another way to
build itself.


Unless I misunderstand something this change hits older linuxes real hard.

Is it really necessary?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QDateTime addDays logic

[NIkolai Marchenko]

It's not like I don't understand all that. But I am not that person who
introduced the regression and

a) He doesn't use a compiler that supports this warning
b) ... and he wouldn't have read it in the first place. (unfortunately)
c) He doesn't much care about docs

Not saying it's correct, just stating the fact that function name is
confusing and potentially problematic because it doesn't do what it states
it does.

On Thu, Dec 13, 2018 at 5:16 PM Sérgio Martins 
wrote:

> On 2018-12-13 13:48, NIkolai Marchenko wrote:
> > This non obvious (from function name) behaviour actually caused
> > infinite
> > loop regression in our code just recently.
> > The person used it inside a while loop thinking it will loop upwards
> > and
> > stop.
>
>
> If your compiler supports it, you should get a warning such as:
>
> warning: ignoring return value of ‘QDateTime QDateTime::addDays(qint64)
> const’, declared with attribute nodiscard [-Wunused-result]
>
> Also useful for many other Qt classes.
>
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QDateTime addDays logic

[NIkolai Marchenko]

This non obvious (from function name) behaviour actually caused infinite
loop regression in our code just recently.
The person used it inside a while loop thinking it will loop upwards and
stop.

On Thu, Dec 13, 2018 at 4:45 PM Edward Welbourne 
wrote:

> Fausto Papandrea (13 December 2018 12:48)
> > Hi, I would like to understand the logic of the addDays function of
> > QDateTime.
> >
> > I mean, why doesn't it modify the calling object, but returns a copy of
> > a new object instead?
>
> At this point, it does what it does because it's done so for years
> (since 5.0, at least) and changing it would break various compatibility
> promises.  I guess the reason for it originally would be a general
> preference for non-mutating methods; think of the add*() methods as
> operator+() specialisations, rather than as operator+=().  If you need
> to advance a QDateTime's day, you can always use
>
>   when->setDate(when.date().addDays(n));
>
> or simply
>
>   when = when.addDays(n);
>
> to achieve the mutating variant.
>
> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Who is in charge of qt-project.org?

[NIkolai Marchenko]

(thiws was  originally sent only to Tuukka, resending)

I would also like to point out the mistrust you've created by proxy.
In believing your promises people have migrated projects at their jobs to
qbs.
Now they will be known as too hasty adopters of dead systems.
Not saying it will be the case for everyone but what you did *really* hurts
your early adopters in more than one way.

On Fri, Nov 2, 2018 at 3:44 PM Tuukka Turunen  wrote:

>
> Exactly. We are very pleased if there are people who start to contribute
> to Qbs. So far it has been very little by others than employees of The Qt
> Company.
>
> We will continue maintaining Qbs so that it stays supported until end of
> 2019 and also release a new version in April 2019 as promised. Most likely
> Qbs remains usable a long time after support ends - even without anyone
> from the community working on it.
>
> This is a good opportunity for those interested in further developing Qbs
> to step up and start taking it forward. We can help with the reviews and
> provide the infrastructure. We can help even with new releases, if there is
> enough interest to develop it further.
>
> I do not think anyone questions the technical merits of Qbs over qmake or
> CMake. Qbs is better than these in many ways. For that reason we have kept
> on investing into it. But we also need to be realistic and think about what
> paying customers prefer. While we have some customers using Qbs, the use of
> CMake is much, much bigger. Both by the number of customers using it and by
> the size of the customers' usage.
>
> We probably should have opened the dialogue about the future of Qbs during
> the process of thinking about the options. This would have been good and
> fair towards the community. But it would not change the facts - it is an
> impossibly huge task to replace CMake with Qbs even within the Qt users,
> let alone outside of Qt.
>
> Yours,
>
> Tuukka
>
> On 02/11/2018, 14.15, "Development on behalf of Martin Smith"
>  martin.sm...@qt.io> wrote:
>
> >You've just dropped Qbs, what's next?
> >I don't trust you anymore, nor the company-ies you represent -
> Nothing personal.
> >I think that it is time for the qt-project.org domain to be handed
> >back to the Qt Project community.
>
> But "dropped Qbs" means The Qt Company won't be developing Qbs
> anymore, which means, effectively, Qbs is being handed to the Qt Project
> community.
>
> martin
>
> 
> From: Development  qt...@qt-project.org> on behalf of Christian Gagneraud 
> Sent: Friday, November 2, 2018 1:08:34 PM
> To: Lars Knoll
> Cc: development@qt-project.org; v.ro...@yahoo.it
> Subject: Re: [Development] Who is in charge of qt-project.org?
>
> On Fri, 2 Nov 2018 at 23:55, Lars Knoll  wrote:
> >
> >
> > On 2 Nov 2018, at 11:45, Christian Gagneraud 
> wrote:
> >
> > On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
> >  wrote:
> >
> >
> >
> > Hi,
> > I have to apologise for my behaviour. While I still think Christian
> Gagneraud's attack on the Qt company abilities was unfair and uncalled for,
> it's not a justification for my actions.
> > Creating an hostile environment is bad for the community and I
> should not have done it.
> > It won't happen again,
> > Regards,
> > Luca
> >
> >
> > Hi All,
> >
> > I would  like to apologise as well, my sarcasm and my provocation
> went
> > uncontrolled.
> > My fault, this was definitely not the most clever way to get things
> sorted.
> > I'm looking forward HTTPS://lists.qt-project.org to be back online
> and
> > would like to thanks everyone working on the matter.
> >
> >
> > Thanks Chris and Luca.
> >
> > Getting lists.qt-project.org fixed is being worked on. I hope it’s
> won’t be too long.
> >
> > But there’s something to take away for TQtC as the party taking care
> of the infrastructure here. TQtC needs to establish some more pro-active
> monitoring of the infrastructure so that these things will get ideally get
> fixed before they become a problem next time. I’ll see what I can do to
> help getting that in place.
>
> 
>
> Hi Lars,
>
> You've just dropped Qbs, what's next?
> I don't trust you anymore, nor the company-ies you represent - Nothing
> personal.
> I think that it is time for the qt-project.org domain to be handed
> back to the Qt Project community.
> I was reading a french article this morning
> (https://linuxfr.org/news/fedora-29), i give you an inaccurate, but
> syntactic and compact translation of the article introduction:
>
> Fedora is a GNU/Linux distribution developed by the Fedora Project and
> sponsored by Red Hat that provide them with developers, finance and
> logistics.
> Fedora can be seen as an open source technological show case of Red
> Hat proprietary technology. 

Re: [Development] Who is in charge of qt-project.org?

[NIkolai Marchenko]

>   But it would not change the facts - it is an impossibly huge task to
replace CMake with Qbs even within the Qt users, let alone outside of Qt.

Yes... then you *should not have encouraged* your customers to switch in
the first place.
Either you are committed to keep you *promises* or you are not.
Promises that have been done *less than a year* ago.

Whether it was a dumb decision to make such a promise is another question,
but you *made it* and people actually migrated to qbs and now risk getting
straddled with dead build system in their projects.
If you make such a promise, be prepared to either keep it or suffer the
mistrust of your users.

There's plenty of salt in your blog post about it: these are all people
that will think ten times before adopting anything of yours again.
Personally, I will discourage anyone from trusting you ever again. I hope
others do too.
Is *this* a risk you are willing to take?

On Fri, Nov 2, 2018 at 3:44 PM Tuukka Turunen  wrote:

>
> Exactly. We are very pleased if there are people who start to contribute
> to Qbs. So far it has been very little by others than employees of The Qt
> Company.
>
> We will continue maintaining Qbs so that it stays supported until end of
> 2019 and also release a new version in April 2019 as promised. Most likely
> Qbs remains usable a long time after support ends - even without anyone
> from the community working on it.
>
> This is a good opportunity for those interested in further developing Qbs
> to step up and start taking it forward. We can help with the reviews and
> provide the infrastructure. We can help even with new releases, if there is
> enough interest to develop it further.
>
> I do not think anyone questions the technical merits of Qbs over qmake or
> CMake. Qbs is better than these in many ways. For that reason we have kept
> on investing into it. But we also need to be realistic and think about what
> paying customers prefer. While we have some customers using Qbs, the use of
> CMake is much, much bigger. Both by the number of customers using it and by
> the size of the customers' usage.
>
> We probably should have opened the dialogue about the future of Qbs during
> the process of thinking about the options. This would have been good and
> fair towards the community. But it would not change the facts - it is an
> impossibly huge task to replace CMake with Qbs even within the Qt users,
> let alone outside of Qt.
>
> Yours,
>
> Tuukka
>
> On 02/11/2018, 14.15, "Development on behalf of Martin Smith"
>  martin.sm...@qt.io> wrote:
>
> >You've just dropped Qbs, what's next?
> >I don't trust you anymore, nor the company-ies you represent -
> Nothing personal.
> >I think that it is time for the qt-project.org domain to be handed
> >back to the Qt Project community.
>
> But "dropped Qbs" means The Qt Company won't be developing Qbs
> anymore, which means, effectively, Qbs is being handed to the Qt Project
> community.
>
> martin
>
> 
> From: Development  qt...@qt-project.org> on behalf of Christian Gagneraud 
> Sent: Friday, November 2, 2018 1:08:34 PM
> To: Lars Knoll
> Cc: development@qt-project.org; v.ro...@yahoo.it
> Subject: Re: [Development] Who is in charge of qt-project.org?
>
> On Fri, 2 Nov 2018 at 23:55, Lars Knoll  wrote:
> >
> >
> > On 2 Nov 2018, at 11:45, Christian Gagneraud 
> wrote:
> >
> > On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
> >  wrote:
> >
> >
> >
> > Hi,
> > I have to apologise for my behaviour. While I still think Christian
> Gagneraud's attack on the Qt company abilities was unfair and uncalled for,
> it's not a justification for my actions.
> > Creating an hostile environment is bad for the community and I
> should not have done it.
> > It won't happen again,
> > Regards,
> > Luca
> >
> >
> > Hi All,
> >
> > I would  like to apologise as well, my sarcasm and my provocation
> went
> > uncontrolled.
> > My fault, this was definitely not the most clever way to get things
> sorted.
> > I'm looking forward HTTPS://lists.qt-project.org to be back online
> and
> > would like to thanks everyone working on the matter.
> >
> >
> > Thanks Chris and Luca.
> >
> > Getting lists.qt-project.org fixed is being worked on. I hope it’s
> won’t be too long.
> >
> > But there’s something to take away for TQtC as the party taking care
> of the infrastructure here. TQtC needs to establish some more pro-active
> monitoring of the infrastructure so that these things will get ideally get
> fixed before they become a problem next time. I’ll see what I can do to
> help getting that in place.
>
> 
>
> Hi Lars,
>
> You've just dropped Qbs, what's next?
> I don't trust you anymore, nor the company-ies you represent - Nothing
> personal.
> I think that it is time for the 

Re: [Development] Who is in charge of qt-project.org?

[NIkolai Marchenko]

TQtC has essentially alienated the very people they want to have on their
side for new stuff: early adopters.
People willing to try and help develop stuff for them. I will not feel
inclined to try anything new you guys showcase in teh future.
Have fun devoping technologies without testers.

On Fri, Nov 2, 2018 at 3:15 PM Martin Smith  wrote:

> >You've just dropped Qbs, what's next?
> >I don't trust you anymore, nor the company-ies you represent - Nothing
> personal.
> >I think that it is time for the qt-project.org domain to be handed
> >back to the Qt Project community.
>
> But "dropped Qbs" means The Qt Company won't be developing Qbs anymore,
> which means, effectively, Qbs is being handed to the Qt Project community.
>
> martin
>
> 
> From: Development 
> on behalf of Christian Gagneraud 
> Sent: Friday, November 2, 2018 1:08:34 PM
> To: Lars Knoll
> Cc: development@qt-project.org; v.ro...@yahoo.it
> Subject: Re: [Development] Who is in charge of qt-project.org?
>
> On Fri, 2 Nov 2018 at 23:55, Lars Knoll  wrote:
> >
> >
> > On 2 Nov 2018, at 11:45, Christian Gagneraud  wrote:
> >
> > On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
> >  wrote:
> >
> >
> >
> > Hi,
> > I have to apologise for my behaviour. While I still think Christian
> Gagneraud's attack on the Qt company abilities was unfair and uncalled for,
> it's not a justification for my actions.
> > Creating an hostile environment is bad for the community and I should
> not have done it.
> > It won't happen again,
> > Regards,
> > Luca
> >
> >
> > Hi All,
> >
> > I would  like to apologise as well, my sarcasm and my provocation went
> > uncontrolled.
> > My fault, this was definitely not the most clever way to get things
> sorted.
> > I'm looking forward HTTPS://lists.qt-project.org to be back online and
> > would like to thanks everyone working on the matter.
> >
> >
> > Thanks Chris and Luca.
> >
> > Getting lists.qt-project.org fixed is being worked on. I hope it’s
> won’t be too long.
> >
> > But there’s something to take away for TQtC as the party taking care of
> the infrastructure here. TQtC needs to establish some more pro-active
> monitoring of the infrastructure so that these things will get ideally get
> fixed before they become a problem next time. I’ll see what I can do to
> help getting that in place.
>
> 
>
> Hi Lars,
>
> You've just dropped Qbs, what's next?
> I don't trust you anymore, nor the company-ies you represent - Nothing
> personal.
> I think that it is time for the qt-project.org domain to be handed
> back to the Qt Project community.
> I was reading a french article this morning
> (https://linuxfr.org/news/fedora-29), i give you an inaccurate, but
> syntactic and compact translation of the article introduction:
>
> Fedora is a GNU/Linux distribution developed by the Fedora Project and
> sponsored by Red Hat that provide them with developers, finance and
> logistics.
> Fedora can be seen as an open source technological show case of Red
> Hat proprietary technology. (NDLR: Free and inaccurate translation, i
> mean it)
> => sold for 34 billions dollars
>
> How do you fell about that? Do you see similarities?
>
> Is the triple-licensed Qt stack an open source technological show case
> of what the Qt Company has to offer?
> 
>
> More seriously, yes, Fedora/RedHat  and
> Qt/Project/Company/Digia/Nokia/Microsoft/TrollTech are different beast
> (apple and oranges, yadi, yada, ...).
> But I see similarities. (and i do not care about the 34 billions)
>
> Chris
> ___
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Who is in charge of qt-project.org?

[NIkolai Marchenko]

Yes, but you've still broken the promise made in the earlier blog post of
making qbs a replacement for qmake and build system  for qt.
Also, there's a high chance that with Chrisitan Kandeler moving away, qbs
will just stagnate and die.

This was somethign that was promised to be developed and nurtured by TQtC
itself. This promise was broken.
We no longer trust TQtC with any new technology.

On Fri, Nov 2, 2018 at 3:15 PM Martin Smith  wrote:

> >You've just dropped Qbs, what's next?
> >I don't trust you anymore, nor the company-ies you represent - Nothing
> personal.
> >I think that it is time for the qt-project.org domain to be handed
> >back to the Qt Project community.
>
> But "dropped Qbs" means The Qt Company won't be developing Qbs anymore,
> which means, effectively, Qbs is being handed to the Qt Project community.
>
> martin
>
> 
> From: Development 
> on behalf of Christian Gagneraud 
> Sent: Friday, November 2, 2018 1:08:34 PM
> To: Lars Knoll
> Cc: development@qt-project.org; v.ro...@yahoo.it
> Subject: Re: [Development] Who is in charge of qt-project.org?
>
> On Fri, 2 Nov 2018 at 23:55, Lars Knoll  wrote:
> >
> >
> > On 2 Nov 2018, at 11:45, Christian Gagneraud  wrote:
> >
> > On Thu, 1 Nov 2018 at 22:25, Kain Vampire via Development
> >  wrote:
> >
> >
> >
> > Hi,
> > I have to apologise for my behaviour. While I still think Christian
> Gagneraud's attack on the Qt company abilities was unfair and uncalled for,
> it's not a justification for my actions.
> > Creating an hostile environment is bad for the community and I should
> not have done it.
> > It won't happen again,
> > Regards,
> > Luca
> >
> >
> > Hi All,
> >
> > I would  like to apologise as well, my sarcasm and my provocation went
> > uncontrolled.
> > My fault, this was definitely not the most clever way to get things
> sorted.
> > I'm looking forward HTTPS://lists.qt-project.org to be back online and
> > would like to thanks everyone working on the matter.
> >
> >
> > Thanks Chris and Luca.
> >
> > Getting lists.qt-project.org fixed is being worked on. I hope it’s
> won’t be too long.
> >
> > But there’s something to take away for TQtC as the party taking care of
> the infrastructure here. TQtC needs to establish some more pro-active
> monitoring of the infrastructure so that these things will get ideally get
> fixed before they become a problem next time. I’ll see what I can do to
> help getting that in place.
>
> 
>
> Hi Lars,
>
> You've just dropped Qbs, what's next?
> I don't trust you anymore, nor the company-ies you represent - Nothing
> personal.
> I think that it is time for the qt-project.org domain to be handed
> back to the Qt Project community.
> I was reading a french article this morning
> (https://linuxfr.org/news/fedora-29), i give you an inaccurate, but
> syntactic and compact translation of the article introduction:
>
> Fedora is a GNU/Linux distribution developed by the Fedora Project and
> sponsored by Red Hat that provide them with developers, finance and
> logistics.
> Fedora can be seen as an open source technological show case of Red
> Hat proprietary technology. (NDLR: Free and inaccurate translation, i
> mean it)
> => sold for 34 billions dollars
>
> How do you fell about that? Do you see similarities?
>
> Is the triple-licensed Qt stack an open source technological show case
> of what the Qt Company has to offer?
> 
>
> More seriously, yes, Fedora/RedHat  and
> Qt/Project/Company/Digia/Nokia/Microsoft/TrollTech are different beast
> (apple and oranges, yadi, yada, ...).
> But I see similarities. (and i do not care about the 34 billions)
>
> Chris
> ___
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

Even the initial support for Qt6 will already make community based efforts
more likely since they will at least have something to work with.
But if QBS support in QtCreator is dropped as Qt6 releases there  is little
to no chance of anyone picking it up as he task might just be too large.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

Tbh, as I see it: qbs is mostly usable now. The only thing it needs to stay
afloat from now on  and have a chance is promise of support for it + qt6 in
qt creator.
Is that really that hard to do?

On Wed, Oct 31, 2018 at 12:37 AM Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> Yes, it's a big requirement for a lot of people using OFX that they be
> able to use also Xcode and / or Visual Studio. But QBS was at some point
> (not sure if still the case) the main one.
> On 30/10/2018 22:25, Иван Комиссаров wrote:
>
> Huh? Looks like they are supporting every build system alive
> https://github.com/openframeworks/openFrameworks/tree/patch-release/libs/openFrameworksCompiled/project
>
> 30 окт. 2018 г., в 22:14, Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> написал(а):
>
> OpenFrameworks, a fairly used creative coding framework has been using QBS
> for a few years. My experience with it in that context has been quite
> negative - a year ago it would break on every new QBS release, so you had
> to use an exact QBS version if you wanted to use OFX (exhibit A:
> https://forum.openframeworks.cc/t/qtcreator-v4-3-1-qbs-problem/27214), so
> multiple people I know have ended up porting OF to use CMake instead :
> https://github.com/ofnode/of which frankly worked better and with less
> breakage. As always, mileage may vary.
>
>
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
>
> On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira <
> thiago.macie...@intel.com> wrote:
>
>> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
>> > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
>> > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
>> > > > doesn't authorize you to impose requirements that make it basically
>> > > > impossible to employ qt as a bootstrapping device for a qbs
>> > > > ecosystem.
>> > >
>> > > The whole point was "let Qt not be the guinea pig".
>> >
>> > you're essentially presuming that qbs is developed by a potentially
>> > incompetent external entity.
>>
>> No. However, I am asking for proof.
>>
>> > > Show me that the tool can achieve what Qt needs for it to achieve
>> >
>> > qtbase//wip/qbs2 speaks for itself.
>>
>> That's the guinea pig. I am asking for proof by seeing someone else adopt
>> it.
>> The tool is now several years old, it ought to have attracted *someone*.
>>
>> And even if it hasn't, there are a couple of years left until we switch
>> for
>> Qt. The community supporting this tool can find other projects of
>> moderate
>> complexity to work with and support.
>>
>> > > and has enough of a track record of a community to ask for help.
>> >
>> > it has enough "community" and intrinsic quality to get things going.
>>
>> I'm not disputing it has quality. But it lacks a specific community I
>> called
>> for: packagers.
>>
>> Tell me, has anyone tried to build that branch in the Boot2Qt context?
>>
>> > asking for more is completely unreasonable before the community from
>> > which the tool originates shows committment by *relying* on it. and as
>> > the current situation shows, everyone who didn't trust the story was
>> > *right*.
>>
>> I disagree and I find it completely reasonable to ask. That's why I did
>> so.
>>
>> And yes, they were right: if qbs is created for Qt alone, then they
>> shouldn't
>> rely on it. Hence the request to show that it can be used by others and
>> that
>> there's at least a modest community behind it.
>>
>> There has been enough time to get more adoption and there's still time
>> left.
>> So get someone else to adopt it.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>
>>
>>
>> ___
>> 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
>
>
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

> Don't ask Qt to switch to it until you've done that work.

Tbh, we wouldn't if this post hasn't almost stated that you are pulling the
plug.
As I saw it: qbs folks have finally started doing the correct thiing (that
is - tutorials) and what you are speaking of had a chance to happen.
But as of right now no amount of tutorials will change the fact that
reluctance to swtich to a new system will become reluctance to change to a
_stillborn_ system.

By pulling the plug Lars ensures that qbs has not had a chance and _will
not have_ that chance.

Oh, and also, maybe we need a separate post about this issue: "Should QBS
stay?"
Or something like that so that it's visible on it's own and more people
jump into the discussion.
So far we have quite a few projects in the spreadsheet I created.
I wonder how many more will be added.



On Wed, Oct 31, 2018 at 12:27 AM Thiago Macieira 
wrote:

> On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote:
> > > and has enough of a track record of a community to ask for help.
> >
> > You quite literally have the system's developer in house.
> > Why do you even need to rely on the community so much?
> > I'd understand if qbs was an external tool, but that's not the case.
>
> Because it's a sign of maturity. If the only people who can solve any
> problem
> are the handful of people who work for the company that developed it, we
> have
> a serious Bus Factor problem. And guess what? It's exactly what's
> happening
> right now.
>
> Ossi and several others are right that qbs was never given a proper
> chance. It
> hasn't.
>
> The only thing I'm criticising is that its proper chance involves Qt being
> the
> guinea pig. Find someone else instead and grow your community. Get track
> record for building, cross-compiling, working with weird set ups,
> containerised build environments, build farms, etc. Don't ask Qt to switch
> to
> it until you've done that work.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

> I'm not disputing it has quality. But it lacks a specific community I
called
for: packagers.

Maybe, but then, you've spent quite some time developing the system ,what's
stopping you from reaching out to suitable projects that involve packaging
to help them set up their project with QBS?
Instead of stating your desire to pull the plug and basically discouraging
such a community from ever appearing.

On Wed, Oct 31, 2018 at 12:07 AM Thiago Macieira 
wrote:

> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
> > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
> > > > doesn't authorize you to impose requirements that make it basically
> > > > impossible to employ qt as a bootstrapping device for a qbs
> > > > ecosystem.
> > >
> > > The whole point was "let Qt not be the guinea pig".
> >
> > you're essentially presuming that qbs is developed by a potentially
> > incompetent external entity.
>
> No. However, I am asking for proof.
>
> > > Show me that the tool can achieve what Qt needs for it to achieve
> >
> > qtbase//wip/qbs2 speaks for itself.
>
> That's the guinea pig. I am asking for proof by seeing someone else adopt
> it.
> The tool is now several years old, it ought to have attracted *someone*.
>
> And even if it hasn't, there are a couple of years left until we switch
> for
> Qt. The community supporting this tool can find other projects of moderate
> complexity to work with and support.
>
> > > and has enough of a track record of a community to ask for help.
> >
> > it has enough "community" and intrinsic quality to get things going.
>
> I'm not disputing it has quality. But it lacks a specific community I
> called
> for: packagers.
>
> Tell me, has anyone tried to build that branch in the Boot2Qt context?
>
> > asking for more is completely unreasonable before the community from
> > which the tool originates shows committment by *relying* on it. and as
> > the current situation shows, everyone who didn't trust the story was
> > *right*.
>
> I disagree and I find it completely reasonable to ask. That's why I did so.
>
> And yes, they were right: if qbs is created for Qt alone, then they
> shouldn't
> rely on it. Hence the request to show that it can be used by others and
> that
> there's at least a modest community behind it.
>
> There has been enough time to get more adoption and there's still time
> left.
> So get someone else to adopt it.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

>  and has enough of a track record of a community to ask for help.

You quite literally have the system's developer in house.
Why do you even need to rely on the community so much?
I'd understand if qbs was an external tool, but that's not the case.

On Tue, Oct 30, 2018 at 11:49 PM Konstantin Shegunov 
wrote:

>
>
> On Tue, Oct 30, 2018 at 9:09 PM Thiago Macieira 
> wrote:
>
>> On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote:
>> > From my point of view qbs is doomed as long as qmake's alive. Either
>> kill
>> > qmake and force the developers using Qt (or developing Qt) to use qbs
>>
>> That's not going to happen any more than our breaking source
>> compatibility in
>> a major way.
>>
>
> Fair enough. As a consequence qbs gets rather limited exposure, thus it's
> not a priority for development.
> To make matters worse smaller user base means smaller amount of
> bugreports/fixes. Less fixes in turn leads to buggier/quirkier system
> leading to fewer people using it. And the circle is complete - unfortunate,
> but somewhat expected.
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

>  But the fact that in 4 years there is just one package in Debian's
archive using qbs says a lot.

Unfortunately all it says is that QBS developers _really_ didn't care to
advertise/document their system.
it's no wonder there are no projects when the only thing you have to work
off of is a bunch module references.

I am not so annoyed at the decision to drop qbs as I am annoyed at the fact
that it failed because it never was given a fair chance
and just as things seemed to begin to improve(i.e. finally tutorial pages)
they decide to drop it.
Of course now those pages become irrelevant as no one will want to jump
onto a dying system regardless of if it has documentation or not.




On Tue, Oct 30, 2018 at 10:32 PM Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:

> El martes, 30 de octubre de 2018 15:26:14 -03 Иван Комиссаров escribió:
> > Wow, hold on for a minute.
> > I’ve been using a qbs package as a standalone leaf package (sudo aptitude
> > install qbs) to build my projects. Also, self-built QBS package was
> > commercially used to create several Debian packages back in 2013.
>
> I can't count what's not in Debian proper. But the fact that in 4 years
> there
> is just one package in Debian's archive using qbs says a lot.
>
> Of course anyone can jump in to help maintain qbs and keep it in the
> archive.
>
> --
> http://www.tiraecol.net/modules/comic/comic.php?content_id=162
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

>  No, we will break source compatibility in a minor way.

I am not aware of what was the end result of QList discussion, but didn't
you want to deprecate/majorly change that at some point?
That alone would be rather huge.

On Tue, Oct 30, 2018 at 10:19 PM Thiago Macieira 
wrote:

> On Tuesday, 30 October 2018 12:11:38 PDT NIkolai Marchenko wrote:
> >  >  That's not going to happen any more than our breaking source
> >
> > compatibility in
> > a major way.
> >
> > You are breaking source compatibility in a major way with Qt6 ... ;)
>
> No, we will break source compatibility in a minor way.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

 >  That's not going to happen any more than our breaking source
compatibility in
a major way.

You are breaking source compatibility in a major way with Qt6 ... ;)

On Tue, Oct 30, 2018 at 10:09 PM Thiago Macieira 
wrote:

> On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote:
> > From my point of view qbs is doomed as long as qmake's alive. Either kill
> > qmake and force the developers using Qt (or developing Qt) to use qbs
>
> That's not going to happen any more than our breaking source compatibility
> in
> a major way.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

>  From my point of view qbs is doomed as long as qmake's alive.

I would much rather this abomination died instead.
I've switched to qbs when I got way too annoyed by how qmake does things
and I've never been happier.

On Tue, Oct 30, 2018 at 8:32 PM Pier Luigi Fiorini <
pierluigi.fior...@gmail.com> wrote:

> Il giorno mar 30 ott 2018 alle ore 17:52 Oswald Buddenhagen <
> oswald.buddenha...@qt.io> ha scritto:
>
>> On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote:
>> > Is it packaged in a Linux distribution? My requirements also included
>> > continuously packaged for 2 years in at least 3 Linux distributions,
>> > at the time of the Qt switch to the particular buildsystem.
>> >
>> it's been packaged for much longer and by more distros already, because
>> it's part of qt creator for quite a while. i don't know whether all of
>> them ship it as separate packages already, but the official messaging
>> from us was that they *should*.
>>
>>
> Distros started packaging it separately for some time now.
> Before that, as you point out, it was packaged inside QtCreator.
>
> Debian: https://packages.debian.org/sid/qbs
> Fedora: https://apps.fedoraproject.org/packages/qbs
> Arch Linux: https://www.archlinux.org/packages/extra/x86_64/qbs/
> OpenSuSE: https://software.opensuse.org/package/qbs?search_term=qbs
>
> --
> https://liri.io
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

For anyone interested in QBS survival, let's fill the sheet with QBS
ecosystem.
Maybe if we show TQtC that people are actually using it they will
reconsider.

Post your projects  (and ones you know of) here:

https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0

On Tue, Oct 30, 2018 at 8:11 PM Oswald Buddenhagen 
wrote:

> On Tue, Oct 30, 2018 at 01:16:43PM +0200, Bogdan Vatra wrote:
> > c.2) back then, none of the existing build system could deliver enough
> > information to IDEs to enable prefect code completion (e.g.  include
> > paths, defines, compiler flags, etc.)
> > ...
> > c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1]
> > and I found some problems, see how QBS developers treat them here:
> > https://bugreports.qt.io/browse/QBS-902 . That was the moment when I
> > started to have doubts :).
> >
> for all i can tell that's a rather poor bug report with little followup
> from you. that's where i start to have doubts whether you actually mean
> it. ;)
>
> > d) last but not least a clean and easily maintainable code base that can
> be
> > used for the next decade(s).
> > ...
> >   - Instread to port QBS to QML JS in the first second when QtScript was
> > deprecated, they fork it! I know that back then QML JS needed some love,
> but
> > instead to collaborate with QML JS folks they decided keep using
> QtScript!
> > IIRC a brave soul, port it to QML JS, but guess what, QBS devs reject it
> and
> > kept using QtScript!
> >  - Even more, they found a few problem also in QML parser, and guess
> what,
> > they forked also QML!
> >
> both these items get a huge "so what?" in response. because they have no
> practical impact whatsoever.
>
> > To fix d) a large part of QBS must be reorganized/rewritten,
> >
> i see no actual evidence of that.
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

> Thus this investment would be at the expense of other things we’d like to
do, like improving our IDE, working on rearchitecting and cleaning up our
core frameworks for Qt 6 or the design tooling we are currently investing
into. The Qt Company believes that those other investments are more
important for the future of Qt than our choice of build tool.

I don't understand. Will it not be a return on the investment when people
use Qt "because their build tool is the best around" ?
Project files are at the root of every project. There are all sorts of good
IDEs around but ppl mostly are forced to use CMAKE which no one seems to
like.
QBS might have been that crucial difference going for qt. Much more
important than any IDE echancment.

On Tue, Oct 30, 2018 at 5:33 PM Cristian Adam 
wrote:

> On Tue, Oct 30, 2018 at 12:42 PM Cristian Adam 
> wrote:
>
>> On Tue, Oct 30, 2018, 12:24 Christian Gagneraud  wrote:
>>
>>> > > On 30 Oct 2018, at 05:00, Christian Gagneraud 
>>> wrote:
>>> > > - Any track record that Qbs was not fit for the job? (Please no "we
>>> > > can't build Qt with it", as you cannot build Qt with anything but
>>> > > qmake right now)
>>> >
>>> > No, of course one could have made it support building Qt. There were
>>> some missing items like the configuration system and some other things, all
>>> of those could of course have been implemented.
>>>
>>> How CMake will solve the 'configuration' problem. Will CMake allow us
>>> to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt!
>>> Everyone is bragging about open source (me first), but the Qt market
>>> is medical, automotive and avionics/space industry, isn't it? How will
>>> CMake cope with that?
>>> CMake is not even aware that they are other OS behind WIndows and
>>> Linux Desktop
>>>
>>
>> CMake is used in Automotive.
>>
>> Here is a link to the blog of one of the QNX's Eclipse CDT contributors,
>> and there you can see how hard it is to write a CMake toolchain file for
>> QNX: https://cdtdoug.ca/2017/10/06/qnx-cmake-toolchain-file.html
>>
>> Cheers,
>> Cristian.
>>
>
> And here is the link with the nightly builds that run on the CMake code
> base:
>
> https://open.cdash.org/index.php?project=CMake=2018-10-29#!/%23Nightly_Expected
>
> There are quite some platform combinations there. QNX is not there because
> of licensing I suppose.
>
> Cheers,
> Cristian.
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

> Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
we have a statement from them so far ?

We have a confirmation from Lars that QtCreator is dropping qbs support in
a year.
That basically reads "qbs dead as there will be no IDE supporting it left".

On Tue, Oct 30, 2018 at 1:21 PM Uwe Rathmann 
wrote:

> On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote:
>
> > What Lars said, if I read the email properly, is that the Qt Company
> > does not see a business value in developing it further.
>
> Yes and this is relevant if it is relevant for the maintainers of Qbs. Do
> we have a statement from them so far ?
>
> > But the project is open source and the code is there and anyone is free
> > to take over if they are interested in it.
>
> In case a maintainer decides to step down the normal process would be to
> find a new one. Only if this is not possible further steps have to be
> taken.
>
> Using Qbs for building Qt has been discussed here and lead to a solid
> decision against it. Obviously then the Qt company decided not to work on
> this code anymore - so far so good.
>
> But deprecating Qbs as a tool for building user projects is absolutely
> not covered by this discussion and if there was a more related one I seem
> to have missed it.
>
> This all has a lot to do with the question if the Qt Company sees itself
> as being a member or the owner of the Qt project. If we really want to be
> a community project, then the process of inventing and deprecating
> modules has to become more independent.
>
> Uwe
>
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

I would like to point out that until very, and I mean *very* recently QBS'
did not even have a bunch of tutorial pages, There was a (poorly
documented) reference and that was it.
If someone wanted to learn QBS and there was no one in their company
already familiar with it, it was one very basic qmake porting tutorial and
then the only source ppl had was asking on IRC.
Like... what did you expect when all the time was spent developing it but
largely ignoring documentaton that would let ppl actually use it with any
kind of success?


On Tue, Oct 30, 2018 at 1:07 PM Pier Luigi Fiorini <
pierluigi.fior...@gmail.com> wrote:

> Il giorno mar 30 ott 2018 alle ore 09:59 Olivier Goffart <
> oliv...@woboq.com> ha scritto:
>
>> On 10/30/18 6:29 AM, resurrect...@centrum.cz wrote:
>> > Honestly I feel very disappointed as well with this decision. I feel
>> similarly
>> > to others, Qbs is now being phased out so fast (half a year of
>> development,
>> > another half a year of maintanance after that it seems). So better get
>> to
>> > porting stuff to CMake right away. Having experience with CMake this is
>> gonna
>> > be very ugly...
>> >
>> > What I do not understand is why the decision was qmake + cmake in the
>> first
>> > place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It
>> is
>> > perfectly understandable to tap into wide CMake user base but why
>> ditching Qbs
>> > and not qmake? I wouldn't expect people would mourn qmake...
>>
>> This is not about "qmake + cmake" vs. anything.
>>
>> Qbs did not disappear from one day to the other.
>> What Lars said, if I read the email properly, is that the Qt Company does
>> not
>> see a business value in developing it further.
>> But the project is open source and the code is there and anyone is free
>> to take
>> over if they are interested in it.
>>
>
> We all know that without company support, the project will stagnate.
>
>
>> And Qbs does not have to build Qt for you to use it.
>>
>
> No but it would have been a great indicator of confidence on the project
> and help its adoption because it would have been much more noticeable than
> QtCreator (not all Qt users and developers build QtCreator but a lot of
> them do build Qt).
> The main problem here is not that Qt will use CMake, the problem is that
> Qbs will no longer be maintained.
> Given that qmake is not suitable for large projects, Qbs will not be
> developed anymore we can expect only CMake support on QtCreator to improve,
> therefore a lot of us will need to migrate to CMake.
>
> --
> https://liri.io
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

Actually, what is considered moderate complexity? I have a project at work
that has been running for a few years, has 4 people working on it and has a
few thousand commits.
It has a couple dozen libraries, is integrated with gRPC and has code
generated with protobuf on build via a custom QBS module. Is this
considered moderate complexity?
(though I siuspect Lars wants a bigger project)

On Tue, Oct 30, 2018 at 12:43 PM Richard Weickelt 
wrote:

> > Can you name any project of moderate complexity using it?
>
> https://github.com/bjorn/tiled
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

That's basically how I switched ppl here at my workplace to QBS: I've
rewritten their .pro files for them and they didn't look back.

On Tue, Oct 30, 2018 at 11:55 AM NIkolai Marchenko 
wrote:

> And if you want large projects using it, shouldn't you have invested time
> and people actually helping those large projects rewrite their build system
> to QBS and show them just how good it is?
> Any large project consists of a lot of experienced developers and every
> experienced developer knows that::"If i works, don't touch it".
>
> Qt needed to invest time and resources to show at least a few projects the
> real benefit of qbs instead of hoping someone randomly would decide to
> rewrite what amounts of hundreds of ours in an extremely poorly documented
> system.
>
> On Tue, Oct 30, 2018 at 11:50 AM NIkolai Marchenko <
> enmarantis...@gmail.com> wrote:
>
>> Main question is: why you even developing it, when you've never properly
>> advertised/documented it? Just as an internal experiment?
>> "Lets' make this thing and make sure almost no one knows of it or can
>> find enough guidance to use it and then call it deprecated."
>>
>> Like... this makes no sense whatsoever.
>>
>> Part of it is me being annoyed at the loss of my primary build system
>> ofc, but mostly I am generally baffled.
>>
>> On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko <
>> enmarantis...@gmail.com> wrote:
>>
>>> I really have to wonder how can they think QBS is a failure when it was
>>> literally never given a chance.
>>>
>>> Thiago, Lars : did you _really_ expect QBS to take off without any kind
>>> of proper documentation (has only started appearing in the last year) or
>>> advertisement? Seriously?
>>> I've pointed out this artificial entry barrier for years. It's not that
>>> QBS hasn't taken off, the people who were responsible for it to take off
>>> did not do even minimal effort to make sure it did.
>>>
>>> During the course of the last year QBS imporved in leaps in leaps and
>>> bounds and it suddenly comes to a schreeching halt now when it's really the
>>> time to push it to gain momentum
>>>
>>> I think you really need to revisit this topic before deprecating what
>>> could easily outclass CMAKE and the likes.
>>>
>>>
>>>
>>> On Tue, Oct 30, 2018 at 11:21 AM  wrote:
>>>
>>>> //Christian Gagneraud wrote:
>>>>
>>>> //
>>>>
>>>> // // set(var1 "Hello")
>>>>
>>>> // // set(var2 "Hello")
>>>>
>>>> // //
>>>>
>>>> // // if(var1 EQUAL var2)
>>>>
>>>> // // message("They are equal")
>>>>
>>>> // // endif()
>>>>
>>>> // //
>>>>
>>>> // // Guess what, it prints NOTHING despite docs explicitly saying this
>>>> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the
>>>> arguments, whatever.
>>>>
>>>> //
>>>>
>>>> // You read the docs wrong:
>>>>
>>>> // EQUAL: True if the given string or variable’s value is a valid
>>>> number and equal to that on the right.
>>>>
>>>> // Neither var1 nor var2 is a valid numbers.
>>>>
>>>> //
>>>>
>>>> // You want
>>>>
>>>> // if (var1 STREQUAL var2) and this works as expected (and documented).
>>>>
>>>> //
>>>>
>>>> // //
>>>>
>>>> // Christian
>>>>
>>>>
>>>>
>>>> No it does not. Have you tried it? As I mentioned it does not work. And
>>>> even if you somehow managed to make it work it would break the moment
>>>> someone would define the variable "Hello" elsewhere in the script. See
>>>> https://cmake.org/pipermail/cmake/2013-February/053587.html
>>>>
>>>>
>>>>
>>>> And that is the point. The fact we are discussing the very fundamental
>>>> programming feature - control flow - that just does not work as expected
>>>> (or documented) is the main problem with CMake. It is a software made of
>>>> features botched together. You will be constantly running into these kinds
>>>> of things because it is CMake "language" is not a standardized programming
>>>> language (like JS is). Writing complex projects in it is extremely
&g

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

And if you want large projects using it, shouldn't you have invested time
and people actually helping those large projects rewrite their build system
to QBS and show them just how good it is?
Any large project consists of a lot of experienced developers and every
experienced developer knows that::"If i works, don't touch it".

Qt needed to invest time and resources to show at least a few projects the
real benefit of qbs instead of hoping someone randomly would decide to
rewrite what amounts of hundreds of ours in an extremely poorly documented
system.

On Tue, Oct 30, 2018 at 11:50 AM NIkolai Marchenko 
wrote:

> Main question is: why you even developing it, when you've never properly
> advertised/documented it? Just as an internal experiment?
> "Lets' make this thing and make sure almost no one knows of it or can find
> enough guidance to use it and then call it deprecated."
>
> Like... this makes no sense whatsoever.
>
> Part of it is me being annoyed at the loss of my primary build system ofc,
> but mostly I am generally baffled.
>
> On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko <
> enmarantis...@gmail.com> wrote:
>
>> I really have to wonder how can they think QBS is a failure when it was
>> literally never given a chance.
>>
>> Thiago, Lars : did you _really_ expect QBS to take off without any kind
>> of proper documentation (has only started appearing in the last year) or
>> advertisement? Seriously?
>> I've pointed out this artificial entry barrier for years. It's not that
>> QBS hasn't taken off, the people who were responsible for it to take off
>> did not do even minimal effort to make sure it did.
>>
>> During the course of the last year QBS imporved in leaps in leaps and
>> bounds and it suddenly comes to a schreeching halt now when it's really the
>> time to push it to gain momentum
>>
>> I think you really need to revisit this topic before deprecating what
>> could easily outclass CMAKE and the likes.
>>
>>
>>
>> On Tue, Oct 30, 2018 at 11:21 AM  wrote:
>>
>>> //Christian Gagneraud wrote:
>>>
>>> //
>>>
>>> // // set(var1 "Hello")
>>>
>>> // // set(var2 "Hello")
>>>
>>> // //
>>>
>>> // // if(var1 EQUAL var2)
>>>
>>> // // message("They are equal")
>>>
>>> // // endif()
>>>
>>> // //
>>>
>>> // // Guess what, it prints NOTHING despite docs explicitly saying this
>>> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the
>>> arguments, whatever.
>>>
>>> //
>>>
>>> // You read the docs wrong:
>>>
>>> // EQUAL: True if the given string or variable’s value is a valid number
>>> and equal to that on the right.
>>>
>>> // Neither var1 nor var2 is a valid numbers.
>>>
>>> //
>>>
>>> // You want
>>>
>>> // if (var1 STREQUAL var2) and this works as expected (and documented).
>>>
>>> //
>>>
>>> // //
>>>
>>> // Christian
>>>
>>>
>>>
>>> No it does not. Have you tried it? As I mentioned it does not work. And
>>> even if you somehow managed to make it work it would break the moment
>>> someone would define the variable "Hello" elsewhere in the script. See
>>> https://cmake.org/pipermail/cmake/2013-February/053587.html
>>>
>>>
>>>
>>> And that is the point. The fact we are discussing the very fundamental
>>> programming feature - control flow - that just does not work as expected
>>> (or documented) is the main problem with CMake. It is a software made of
>>> features botched together. You will be constantly running into these kinds
>>> of things because it is CMake "language" is not a standardized programming
>>> language (like JS is). Writing complex projects in it is extremely
>>> difficult which I have been unfortunate to experience first hand (had to
>>> write a few in it). While the business decision might be understandable
>>> from the technical standpoint it is an absolute nightmarish prospect. Not
>>> to mention it is very slow so working with codebase the size of Qt will be
>>> extra difficult. There will likely be effort to improve on that either on
>>> CMake side (if they cared) or QtComany side (more likely, because they do
>>> care).
>>>
>>>
>>>
>>> However I have no problem with CMake becoming the primary build
&

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

Main question is: why you even developing it, when you've never properly
advertised/documented it? Just as an internal experiment?
"Lets' make this thing and make sure almost no one knows of it or can find
enough guidance to use it and then call it deprecated."

Like... this makes no sense whatsoever.

Part of it is me being annoyed at the loss of my primary build system ofc,
but mostly I am generally baffled.

On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko 
wrote:

> I really have to wonder how can they think QBS is a failure when it was
> literally never given a chance.
>
> Thiago, Lars : did you _really_ expect QBS to take off without any kind of
> proper documentation (has only started appearing in the last year) or
> advertisement? Seriously?
> I've pointed out this artificial entry barrier for years. It's not that
> QBS hasn't taken off, the people who were responsible for it to take off
> did not do even minimal effort to make sure it did.
>
> During the course of the last year QBS imporved in leaps in leaps and
> bounds and it suddenly comes to a schreeching halt now when it's really the
> time to push it to gain momentum
>
> I think you really need to revisit this topic before deprecating what
> could easily outclass CMAKE and the likes.
>
>
>
> On Tue, Oct 30, 2018 at 11:21 AM  wrote:
>
>> //Christian Gagneraud wrote:
>>
>> //
>>
>> // // set(var1 "Hello")
>>
>> // // set(var2 "Hello")
>>
>> // //
>>
>> // // if(var1 EQUAL var2)
>>
>> // // message("They are equal")
>>
>> // // endif()
>>
>> // //
>>
>> // // Guess what, it prints NOTHING despite docs explicitly saying this
>> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the
>> arguments, whatever.
>>
>> //
>>
>> // You read the docs wrong:
>>
>> // EQUAL: True if the given string or variable’s value is a valid number
>> and equal to that on the right.
>>
>> // Neither var1 nor var2 is a valid numbers.
>>
>> //
>>
>> // You want
>>
>> // if (var1 STREQUAL var2) and this works as expected (and documented).
>>
>> //
>>
>> // //
>>
>> // Christian
>>
>>
>>
>> No it does not. Have you tried it? As I mentioned it does not work. And
>> even if you somehow managed to make it work it would break the moment
>> someone would define the variable "Hello" elsewhere in the script. See
>> https://cmake.org/pipermail/cmake/2013-February/053587.html
>>
>>
>>
>> And that is the point. The fact we are discussing the very fundamental
>> programming feature - control flow - that just does not work as expected
>> (or documented) is the main problem with CMake. It is a software made of
>> features botched together. You will be constantly running into these kinds
>> of things because it is CMake "language" is not a standardized programming
>> language (like JS is). Writing complex projects in it is extremely
>> difficult which I have been unfortunate to experience first hand (had to
>> write a few in it). While the business decision might be understandable
>> from the technical standpoint it is an absolute nightmarish prospect. Not
>> to mention it is very slow so working with codebase the size of Qt will be
>> extra difficult. There will likely be effort to improve on that either on
>> CMake side (if they cared) or QtComany side (more likely, because they do
>> care).
>>
>>
>>
>> However I have no problem with CMake becoming the primary build generator
>> replacing qmake. It is widespread etc. My issue is with deprecating Qbs.
>> Having 2 people (likely very motivated now after they spent years
>> developing Qbs) transfered or replaced to CMake support in Qt can hardly
>> mean "Deprecating Qbs allows us to significantly improve CMake support.".
>> Sounds more like standard PR BS to me, sorry.
>>
>>
>>
>> And saying Qbs got a chance when it was literally never promoted
>> anywhere, not even in Qt project itself is riduclous. And coming from
>> Thiago who even claimed before he never actually used it.
>> ___
>> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

I really have to wonder how can they think QBS is a failure when it was
literally never given a chance.

Thiago, Lars : did you _really_ expect QBS to take off without any kind of
proper documentation (has only started appearing in the last year) or
advertisement? Seriously?
I've pointed out this artificial entry barrier for years. It's not that QBS
hasn't taken off, the people who were responsible for it to take off did
not do even minimal effort to make sure it did.

During the course of the last year QBS imporved in leaps in leaps and
bounds and it suddenly comes to a schreeching halt now when it's really the
time to push it to gain momentum

I think you really need to revisit this topic before deprecating what could
easily outclass CMAKE and the likes.



On Tue, Oct 30, 2018 at 11:21 AM  wrote:

> //Christian Gagneraud wrote:
>
> //
>
> // // set(var1 "Hello")
>
> // // set(var2 "Hello")
>
> // //
>
> // // if(var1 EQUAL var2)
>
> // // message("They are equal")
>
> // // endif()
>
> // //
>
> // // Guess what, it prints NOTHING despite docs explicitly saying this
> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the
> arguments, whatever.
>
> //
>
> // You read the docs wrong:
>
> // EQUAL: True if the given string or variable’s value is a valid number
> and equal to that on the right.
>
> // Neither var1 nor var2 is a valid numbers.
>
> //
>
> // You want
>
> // if (var1 STREQUAL var2) and this works as expected (and documented).
>
> //
>
> // //
>
> // Christian
>
>
>
> No it does not. Have you tried it? As I mentioned it does not work. And
> even if you somehow managed to make it work it would break the moment
> someone would define the variable "Hello" elsewhere in the script. See
> https://cmake.org/pipermail/cmake/2013-February/053587.html
>
>
>
> And that is the point. The fact we are discussing the very fundamental
> programming feature - control flow - that just does not work as expected
> (or documented) is the main problem with CMake. It is a software made of
> features botched together. You will be constantly running into these kinds
> of things because it is CMake "language" is not a standardized programming
> language (like JS is). Writing complex projects in it is extremely
> difficult which I have been unfortunate to experience first hand (had to
> write a few in it). While the business decision might be understandable
> from the technical standpoint it is an absolute nightmarish prospect. Not
> to mention it is very slow so working with codebase the size of Qt will be
> extra difficult. There will likely be effort to improve on that either on
> CMake side (if they cared) or QtComany side (more likely, because they do
> care).
>
>
>
> However I have no problem with CMake becoming the primary build generator
> replacing qmake. It is widespread etc. My issue is with deprecating Qbs.
> Having 2 people (likely very motivated now after they spent years
> developing Qbs) transfered or replaced to CMake support in Qt can hardly
> mean "Deprecating Qbs allows us to significantly improve CMake support.".
> Sounds more like standard PR BS to me, sorry.
>
>
>
> And saying Qbs got a chance when it was literally never promoted anywhere,
> not even in Qt project itself is riduclous. And coming from Thiago who even
> claimed before he never actually used it.
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

Lars, I have to wonder, don't you guys miss an opportunity here?
Qt 5 was not developed with QBS in mind.  As such it probably took more
effort than needed to fit QBS to something that was originally QMake based.

At the same time you will have to fit CMake to suit the needs for Qt6.  (or
vice versa)

Would it really be so much extra investment to have a build system fully
integrated into Qt framework process that you can just make fit on the fly,
over fiddling around the system that is overgeneralized and perhaps doesn't
support everything as much as you'd want?

You've said it yourself that qbs did give good results. Maybe give it a
chance?


On Mon, Oct 29, 2018 at 3:17 PM Lars Knoll  wrote:

> Hi all,
>
> As you will probably remember, there have been lively discussions around
> what kind of build tool to use for Qt 6 both during Qt Contributor Summits
> as well as on this mailing list.
>
> There has been a strong consent that we should move away from qmake as our
> build tool for Qt due to many shortcomings and the burden we have
> maintaining the system.
>
> Thiago wrote a set of relatively strict requirements for such a build tool
> in his mail in July. While some of the requirements had a bit of a Linux
> specific background, they have been a good basis.
>
> There have been rather lively discussions around alternatives, but most
> focused around two possible choices for us: Qbs and cmake.
>
> Qbs is something that has been developed almost exclusively by The Qt
> Company. As such, TQtC had to also look at it from a business perspective
> and how it fits into the larger picture of making Qt successful. To make a
> long story short, while Qbs is pretty cool and interesting technology, it
> doesn’t really help us expand the Qt ecosystem and usage.
>
> To make Qbs really successful would require a rather large effort and
> investment in promoting it towards the larger C++ ecosystem as a new build
> tool. At the same time it has to be an open source product to stand any
> chance in the market. Together this makes it challenging for TQtC to see
> how to recover that investment. Thus this investment would be at the
> expense of other things we’d like to do, like improving our IDE, working on
> rearchitecting and cleaning up our core frameworks for Qt 6 or the design
> tooling we are currently investing into. The Qt Company believes that those
> other investments are more important for the future of Qt than our choice
> of build tool.
>
> As such, we were left with the question on whether we need Qbs as the
> build system for Qt 6 or whether cmake (as the other alternative) would be
> up to the task.
>
> Given that background, we’ve done some more research on using both Qbs and
> cmake to build Qt. Both projects did give us good results but we were
> actually surprised on how far we got with cmake in a rather limited period
> of time.
>
> In addition, cmake has the advantage of being very widely used in the C++
> ecosystem (amongst many others by KDE), has a very wide support in many
> IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of
> knowledge about the build system available in the ecosystem. Using it with
> Qt 6 would also mean that we can focus our support on two build systems for
> our users (qmake and cmake) and we would not have to add a third one to the
> mix.
>
> Given that we are confident we can build Qt 6 with cmake, I believe that
> it makes most sense to follow down that route. In case you’re interested,
> you can have a look at the cmake prototype code for qtbase on Gerrit in the
> wip/cmake branch. Please also let us know if you’re interested in helping
> with the effort of porting Qt’s build system over to cmake.
>
> We have been developing Qbs over the last years, and as such are committed
> to it for some more time. We are planning on another feature release in the
> first quarter of next year and will support it in Qt Creator for at least
> another year. Qbs is open source and if someone wants to take over and
> develop it further let us know as well. I’d also like to use this place to
> thank Christian and Jörg for all their great work on Qbs  (and of course
> also anybody else who contributed to it).
>
> Cheers,
> Lars
> ___
> 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

Re: [Development] Build system for Qt 6

[NIkolai Marchenko]

I don't understand how can Qt just let QBS die like that. It's absolutely
fantastic.
I really hope open source development happens becuase ti will be bloody
shame if ti doesn't :(


On Tue, Oct 30, 2018 at 12:54 AM Ola Røer Thorsen 
wrote:

>
>> > >> We have been developing Qbs over the last years, and as such are
>> > >> committed to it for some more time. We are planning on another
>> feature
>> > >> release in the first quarter of next year and will support it in Qt
>> > >> Creator for at least another year.
>>
>
> This is _really_ disappointing news. I'd be happy to see qmake go, now
> this.
>
> We (at work, commercial Qt license) recently ported a rather big build
> system to Qbs, replacing qmake and scons. We now have good IDE integration
> for all our projects in QtCreator, both the Qt-based applications as well
> as pure C/C++-based projects for desktop, embedded Linux and "bare metal"
> embedded. We spent some time debugging and reporting/fixing bugs in Qbs
> too. Now with Qbs 1.12.0 we're having good and stable results. Incremental
> builds are _very_ fast. Project files are easy to set up, read and extend,
> even with custom code generation rules, things we never were able to do
> with (even undocumented) qmake. It's really impressive.
>
> Well I guess all that was for nothing, let's rewrite the build system next
> year again, and make really sure not to embrace new Qt technologies so fast
> next time.
>
> Cheers,
> Ola
>
>
>
>
>
> ___
> 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

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

I am yet to hear an answer about what is going to be done in case the
person mistreating is an active contributor.
Will you chose potential harm, over actual benefit of having such a person
on the project?

The edge case being, for example, if a module maintainer is mistreating
someone for whatever reason.
The other person can just stop trying to interact with that maintainer, but
I fail to see how removing a maintainer over a potential benefit of someone
not being mistreated actually benefits the project.

I've heard from people in this thread that it _is_ a problem you are trying
to sovle and there _have _ been mistreatment.
Now, I am not asking for dirty laundry, but isn't community supposed to
know at least in broad strokes, the kind of problems yo uare even tring to
solve before actually voting on anything?
Maybe the community have a better answer for these specific problems?

On Sat, Oct 27, 2018 at 4:56 PM Martin Smith  wrote:

>
> >1) To contact the contributor first and try to resolve the issue civilly.
> >2) To seek help with a third party (another contributor) who is known to
> the
> >alleged victim and who can act as mediator to try an resolve it.
> >3) If 1) and 2) don't work he/she may also bring it to the attention of
> the
> >community (e.g. the mailing list). The community is then free to react or
> not to
> >react.
>
> You just specified a code of conduct. The problem with your code of
> conduct is that it isn't guaranteed to end in resolution.
>
> >The implication that currently, if you're feeling mistreated, it's
> impossible to act
> >(respectfully) against harassment seems rather far-fetched to me.
>
> But that isn't the implication. The implication is that a mistreated
> person can take the actions you have specified, and the result can be that
> the mistreatment, real or not, is not resolved.
>
> 
> From: Konstantin Shegunov 
> Sent: Saturday, October 27, 2018 3:48:49 PM
> To: Martin Smith
> Cc: development@qt-project.org
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Sat, Oct 27, 2018 at 4:09 PM Martin Smith  martin.sm...@qt.io>> wrote:
> In that case, if a contributor is mistreated by another contributor, what
> recourse does the victim have?
>
> 1) To contact the contributor first and try to resolve the issue civilly.
> 2) To seek help with a third party (another contributor) who is known to
> the alleged victim and who can act as mediator to try an resolve it.
> 3) If 1) and 2) don't work he/she may also bring it to the attention of
> the community (e.g. the mailing list). The community is then free to react
> or not to react.
>
> The implication that currently, if you're feeling mistreated, it's
> impossible to act (respectfully) against harassment seems rather
> far-fetched to me.
> ___
> 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

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

Note that installing a conflict resolution authority doesn't need
installing a controversial CoC and formalizing every thing a contributor
can or cannot do..
True, there won't be formalized and standadized rules for resolution, but
aren't people in this project sensible enough, in general, to have the
common sense to reach an adequate solution?

On Sat, Oct 27, 2018 at 4:10 PM Martin Smith  wrote:

> >Well, then let me give you my simple minded opinion on this topic, an
> engineers
> >opinion:
> >Do not introduce a CoC.
>
> In that case, if a contributor is mistreated by another contributor, what
> recourse does the victim have?
>
> martin
>
> 
> From: Development 
> on behalf of Bernhard Lindner 
> Sent: Saturday, October 27, 2018 12:39:40 AM
> To: development@qt-project.org
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> > But the only mailing list with sufficient representation of the
> community is
> > this one. We don't have to like discussing this, but it seems necessary
> that
> > we do.
>
> Well, then let me give you my simple minded opinion on this topic, an
> engineers opinion:
> Do not introduce a CoC.
>
> Resisting to have anything and everything in black and white is hard and
> is not popular
> and surely not zeitgeist but sometimes the better way.
>
> Please do not make me discuss about that as well, I prefer to wrangle with
> item delegate
> code ;)
>
> --
> Best regards,
> Bernhard Lindner
>
> ___
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

> Let's assume for the sake of the argument that the text was written with
ill-
intent and let's ignore the taint that it would cause us just by adopting
it:
what's the worst that could happen? The interpretation of the CoC is left
to
the community that *is* part of the project, not the text's author.

Very simple.
Once someone like her tries to exploit the vulnerabilities community have
created by adopting this document,
the Qt project will likely shut them down with a simple "no, you are not
being reasonable".

But being unreasonable, this person will immediately blast Qt Community for
not adhering to code of conduct and doubts will arise both inside and
outside.
Depending on how persistent they are, it could become a full blown media
storm tarnishing the community's image.

This could all have been avoided by just not letting those people assume Qt
picked _their_ Code.
And whatever Qt Community thinks, they _will_ assume that it is their code
that has been picked and will hold Qt liable to that.



On Sat, Oct 27, 2018 at 12:13 AM Thiago Macieira 
wrote:

> On Friday, 26 October 2018 11:40:14 PDT NIkolai Marchenko wrote:
> > I have to disagree. As I see it: she has spent considerable amount of
> time
> > drafting the exact text to allow her to bully projects.
> > Have you spent as much time analyzing all of the potential pitfalls she
> may
> > or may not have inserted into this document?
>
> I have read the text assuming it was written and adopted in good faith,
> which
> is also how the people in the Linux kernel's TAB as well as whomever we
> empower in the Qt Project would. That's why the decisions are left to
> humans,
> not a script.
>
> > She's a malicious person and not second guessign her Code is a mistake.
>
> Let's assume for the sake of the argument that the text was written with
> ill-
> intent and let's ignore the taint that it would cause us just by adopting
> it:
> what's the worst that could happen? The interpretation of the CoC is left
> to
> the community that *is* part of the project, not the text's author.
>
> I believe the worst that could happen is an argument on the original
> spirit of
> the text versus our interpretation of it. But the Qt Project makes the
> decision, not the original author, so our opinion of what it is meant to
> say
> has more weight.
>
> So I don't think this is a danger.
>
> > Yes, indeed, is the text good? This has to be analyzed: in depth. And I
> > would still probably avoid using hers.
>
> And personally I'm leaning in favour of KDE's.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> 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

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

>  Coraline's intentions are irrelevant. What matters is the text: is it
good?

I have to disagree. As I see it: she has spent considerable amount of time
drafting the exact text to allow her to bully projects.
Have you spent as much time analyzing all of the potential pitfalls she may
or may not have inserted into this document?
She's a malicious person and not second guessign her Code is a mistake.

Yes, indeed, is the text good? This has to be analyzed: in depth. And I
would still probably avoid using hers.

On Fri, Oct 26, 2018 at 9:35 PM Thiago Macieira 
wrote:

> On Friday, 26 October 2018 09:48:11 PDT Jason H wrote:
> > My fundamental problem about the Contributor Covenant[1] was initially
> and
> > solely the fallout from the Linux Kernel fiasco. But then I learned that
> it
> > was drafted by Coraline Ada Ehmke, who sought to have a contributor
> removed
> > [2] from a project preemptively. The contributor did nothing wrong with
> > respect to the project or the project's community.  She constructed a
> claim
> > of "transphobia" based on a tweet the contributor wrote in no way
> relating
> > to the project at hand, and slandered the project for not expunging them.
> > My mind is made up: the Contributor Covenant is a tool of oppression.
>
> First of all, the kernel adoption of CoC was not a fiasco. All the
> negative
> emails you may have seen came from people who are not contributors, often
> their first and only email to the mailing list. Despite what Eric Raymond
> has
> said, revoking the copyright licence for GPL just cannot be done -- it
> would
> be against GPL's spirit.
>
> Coraline's intentions are irrelevant. What matters is the text: is it good?
>
> But if your mind is made up, kindly refrain from trying to convince others
> to
> change their minds too. This is a two-way street and you're only welcome
> to
> argue your point if you're willing to admit defeat too.
>
> > The specific sentence in the Covenant is:
> > "This Code of Conduct applies both within project spaces and in public
> > spaces when an individual is representing the project or its community."
> >
> > However, despite being the author of the Covenant (2014), she found it
> > appropriate to attack someone who was clearly not operating in a project
> > space or representing the project community (2015). We now have two
> > examples - the linux Kernel and Opal project, that after CC was enacted
> > that calls for removal of members based on past unrelated tweets went
> out.
> > One of the problems its politics and political climates change over time.
> > Expressing what is not political at one point in time may become
> political
> > in subsequent years. People's minds also change over time.
>
> What is the kernel example? Who was forced out, or attempted to?
>
> > I urge you to read link[3] below and see if we want that kind of
> attention.
> > It summarizes what happens when the CC has been adopted by other
> projects.
> >
> > [1] https://en.wikipedia.org/wiki/Contributor_Covenant
> > [2] https://github.com/opal/opal/issues/941
> > [3]
> https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/
>
> I have.
>
> The proponents of the removal were arguing that having such a person as a
> project leader is poisonous to the project, *regardless* of the fact that
> it
> was done in private time, because it would turn away potential new
> contributors as they didn't want to associate with such a person. This is
> an
> extreme situation, indeed, and one that the CoC committee should be able
> to
> make a judgement on: which way is the project best served?
>
> Anyway, given that the request to get the maintainer removed was not
> accepted,
> how is that a failure of the CoC? Isn't it showing that it's *working*?
>
> I personally think those situations explain why we need a CoC in the first
> place and why the judgment on such situations is very subjective, best
> left to
> humans, not to a script. And the deliberations should not be in a public
> forum, like a GitHub issue.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> 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

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

And we already see the budding sentiments to that exact tune:

(quote from Edward Welbourne)
>That sometimes folk have felt so intimidated that they give up on trying
>  to make a contribution; and that, were potential worse conduct to cause
>  distress to a contributor, we have no process in place that could give
>  them confidence that their distress will be respected and honest efforts
vwill be made to relieve it.  Various variations and permutations on
>  these themes may also be relevant; see Simon's mail.

Note: I understand that he means well, but Within the context of
Contributor Covenant the punishability of the potential harm of people not
contributing can escalate to stupid proportions.
I have nothing against KDE's code. It strives to add positivity.
I am very much against Qt's CoC being drafted from Covenant. Covenant is
focused on oppression and excluding ppl.

On Fri, Oct 26, 2018 at 9:06 PM Jason H  wrote:

> I don't really care that their role, though that move takes gravitas.
>
> I will never endorse a measure that encourages (and the CC does
> encourage) a witchhunt on the members of the community. It encourages by
> creating a metric of "maximum comfort" (or "least harmful") and that
> anything else is somehow a violation. She did it herself with these
> words[2]: "Is this what the other maintainers want to be reflected in the
> project? Will any transgender developers feel comfortable contributing?"
> With those words she created a metric of "maximum comfort". So now the
> question moves from not just having not offended someone, but to be
> maximally comforting to every possible person. Not that there's anything
> wrong with *wanting* to be maximally comfortable for everyone. It's a great
> goal. But now every interaction is to be judged by this metric, and
> anything less than the maximal comfort is somehow potentially alienating to
> a population and can be construed to be a cause for removal.
>
> In the CC itself it encourages a witchhunt with these words:
> "Project maintainers have the right and responsibility to remove, edit,
> or reject comments, commits, code, wiki edits, issues, and other
> contributions that are not aligned to this Code of Conduct, or to ban
> temporarily or permanently any contributor for other behaviors that they
> deem inappropriate, threatening, offensive, or harmful."
>
> That last word, "harmful" significantly alters the statement. Don't let
> your eyes glaze over. Now anything that happens is potentially harmful.
> (Ironically C++, or its constructs is even "considered harmful". Just
> google "C++ considered harmful", lol). I probably would have let this whole
> issue slide but that last word _really_ changes the character of the
> covenant. I beleive that is *the* word that allows the witchhunting. It's
> not just direct harm but potential harm. From [2]: "As a queer person
> this sort of argument from a maintainer makes me feel unwelcome. The
> ignorance which @elia <https://github.com/elia> shows by claiming that
> transfolk are "not accepting reality" is actively harmful. I will not
> contribute to this project or any other project which @elia
> <https://github.com/elia> maintains." - strand
>
> Not that strand was participating, but states that there will be no future
> contribution by strand.  This is an appeal to percieved harm - that now
> strand will not ever contribute, the project is potentially harmed by
> missing out on a contributor. So now this issue can fall under the
> Covenant.
>
>
> How can we avoid witchhunts?
>
> *Sent:* Friday, October 26, 2018 at 1:24 PM
> *From:* "NIkolai Marchenko" 
> *To:* jh...@gmx.com
> *Cc:* "Christian Kandeler" , "Qt development
> mailing list" 
> *Subject:* Re: [Development] QUIP 12: Code of Conduct
> Just to clarify: she sought to remove _maintainer_ of the project :) At
> that point the guy was doing most of the work.
>
> On Fri, Oct 26, 2018 at 7:48 PM Jason H  wrote:
>
>> My fundamental problem about the Contributor Covenant[1] was initially
>> and solely the fallout from the Linux Kernel fiasco. But then I learned
>> that it was drafted by Coraline Ada Ehmke, who sought to have a contributor
>> removed [2] from a project preemptively. The contributor did nothing wrong
>> with respect to the project or the project's community.  She constructed a
>> claim of "transphobia" based on a tweet the contributor wrote in no way
>> relating to the project at hand, and slandered the project for not
>> expunging them. My mind is made up: the Contributor Covenant is a tool of
>> oppression.
>>
>> The specific s

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

Just to clarify: she sought to remove _maintainer_ of the project :) At
that point the guy was doing most of the work.

On Fri, Oct 26, 2018 at 7:48 PM Jason H  wrote:

> My fundamental problem about the Contributor Covenant[1] was initially and
> solely the fallout from the Linux Kernel fiasco. But then I learned that it
> was drafted by Coraline Ada Ehmke, who sought to have a contributor removed
> [2] from a project preemptively. The contributor did nothing wrong with
> respect to the project or the project's community.  She constructed a claim
> of "transphobia" based on a tweet the contributor wrote in no way relating
> to the project at hand, and slandered the project for not expunging them.
> My mind is made up: the Contributor Covenant is a tool of oppression.
>
> The specific sentence in the Covenant is:
> "This Code of Conduct applies both within project spaces and in public
> spaces when an individual is representing the project or its community."
>
> However, despite being the author of the Covenant (2014), she found it
> appropriate to attack someone who was clearly not operating in a project
> space or representing the project community (2015). We now have two
> examples - the linux Kernel and Opal project, that after CC was enacted
> that calls for removal of members based on past unrelated tweets went out.
> One of the problems its politics and political climates change over time.
> Expressing what is not political at one point in time may become political
> in subsequent years. People's minds also change over time.
>
> I urge you to read link[3] below and see if we want that kind of
> attention. It summarizes what happens when the CC has been adopted by other
> projects.
>
> [1] https://en.wikipedia.org/wiki/Contributor_Covenant
> [2] https://github.com/opal/opal/issues/941
> [3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/
>
> > Sent: Friday, October 26, 2018 at 3:50 AM
> > From: "Christian Kandeler" 
> > To: "development@qt-project.org" 
> > Subject: Re: [Development] QUIP 12: Code of Conduct
> >
> > On Thu, 25 Oct 2018 19:39:45 +0200
> > André Pönitz  wrote:
> >
> > > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via
> Development wrote:
> > > > We do have a Code of Conduct at KDE for about 10 years now, and this
> hasn't
> > > > led to abuse of power, suppression of free speech, racism against
> white people
> > > > or whatever other nonsense people seem to attribute to CoCs
> nowadays.
> > >
> > > The KDE CoC is *friendly*. It contains words like "considerate",
> "pragmatic",
> > > "support". It doesn't push someone's personal political agenda.
> >
> > I agree. It reads as if it was written with the intention of creating a
> constructive environment, lacks the inquisition-y vibe and is free of
> jargon and weirdly over-specific lists.
> >
> >
> > Christian
> > ___
> > 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

>  To answer your question: in my experience, nothing happens. They
continue being a rude arse because:
And that's my problem with this code of conduct.
If it's unenforceable then this should not be Code but Guidelines.
If it's enforceable it should first be decided what is going to happen in
the case I described.

> This is a real problem in this project that not only makes it a less than
great place to work, but is also indirectly affecting the quality of the
code
Multiple people have alrady asked for examples of what the code is trying
to solve.
If you have those, we'd like to hear about these exact cases.




On Thu, Oct 25, 2018 at 2:32 PM Tor Arne Vestbø 
wrote:

> I 100% stand behind Mitch’s summary below. This is a real problem in this
> project that not only makes it a less than great place to work, but is also
> indirectly affecting the quality of the code, for those that care only
> about that part.
>
> Tor Arne
>
> > On 25 Oct 2018, at 13:22, Mitch Curtis  wrote:
> >
> > It's a bit of a loaded question. First you call asocial behaviour a
> "quirk", as if someone who treats other people like crap is "quirky" - I
> prefer your phrase "rude arse". Should a code of conduct aim to stop
> "quirky" behaviour amongst contributors? No, of course not. That's what
> makes people interesting. A code of conduct should draw the line between
> quirky behaviour and "rude arse" behaviour.
> >
> > To answer your question: in my experience, nothing happens. They
> continue being a rude arse because:
> >
> > 1) That is who they are and they aren't interested in changing.
> > 2) People have already decided that this person's technical
> contributions are worth enough that they can step on anyone, regardless of
> the fact that it's supposed to be a professional setting.
> > 3) They're "actually a nice person in real life"... as if this excuses
> it. So if I write "You're a dumbarse" on a piece of paper and send it
> through the post, but a week later invite you over to my house for a
> home-cooked meal, it's OK? Are we really encouraging keyboard warriors?
> >
> > Rafael said:
> >
> > "During all these years contributing to Qt I have encountered many times
> strong criticism in gerrit - some people were very harsh or *seemingly*
> rude - or that was what I thought, until I realized that: 1) it was just
> their modus operandi; 2) at the end of the day, their comments made sense
> and improved my code; 3) they were not butt hurt when roles were reversed."
> >
> > To me it seems like you guys are saying:
> >
> > "I don't care if this person treats me like crap because they sure can
> code."
> >
> > I'm happy for you if you've gotten this far in life and decided that you
> like being insulted in exchange for someone reviewing your code (or even
> just asking a question on IRC), but personally I do not like it. I'm more
> than capable of standing up for myself, but other people who feel the same
> way may not feel comfortable speaking out.
> >
> > What you're also saying is:
> >
> > "You (the Qt Project) aren't going to do anything about their behaviour
> because they contribute good code."
> >
> > Which sadly is true. Really, your question seems almost rhetorical given
> this. It's even explicitly acknowledged on the home page of the thing that
> we're basing our code of conduct on:
> >
> > "People with “merit” are often excused for their bad behavior in public
> spaces based on the value of their technical contributions."
> >
> > - https://www.contributor-covenant.org/
> >
> > Disregarding all of the other factors (racism, sexual identity, age,
> etc.) and just keeping it purely about treating other people with respect:
> the statement above is absolutely true.
> >
> > Honestly I have my doubts whether this code of conduct will actually
> achieve its most basic goal, given that many people have apparently tried
> to intervene with the people who treat others poorly and nothing has come
> of it (although people will tell you it's gotten better). I hope it does,
> but I've been in the community and around these people long enough to know
> that it probably won't. Reading through these replies, it's also clear that
> a large amount of the people responding are quite happy with the status
> quo, which, although not surprising to me, is always disheartening.
> >
> > I haven't seen any racism, discrimination, etc., but there are
> definitely people within the community whose behaviour is such that other
> developers will avoid interacting with them, even if it wo

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

> This community would not be the first from which people that feel
assaulted or disrespected would rather quietly disappear than to raise the
concern.

Innocent until proved guilty. This statement is hearsay in the context of
this particular project, whereas there were already accounts of people
saying a certain amount of "rudeness" never was a problem for them.
I could also try to argue the case that thesame amount of ppl will leave
quitely because their style of communication is explicitly prohibited by
the code and they don't want to change it.

On Thu, Oct 25, 2018 at 1:33 PM Simon Hausmann  wrote:

>
> Am 25.10.18 um 11:50 schrieb Rafael Roquetto:
> > I understand this has already been set in stone, and I am not here in
> > the hopes this will change. However, I do feel like I should voice my
> > own humble opinion - perhaps it can be useful, or maybe not...
>
>
> Your feedback is most certainly useful. (at least in my humble opinion ;-)
>
>
> > I would like to start by saying I fully agree with Shawn: what exactly
> > are we trying to fix? That is not to say problems never happened, but
> > these things have side effects - sometimes the most unintended ones. As
> > C++ programmers, we should know well that unintended side-effects
> > steaming from well-intentioned constructs are no exception (pun
> intended).
>
>
> You're right, there can be side-effects. We have to be careful about those,
>
> as much as we have to be careful to address the situation of uncaught
>
> exceptions. Those terminating the process of contribution and potentially
>
> causing further side-effects is what this is trying to "fix" or at least
> attempt
>
> to improve.
>
>
> I think the best way to minimize the side effects you may be concerned
> about
>
> is to ensure that the wording emphasizes the desire for a positive
> environment
>
> (for the purpose of reasoning) and also frames the part of handling
> violations
>
> as a last resort, as something that should be the exception.
>
>
> If, on the other hand, a CoC is not used as a last resort but at the
> beginning of
>
> every slight misunderstanding, then we would perhaps have failed.
>
>
> This is where input from other projects that have had a CoC, such as KDE,
> is
>
> beneficial in assessing the risks.
>
>
> > So I will go back to my question: what is it we are trying to solve? Or
> > rather, what is it that happened, that we are trying to prevent from
> > happening again? There will always be lunatics, and a CoC won't stop
> > them. Perhaps it will improve things... but... perhaps it will do more
> > harm than good. Or is it proven technology?
>
>
> As I also said in my earlier email, I'm aware of at least one case
>
> where terrible behavior resulted in a contributor with track record
>
> of patches being turned away and no consequence for the person
>
> responsible for it. That is unjust and I think doing _something_ about it
>
> is better than us - the community - keeping quiet and sweeping these
>
> exceptions under the carpet. The sweeping under the carpet, _that_ is
>
> what we must prevent from happening again.
>
>
> What are your thoughts about that?
>
>
> >
> > Which brings to my second point, a very personal one: more or less in
> > line with what Jason said, programming *to me* has always been about
> > bits and bytes, about the code, about computers, about being able to
> > make things appear on the screen and to control the machine. Free
> > Software has been about free software and that's it. I find it
> > extremely off-putting to see that the Qt project is embarking in this
> > sort of politics - again, if things were broken and a CoC could fix
> > them, I would be more than happy to join the train, but that doesn't
> > seem to be the case. At least from my humble perspective.
>
>
> I think it should be like that, at the heart of it.
>
>
> On the other hand much has happened in the world since the early
>
> days of free software projects. A much larger part of the population
>
> on the planet has access to the internet and education that makes it
>
> possible for them to join our community. I think that is a fantastic
>
> opportunity. It means that people different backgrounds, different cultures
>
> and different upbrinings are able to join. We must assume good faith,
>
> but we should be prepared to be able to explain what we would perhaps
>
> consider "common sense" in terms of behavior. A well worded document
>
> may be of tremendous help.
>
>
> This is one aspect I really like about the GNU Kind Communications
> Guidelines
>
> as an alternative. It's _something_ more than what we have today.
>
>
> > During all these years contributing to Qt I have encountered many times
> > strong criticism in gerrit - some people were very harsh or *seemingly*
> > rude - or that was what I thought, until I realized that: 1) it was just
> > their modus operandi; 2) at the end of the day, their comments made
> > sense and improved my code; 3) they were not butt 

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

I would also like to point out an extreme case:
https://github.com/opal/opal/issues/941
Now, I am not saying the Code is going to transform into a shitstorm like
this. But it's something to be aware of.
Some clear boundaries must be set if Code is ever enforced.

Also: a question needs to be answered: say, there's a contributor that does
a lot.
He's a rude ass, but he is a _productive_ rude ass and mostly everyone
agrees that his contributions outweigh his particular quirk.
What are you going to do under such a code of conduct? Remove his access to
the project? This sounds ridiculous tbh.

On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev 
wrote:

>
>
> 25.10.2018, 13:01, "NIkolai Marchenko" :
> >> And btw, we have had a clear majority in favour of adding a CoC at the
> Contributor Summit
> >
> > It seems very wrong to make such decisions at conventions where only a
> small part of the contributors can participate.
> > Especially for something as big and divisive
>
> +1
>
> --
> Regards,
> Konstantin
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

> And btw, we have had a clear majority in favour of adding a CoC at the
Contributor Summit

It seems very wrong to make such decisions at conventions where only a
small part of the contributors can participate.
Especially for something as big and divisive

On Thu, Oct 25, 2018 at 12:52 PM Rafael Roquetto 
wrote:

> I understand this has already been set in stone, and I am not here in
> the hopes this will change. However, I do feel like I should voice my
> own humble opinion - perhaps it can be useful, or maybe not...
>
> I would like to start by saying I fully agree with Shawn: what exactly
> are we trying to fix? That is not to say problems never happened, but
> these things have side effects - sometimes the most unintended ones. As
> C++ programmers, we should know well that unintended side-effects
> steaming from well-intentioned constructs are no exception (pun intended).
>
> So I will go back to my question: what is it we are trying to solve? Or
> rather, what is it that happened, that we are trying to prevent from
> happening again? There will always be lunatics, and a CoC won't stop
> them. Perhaps it will improve things... but... perhaps it will do more
> harm than good. Or is it proven technology?
>
> Which brings to my second point, a very personal one: more or less in
> line with what Jason said, programming *to me* has always been about
> bits and bytes, about the code, about computers, about being able to
> make things appear on the screen and to control the machine. Free
> Software has been about free software and that's it. I find it
> extremely off-putting to see that the Qt project is embarking in this
> sort of politics - again, if things were broken and a CoC could fix
> them, I would be more than happy to join the train, but that doesn't
> seem to be the case. At least from my humble perspective.
>
> During all these years contributing to Qt I have encountered many times
> strong criticism in gerrit - some people were very harsh or *seemingly*
> rude - or that was what I thought, until I realized that: 1) it was just
> their modus operandi; 2) at the end of the day, their comments made
> sense and improved my code; 3) they were not butt hurt when roles were
> reversed.
>
> Communication/criticism just like this is unambiguously straightforward
> and I *personally* prefer it this way. Unfortunately I could not make it
> to the QtCS, but had I been there, I would have voted against the CoC,
> for sure. I hate to see politics tainting the project. But, that is my
> view, and in spite of that, I do hope that in the end I am wrong and
> that the CoC is another step on the right direction. Let's remain
> positive and hope it won't even be necessary to invoke it after all, and
> that respect and common-sense shall prevail.
>
>
> - Rafael
>
> PS: if you have read this far (sorry!), you may also be interested in
> donating a tad more of your time and help with reviewing this
>
>  https://codereview.qt-project.org/#/c/241598/
>
>  ;)
>
>
> On 10/25/18 5:58 PM, Lars Knoll wrote:
> >> On 25 Oct 2018, at 09:51, Volker Krause via Development
> >> mailto:development@qt-project.org>> wrote:
> >>
> >> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote:
> >>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge:
> >>>
> 
> 
> > On 24 Oct 2018, at 17:09, Jason H  > > wrote:
> >
> >
> >
> > In case it needs to be said-
> > I am AGAINST racism, sexism, bigotry, and all the other exclusionary
> > things. But I am also against people judging other people's code for
> > factors that have nothing to do with the code itself. I find that
> > adding
> > a value judgement of conduct to code to be intolerant. We had the
> > ideal.
> >> I am FOR inclusion. I want everyone to feel welcome here.
> > Everyone.>
>  I agree.  It seems to be about fixing something that isn’t broken, or
> as
>  in that story in the Bible where the people came to a consensus that
>  every other country around them had a king, so they should have a king
>  too.  Nothing good came out of it in any cases where we have seen this
>  kind of illogic applied.  “Most other big corporations have a deep
>  hierarchy of management, with too much power concentrated at the
>  top, and
>  we want to be a big corporation, so we need to replicate that.”  “The
>  other lemmings are running away so maybe we’d better follow.”  It’s
> not
>  the open source way, which seemed to be working well enough already.
> >>>
> 
> 
>  If you give power to a committee of 3 people, they will probably
>  abuse it
>  eventually, misjudge, cause bitterness, create factions, and some
>  developers will end up walking away.  Seems predictable, doesn’t it?
> >>>
> 
> >>>
> >>>
> >>> You claim that this is about fixing something that isn't broken. Your
> >>> statement that a committee will predictably and 

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

Looking from outside: Qt has always seemed the community that just dpesn't
need something like that to regulate itself.
Explicit Code seems like an alien entity and ppl already trying to enforce
"at least one female" rise all kinds of warning flags in my eyes.

Personally, I only see the potential to strangle creativity and turning ppl
off from joining in enforcing such a code without any benefit other than
"to look civilized"


On Wed, Oct 24, 2018 at 9:32 PM André Pönitz  wrote:

> On Wed, Oct 24, 2018 at 05:42:59PM +0200, Aleix Pol wrote:
> > On Wed, Oct 24, 2018 at 5:10 PM Jason H  wrote:
> > >
> > > I am whole-heartedly against a Code of Conduct. [...]
> > > >
> > > > Hi,
> > > >
> > > > regarding our earlier discussions on a possible Code of Conduct,
> here as
> > > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> > > > necessary rules and definitions:
> > > >
> > > > https://codereview.qt-project.org/243623
> > > >
> > > > Please review it.
> > > >
> > > > regards, Ulf
> >
> > Dear Jason, I fail to see how you can feel entitled to give your opinion
> when
> > you've done nothing to earn that right
>
> The Governance Model states that
>
>"The Qt Project is a meritocratic, consensus-based community interested
> in Qt.
>
>"Anyone who shares that interest can join the community, participate in
> its
> decision making processes, and contribute to Qt's development. "
>
> Jason has shown his interest in Qt multiple times. According to this
> definition
> he is clearly a member of the community, he is under the current rules
> fully
> entitled to take part in the decision making process and state his opinion.
>
> Andre'
>
> PS:
>
> > (I can't find any significant contribution by you), especially when it
> comes
> > to oppose something that was agreed together with the rest of the
> contributors.
> >
> > I don't think you have even read the proposal. If you want to play with
> the
> > grown-ups, act like one first.
>
> I refrain from commenting this further.
> ___
> 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

Re: [Development] Dropping remaining support of qtquick1

[NIkolai Marchenko]

Doesn't that mean that Controls will also get the boot though?

On Sat, Oct 6, 2018 at 3:33 PM Pierre-Yves Siret  wrote:

>
>
> Le ven. 5 oct. 2018 à 18:34, Edward Welbourne  a
> écrit :
>
>> NIkolai Marchenko (5 October 2018 18:30) wrote:
>> > I would like to remind people that there has already been a deprecation
>> thread "
>> > [Development] Deprecation of Qt Quick Controls 1" by
>> > Frederik Gladhorn this Februrary.
>> > A couple issues were raised there that were rather relevant and I would
>> like to know if they were ever addressed.
>>
>> To save others the finding of it, that starts here:
>>
>> https://lists.qt-project.org/pipermail/development/2018-February/032073.html
>>
>> Eddy.
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>
> Kai is talking about Qt Quick 1 not Qt Quick Controls 1
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dropping remaining support of qtquick1

[NIkolai Marchenko]

I would like to remind people that there has already been a deprecation
thread "[Development] Deprecation of Qt Quick Controls 1" byFrederik
Gladhorn this Februrary.
A couple issues were raised there that were rather relevant and I would
like to know if they were ever addressed.

On Fri, Oct 5, 2018 at 6:29 PM Thiago Macieira 
wrote:

> On Friday, 5 October 2018 02:24:39 PDT Kai Koehne wrote:
> > The last remaining support for Qt Quick 1 are in the build system
> > (qml1_module.prf, qml1_plugin.prf), QLibraryInfo::ImportsPath, qmake
> > ($$QT_INSTALL_IMPORTS), and finally in QObject and QWidget (handling of
> > QAbstractDeclarativeData::destroyed_qml1).
> >
> > We could remove these already in 5.12, in 5.13, or wait for Qt 6. I'd
> prefer
> > 5.12 if nobody objects
>
> I don't think we should.  qtquick1 may not be as dead as we'd like it to
> be.
> I'd rather keep the QtCore API just in case someone is keeping the old
> module
> working for their applications (or Linux distribution, though I can't find
> any). They may also be (ab)using QLibraryInfo::ImportsPath for some other
> purpose.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> 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

Re: [Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit)

[NIkolai Marchenko]

Wasn't it decided it was not the time to switch? Saying for myself - this
will will likely see me not upgrade Qt distro until at least 6.0 once your
suggested change hits..

On Tue, Oct 2, 2018 at 3:47 PM Alex Blasche  wrote:

> Hi,
>
> We had this discussion for Qt 5.11 already but it is time to decide for Qt
> 5.12. The discussion details can be found under
>
> https://bugreports.qt.io/browse/QTBUG-63708
>
> Based on download figures and dropped MSVC2015 support for webengine we
> plan to change MSVC2015 32bit binaries over to MSVC2017 32bit. I realize
> this will not be happy news for everybody but considering the LTS
> implications of Qt 5.12 it makes sense. Nevertheless if you believe you
> have strong counter arguments please comment on the issue in Jira.
>
> Thank you.
> --
> Alex
>
> P.S. This does *not* mean that we drop 32bit for MSVC2015 support. We
> merely drop the pre-built binary offering in our installer.
> ___
> 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

Re: [Development] Prebuilt 32-bit versjon for MSVC 2017

[NIkolai Marchenko]

This dedication to dropping MSVC2015x32 seems quite stange after the whole
controversy of dropping MSVC2013 and how many people prefered to tread very
carefully and slowly.

Unlike msvc 2013, 15th compiler is way better and doesn't restrain Qt
codebase nearly as much

On Wed, Feb 21, 2018 at 3:44 PM, Harald Kjølberg 
wrote:

>
> Hi,
>
> Currently Qt ships with 32-bit binaries for MSVC 2015, but not for MSVC
> 2017. The Qt Company have received requests for adding prebuilt 32-bit
> binaries also for MSVC 2017. By adding more prebuilt binaries, we increase
> the complexity, and add to the overall maintenance of our QA system. Our
> preferred approach would be to add binaries for MSVC 2017 and remove the
> binaries for MSVC 2015, as the numbers of binaries in the build remains the
> same. It will still be possible to manually build Qt for MSVC 2015, in the
> same way as it is possible to manually build for MSVC 2017 today. Feedback
> and viewpoints are much appreciated and will enable us to make the best
> possible decision.
>
>
>
>
> Best regards,
> Harald Kjølberg
> Product Manager - Qt for Application Development
>
>
>
> ___
> 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

Re: [Development] Deprecation of Qt Quick Controls 1

[NIkolai Marchenko]

Well, thank you for your example, but I would rather code a completely
custom combobox in QML than go this route
(even with my qml skills noobish at best it seems a more reasonable idea,
than coding a "widgets monster" )

And for the time being I will just stick with Controls 1 as I want to be
improving the core of my app
rather than spend weeks of my weekend time fixing UI problem introduced by
controls deprecation.

I just wanted to highlight the problem, that it is really, really too early
to cycle out V1.
And that combobox V2 is completely unacceptable on desktop. I still have to
see the "fusion" suggestion though

On Wed, Feb 7, 2018 at 6:48 PM, Olivier Goffart <oliv...@woboq.com> wrote:

> Am Mittwoch, 7. Februar 2018, 15:35:34 CET schrieb NIkolai Marchenko:
> > even stuff like that?
> > https://imgur.com/a/tTFeO
> > I doubt it. I really don't want to delve into manual painter usage and
> > styleoptions when I can just quickly make such stuff with qml listview.
> > And basically the only thing that really hurts me with controls 2 is that
> > combobox becomes quite horrible
>
> That can be done without too much difficulty.  For reference, i have been
> doing the ui for the ownCloud client with a QTreeView:
> https://imgur.com/a/7ore2
>
> "All you have to do," is create a QAbstractItemDelegate, then you can paint
> anything with QPainter. It is just a bunch of drawRectangle and drawText,
> and for the style element, you can use style()->drawComplexControl
> You have to layout everything by manually computing the position of items.
> The logic of the embedded combobox might be a bit tricky but perhaps a
> spinbox
> would be much easier to draw.
>
> Clearly this is not the prettiest code ever
> https://code.woboq.org/owncloud/client/src/gui/
> folderstatusdelegate.cpp.html#_ZNK3OCC20FolderStatusDelegate5
> paintEP8QPainterRK20QStyleOptionViewItemRK11QModelIndex
>
> So while it is possible to do this, this is indeed much harder and less
> maintainable than with QML.
>
> Unfortunately, it seems that the story for QML on desktop is less than
> ideal.
> There is still much polishing to do to get there. And the fact that Qt
> Quick
> Controls 2 does not seem to have the desktop as a first place citizen is
> worrying.
>
> The Qt Company does not seem to be interested in the desktop. The fact that
> QtCreator went back from using some of QML for example just shows that the
> situation is regressing rather than improving.
>
> --
> Olivier
>
> Woboq - Qt services and support - https://woboq.com -
> https://code.woboq.org
>
>
>
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Deprecation of Qt Quick Controls 1

[NIkolai Marchenko]

I meant, I will *lose* model:10 syntax like this
(mailing lists and unfixable wording errors, ugh)

On Wed, Feb 7, 2018 at 6:02 PM, NIkolai Marchenko <enmarantis...@gmail.com>
wrote:

> Thanks, I will see how it works. Though I will use the model: 10 syntax
> like this :(
>
> On Wed, Feb 7, 2018 at 5:46 PM, Helmut Mülner <helmut.muel...@gmail.com>
> wrote:
>
>> Ø  And basically the only thing that really hurts me with controls 2 is
>> that combobox becomes quite horrible
>>
>>
>>
>> I use something like this for a decent looking combobox:
>>
>>
>>
>> ComboBox {
>>
>> id: *comboBox*
>>
>> Layout.fillWidth: true
>>
>> height: 30
>>
>> Layout.maximumHeight: 30
>>
>> Layout.minimumHeight: 30
>>
>> font.pointSize: 10
>>
>> anchors.verticalCenter: *parent*.verticalCenter
>>
>> textRole: "name"
>>
>> model: myModel
>>
>> delegate: ItemDelegate {
>>
>> width: *comboBox*.width
>>
>> height: 30
>>
>> contentItem: Text {
>>
>> id: *itemDelegateText*
>>
>> text: name
>>
>> font: *comboBox*.font
>>
>> elide: Text.ElideRight
>>
>> verticalAlignment: Text.AlignVCenter
>>
>> }
>>
>> highlighted: *comboBox*.highlightedIndex == index
>>
>> }
>>
>> }
>>
>>
>>
>> Cheers,
>>
>> Helmut
>>
>>
>>
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Deprecation of Qt Quick Controls 1

[NIkolai Marchenko]

Thanks, I will see how it works. Though I will use the model: 10 syntax
like this :(

On Wed, Feb 7, 2018 at 5:46 PM, Helmut Mülner 
wrote:

> Ø  And basically the only thing that really hurts me with controls 2 is
> that combobox becomes quite horrible
>
>
>
> I use something like this for a decent looking combobox:
>
>
>
> ComboBox {
>
> id: *comboBox*
>
> Layout.fillWidth: true
>
> height: 30
>
> Layout.maximumHeight: 30
>
> Layout.minimumHeight: 30
>
> font.pointSize: 10
>
> anchors.verticalCenter: *parent*.verticalCenter
>
> textRole: "name"
>
> model: myModel
>
> delegate: ItemDelegate {
>
> width: *comboBox*.width
>
> height: 30
>
> contentItem: Text {
>
> id: *itemDelegateText*
>
> text: name
>
> font: *comboBox*.font
>
> elide: Text.ElideRight
>
> verticalAlignment: Text.AlignVCenter
>
> }
>
> highlighted: *comboBox*.highlightedIndex == index
>
> }
>
> }
>
>
>
> Cheers,
>
> Helmut
>
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Deprecation of Qt Quick Controls 1

[NIkolai Marchenko]

I really don't want to go there for a project I am not paid to develop :)

On Wed, Feb 7, 2018 at 5:54 PM, Konstantin Tokarev <annu...@yandex.ru>
wrote:

>
>
> 07.02.2018, 17:42, "NIkolai Marchenko" <enmarantis...@gmail.com>:
> > even stuff like that?
> > https://imgur.com/a/tTFeO
> > I doubt it. I really don't want to delve into manual painter usage and
> styleoptions when I can just quickly make such stuff with qml listview.
>
> FWIW, in company where I work we routinely did such UIs for embedded
> systems with Qt 4 and widgets. However, it required quite a bit of work to
> implement basic ListView with pluggable renderers. However, we didn't use
> QStyle and style options, and had no tough controls like combo box there.
>
> > And basically the only thing that really hurts me with controls 2 is
> that combobox becomes quite horrible
> >
> > On Wed, Feb 7, 2018 at 5:25 PM, Konstantin Tokarev <annu...@yandex.ru>
> wrote:
> >
> >> 07.02.2018, 16:13, "NIkolai Marchenko" <enmarantis...@gmail.com>:
> >>> And no, widgets is not an alterlative to proper qml controls on
> desktop when you want custom interface.
> >>> I have an app that uses qml to draw a custom listview for users, it
> would be extremely hard to replicate it with widgets and why should I do
> that when I have qml?
> >>
> >> FWIW, it's not really hard to implement your own ItemView widgets.
> >>
> >> --
> >> Regards,
> >> Konstantin
>
>
> --
> Regards,
> Konstantin
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Deprecation of Qt Quick Controls 1

[NIkolai Marchenko]

even stuff like that?
https://imgur.com/a/tTFeO
I doubt it. I really don't want to delve into manual painter usage and
styleoptions when I can just quickly make such stuff with qml listview.
And basically the only thing that really hurts me with controls 2 is that
combobox becomes quite horrible

On Wed, Feb 7, 2018 at 5:25 PM, Konstantin Tokarev <annu...@yandex.ru>
wrote:

>
>
> 07.02.2018, 16:13, "NIkolai Marchenko" <enmarantis...@gmail.com>:
> > And no, widgets is not an alterlative to proper qml controls on desktop
> when you want custom interface.
> > I have an app that uses qml to draw a custom listview for users, it
> would be extremely hard to replicate it with widgets and why should I do
> that when I have qml?
>
> FWIW, it's not really hard to implement your own ItemView widgets.
>
>
> --
> Regards,
> Konstantin
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development