On Thursday 18 June 2015 22:36:01 Matthew Woehlke wrote:
> On 2015-06-18 16:33, Marc Mutz wrote:
> > On Thursday 18 June 2015 18:16:30 Matthew Woehlke wrote:
> >>> If you step back a bit, you'll notice that both and
> >>> , as well as are big, fat, mistakes.
> >>
> >> Why? How can QtNumeric, in
On Thursday 18 June 2015 21:49:38 André Pönitz wrote:
> So far no reason was given in favour of the additional inconsistencies
> that went beyond "I think it is posh" and "I want to have fun playing
> with the Qt API".
http://lists.qt-project.org/pipermail/development/2015-June/022038.html
> Ther
On 2015-06-18 16:33, Marc Mutz wrote:
> On Thursday 18 June 2015 18:16:30 Matthew Woehlke wrote:
>>> If you step back a bit, you'll notice that both and
>>> , as well as are big, fat, mistakes.
>>
>> Why? How can QtNumeric, in particular, be a mistake unless qnumeric.h is
>> also a mistake?
>
>
On Thu, Jun 18, 2015 at 09:22:07AM +0100, Sean Harmer wrote:
> On Thursday 18 Jun 2015 09:18:15 Giuseppe D'Angelo wrote:
> > On Thu, Jun 18, 2015 at 9:08 AM, Simon Hausmann
> >
> > wrote:
> > > Or would the idea be to place the Q_DECLARE_METATYPE outside of the
> > > namespace?
> > Why "the idea"
On Thursday 18 June 2015 18:16:30 Matthew Woehlke wrote:
> > If you step back a bit, you'll notice that both and
> > , as well as are big, fat, mistakes.
>
> Why? How can QtNumeric, in particular, be a mistake unless qnumeric.h is
> also a mistake?
because is the header that brings in all of
On 2015-06-18 11:17, Marc Mutz wrote:
> On Thursday 18 June 2015 15:45:06 Matthew Woehlke wrote:
>> Reasons I have used :
>>
>> - I want only the macros
>> - I want only the platform / compiler feature symbols
>> - I want only some free function (e.g. qRound)
>> - I want only the convenience typede
On Thursday 18 June 2015 15:45:06 Matthew Woehlke wrote:
> On 2015-06-18 09:07, Marc Mutz wrote:
> > 4. Includes:
> >a. includes the whole module (as is the case for QtCore, ...
> >now) b. There's no include for just the namespace (with
> >enums, free
> >
> > functions, etc)
On 2015-06-18 09:07, Marc Mutz wrote:
> 4. Includes:
>a. includes the whole module (as is the case for QtCore, ... now)
>b. There's no include for just the namespace (with enums, free
> functions, etc). To get the namespace, users include any class from the
> module (much like
Or a bug in moc. I think that moc should always resolve the fully qualified
name and store that one in the generated tables. Otherwise these kind of errors
happen way too easily.
Cheers,
Lars
On 18/06/15 15:01,
"development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
Sean
That's a bug in Qt3D.
https://codereview.qt-project.org/#/c/114639/
Cheers,
Sean
On Thursday 18 Jun 2015 13:19:24 Simon Hausmann wrote:
> On Thursday, June 18, 2015 12:45:53 PM Marc Mutz wrote:
> [...]
>
> > The meta-type system and moc are perfectly fine with namespaces. If people
> > would
On Thursday 18 June 2015 12:51:01 Smith Martin wrote:
> Do you also advocate rules for using namespaces in Qt? What rules does KDE
> use?
I believe it's worth reading Sze Howe Koh's mails in this thread and the last
one (Oct 2013), even if the mails tend to be overwhelmingly full of
information
Le jeudi 18 juin 2015 à 13:19 +0200, Simon Hausmann a écrit :
> On Thursday, June 18, 2015 12:45:53 PM Marc Mutz wrote:
> [...]
> > The meta-type system and moc are perfectly fine with namespaces. If people
> > would just peek over their own noses and over to your cousin, KDE, you'd see
> > that,
On Thursday, June 18, 2015 12:45:53 PM Marc Mutz wrote:
[...]
> The meta-type system and moc are perfectly fine with namespaces. If people
> would just peek over their own noses and over to your cousin, KDE, you'd see
> that, say, kdepimlibs would have a very hard time indeed, if QMetaType or
> moc
; behalf of Marc Mutz Sent: Thursday, June 18, 2015 1:32
> PM
> To: development@qt-project.org
> Subject: Re: [Development] Some Qt3D feedback
>
> On Thursday 18 June 2015 11:37:48 Knoll Lars wrote:
> > >Curiously, you didn't list any pro-namespace arguments. I don't k
-bounces+martin.smith=theqtcompany@qt-project.org
on behalf of
Marc Mutz
Sent: Thursday, June 18, 2015 1:32 PM
To: development@qt-project.org
Subject: Re: [Development] Some Qt3D feedback
On Thursday 18 June 2015 11:37:48 Knoll Lars wrote:
> >Curiously, you didn't list any pro-nam
On Thursday 18 June 2015 11:37:48 Knoll Lars wrote:
> >Curiously, you didn't list any pro-namespace arguments. I don't know what
> >to make of this, but I fear that a decision is being made based solely
> >on arguments from one side.
>
> So what are the arguments from your point of view then? Apa
On Thursday 18 June 2015 09:08:18 Simon Hausmann wrote:
> On Wednesday, June 17, 2015 03:36:11 PM Marc Mutz wrote:
> > On Wednesday 17 June 2015 12:56:54 Knoll Lars wrote:
> > [...]
> >
> > > * connect statements are hard with namespaces. Old style connects could
> > > easily break if you forgot t
On 17/06/15 15:36,
"development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
Marc Mutz" wrote:
>On Wednesday 17 June 2015 12:56:54 Knoll Lars wrote:
>[...]
>> * connect statements are hard with namespaces. Old style connects could
>> easily break if you forgot to fully q
On Thursday 18 Jun 2015 09:18:15 Giuseppe D'Angelo wrote:
> On Thu, Jun 18, 2015 at 9:08 AM, Simon Hausmann
>
> wrote:
> > Or would the idea be to place the Q_DECLARE_METATYPE outside of the
> > namespace?
> Why "the idea"? It's the way it's supposed to be used right now.
Indeed, and we've been
Simon Hausmann schreef op 18-6-2015 om 09:08:
>
>>> * metatype registration is problematic with namespaced types, as the macro
>>> extracts the name of the type through the preprocessor. People can very
>>> easily end up registering the type multiple times with different
>>> (qualified vs non quali
On Thu, Jun 18, 2015 at 9:08 AM, Simon Hausmann
wrote:
> Or would the idea be to place the Q_DECLARE_METATYPE outside of the namespace?
Why "the idea"? It's the way it's supposed to be used right now.
Cheers,
--
Giuseppe D'Angelo
___
Development maili
On Wednesday 17 June 2015 20:32:48 Stephen Kelly wrote:
> It seems that most people, but not everyone, in the discussion see the
> inconsistency and there are good reasons that it is not a good thing.
I *do* see the inconsistency. I'm just not convinced that it *matters*.
Paraphrasing Sharekspea
On Wednesday, June 17, 2015 03:36:11 PM Marc Mutz wrote:
> On Wednesday 17 June 2015 12:56:54 Knoll Lars wrote:
> [...]
>
> > * connect statements are hard with namespaces. Old style connects could
> > easily break if you forgot to fully qualify a parameter. New style
> > connects might end up wit
Knoll Lars wrote:
> * Generic and duplicated names from different namespaces can
> easily lead to confusion when reading code.
... and when searching about information about a class by unqualified name.
'QTransform' is now ambiguous to google. If the namespace route is used for
existing modules
On Wednesday 17 June 2015 14:54:03 Daniel Teske wrote:
> > Curiously, you didn't list any pro-namespace arguments.
>
> Actually:
> >> We couldn’t make things work in a source compatible way.
not a pro argument
> >> * connect statements are hard with namespaces.
not a pro argument
> >> * meta
> Curiously, you didn't list any pro-namespace arguments.
Actually:
>> We couldn’t make things work in a source compatible way.
>> * connect statements are hard with namespaces.
>> * metatype registration is problematic with namespaced types
>> * One of our coding guidelines is that you writ
> That side might be the vocal majority, too, tramping over the silent majority,
> since I note that QtC is full of namespaces.
>
> Roughly one per library after a quick grep.
>
> If name prefixing is The Way To Go, I wonder why QtC, as the biggest internal
> consumer, and second-biggest producer o
On Wednesday 17 June 2015 12:56:54 Knoll Lars wrote:
[...]
> * connect statements are hard with namespaces. Old style connects could
> easily break if you forgot to fully qualify a parameter. New style
> connects might end up with rather ugly looking syntax.
This is nothing new. We have that for n
On 16/06/15 23:19, "Stephen Kelly" wrote:
>Stephen Kelly wrote:
>
>>> I said I'm happy to discuss. I'm just waiting for some more opinions,
>>> please don't take that as me trying to shut the discussion down. :)
>>
>> Cool. Let's wait and see.
>
>This thread has gone way off-topic now, but we ga
Stephen Kelly wrote:
>> I said I'm happy to discuss. I'm just waiting for some more opinions,
>> please don't take that as me trying to shut the discussion down. :)
>
> Cool. Let's wait and see.
This thread has gone way off-topic now, but we gathered a week of opinions
and reasons, and I think
On Tuesday 16 June 2015 13:35:55 Thiago Macieira wrote:
> On Tuesday 16 June 2015 10:27:15 Matthew Woehlke wrote:
> > Ignoring whether or not to use 'auto', there actually *is* a reason to
> > use the static_cast... it communicates that, yes, you really want back
> > an 'int', even if that means a
On Tuesday 16 June 2015 10:27:15 Matthew Woehlke wrote:
> Ignoring whether or not to use 'auto', there actually *is* a reason to
> use the static_cast... it communicates that, yes, you really want back
> an 'int', even if that means a conversion loss e.g. because your input
> is a 'double'. (See e.
On 2015-06-16 09:33, André Somers wrote:
> Marc Mutz schreef op 16-6-2015 om 15:41:
>> For type conversions, you're supposed to use static_cast on the rhs:
>>
>> auto integer = static_cast(someLongLong);
>
> Sorry, but that just looks silly to me. Why obfusticate the type of the
> variable -
On 2015-06-15 04:18, Marc Mutz wrote:
> On Monday 15 June 2015 08:24:22 Simon Hausmann wrote:
>> A namespace for functions only, no public classes within.
>
> _That_ argument again... :)
>
> Could you explain to me why you think that classes are different from
> functions, pleaae?
With a small
On Tuesday 16 Jun 2015 15:33:00 André Somers wrote:
> Marc Mutz schreef op 16-6-2015 om 15:41:
> > On Tuesday 16 June 2015 11:39:56 Ulf Hermann wrote:
> >>> Note that in a world of auto variables, class names are no longer _that_
> >>> important. Functions are important, they are still visible. But
Marc Mutz schreef op 16-6-2015 om 15:41:
> On Tuesday 16 June 2015 11:39:56 Ulf Hermann wrote:
>>> Note that in a world of auto variables, class names are no longer _that_
>>> important. Functions are important, they are still visible. But other
>>> than at initial creation, class names fade to be
On Tuesday 16 June 2015 11:39:56 Ulf Hermann wrote:
> > Note that in a world of auto variables, class names are no longer _that_
> > important. Functions are important, they are still visible. But other
> > than at initial creation, class names fade to be background.
> >
> > And now you tell me ho
> Note that in a world of auto variables, class names are no longer _that_
> important. Functions are important, they are still visible. But other than at
> initial creation, class names fade to be background.
>
> And now you tell me how using lots of auto is bad for readability,
> because you neve
On Tuesday 16 June 2015 08:59:11 Knoll Lars wrote:
> >Marc Mutz schreef op 15-6-2015 om 22:26:
> >> On Monday 15 June 2015 21:01:54 André Pönitz wrote:
> >>> if so:
> >>> Please explain how that avoids name clashes.
> >>>
> >> You only need to add the prefix when the compiler tells you. E.g. i
On Friday, June 12, 2015 10:52:35 PM André Pönitz wrote:
> On Fri, Jun 12, 2015 at 12:58:42AM +0200, Marc Mutz wrote:
> > On Thursday 11 June 2015 23:15:20 André Pönitz wrote:
> > > That's exactly the kind of situation I was referring to in my previous
> > > mail: This is intentionally introducing
On 16/06/15 08:14, "André Somers" wrote:
>Marc Mutz schreef op 15-6-2015 om 22:26:
>> On Monday 15 June 2015 21:01:54 André Pönitz wrote:
>>> if so:
>>>
>>> Please explain how that avoids name clashes.
>> You only need to add the prefix when the compiler tells you. E.g. if
>>you use
>> QtGui
Marc Mutz schreef op 15-6-2015 om 22:26:
> On Monday 15 June 2015 21:01:54 André Pönitz wrote:
>> if so:
>>
>> Please explain how that avoids name clashes.
> You only need to add the prefix when the compiler tells you. E.g. if you use
> QtGui::QTransform in one file and Qt3D::QTransform in ano
On Monday 15 June 2015 21:01:54 André Pönitz wrote:
> if so:
>
> Please explain how that avoids name clashes.
You only need to add the prefix when the compiler tells you. E.g. if you use
QtGui::QTransform in one file and Qt3D::QTransform in another, in the same
project, you can write QTrans
There seem to be two claims floating around:
(a) namespaces help avoiding name clashs
-- and --
(b) namespaces are not more onerous than poor man's prefixes
I see that that both can be true.
I cannot see that both can be true *at the same time*.
Which one can be true depends on the recom
On Monday 15 June 2015 13:01:04 Sean Harmer wrote:
> * The existing syncqt.pl works
syncqt actually has support for namespaces so you could #include
but I think it's disabled since it has some bugs and nothing is using it. We
could re-enable it.
Note that the namespace should not be the same a
On 12/06/15 16:59,
"development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
Sean Harmer" wrote:
>Thanks for structuring this! Much appreciated.
>
>On Friday 12 June 2015 22:23:09 Sze Howe Koh wrote:
>> First, a big thanks to Stephen for bringing the
>> I propose the followi
On 15/06/2015 12:49, Knoll Lars wrote:
> On 15/06/15 12:27,
> "development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
> Simon Hausmann"
> simon.hausm...@theqtcompany.com> wrote:
>
>> On Monday, June 15, 2015 10:18:38 AM Marc Mutz wrote:
>> [...]
> QtConcurrent
A na
On 15/06/15 12:27,
"development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of
Simon Hausmann" wrote:
>On Monday, June 15, 2015 10:18:38 AM Marc Mutz wrote:
>[...]
>> > > QtConcurrent
>> >
>> > A namespace for functions only, no public classes within.
>> >
>> > > QTest
>> >
On Monday, June 15, 2015 10:18:38 AM Marc Mutz wrote:
[...]
> > > QtConcurrent
> >
> > A namespace for functions only, no public classes within.
> >
> > > QTest
> >
> > A namespace for functions only, no public classes within.
>
> _That_ argument again... :)
>
> Could you explain to me why you
On Monday 15 June 2015 08:24:22 Simon Hausmann wrote:
> > QtPatternist
>
> An internal namespace, not reflected in the public API.
QtPatternist::Item appears in public functions of exported public API class
QXmlNodeModelIndex, e.g. Yes, now I see the comment (git grep hid it).
> > QtConcurrent
>
On Thursday, June 11, 2015 11:49:23 AM Marc Mutz wrote:
> On Wednesday 10 June 2015 21:03:32 Stephen Kelly wrote:
> > I would encourage a discussion of why this module needs namespaces when
> > the rest of Qt gets by without them. There is certainly a consistency
> > angle.
>
> I think you come a
On Fri, Jun 12, 2015 at 12:58:42AM +0200, Marc Mutz wrote:
> On Thursday 11 June 2015 23:15:20 André Pönitz wrote:
> > That's exactly the kind of situation I was referring to in my previous
> > mail: This is intentionally introducing API inconsistency. It does not
> > really matter to me whether "p
Thanks for structuring this! Much appreciated.
On Friday 12 June 2015 22:23:09 Sze Howe Koh wrote:
> First, a big thanks to Stephen for bringing the
> I propose the following, with the hope that we formalise our decisions
> at http://wiki.qt.io/Coding_Conventions for future reference.
Agreed.
>
First, a big thanks to Stephen for bringing these issues to the ML's attention.
The topic of namespacing has been raised a few times before, but
discussions faded without us reaching any solid conclusions:
http://comments.gmane.org/gmane.comp.lib.qt.devel/13176
I think the disagreements we have o
Hi,
On Thursday 11 June 2015 23:15:20 André Pönitz wrote:
> Specifically, for item #6:
>
> [Stephen]
>
> > Qt3DParamter might be better *and* more consistent.
> > Similar applies to other classes.
>
> [Sean]
> It's precisely because of these kinds of issues that we decided t
On Thursday 11 June 2015 23:15:20 André Pönitz wrote:
> That's exactly the kind of situation I was referring to in my previous
> mail: This is intentionally introducing API inconsistency. It does not
> really matter to me whether "poor-man's prefix name spacing" is
> unfashionable or "we" consider
On Thu, Jun 11, 2015 at 06:46:54PM +0100, Sean Harmer wrote:
> On Thursday 11 June 2015 19:42:55 Stephen Kelly wrote:
> > Marc Mutz wrote:
> > > On Thursday 11 June 2015 13:09:39 Stephen Kelly wrote:
> > >> I didn't make any claim that "the use of a namespace for a Qt library is
> > >> new".
> > >>
Sean Harmer wrote:
>> I don't know. As far as I know deciding to use a namespace for this one
>> was done without discussion on the mailing list?
>
> There has been at least some discussion of namespaces in the past. For
> e.g.
>
> http://lists.qt-project.org/pipermail/development/2012-August/00
Sean Harmer wrote:
> On Thursday 11 June 2015 19:42:55 Stephen Kelly wrote:
>> Marc Mutz wrote:
>> > On Thursday 11 June 2015 13:09:39 Stephen Kelly wrote:
>> >> I didn't make any claim that "the use of a namespace for a Qt library
>> >> is new".
>> >>
>> >> Whatever you rebutted was not my claim
On Thursday 11 June 2015 19:42:55 Stephen Kelly wrote:
> Marc Mutz wrote:
> > On Thursday 11 June 2015 13:09:39 Stephen Kelly wrote:
> >> I didn't make any claim that "the use of a namespace for a Qt library is
> >> new".
> >>
> >> Whatever you rebutted was not my claim.
>
> So, you believe there
Marc Mutz wrote:
> On Thursday 11 June 2015 13:09:39 Stephen Kelly wrote:
>> I didn't make any claim that "the use of a namespace for a Qt library is
>> new".
>>
>> Whatever you rebutted was not my claim.
So, you believe there is no use in pursuing any of the questions I asked
here:
http://thr
On Thursday 11 June 2015 13:09:39 Stephen Kelly wrote:
> On Thu, Jun 11, 2015 at 12:29 PM, Marc Mutz wrote:
> > I was listing namespaces that are used in Qt already. That was to rebut
> > your claim that the use of a namespace for a Qt library is new.
>
> I didn't make any claim that "the use of
On Thu, Jun 11, 2015 at 12:29 PM, Marc Mutz wrote:
> I was listing namespaces that are used in Qt already. That was to rebut your
> claim that the use of a namespace for a Qt library is new.
I didn't make any claim that "the use of a namespace for a Qt library is new".
Whatever you rebutted was
Hi Steve,
On Wednesday 10 Jun 2015 21:03:32 Stephen Kelly wrote:
> >> 5) Qt3D namespace
> >>
> >> This is the first time that all classes in a library are in a namespace.
> >> Previously only enums (in various modules) and free functions (in
> >> QtConcurrent) have been put in namespaces.
> >>
On Thu, Jun 11, 2015 at 12:29:34PM +0200, Marc Mutz wrote:
> So even if we follow your reasoning, Qt3D is doing nothing that QtConcurrent
> and QtXmlPatterns, combined, haven't been doing for years. So the only new
> thing is that instead of separate libraries, it's now used in one.
>
the thing
On Thursday 11 June 2015 10:47:27 Stephen Kelly wrote:
> On Thu, Jun 11, 2015 at 11:49 AM, Marc Mutz wrote:
> > On Wednesday 10 June 2015 21:03:32 Stephen Kelly wrote:
> >> I would encourage a discussion of why this module needs namespaces when
> >> the rest of Qt gets by without them. There is c
On Wednesday 10 Jun 2015 21:09:15 Stephen Kelly wrote:
> Stephen Kelly wrote:
> > Sean Harmer wrote:
> >>> 1) The include/Qt3DCore/Window file doesn't have a Q prefix.
> >>>
> >>> as every other header does. Should probably be Qt3DWindow.
> >>
> >> Right, this actually needs removing and somethin
On Thu, Jun 11, 2015 at 11:49 AM, Marc Mutz wrote:
> On Wednesday 10 June 2015 21:03:32 Stephen Kelly wrote:
>> I would encourage a discussion of why this module needs namespaces when
>> the rest of Qt gets by without them. There is certainly a consistency
>> angle.
>
> I think you come a few yea
On Wednesday 10 June 2015 21:03:32 Stephen Kelly wrote:
> I would encourage a discussion of why this module needs namespaces when
> the rest of Qt gets by without them. There is certainly a consistency
> angle.
I think you come a few years late :)
QtPatternist
QtConcurrent
QTest
QV4
QtQml
QtDecl
On Wednesday 10 June 2015 21:09:15 Stephen Kelly wrote:
> Is installation of unprefixed headers a release blocker?
Yes. Because the buildsystem will add -I$QTINCDIR/Qt3D, so #include
will find it, possibly clobbering other includes with the name.
So this is a release blocker.
--
Thiago Maciei
Stephen Kelly wrote:
> Sean Harmer wrote:
>
>>> 1) The include/Qt3DCore/Window file doesn't have a Q prefix.
>>>
>>> as every other header does. Should probably be Qt3DWindow.
>>
>> Right, this actually needs removing and something temporary putting in
>> place in the examples for now.
>
>> I'
Stephen Kelly wrote:
> Sean Harmer wrote:
>
>>> 1) The include/Qt3DCore/Window file doesn't have a Q prefix.
>>>
>>> as every other header does. Should probably be Qt3DWindow.
>>
>> Right, this actually needs removing and something temporary putting in
>> place in the examples for now.
>
>> I'
Sean Harmer wrote:
>> 1) The include/Qt3DCore/Window file doesn't have a Q prefix.
>>
>> as every other header does. Should probably be Qt3DWindow.
>
> Right, this actually needs removing and something temporary putting in
> place in the examples for now.
> I'll try to tidy up and move the exi
On Tuesday 09 Jun 2015 13:09:50 Stephen Kelly wrote:
> On Tue, Jun 9, 2015 at 11:01 AM, Sean Harmer wrote:
> > On Monday 08 Jun 2015 14:18:33 Sean Harmer wrote:
> >> On Monday 08 Jun 2015 01:11:23 Stephen Kelly wrote:
> >> > 2) A private header is included in a public header:
> >> > include/Qt3DC
Hi,
If some of the fixes are critical to have in Qt 5.5.0, they should be targeted
to that branch. Please discuss with Jani Heikkinen, and add to release meta
task. All non-critical fixes to 5.5, of course.
Doc fixes should be safe to go into 5.5.0 branch - and in many ways these are
critical
On Tue, Jun 9, 2015 at 11:01 AM, Sean Harmer wrote:
> On Monday 08 Jun 2015 14:18:33 Sean Harmer wrote:
>>
>> On Monday 08 Jun 2015 01:11:23 Stephen Kelly wrote:
>> > 2) A private header is included in a public header:
>> > include/Qt3DCore$ grep private/ *.h
>> > qaspectjobmanager.h:#include
>
On Monday 08 Jun 2015 14:18:33 Sean Harmer wrote:
>
> On Monday 08 Jun 2015 01:11:23 Stephen Kelly wrote:
> > 2) A private header is included in a public header:
> > include/Qt3DCore$ grep private/ *.h
> > qaspectjobmanager.h:#include
> >
> > This is concerning - Don't we have a unit test prev
Hey Steve,
thanks for the feedback!
On Monday 08 Jun 2015 01:11:23 Stephen Kelly wrote:
> Hello,
>
> Congrats to Paul, Sean and others working on getting this module in a
> releasable state for Qt 5.5!
>
> I have not reviewed the code, but I found some items to raise:
>
> 1) The include/Qt3DCo
Hello,
Congrats to Paul, Sean and others working on getting this module in a
releasable state for Qt 5.5!
I have not reviewed the code, but I found some items to raise:
1) The include/Qt3DCore/Window file doesn't have a Q prefix.
as every other header does. Should probably be Qt3DWindow.
2)
79 matches
Mail list logo
