On Tuesday 25 April 2017 10:09:50 Edward Welbourne wrote:
[,,,]
> ask that
> each introduce self in the course of it - possibly *after* we've made
> our decision, so we won't be prejudiced by their weird hobbies. ISTR
> Lars, when proposing me, just linked to my review history in gerrit;
> that pr
On 2017-04-25 19:41, Thiago Macieira wrote:
On Tuesday, 25 April 2017 13:39:52 -03 Marc Mutz wrote:
On 2017-04-25 16:34, Lars Knoll wrote:
[...]
> But I agree with Thiago, that we should have this written down in a
> QUIP, ideally with a list of the classes we consider ok to use in our
> APIs.
On 2017-04-25 23:04, Thiago Macieira wrote:
On Tuesday, 25 April 2017 17:49:16 -03 Alejandro Exojo wrote:
On Tuesday 25 April 2017 16:35:01 Thiago Macieira wrote:
> QVector and QList don't have the same API. They're slightly different.
> What'sm ore, QList has a beginning-of-list optimisation,
On Tuesday, 25 April 2017 17:49:16 -03 Alejandro Exojo wrote:
> On Tuesday 25 April 2017 16:35:01 Thiago Macieira wrote:
> > QVector and QList don't have the same API. They're slightly different.
> > What'sm ore, QList has a beginning-of-list optimisation, whereas QVector
> > doesn't (not even my
On Tuesday 25 April 2017 16:35:01 Thiago Macieira wrote:
> QVector and QList don't have the same API. They're slightly different.
> What'sm ore, QList has a beginning-of-list optimisation, whereas QVector
> doesn't (not even my copy, I stopped development shortly before I got to
> that part, even
On Tuesday, 25 April 2017 15:45:12 -03 Matthew Woehlke wrote:
> Maybe an alternate approach makes sense?
>
> 1. Rename QList -> QArrayList.
> 2. Remove special case of inline storage.
> 3. Add QList as an alias to either QArrayList or QVector
> depending on T.
QVector and QList don't have the sam
On Tuesday, 25 April 2017 14:30:50 -03 André Pönitz wrote:
> > Why does it need to be versioned on a per-branch basis? Because of when we
> > deprecate older compilers, we can update the list?
>
> Since the rules will likely differ per branch I actually think it's
> a good idea to have the rules c
On Tue, Apr 25, 2017 at 08:09:50AM +, Edward Welbourne wrote:
> Steve Schilz asked me (24 April 2017 19:10) a pertinent question (heavily
> edited):
> > I’m not really sure what/where your role is… and I’m curious.
> > Perhaps an introduction on the mailing list (say, from Lars Knoll?)
> > for
On 2017-04-25 20:45, Matthew Woehlke wrote:
On 2017-04-25 09:48, Thiago Macieira wrote:
Basically the discussion is: what should happen to QArrayList or
QArrayList?
a) fail to compile
b) become an array list
c) become a vector
I point out that (c) is what QList does, and we don't need the s
On 2017-04-25 09:48, Thiago Macieira wrote:
> Basically the discussion is: what should happen to QArrayList or
> QArrayList?
>
> a) fail to compile
> b) become an array list
> c) become a vector
>
> I point out that (c) is what QList does, and we don't need the same behaviour
> as QList alre
On Tue, Apr 25, 2017 at 02:41:19PM -0300, Thiago Macieira wrote:
> On Tuesday, 25 April 2017 13:39:52 -03 Marc Mutz wrote:
> > On 2017-04-25 16:34, Lars Knoll wrote:
> > [...]
> >
> > > But I agree with Thiago, that we should have this written down in a
> > > QUIP, ideally with a list of the class
On Tuesday, 25 April 2017 13:39:52 -03 Marc Mutz wrote:
> On 2017-04-25 16:34, Lars Knoll wrote:
> [...]
>
> > But I agree with Thiago, that we should have this written down in a
> > QUIP, ideally with a list of the classes we consider ok to use in our
> > APIs.
>
> [...]
>
> I'd make the QUIP d
On 2017-04-25 16:34, Lars Knoll wrote:
[...]
But I agree with Thiago, that we should have this written down in a
QUIP, ideally with a list of the classes we consider ok to use in our
APIs.
[...]
I'd make the QUIP define the updated BC guarantee. The list of std types
available for use in Qt AP
On 25 April 2017 at 17:34, Lars Knoll wrote:
>
>> On 25 Apr 2017, at 15:51, Thiago Macieira wrote:
>>
>> Em terça-feira, 25 de abril de 2017, às 07:59:03 -03, Marc Mutz escreveu:
>>> What's holding us back?
>>
>> At this point, inertia.
>>
>> I've already lifted my objection in the grounds that n
Hi,
There were quite many people who expressed interest a few months ago to help in
making the releases, so hopefully we get a lot of suggestions to better engage
with the whole community for testing the releases.
Quite many are testing new Qt versions with their applications and reporting
is
> On 25 Apr 2017, at 15:51, Thiago Macieira wrote:
>
> Em terça-feira, 25 de abril de 2017, às 07:59:03 -03, Marc Mutz escreveu:
>> What's holding us back?
>
> At this point, inertia.
>
> I've already lifted my objection in the grounds that no one in the Linux
> sphere cares about compatibili
On 25 Apr 2017, at 15:48, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
Em terça-feira, 25 de abril de 2017, às 03:14:54 -03, Marc Mutz escreveu:
On Tuesday 25 April 2017 06:45:04 André Somers wrote:
Op 24/04/2017 om 20:39 schreef Marc Mutz:
On 2017-04-24 20:19, Ville Voutilainen wro
> On 25 Apr 2017, at 14:09, Alberto Mardegan
> wrote:
>
> On 25/04/2017 09:29, Martin Smith wrote:
>>> What would be incorrect as those APIs are only internal for C++, but
>>> public for QML or v.v.
>>
>> Then we need \cpponly and \qmlonly, or something like that.
>
> This is calling for futu
Em terça-feira, 25 de abril de 2017, às 07:59:03 -03, Marc Mutz escreveu:
> What's holding us back?
At this point, inertia.
I've already lifted my objection in the grounds that no one in the Linux
sphere cares about compatibility between libstdc++ and libc++ without a
"rebuild the world" step.
Em terça-feira, 25 de abril de 2017, às 03:14:54 -03, Marc Mutz escreveu:
> On Tuesday 25 April 2017 06:45:04 André Somers wrote:
> > Op 24/04/2017 om 20:39 schreef Marc Mutz:
> > > On 2017-04-24 20:19, Ville Voutilainen wrote:
> > > [...]
> > >
> > >> What is wrong with QArrayList?
> > >
> > > N
On 25/04/2017 09:29, Martin Smith wrote:
>> What would be incorrect as those APIs are only internal for C++, but
>> public for QML or v.v.
>
> Then we need \cpponly and \qmlonly, or something like that.
This is calling for future headaches, when you start adding python or
other languages.
It's b
On Tuesday 14 March 2017 11:32:39 Olivier Goffart wrote:
> On Dienstag, 14. März 2017 10:33:44 CET Simon Hausmann wrote:
> > Hi,
> >
> >
> > I understand that there are limitations (to put it mildly) regarding the
> > use of API from the C++ standard library in Qt API itself due to the
> > inabil
On Mon, Apr 24, 2017, at 05:08 PM, Shawn Rutledge wrote:
> > And if a C++ class has a corresponding QML type, should every member
> > function be included in the documentation for both? How will qdoc know that
> > a member function only applies to the C++ class or only to the QML type?
>
> Q_INV
Hi all,
There is now wiki page for reporting testing effort and results in
https://wiki.qt.io/Qt59_release_testing . I also asked you all to take a tour
for Qt 5.9 beta2 & report the effort via it. As you can see there isn't really
any reports from community yet. It would be really beneficial f
On mandag 24. april 2017 14.05.17 CEST Sean Harmer wrote:
> Hi,
>
> are there any plans to reduce/remove the redundancy when writing
> documentation for both C++ and QML? Seems a waste of time to have to
> copy/paste or update the docs twice for both languages when really the
> only things differi
Steve Schilz asked me (24 April 2017 19:10) a pertinent question (heavily
edited):
> I’m not really sure what/where your role is… and I’m curious.
> Perhaps an introduction on the mailing list (say, from Lars Knoll?)
> for people further out in the Qt orbit is in order, or perhaps I
> missed it?
26 matches
Mail list logo
