Re: [Development] Supported platforms for Qt 5.8

2016-02-22 Thread Thiago Macieira 
On terça-feira, 23 de fevereiro de 2016 05:32:55 PST Turunen Tuukka wrote:
> > Is Qt 5.7 going to be the *only* release to support WEC2013?
> 
> No. Both Qt 5.6 and Qt 5.7 will support WEC13.

Quoting you on your yesterday's email:

"With Qt 5.6.0 the WEC13 is still experimental"

So 5.6 doesn't count. That leaves just one release, which is way too short.

> > I want that answer to be "no". Let's support it for at least a year.
> 
> Me too. I want to support it 3 years with the Qt 5.6 LTS - and after that
> offer extended support to customers needing it.
> 
> But let's re-check if VS2013 is actually now supported as a compiler or not.
> Maybe we can remove VS2012 but still support WEC13 with Qt 5.8 - however
> this may require some more though that just the compiler support. It seems
> very clear that Microsoft is aggressively pushing towards Windows 10 IoT,
> so I think that would be the right thing to focus on in the future of
> embedded Windows.

While I wish that Windows 10 Core gain market share quickly compared to the 
older Embedded Compact versions, it's unlikely to happen.

In fact, even VS 2012's market share is today too high to be dropped. It would 
be nice to confirm whether that's the case for us by checking the download 
counts for each version in the last 3 months and over the 5.6 release.

-- 
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] Supported platforms for Qt 5.8

2016-02-22 Thread Turunen Tuukka 


> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=theqtcompany@qt-project.org] On Behalf Of
> Thiago Macieira
> Sent: maanantaina 22. helmikuuta 2016 19.32
> To: development@qt-project.org
> Subject: Re: [Development] Supported platforms for Qt 5.8
> 
> On segunda-feira, 22 de fevereiro de 2016 18:16:47 PST Turunen Tuukka
> wrote:
> > Hi,
> >
> > For both WEC7 and WEC13 Qt 5.6 should be a very good release to use,
> > while for WEC13 also Qt 5.7 is an option. However as Qt 5.6 is a LTS
> > release supporting both WEC7 and WEC13, it is a very good baseline.
> > With Qt 5.6.0 the WEC13 is still experimental, but target is to have
> > it supported equally well as WEC7 is within Qt 5.6.x patch level releases.
> 
> So, to echo what Gunnar is saying:
> 
> Is Qt 5.7 going to be the *only* release to support WEC2013?
> 

No. Both Qt 5.6 and Qt 5.7 will support WEC13.

> I want that answer to be "no". Let's support it for at least a year.
> --

Me too. I want to support it 3 years with the Qt 5.6 LTS - and after that offer 
extended support to customers needing it.

But let's re-check if VS2013 is actually now supported as a compiler or not. 
Maybe we can remove VS2012 but still support WEC13 with Qt 5.8 - however this 
may require some more though that just the compiler support. It seems very 
clear that Microsoft is aggressively pushing towards Windows 10 IoT, so I think 
that would be the right thing to focus on in the future of embedded Windows. 

Yours,

Tuukka

> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QJSEngine replacement for QScriptEngine misses newFunction

2016-02-22 Thread Walter Stefan 
Hi,

I am looking into migrating my code to QJSEngine, because of the deprecation of 
the QScriptEngine (QtScript). As we have used the functionality of newFunction 
very extensive and all related scripts are depending on this, the newFunction 
in QJSEngine is for us mandatory or something that creates and equivalent 
result.

How do I currently map a native C++ class member function to the engine:
QScriptValue func_sqrt = m_engine->newFunction(sqrt, liEngine);
m_engine->globalObject().setProperty("sqrt", func_sqrt, QScriptValue::ReadOnly 
| QScriptValue::Undeletable);

This is an example of a native function:
QScriptValue ScriptModuleMath::sqrt(QScriptContext *context, QScriptEngine 
*engine, void *arg)
{
Q_UNUSED(engine)
Q_UNUSED(arg)
if (context->argumentCount()!=1)
{
return context->throwError( QScriptContext::SyntaxError, "sqrt(...): 
illegal number of arguments.");
} else if (!context->argument(0).isNumber())
{
return context->throwError( QScriptContext::SyntaxError, "sqrt(...): 
argument 1 is not a number.");
}

return qSqrt(context->argument(0).toNumber());
}

And in this way. I can use it then in the script:
value = sqrt(4);

I actually don't want to map a whole QObject, because that would require a call 
like this:
value = MyMath.sqrt(4);

Is there any way to achive in QJSEngine the same result as I do within the 
QScriptEngine?

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

[Development] QtQuick mouse event handling

2016-02-22 Thread Filippo Cucchetto 
Hi all,
i want to talk about the mouse event handling in QtQuick. From my
experience mouse event
handling is rather unflexible. The current implementation is
straightforward:
the events are propagated  from the top mousearea until accepted.
This is fine however consider the common scenario of an item delegate for a
row in a view (be it a TableView or TreeView)
that needs to listen for mouse events:
1) The user put a MouseArea inside the item delegate
1.a) if the user is only interested in the press event the solution is
simple: handle the onPress event in the MouseArea
  and simply propagate the event by setting "mouse.accepted = false"
1.b) if the user need to listen for the click event he can't reject the
press event. This in turn break the view selection handling
  and maybe more. AFAIK there's no way to temporary store the mouse
events and later propagate them beneath. The user
  has to reimplement most of the event handling in the item delegate
(like handling selection/multi selection).
2) Rely on the view signals. Some view exposes some mouse signals like
clicked and doubleClicked etc.
Most of the implementations in QtQuickControls are not sufficient. For
example they lack of the button pressed or mouse
positions. Furthermore most of the view signals are for composed events
(clicked) and so there're no press and release events. One
could argue that most of the implementations expose the view mouseArea
(__mouseArea) so a user can connect to it
through a Connection object. This is a partial solution because the
press[release] event is sent after the view handled it and
again the user act after the view already handled it (so there's no way
to swallow it).
Another downside of option (2) is that most of the times the user need
to do some actions on the item delegate. So from the view
onClicked we must obtain the itemDelegate. This imply one these
solutions:
1) the existance of a itemAt(index) or itemAt(row) function (AFAIK
there isn't right now)
2) Each item delegate connect to the clicked signal of the view
To me both solutions are ugly. First they have an overhead: connections
costs in the delegate item construction and also finding
an item could be expensive. Keep in mind that solution (1.b) is simpler
since we handle the event directly in the delegate.

What do you think about it? Do you have a solution for this kind of
problems?

1) One possible solution could be exposing the views event handlers like
callable functions (
onPressed, onRelease etc.) In this way with solution (1.b) we can both
accept the mouse event and also propagate it to the view.
i.e. MouseArea { onPressed: { mouse.accepted; view.onPressed(...) } }
2) Other frameworks like WPF has the notion of "handledEventsToo" where
basically you let propagate an event even if it has been handled
3) Another solution could to remove the need of accepting the press event
for having the notification for the click event. Most of the times the
user just need to know that an item delegate has been clicked without
swallowing it. But for receiving the click event he must swallow (accept)
the press event.

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

Re: [Development] Supported platforms for Qt 5.8

2016-02-22 Thread Thiago Macieira 
On segunda-feira, 22 de fevereiro de 2016 21:08:12 PST Knoll Lars wrote:
> I can see the reasoning here, just as well as I see the reasoning of the
> people that would like to get rid of VS2012 as quickly as possible.

Why do we need to get rid of it? What are the problems with it, aside from 
lack of certain C++11 support?

-- 
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] Making ItemSelectionModel more useful

2016-02-22 Thread deDietrich Gabriel 
On Feb 20, 2016, at 4:19 AM, Alberto Mardegan  
wrote:
> 
> Hi all!
>  Since Qt 5.5, the QItemSelectionModel class is exposed to QML as
> ItemSelectionModel (in the QtQml.Models module):
> 
> http://doc.qt.io/qt-5/qml-qtqml-models-itemselectionmodel.html
> 
> Apart from having almost no documentation, this component seems to be
> rather hard to use in QML: its methods work with QModelIndex (while all
> the models I've ever used in QML just speak row numbers) or
> QItemSelection, which I believe is not usable in QML at all (at least,
> it's not documented as a QML component).
> 
> I understand that the reason for all of this is that QItemSelectionModel
> is a class originally created for C++ consumption, and that the
> QModelIndex makes a lot of sense there. However, I would argue that the
> QML version is hardly usable.
> 
> As I see it, either this class gets a "model" property and methods which
> operate on integers (row numbers), or QModelIndex and QItemSelection
> need to become first class citizens in QML as well. I guess that having
> Q_GADGET is already a huge step forward, but we should also have a
> generic way to turn a model+rowNumber into a QModelIndex: maybe a global
> method Qt.makeIndex(model, row), which would also work on all models
> supported by the QML engine?

QModelIndex is a rather simple class that’s closely tied to QAbstractItemModel. 
On the Qt Quick side, when you assign a model to a ListView, for example, Qt 
Quick will wrap it into an internal class. That class can work with both QAIM 
or a JS array (and others) and deals with the view in an opaque (to the view) 
way. In the latter case, there's no QAIM at all, so there's no way we can make 
a QModelIndex out of it. Whether that would be a wise thing to do internally is 
debatable.

The story behind having QModelIndex and QItemSelectionModel exposed to the QML 
engine was to solve the selection problem in the Qt Quick Controls 1 TreeView. 
TableView could use a simple selection model because of the trivial mapping 
between table row and model index. That’s not possible for the TreeView, so we 
decided to reuse what was already available in the QtWidgets side. Note that 
QAbstractItemModel::index() and several more functions have been made 
invokable. So those are available in QML provided your model is QAIM-based.

Best regards,

Dr. Gabriel de Dietrich
Senior Software Developer
The Qt Company — www.qt.io

> Are there any plans about this, or what would be the best way to address
> this?
> 
> Ciao,
>  Alberto
> 
> ___
> 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] Supported platforms for Qt 5.8

2016-02-22 Thread Knoll Lars 

On 22/02/16 19:32, "Development on behalf of Thiago Macieira" 
 wrote:

>On segunda-feira, 22 de fevereiro de 2016 18:16:47 PST Turunen Tuukka wrote:
>> Hi,
>> 
>> For both WEC7 and WEC13 Qt 5.6 should be a very good release to use, while
>> for WEC13 also Qt 5.7 is an option. However as Qt 5.6 is a LTS release
>> supporting both WEC7 and WEC13, it is a very good baseline. With Qt 5.6.0
>> the WEC13 is still experimental, but target is to have it supported equally
>> well as WEC7 is within Qt 5.6.x patch level releases.
>
>So, to echo what Gunnar is saying:
>
>Is Qt 5.7 going to be the *only* release to support WEC2013?
>
>I want that answer to be "no". Let's support it for at least a year.

I can see the reasoning here, just as well as I see the reasoning of the people 
that would like to get rid of VS2012 as quickly as possible.

Before we continue this, could someone check the claim made in 
https://msdn.microsoft.com/en-us/library/gg154234.aspx ? That article has been 
published after we last discussed the topic.

Thanks,
Lars

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

Re: [Development] Supported platforms for Qt 5.8

2016-02-22 Thread Thiago Macieira 
On segunda-feira, 22 de fevereiro de 2016 18:16:47 PST Turunen Tuukka wrote:
> Hi,
> 
> For both WEC7 and WEC13 Qt 5.6 should be a very good release to use, while
> for WEC13 also Qt 5.7 is an option. However as Qt 5.6 is a LTS release
> supporting both WEC7 and WEC13, it is a very good baseline. With Qt 5.6.0
> the WEC13 is still experimental, but target is to have it supported equally
> well as WEC7 is within Qt 5.6.x patch level releases.

So, to echo what Gunnar is saying:

Is Qt 5.7 going to be the *only* release to support WEC2013?

I want that answer to be "no". Let's support it for at least a year.
-- 
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] Supported platforms for Qt 5.8

2016-02-22 Thread Turunen Tuukka 

Hi,

For both WEC7 and WEC13 Qt 5.6 should be a very good release to use, while for 
WEC13 also Qt 5.7 is an option. However as Qt 5.6 is a LTS release supporting 
both WEC7 and WEC13, it is a very good baseline. With Qt 5.6.0 the WEC13 is 
still experimental, but target is to have it supported equally well as WEC7 is 
within Qt 5.6.x patch level releases.

Yours,

 Tuukka

From: Development 
[mailto:development-bounces+tuukka.turunen=theqtcompany@qt-project.org] On 
Behalf Of Gunnar Roth
Sent: maanantaina 22. helmikuuta 2016 18.51
To: Andrew Knight 
Cc: development@qt-project.org
Subject: Re: [Development] Supported platforms for Qt 5.8

This is a deja vu to me, somehow.
please have a look at this discussion 
https://www.mail-archive.com/search?l=development@qt-project.org&q=subject:%22Re%5C%3A+%5C%5BDevelopment%5C%5D+QtCS%5C%3A+Long+Term+Release+discussion%22&o=newest&f=1

To quote myself:
"

 Hi Björn, i had the assumption you could mean that, but thats not a

 knowledge base article. I think you mean Compact 2013 uses the Microsoft

 Visual Studio 2013 compiler,? That part was also sent to me by a colleage

 from another department when discussing v8 usage( as this has vs2013

 depedancy according to wiki).  So we startet a MS Request to clear this

 issue. The answer was that the arcticle is wrong here."

MS promised to fix that article but maybe they need some more years for that.

By the way I am strongly against droping wec2013 support after just one other 
version, actually support for wec2013
has not yet arrived yet. So this is probaly unique for a platform supported by 
qt , where the deprecation announcement comes before the release of the actual 
platform support.

There is also a some importat stuff missing for wec2013 in qt 5.6 beta like no 
quick2 controls support, no webkit/engine support  and no multimedia support, 
no neon intrinsics support, no openssl support, no sse2 support.

Regards,
Gunnar Roth

Gesendet: Montag, 22. Februar 2016 um 17:01 Uhr
Von: "Andrew Knight" 
mailto:andrew.kni...@intopalo.com>>
An: development@qt-project.org
Betreff: Re: [Development] Supported platforms for Qt 5.8
On 02/22/2016 05:54 PM, Thiago Macieira wrote:
> On segunda-feira, 22 de fevereiro de 2016 14:59:52 PST Roger Briggen wrote:
>> WEC2013 is also supported by Visual Studio 2013 and Visual Studio 2015
>> (according to https://msdn.microsoft.com/en-us/library/gg154234.aspx)
>> because it uses now the ARM Desktop Compiler.
>> So dropping VS2012 must not be the end of WEC2013 support of Qt.
> Hi Roger
>
> That is IDE support using the compiler from VS2012. When we say we drop
> support for a compiler, we don't mean the IDE that you're using.
>

That link clearly states that the MSVC2013 compiler is now used with
WEC2013 Update 5 and 11, as is the latest C runtime. So, this indeed
looks like a compiler and C runtime upgrade, not simply the new IDE
targeting the old compiler.

Maybe someone with a WEC2013 installation can check this out in practice?

Andrew
___
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] Supported platforms for Qt 5.8

2016-02-22 Thread Gunnar Roth 
This is a deja vu to me, somehow.

please have a look at this discussion https://www.mail-archive.com/search?l=development@qt-project.org&q=subject:%22Re%5C%3A+%5C%5BDevelopment%5C%5D+QtCS%5C%3A+Long+Term+Release+discussion%22&o=newest&f=1

 

To quote myself:

"
 Hi Björn, i had the assumption you could mean that, but thats not a
 knowledge base article. I think you mean Compact 2013 uses the Microsoft
 Visual Studio 2013 compiler,? That part was also sent to me by a colleage
 from another department when discussing v8 usage( as this has vs2013
 depedancy according to wiki).  So we startet a MS Request to clear this
 issue. The answer was that the arcticle is wrong here."

 

MS promised to fix that article but maybe they need some more years for that.



 

By the way I am strongly against droping wec2013 support after just one other version, actually support for wec2013

has not yet arrived yet. So this is probaly unique for a platform supported by qt , where the deprecation announcement comes before the release of the actual platform support.

 

There is also a some importat stuff missing for wec2013 in qt 5.6 beta like no quick2 controls support, no webkit/engine support  and no multimedia support, no neon intrinsics support, no openssl support, no sse2 support.

 

Regards,

Gunnar Roth

 

Gesendet: Montag, 22. Februar 2016 um 17:01 Uhr


Von: "Andrew Knight" 
An: development@qt-project.org
Betreff: Re: [Development] Supported platforms for Qt 5.8

On 02/22/2016 05:54 PM, Thiago Macieira wrote:
> On segunda-feira, 22 de fevereiro de 2016 14:59:52 PST Roger Briggen wrote:
>> WEC2013 is also supported by Visual Studio 2013 and Visual Studio 2015
>> (according to https://msdn.microsoft.com/en-us/library/gg154234.aspx)
>> because it uses now the ARM Desktop Compiler.
>> So dropping VS2012 must not be the end of WEC2013 support of Qt.
> Hi Roger
>
> That is IDE support using the compiler from VS2012. When we say we drop
> support for a compiler, we don't mean the IDE that you're using.
>

That link clearly states that the MSVC2013 compiler is now used with
WEC2013 Update 5 and 11, as is the latest C runtime. So, this indeed
looks like a compiler and C runtime upgrade, not simply the new IDE
targeting the old compiler.

Maybe someone with a WEC2013 installation can check this out in practice?

Andrew
___
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] Supported platforms for Qt 5.8

2016-02-22 Thread Andrew Knight 

On 02/22/2016 05:54 PM, Thiago Macieira wrote:

On segunda-feira, 22 de fevereiro de 2016 14:59:52 PST Roger Briggen wrote:

WEC2013 is also supported by Visual Studio 2013 and Visual Studio 2015
(according to https://msdn.microsoft.com/en-us/library/gg154234.aspx)
because it uses now the ARM Desktop Compiler.
So dropping VS2012 must not be the end of WEC2013 support of Qt.

Hi Roger

That is IDE support using the compiler from VS2012. When we say we drop
support for a compiler, we don't mean the IDE that you're using.



That link clearly states that the MSVC2013 compiler is now used with 
WEC2013 Update 5 and 11, as is the latest C runtime. So, this indeed 
looks like a compiler and C runtime upgrade, not simply the new IDE 
targeting the old compiler.


Maybe someone with a WEC2013 installation can check this out in practice?

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

Re: [Development] GCC-built Qt 5.6 can't be used with Clang

2016-02-22 Thread Thiago Macieira 
On segunda-feira, 22 de fevereiro de 2016 11:05:24 PST Welbourne Edward wrote:
> I'm sure there's a specific command for asking git whether a given
> branch contains a given commit: but I can't remember it.
> Still, git log dev..3726c4673 reveals that it is indeed not yet in dev.

That is actually the correct command to do what you asked.

Using git branch --contains is more expensive, as it will check whether all 
branches, not just dev, contain it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Supported platforms for Qt 5.8

2016-02-22 Thread Thiago Macieira 
On segunda-feira, 22 de fevereiro de 2016 14:59:52 PST Roger Briggen wrote:
> WEC2013 is also supported by Visual Studio 2013 and Visual Studio 2015
> (according to https://msdn.microsoft.com/en-us/library/gg154234.aspx)
> because it uses now the ARM Desktop Compiler.
> So dropping VS2012 must not be the end of WEC2013 support of Qt.

Hi Roger

That is IDE support using the compiler from VS2012. When we say we drop 
support for a compiler, we don't mean the IDE that you're using.

-- 
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] Supported platforms for Qt 5.8

2016-02-22 Thread Roger Briggen 
Knoll Lars  theqtcompany.com> writes:

> 
> Hi,
> 
> Now that 5.7 is branched, I'd like to propose that we update our list of
supported compilers and platforms
> for Qt 5.8. After some discussions with different people, here's an
initial proposal from my side:
> 
> * We drop support for VS2012. This implicitly drops support for WEC2013.
Reason is that the compiler is
> still having rather large problems with it's C++11 support. I hope that we
could serve the WEC market
> rather well with 5.6 and 5.7 for the years to come. In the end, the
benefit we get with dropping the compiler
> will hopefully outweigh the cost (loosing WEC) by a good margin.
> 


Hi Lars,

WEC2013 is also supported by Visual Studio 2013 and Visual Studio 2015
(according to https://msdn.microsoft.com/en-us/library/gg154234.aspx)
because it uses now the ARM Desktop Compiler.
So dropping VS2012 must not be the end of WEC2013 support of Qt.

Regards,
Roger


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

Re: [Development] GCC-built Qt 5.6 can't be used with Clang

2016-02-22 Thread Koehne Kai 


> -Original Message-
> From: Development [mailto:development-
> bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of
> Welbourne Edward
> Sent: Monday, February 22, 2016 12:05 PM
> To: Stephen Kelly ; development@qt-project.org
> Subject: Re: [Development] GCC-built Qt 5.6 can't be used with Clang
> 
> > Simon Hausmann wrote:
> >> Hmm, change ‎https://codereview.qt-project.org/#/c/147846/ was
> >> supposed to fix this issue.
> >>
> >> ‎The subject of the email refers to 5.6 but in the body you say that
> >> you are building the dev branch. If it is the latter, could it be
> >> that the fix hasn't hit dev yet?
> 
> Stephen Kelly replied
> > Indeed, I built without that patch. Perhaps it is indeed fixed in 5.6
> > already (but I didn't check). Reading the commit message and the
> > commit I don't have the expertise to know.
> 
> It was commit 3726c46735edb23ad37af818ff7d52d661ec87e7.
> I'm sure there's a specific command for asking git whether a given branch
> contains a given commit: but I can't remember it.

git branch -r --contains SHA

Shows all remote branches containing a specific SHA

The same works for tags

git tag --contains SHA

Commit 3726c46735edb23ad37af818ff7d52d661ec87e7 is only in 5.6.0 so far.

Regards

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

Re: [Development] GCC-built Qt 5.6 can't be used with Clang

2016-02-22 Thread Welbourne Edward 
> Simon Hausmann wrote:
>> Hmm, change ‎https://codereview.qt-project.org/#/c/147846/ was
>> supposed to fix this issue.
>>
>> ‎The subject of the email refers to 5.6 but in the body you say that
>> you are building the dev branch. If it is the latter, could it be
>> that the fix hasn't hit dev yet?

Stephen Kelly replied
> Indeed, I built without that patch. Perhaps it is indeed fixed in 5.6
> already (but I didn't check). Reading the commit message and the
> commit I don't have the expertise to know.

It was commit 3726c46735edb23ad37af818ff7d52d661ec87e7.
I'm sure there's a specific command for asking git whether a given
branch contains a given commit: but I can't remember it.
Still, git log dev..3726c4673 reveals that it is indeed not yet in dev.
(Or, at least, wasn't this morning when my nightly cron job pulled into
my local bare repos.)

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

Re: [Development] Scalable UIs in QtQuick (take 2)

2016-02-22 Thread Sorvig Morten 

> On 19 Feb 2016, at 10:44, Gunnar Sletta  wrote:
> 
> Now every piece of code needs to also know about device pixel ratio and that 
> needs to passed down to image loaders, icon generators


This is essential complexity, not accidental complexity. With
high-DPI displays in use raster images now vary across two
dimensions: amount of content and amount of detail.

Consider a map tile provider: starting with a 50x50 base tile
there are two ways to render a 100x100 tile: More map content
or finer content detail.

The inputs to the image provider is either (logical pixels, scale)
or (actual pixels, scale). In both cases you have to carry the
scale factor.

The only way out is to reject the extra dimensionality (as I did
initially with the QML image providers), but I think Qt will be 
better off if we support it. 

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

Re: [Development] Supported platforms for Qt 5.8

2016-02-22 Thread Turunen Tuukka 


> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=theqtcompany@qt-project.org] On Behalf Of
> Thiago Macieira
> Sent: sunnuntaina 21. helmikuuta 2016 23.51
> To: development@qt-project.org
> Subject: Re: [Development] Supported platforms for Qt 5.8
> 
> On sexta-feira, 19 de fevereiro de 2016 21:01:02 PST Knoll Lars wrote:
> > Now that 5.7 is branched, I'd like to propose that we update our list
> > of supported compilers and platforms for Qt 5.8. After some
> > discussions with different people, here's an initial proposal from my side:
> 
> Let me just say that I don't think changing the requirements one release
> after such a big bump is a good idea. Maybe postpone the update to Qt 5.9?
> 

It is of course a matter of viewpoint, but I think similarly as Lars that it is 
better to do the required changes now for Qt 5.8 and then aim to avoid bigger 
changes for Qt 5.9 to the extent feasible.

There will be quite many new things developed for Qt 5.8 and keeping support 
for some older compilers and platforms we aim to then drop immediately after 
would be just an extra burden for the development. With Qt 5.6 and to some 
extent also with Qt 5.7 we have a wide set of older compilers supported, which 
makes it a great choice for those who can not move to the newer ones yet.

Yours,

Tuukka

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

Re: [Development] Supported platforms for Qt 5.8

2016-02-22 Thread Bogdan Vatra 
Hi,
On Friday 19 February 2016 21:01:02 Knoll Lars wrote:
> Hi,
> 
> Now that 5.7 is branched, I'd like to propose that we update our list of
> supported compilers and platforms for Qt 5.8. After some discussions with
> different people, here's an initial proposal from my side:
> 
[...]
> 
> * Minimum version for Android is probably going to stay with 4.1 (as with
> 5.7). We would like to add a 64 bit build to the CI
> 
[...]

I was hoping that (at least) 5.7 will add Android 64 bit. Is the any problem 
to add 64 bit support to 5.7 (or 5.6.1)?

Cheers,
BogDan.

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

Re: [Development] Supported platforms for Qt 5.8

2016-02-22 Thread Thiago Macieira 
On segunda-feira, 22 de fevereiro de 2016 07:59:55 PST Ziller Eike wrote:
> > It would buy us, if we raised to GCC 4.8 too:
> > - deleted and defaulted members
> 
> Hm, deleted and defaulted members should work fine with gcc 4.7(.3) as well.

Right, I think I cut/pasted the wrong entry. We'd need GCC 4.8 for inheriting 
constructors.

-- 
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] Supported platforms for Qt 5.8

2016-02-22 Thread Ziller Eike 

> On Feb 20, 2016, at 7:04 PM, Thiago Macieira  
> wrote:
> 
> On sexta-feira, 19 de fevereiro de 2016 21:01:02 PST Knoll Lars wrote:
>> * We drop support for VS2012. This implicitly drops support for WEC2013.
>> Reason is that the compiler is still having rather large problems with it's
>> C++11 support. I hope that we could serve the WEC market rather well with
>> 5.6 and 5.7 for the years to come. In the end, the benefit we get with
>> dropping the compiler will hopefully outweigh the cost (loosing WEC) by a
>> good margin.
> 
> This buys us:
> 
> - delegating constructors
> - "explicit operator" member funcvtions
> - nsdmi
> - initializer_list (not uniform initialisation!)
> - raw strings
> - template alias (using ... = ...)
> - variadic templates
> 
> It would buy us, if we raised to GCC 4.8 too:
> - deleted and defaulted members

Hm, deleted and defaulted members should work fine with gcc 4.7(.3) as well.
Please note that MSVC2013 fails to recognize move constructors and move 
assignment operators as special member functions, so you cannot default or 
delete them.
There is also an issue with perfect forwarding in MSVC2013 (it copies anyway).

>  (nsdmi, delegating constructors, template aliases require GCC 4.7)
> 
> Is it worth it? The only things I'd really want are intialiser lists and 
> variadic templates. Note that without constexpr, initialiser lists' value is 
> limited.
> 
> (I'm assuming Clang minimum version 3.4, as found on FreeBSD, which is 
> feature-complete for C++11)
> 
> -- 
> 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

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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