Re: [Development] Let's please drop MSVC 2013 for 5.10

[Thiago Macieira]

On Friday, 16 June 2017 16:35:54 PDT André Pönitz wrote:
> On Fri, Jun 16, 2017 at 12:52:24PM -0700, Thiago Macieira wrote:
> > Here's a tricky question: how do you create a QStringLiteral with
> > non-ASCII
> > characters that will work on all our supported compilers?
> 
> I don't have to, unless I have profiler supported evidence that
> it matters.

QStringLiteral is infinitely faster at runtime than QString::fromUtf8. It also 
occupies roughly 33% less memory than QString::fromUtf8 of a literal, as the 
latter needs the narrow character equivalent (read-only memory) plus the 
UTF-16 converted text (heap, which has overhead).

This is for a simple, static message. 

> In the common case where it does not matter, the string can be
> created at run time.

At a cost and overhead.

> QSTRINGLITERAL('M', 0xf6, 0xf6, 0xf6, 'p', '!')
> 
> instead of
> 
> QStringLiteral("Möööp!")

Yeah, no thanks.

The whole point is that we can do better. All we need to do is drop an old, 
buggy compiler.

-- 
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

Re: [Development] Let's please drop MSVC 2013 for 5.10

[André Pönitz]

On Fri, Jun 16, 2017 at 12:52:24PM -0700, Thiago Macieira wrote:
> Here's a tricky question: how do you create a QStringLiteral with non-ASCII 
> characters that will work on all our supported compilers?

I don't have to, unless I have profiler supported evidence that
it matters.

In the common case where it does not matter, the string can be
created at run time.

For the rare (vulgo: non-existent) case where that would matter
in Qt sources, something QStringLiteral-like along the lines of

#define QSTRINGLITERAL(...) \
[]() -> QString { \
const ushort X[] = { __VA_ARGS__ }; \
enum { Size = sizeof(X) / sizeof(X[0]) }; \
static const QStaticStringData qstring_literal = { \
{ Q_REFCOUNT_INITIALIZE_STATIC, Size, 0, 0, sizeof(QStringData) 
}, \
__VA_ARGS__ \
}; \
QStringDataPtr holder = { qstring_literal.data_ptr() }; \
const QString qstring_literal_temp(holder); \
return qstring_literal_temp; 
}()

and using 

QSTRINGLITERAL('M', 0xf6, 0xf6, 0xf6, 'p', '!')

instead of

QStringLiteral("Möööp!")

should be possible to use, too.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] "Getting started" tutorials (Was: Examples and Demos in qtdoc)

[Samuel Gaist]

> On 16 Jun 2017, at 16:17, Sze Howe Koh  wrote:
> 
> On 15 June 2017 at 01:29, Tuukka Turunen  wrote:
> > Hi,
> >
> > Yes, we would like to overall improve the examples. This is related to 
> > having a new repo for examples, but not fully the same thing. Main goal in 
> > example improvement being to make them more useful in what they are: 
> > examples of how to use Qt. Currently there are some examples that implement 
> > their own rudimentary controls instead of using Qt Quick Controls 2. We 
> > also have some examples that do not properly leverage our tooling. Some 
> > examples might not show the very best way to do things, as the new APIs 
> > allow even better way than at the time of creating the example.
> >
> > What comes to WOW, we do need to have great looking demos and at least some 
> > examples should look good as well. However, that WOW should not be the 
> > ultimate goal. The purpose of examples is to help users make better use of 
> > Qt and sometimes making things too shiny can be counterproductive. Another 
> > thing is that this WOW is a quite subjective matter and different trends 
> > come and go. It is fine to make an example look great, but that should not 
> > be the sole purpose.
> >
> > Yours,
> >
> > Tuukka
> 
> Understood.
> 
> On the topic of showing users "how to use Qt" and "leverage our tooling", I 
> feel that our "getting started" tutorials/examples need some love too.
> 
> IMHO, the "Getting Started" tutorial from Qt 4.3 
> (https://doc.qt.io/archives/4.3/tutorial-t1.html) is more accessible to 
> beginners than http://doc.qt.io/qt-5/gettingstartedqt.html mainly because the 
> Qt 4.3 tute presents material in digestible chunks. Readers are introduced to 
> the bare bones, and get to compile and interact with their code very early 
> on. Then, the tute gradually introduces more and more concepts across a 
> number of chapters; each chapter builds upon the previous. The reader gets to 
> build and try out the new concepts in each chapter, before moving on to the 
> next.
> 
> In contrast, the Qt 5 tutorial takes the reader through a multitude of 
> concepts (Qt Designer, the UIC file format, the *.pro file, subclassing 
> widgets, the Q_OBJECT macro, properties, signals and slots, layouts, and many 
> different classes) before the reader is taught how to compile and run their 
> first app. If the reader made a mistake somewhere along the way, it's hard to 
> find out where. There is far too much material packed into a single "getting 
> started" article.
> 
> I'm thinking of spending some time to update the Qt 4.3 tutorial (chapters 1 
> - 7) for Qt 5, presented in a few different ways to show how to do the same 
> thing using different Qt technologies:
> 
> 1. C++ only
> 2. C++ with Qt Designer
> 3. QML only
> 4. QML with Qt Quick Designer
> 
> Is this something you'd want in the official documentation?
> 
> 
> Regards,
> Sze-Howe
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

+100

We seem to, lately, have a lot of beginners on the forum that would benefit 
from such a nice set of tutorials.

Cheers,
Samuel



signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] CI problems

[Thiago Macieira]

On Thursday, 15 June 2017 23:44:08 PDT Tony Sarajärvi wrote:
> Hi
> 
> We're facing an unknown problem with contacting our RHEL 6.6 virtual
> machines. This stops all CI from progressing. We're investigating.

Pretty sure that either what caused this problem or the solution is the reason 
why tst_QUdpSocket::linkLocalIPv6 is now failing. The test wasn't failing 
until then.

-- 
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

Re: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail?

[Thiago Macieira]

On Friday, 16 June 2017 13:23:07 PDT Thiago Macieira wrote:
>  QDEBUG : tst_QUdpSocket::linkLocalIPv6(WithoutProxy)
> QHostAddress("fe80::250:56ff:feab:4818%eth1")
>  FAIL!  : tst_QUdpSocket::linkLocalIPv6(WithoutProxy)
> '(neutralReadSpy.count()
> > 0)' returned FALSE. ()
> 
> Loc: [../tst_qudpsocket.cpp(1600)]

Emergency workaround: https://codereview.qt-project.org/197753 
(compiles and works for me on bare metal, no test on a VM)

This commit basically disables the test entirely on virtual machines. If any 
QtNetwork developers use virtual machines, please make sure you get bare-metal 
hardware for all three platforms. You won't be doing your job if you continue 
with VMs.

-- 
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

Re: [Development] Let's please drop MSVC 2013 for 5.10

[Thiago Macieira]

On Friday, 16 June 2017 13:10:10 PDT Henry Skoglund wrote:
> That question reminds me of the discussion last August
> http://lists.qt-project.org/pipermail/interest/2016-August/023882.html
> about Unicode code points in MSVC and how to fix so that
> tr("Coördinaat") or tr("Co\u00F6rdinaat"); worked with old MSVC compilers.
> 
> My workaround: use raw UTF8 hex bytes: tr("Co\xC3\xB6rdinaat");
> 
> I think using that stunt should allow you to encode any non-ASCII
> characters inside a QStringLiteral with any compiler that supports "\x..."

You'd be wrong. That trick works for tr("Co\xC3\xB6rdinaat"); and the QString 
constructor.

It does NOT work for QStringLiteral.

So to answer my question:
Q:  How does one create a QStringLiteral containing non-ASCII characters 
that 
will work on all our supported compilers?
A:  You don't, unless you drop MSVC 2013 from that list in the first place.

-- 
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] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail?

[Thiago Macieira]

 QDEBUG : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) 
QHostAddress("fe80::250:56ff:feab:4818%eth1")
 FAIL!  : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) '(neutralReadSpy.count() 
> 0)' returned FALSE. ()
Loc: [../tst_qudpsocket.cpp(1600)]

This test was passing on Linux without a problem for years. Red Hat Enterprise 
Linux 6.6 isn't a new distribution, so I assume that the test was passing on 
it for some time. So can someone investigate what changed that is causing it 
to fail?

I'm also interested in two details about this:
 1) eth1 is listed, but not eth0. Is eth0 down?
 2) what kind of virtual network is eth1 connected to?

That test has two blacklists already, one for Windows and one for Darwin, 
because those systems have network interfaces that, despite being up and 
running, don't really work and don't loop back packets. I can't blacklist 
"eth1" on the test, that's too generic a name.

-- 
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

Re: [Development] Let's please drop MSVC 2013 for 5.10

[Henry Skoglund]

On 2017-06-16 21:52, Thiago Macieira wrote:

On Friday, 16 June 2017 11:14:20 PDT André Pönitz wrote:

On Thu, Jun 15, 2017 at 04:07:03PM -0700, Thiago Macieira wrote:

character set. Without the /utf-8 option added in MSVC 2015 Update 2, the
conversion fails and the compiler prints:

warning C4566: character represented by universal-character-name '\u0431'
cannot be represented in the current code page (1252)

[ok, not a C++11 issue per se, but we still want to use Unicode source
code]

There was never *consensus* on using something outside plain ASCII in
Qt sources.

This is predicted, self-inflicted pain.


Right, we've had to live with ASCII-only sources for the last 25 years. We
could wait a little longer.

I just don't want to!

Here's a tricky question: how do you create a QStringLiteral with non-ASCII
characters that will work on all our supported compilers?



That question reminds me of the discussion last August 
http://lists.qt-project.org/pipermail/interest/2016-August/023882.html 
about Unicode code points in MSVC and how to fix so that 
tr("Coördinaat") or tr("Co\u00F6rdinaat"); worked with old MSVC compilers.


My workaround: use raw UTF8 hex bytes: tr("Co\xC3\xB6rdinaat");

I think using that stunt should allow you to encode any non-ASCII 
characters inside a QStringLiteral with any compiler that supports "\x..."


Rgrds Henry

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Let's please drop MSVC 2013 for 5.10

[André Pönitz]

On Fri, Jun 16, 2017 at 07:18:25PM +, Shawn Rutledge wrote:
> 
> > On 16 Jun 2017, at 11:14, André Pönitz  wrote:
> > 
> > On Thu, Jun 15, 2017 at 04:07:03PM -0700, Thiago Macieira wrote:
> >> character set. Without the /utf-8 option added in MSVC 2015 Update 2, the 
> >> conversion fails and the compiler prints:
> >> 
> >> warning C4566: character represented by universal-character-name '\u0431' 
> >> cannot be represented in the current code page (1252)
> >> 
> >> [ok, not a C++11 issue per se, but we still want to use Unicode source 
> >> code]
> > 
> > There was never *consensus* on using something outside plain ASCII in
> > Qt sources.
> 
> The backslash, u, and the digits are all ASCII characters.
> This time we are not talking about utf-8 in source code.

The broad topic would be "insisting on ways to write code that
- while being formally correct - cause pain already in our own
processes, not to mention those of our users."

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Let's please drop MSVC 2013 for 5.10

[Thiago Macieira]

On Friday, 16 June 2017 11:14:20 PDT André Pönitz wrote:
> On Thu, Jun 15, 2017 at 04:07:03PM -0700, Thiago Macieira wrote:
> > character set. Without the /utf-8 option added in MSVC 2015 Update 2, the
> > conversion fails and the compiler prints:
> > 
> > warning C4566: character represented by universal-character-name '\u0431'
> > cannot be represented in the current code page (1252)
> > 
> > [ok, not a C++11 issue per se, but we still want to use Unicode source
> > code]
> There was never *consensus* on using something outside plain ASCII in
> Qt sources.
> 
> This is predicted, self-inflicted pain.

Right, we've had to live with ASCII-only sources for the last 25 years. We 
could wait a little longer.

I just don't want to!

Here's a tricky question: how do you create a QStringLiteral with non-ASCII 
characters that will work on all our supported compilers?

-- 
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

Re: [Development] Let's please drop MSVC 2013 for 5.10

[Shawn Rutledge]

> On 16 Jun 2017, at 11:14, André Pönitz  wrote:
> 
> On Thu, Jun 15, 2017 at 04:07:03PM -0700, Thiago Macieira wrote:
>> character set. Without the /utf-8 option added in MSVC 2015 Update 2, the 
>> conversion fails and the compiler prints:
>> 
>> warning C4566: character represented by universal-character-name '\u0431' 
>> cannot be represented in the current code page (1252)
>> 
>> [ok, not a C++11 issue per se, but we still want to use Unicode source code]
> 
> There was never *consensus* on using something outside plain ASCII in
> Qt sources.

The backslash, u, and the digits are all ASCII characters.  This time we are 
not talking about utf-8 in source code.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Let's please drop MSVC 2013 for 5.10

[André Pönitz]

On Thu, Jun 15, 2017 at 04:07:03PM -0700, Thiago Macieira wrote:
> character set. Without the /utf-8 option added in MSVC 2015 Update 2, the 
> conversion fails and the compiler prints:
> 
> warning C4566: character represented by universal-character-name '\u0431' 
> cannot be represented in the current code page (1252)
> 
> [ok, not a C++11 issue per se, but we still want to use Unicode source code]

There was never *consensus* on using something outside plain ASCII in
Qt sources.

This is predicted, self-inflicted pain.

> But I repeat: these problems are going to turn up again and again.

Of course. But the problem is not compilers.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Let's please drop MSVC 2013 for 5.10

[Lars Knoll]

> On 16 Jun 2017, at 18:11, Thiago Macieira  wrote:
> 
> On Thursday, 15 June 2017 16:07:03 PDT Thiago Macieira wrote:
>> We have not one, not two, but THREE integration failures TODAY alone caused
>> by that compiler failing to meet what we've come to expect from C++11. This
>> is going to happen again and again.
> 
> Fourth reason, just over 24 hours since the first:
> 
> https://codereview.qt-project.org/197638 requires a constexpr constructor to 
> avoid introducing a load-time initialisation. Guess which compiler doesn't 
> support the feature?
> 
> I'm going to give Allan +2 even if it causes detrimental side effects for 
> MSVC 
> 2013. Sorry, I can't seem to care anymore for old compilers.

I don't mind at all if the code generated is less optimal on 2013. That's what 
you get by using older compilers.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtScript (deprecated) vs QJSEngine and reasons why QJSEngine isn't up to scratch

[Konstantin Tokarev]

16.06.2017, 19:45, "NAVSYSTEMS LTD" :
> NB I also use WebKit and am looking at the QWebEngine replacement but thats a 
> whole other story and is similar and also rather unpleasant.

http://lists.qt-project.org/pipermail/development/2017-May/029795.html

Sorry, I don't have anything to comment on QtScript


> Of course deprecation has to happen sometimes but premature deprecation and 
> removal of features tend to force people to stick with the earlier working 
> version s. So the question I would like to ask is are there any plans to 
> extend the QJSEngine framework to add debugger support or should I assume I'm 
> going to be stuck forever?
>
> NavSystems (IOM) Ltd. +44 (0)1624 851253
> Mobile:   +44 (0)7624 330943
> Use Skype to call me or send files.
> Registered in the Isle of Man No: 122393C  VAT: GB 003 1736 25
> Registered office: Kissack Court, Parliament Street, Ramsey, Isle of Man, IM8 
> 1AT
> Consider the Environment. Do you really need to print this e-mail?
> Information in this e-mail may be confidential and is intended only for the 
> recipients to which it is addressed.
> Please notify the sender if you receive this e-mail by mistake.
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtScript (deprecated) vs QJSEngine and reasons why QJSEngine isn't up to scratch

[NAVSYSTEMS LTD]

I have been using QtScript for many years (along with many other qt modules). 
Porting from QtScript to QJSEngine is clearly not trivial especially when I 
have multiple QScriptEngine uses in many processes but thats specific to my use 
not general. One very nice feature in QtScript is the debugger. In fact the 
debugger can even be split out into a separate process e.g a remote debugger 
(using QScriptDebuggerFrontend/Backend and a developer built of QScriptTools) 
and I'm sure others use this feature too. The debugger isn't simply a nice 
feature as without a debugger the amount of time needed to develop and debug 
scripts becomes so great its probably a non-starter. So looking at QJSEngine 
the first major obstacle to porting is the utter lack of any debugger support. 
This means for me at least QJSEngine is still not up to the job. I use scripts 
in several different applications (suites of applications actually), for us, 
they are not used for UI interaction but for behind the scenes custom data 
processing and realtime control. Our applications expose hundreds of QObject 
based classes and other data types to script land. Use of signals and slots and 
exposing signals to javascript is commonplace. For one application that is 
installed on unattended computers in remote locations the ability to connect a 
remote script debugger is an absolutely essential feature. So to keep this post 
short and to the point I won't ramble on anymore but will simply state that the 
first and probably most important deficiency, as I see it, is simply the lack 
of debugger support in QJSEngine. I am certain that there are others. There 
have been some posts earlier relating to QJSEngine vs QtScript performance but 
I cannot comment as I have not tried to port anything other than a simple test 
application and I have not benchmarked it either. I strongly suspect that the 
lack of debugger will make adoption of QJSEngine far less likely for many 
existing QtScript users other than those who's use cases are very trivial. NB I 
also use WebKit and am looking at the QWebEngine replacement but thats a whole 
other story and is similar and also rather unpleasant. Of course deprecation 
has to happen sometimes but premature deprecation and removal of features tend 
to force people to stick with the earlier working version s. So the question I 
would like to ask is are there any plans to extend the QJSEngine framework to 
add debugger support or should I assume I'm going to be stuck forever?

NavSystems (IOM) Ltd. +44 (0)1624 851253

Mobile:   +44 (0)7624 330943
Use Skype to call me 
or send files.
Registered in the Isle of Man No: 122393C  VAT: GB 003 1736 25
Registered office: Kissack Court, Parliament Street, Ramsey, Isle of Man, IM8 
1AT
Consider the Environment. Do you really need to print this e-mail?
Information in this e-mail may be confidential and is intended only for the 
recipients to which it is addressed.
Please notify the sender if you receive this e-mail by mistake.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] "Getting started" tutorials (Was: Examples and Demos in qtdoc)

[Mandeep Sandhu]

>
> On the topic of showing users "how to use Qt" and "leverage our tooling",
> I feel that our "getting started" tutorials/examples need some love too.
>
> IMHO, the "Getting Started" tutorial from Qt 4.3 (
> https://doc.qt.io/archives/4.3/tutorial-t1.html) is more accessible to
> beginners than http://doc.qt.io/qt-5/gettingstartedqt.html mainly because
> the Qt 4.3 tute presents material in digestible chunks. Readers are
> introduced to the bare bones, and get to compile and interact with their
> code very early on. Then, the tute gradually introduces more and more
> concepts across a number of chapters; each chapter builds upon the
> previous. The reader gets to build and try out the new concepts in each
> chapter, before moving on to the next.
>
> In contrast, the Qt 5 tutorial takes the reader through a multitude of
> concepts (Qt Designer, the UIC file format, the *.pro file, subclassing
> widgets, the Q_OBJECT macro, properties, signals and slots, layouts, and
> many different classes) before the reader is taught how to compile and run
> their first app. If the reader made a mistake somewhere along the way, it's
> hard to find out where. There is far too much material packed into a single
> "getting started" article.
>
> I'm thinking of spending some time to update the Qt 4.3 tutorial (chapters
> 1 - 7) for Qt 5, presented in a few different ways to show how to do the
> same thing using different Qt technologies:
>
> 1. C++ only
> 2. C++ with Qt Designer
> 3. QML only
> 4. QML with Qt Quick Designer
>
> Is this something you'd want in the official documentation?
>

+1 for this approach.

I had a quick look at the Qt5 tut & it was a bit overwhelming for a
beginner IMO. I think separating out the core C++ parts from the UI part
would be beneficial for newbies. Making easily digestable examples each of
these topics will go a long way in helping more ppl get on board.

My 2¢.

-mandeep


>
>
> Regards,
> Sze-Howe
>
> ___
> 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] Development Digest, Vol 69, Issue 22 - Getting Started Tutorials

[Steve Schilz]

Sze-Howe Wrote:
> On the topic of showing users "how to use Qt" and "leverage our tooling", I 
> feel that our "getting started" tutorials/examples need some love too.
> 
> IMHO, the "Getting Started" tutorial from Qt 4.3 (
> https://doc.qt.io/archives/4.3/tutorial-t1.html) is more accessible to 
> beginners than http://doc.qt.io/qt-5/gettingstartedqt.html mainly because the 
> Qt 4.3 tute
> presents material in digestible chunks. Readers are introduced to the bare 
> bones, and get to compile and interact with their code very early on. Then, 
> the tute
> gradually introduces more and more concepts across a number of chapters; each 
> chapter builds upon the previous. The reader gets to build and try out the 
> new 
> concepts in each chapter, before moving on to the next.
>
> In contrast, the Qt 5 tutorial takes the reader through a multitude of 
> concepts (Qt Designer, the UIC file format, the *.pro file, subclassing 
> widgets, the Q_OBJECT
> macro, properties, signals and slots, layouts, and many different classes) 
> before the reader is taught how to compile and run their first app. If the 
> reader made a
> mistake somewhere along the way, it's hard to find out where. There is far 
> too much material packed into a single "getting started" article.
>
> I'm thinking of spending some time to update the Qt 4.3 tutorial (chapters
> 1 - 7) for Qt 5, presented in a few different ways to show how to do the same 
> thing using different Qt technologies:
>
>
> 1. C++ only
> 2. C++ with Qt Designer
> 3. QML only
> 4. QML with Qt Quick Designer
>
> Is this something you'd want in the official documentation?
>
>
>Regards,
>Sze-Howe

Well, when I got my current job 7 years ago they asked me about Qt, and I went 
through the Cannon Field tutorial: 
https://doc.qt.io/archives/qtextended4.4/tutorials-tutorial.html,  It was a fun 
progression from hello world through a very rudimentary game. I was able to 
talk about what I learned in the second Interview and I got the job.  

I have been very successful in learning other languages with that sort of 
chapter-based incremental tutorial. 
They take a little while to get through, but at the end of it, you have a firm 
grasp of the fundamentals.

+1

Steve Schilz
PASCO scientific
think science

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Let's please drop MSVC 2013 for 5.10

[Thiago Macieira]

On Thursday, 15 June 2017 16:07:03 PDT Thiago Macieira wrote:
> We have not one, not two, but THREE integration failures TODAY alone caused
> by that compiler failing to meet what we've come to expect from C++11. This
> is going to happen again and again.

Fourth reason, just over 24 hours since the first:

https://codereview.qt-project.org/197638 requires a constexpr constructor to 
avoid introducing a load-time initialisation. Guess which compiler doesn't 
support the feature?

I'm going to give Allan +2 even if it causes detrimental side effects for MSVC 
2013. Sorry, I can't seem to care anymore for old compilers.

-- 
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

Re: [Development] Let's please drop MSVC 2013 for 5.10

[Thiago Macieira]

On Thursday, 15 June 2017 23:57:28 PDT Santtu Ahonen wrote:
> We also have paying customers whom may be using MSVC2013 and whom are not on
> this list, thus we need to look at this from business side too. Not ready
> yet to give my vote for dropping it but will get back to this in due time.

This is the development mailing list, we don't expect the users to be here. 
That's why you're here and your opinion counts.

-- 
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] "Getting started" tutorials (Was: Examples and Demos in qtdoc)

[Sze Howe Koh]

On 15 June 2017 at 01:29, Tuukka Turunen  wrote:
> Hi,
>
> Yes, we would like to overall improve the examples. This is related to
having a new repo for examples, but not fully the same thing. Main goal in
example improvement being to make them more useful in what they are:
examples of how to use Qt. Currently there are some examples that implement
their own rudimentary controls instead of using Qt Quick Controls 2. We
also have some examples that do not properly leverage our tooling. Some
examples might not show the very best way to do things, as the new APIs
allow even better way than at the time of creating the example.
>
> What comes to WOW, we do need to have great looking demos and at least
some examples should look good as well. However, that WOW should not be the
ultimate goal. The purpose of examples is to help users make better use of
Qt and sometimes making things too shiny can be counterproductive. Another
thing is that this WOW is a quite subjective matter and different trends
come and go. It is fine to make an example look great, but that should not
be the sole purpose.
>
> Yours,
>
> Tuukka

Understood.

On the topic of showing users "how to use Qt" and "leverage our tooling", I
feel that our "getting started" tutorials/examples need some love too.

IMHO, the "Getting Started" tutorial from Qt 4.3 (
https://doc.qt.io/archives/4.3/tutorial-t1.html) is more accessible to
beginners than http://doc.qt.io/qt-5/gettingstartedqt.html mainly because
the Qt 4.3 tute presents material in digestible chunks. Readers are
introduced to the bare bones, and get to compile and interact with their
code very early on. Then, the tute gradually introduces more and more
concepts across a number of chapters; each chapter builds upon the
previous. The reader gets to build and try out the new concepts in each
chapter, before moving on to the next.

In contrast, the Qt 5 tutorial takes the reader through a multitude of
concepts (Qt Designer, the UIC file format, the *.pro file, subclassing
widgets, the Q_OBJECT macro, properties, signals and slots, layouts, and
many different classes) before the reader is taught how to compile and run
their first app. If the reader made a mistake somewhere along the way, it's
hard to find out where. There is far too much material packed into a single
"getting started" article.

I'm thinking of spending some time to update the Qt 4.3 tutorial (chapters
1 - 7) for Qt 5, presented in a few different ways to show how to do the
same thing using different Qt technologies:

1. C++ only
2. C++ with Qt Designer
3. QML only
4. QML with Qt Quick Designer

Is this something you'd want in the official documentation?


Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] CI problems

[Tony Sarajärvi]

Hi

All seem to be working again. We also had some problems with servers not seeing 
LUNs for some reason, and we fixed those as well.

-T

From: Development 
[mailto:development-bounces+tony.sarajarvi=qt...@qt-project.org] On Behalf Of 
Tony Sarajärvi
Sent: perjantai 16. kesäkuuta 2017 9.44
To: development@qt-project.org
Subject: [Development] CI problems

Hi

We're facing an unknown problem with contacting our RHEL 6.6 virtual machines. 
This stops all CI from progressing. We're investigating.

-Tony
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Examples and Demos in qtdoc

[Lars Knoll]

On 15 Jun 2017, at 15:23, Mitch Curtis 
mailto:mitch.cur...@qt.io>> wrote:

-Original Message-
From: Development 
[mailto:development-bounces+mitch.curtis=qt.io@qt-
project.org] On Behalf Of Joerg Bornemann
Sent: Thursday, 15 June 2017 9:54 AM
To: Pasi Keränen mailto:pasi.kera...@qt.io>>; 
development@qt-project.org
Subject: Re: [Development] Examples and Demos in qtdoc

On 14/06/2017 14:59, Pasi Keränen wrote:

I’m not 100% sure about qtdoc as the repo though. But I can live with it if
that is what is seen as best option by others.

There are two kinds of examples:
  1. Simple examples demonstrating the use of a certain technique.
 Those usually come with detailed source code documentation.
  2. Complex examples demonstrating much of the bling that's possible.
 Those are not source-documented, because writing the docs would be
 too laborious, and who would want to read them anyway.

I believe that examples of category 1 should live in the qdoc repository / in
their respective module repository. Examples of category 2 deserve a
separate space.

The "bigger examples" from Frederik's original mail are category 2. In
Qt4 those were called "demos". There could be a "qtdemos" repo with git-
lfs.

In qtwebengine there's this question bobbing up every once in a while what
to do with the demobrowser example. As an example, it actually needs
source documentation. But it's too big. There are voices that want to remove
it. Instead it could live on in such a qtdemos repo.

+1

That sounds like a good idea.

So documented examples in qtdoc, larger demos (that can also contain lots of 
image data) in a separate qtdemos repo.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Let's please drop MSVC 2013 for 5.10

[Sean Harmer]

On Friday 16 June 2017 06:57:28 Santtu Ahonen wrote:
> >From: Shawn Rutledge
> >
> >> On 15 Jun 2017, at 16:07, Thiago Macieira 
> >> wrote:
> >> 
> >> We have not one, not two, but THREE integration failures TODAY alone
> >> caused by that compiler failing to meet what we've come to expect from
> >> C++11. This is going to happen again and again.
> >> 
> >> So I'm pleading again: can we drop it? What are the download numbers
> >> for 5.9.0?
> >
> >+1 from me
> 
> Hi all
> 
> We also have paying customers whom may be using MSVC2013 and whom are not on
> this list, thus we need to look at this from business side too. Not ready
> yet to give my vote for dropping it but will get back to this in due time.

They have 5.9 as an LTS now. I'm with Thiago here, and would love us to drop 
MSVC2013. The pain/benefit ratio is not good.

Cheers,

Sean

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Dropping older compilers for Qt 5.10 (was: Qt 5.10 pre-built bunaries)

[Cristian Adam]

On Fri, Jun 9, 2017 at 10:46 PM, Ville Voutilainen <
ville.voutilai...@gmail.com> wrote:

>
> So, what's your take on gcc versions? You seemed hesitant to drop
> support for QNX 6
> here: http://lists.qt-project.org/pipermail/development/2017-
> June/030113.html
> Are you suggesting we drop support for the MSVC versions you mentioned,
> but keep
> GCC 4.7 support?
>
>
Rumor has it that QNX is offering GCC 4.9 for QNX 6.6 to certain customers
for quite a while now

.

Could you guys ask QNX about this? GCC 4.9 should have more C++11 support
than GCC 4.7

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development