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 li
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
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
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,
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:
>
>>
eral_ 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
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
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 C
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 behav
> 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 wro
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?
> 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'Angel
> 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 F
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 w
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 ne
> 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 Q
> I personally consider “sudo apt-get install -y qtcreator”
distros come with outdated qt
On Wed, Jan 29, 2020 at 7:10 PM Volker Hilsheimer
wrote:
> > On 29 Jan 2020, at 15:20, Benjamin TERRIER wrote:
> > On Wed, 29 Jan 2020 at 14:10, Cristián Maureira-Fredes <
> cristian.maureira-fre...@qt.io
> 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
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
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 (qui
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
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 machin
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.
>>>
>> [...]
>>&g
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 +, Tuukk
ker 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 bec
> 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 th
tinue 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,
rce 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 b
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 bina
ope 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
> 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 av
> 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, corobe
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 : absolut
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
wi
> 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 automati
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
> 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 require
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&q
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
> 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
arev" :
> > 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
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 ju
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 essenit
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 a
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
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,
>
>
tml#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
> написал(а):
>
&g
iscussions 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:
ssigned
> 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&#x
> 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
> 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, Kon
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
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 u
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
real
> hard.
>
> Current minimal required version by Qt is 0.5.0 and only really old
> distros do not have it. And to quote the commit message that removed the
> library from bundled sources:
>
> "This library is present on all supported platforms."
>
>
- [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'
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 (f
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)
>
(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 fo
> 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 no
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,
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 nurt
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.
_
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
8 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 ne
> 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
> 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 She
> 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
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 ... ;)
&g
> 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:
> > F
> 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.co
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#g
> 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
importa
> 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
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 qma
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
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 tim
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 t
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
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 a
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 vers
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,
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
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
e 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:
> >
> 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 h
his 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
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. Bu
tus
> 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 i
> 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
s
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
> 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 R
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
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 r
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, 201
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 d
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 P
to
see the "fusion" suggestion though
On Wed, Feb 7, 2018 at 6:48 PM, Olivier Goffart 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'
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
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, H
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 decen
1 - 100 of 137 matches
Mail list logo
