Re: [Development] qtfeedback and qtdocgallery: status?

[Hausmann Simon]

I'm not sure what you'd like me to answer at this point. I think that it is 
possible to fix the
build of these modules, the CI system is in place for that. However it requires 
a fair bit of
work (ask Robin about qtmessagingframework ;-).

However fixing the modules appears to me to be orthogonal to the question about 
whether
they should be mentioned in .gitmodules or not. It is my opinion that them 
being listed in
the file does not cause any harm because they have the status "ignore", which 
excludes them
from init-repository, the CI system and consequently the release of Qt.

Simon


From: Development 
<development-bounces+simon.hausmann=theqtcompany@qt-project.org> on behalf 
of Marc Mutz <marc.m...@kdab.com>
Sent: Tuesday, March 22, 2016 10:38
To: development@qt-project.org
Subject: Re: [Development] qtfeedback and qtdocgallery: status?

On Tuesday 22 March 2016 09:58:48 Hausmann Simon wrote:
> As the modules are not part of any release of Qt and unmaintained, I don't
> think they need fixing.

C'mon — FTBFS without the possibility to submit a fix?

--
Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] qtfeedback and qtdocgallery: status?

[Hausmann Simon]

As the modules are not part of any release of Qt and unmaintained, I don't 
think they need fixing.

Simon


From: m...@kdab.com <m...@kdab.com> on behalf of Marc Mutz <marc.m...@kdab.com>
Sent: Tuesday, March 22, 2016 9:37
To: Hausmann Simon
Cc: development@qt-project.org
Subject: Re: [Development] qtfeedback and qtdocgallery: status?

On Tuesday 22 March 2016 09:19:26 Hausmann Simon wrote:
> Hi,
>
> I see no reason for dropping them from qt5.git as long as they are in
> status = ignore
> (http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules?h=5.6.0 ). What harm
> does it cause?

You mean other than failing integrations? None.

Specifically, I'l like to enable -Wzero-as-null-pointer-constant in headercheck
and those are the only modules that have not integrated the respective fixes.

What about the other option, then? Fixing them? I have no idea how to fix them
so that both 5.6 and 5.7 are happy, and they don't follow the Qt branching, it
seems.

Thanks,
Marc

--
Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] http://testresults.qt.io/ci/status/ stale?

[Hausmann Simon]

Not implemented feature. That site is a mirror of the internal system and we do 
not mirror running integrations currently.


Simon

  Original Message
From: Marc Mutz
Sent: Tuesday, March 22, 2016 08:50
To: development@qt-project.org
Subject: Re: [Development] http://testresults.qt.io/ci/status/ stale?


On Tuesday 22 March 2016 07:32:45 Liang Qi wrote:
> The status of new CI: http://testresults.qt.io/coin/

About that: it always shows "no integrations running", while clearly there are
active integrations according to Gerrit. Bug or feature?

Thanks,
Marc

--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] Qt Coding Guidelines

[Hausmann Simon]

I agree with Rich.

This isn't documentation our users are facing. We don't need to extract from 
cpp files or use a particular style sheet.

+1 for Kai's initiative.

Simon

From: Richard Moore
Sent: Wednesday, March 16, 2016 22:55
To: Knoll Lars
Cc: development@qt-project.org
Subject: Re: [Development] Qt Coding Guidelines




On 16 March 2016 at 21:43, Knoll Lars 
> wrote:
Good initiative. I think this is the right idea. Let's put the coding 
guidelines into .qdoc files after having a decision on the ML.

We should actually consider having a section about contributing to Qt in our 
documentation. Coding guidelines would fit nicely into that. But I think the 
.qdoc files should rather live in qtdoc instead of qtbase as most of the 
overview documentation is there.

?Personally I think markdown as Kai's used is better since we can link to that 
in git and have it rendered sensibly.

Rich.?

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

Re: [Development] QtQuick Call for Maintainer

[Hausmann Simon]

+alot :)


Simon


From: Development 
 on behalf 
of Eskil Abrahamsen Blomfeldt 
Sent: Thursday, March 10, 2016 10:43
To: development@qt-project.org
Subject: Re: [Development] QtQuick Call for Maintainer

Den 09.03.2016 10:56, skrev Frederik Gladhorn:
> We are in the luxury position of having two great candidates.
> I briefly talked to both Robin and Shawn yesterday and one option would be to
> have a shared maintainership. This seems to have worked nicely for Qt
> Networking and dividing the responsibilty will lessen the burden.

+1 for shared maintainership.

-- Eskil

___
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] QNX broken on 5.7

[Hausmann Simon]

No worries :). The fact that you didn't see a proper configure error message 
suggests that the follow up patch to verify the qnx installation didn't make it 
or is buggy. Hmm.


Simon

  Original Message
From: Rafael Roquetto
Sent: Tuesday, March 8, 2016 19:48
To: Hausmann Simon
Cc: development@qt-project.org
Subject: Re: [Development] QNX broken on 5.7


Hi Simon,

You are right, I completely forgot about that thread. Thanks for the feedback.

Cheers,
Rafael

On Tue, Mar 08, 2016 at 06:31:15PM +, Hausmann Simon wrote:
> Hi,
>
> When building Qt 5.7 for QNX a special patch is applied in the CI that fixes 
> the Dinkumware headers. You were CCed when this was discussed (Subject was 
> "‎QNX and Dinkumware support for constexpr and nullptr").
>
> Simon
>
>   Original Message
> From: Rafael Roquetto
> Sent: Tuesday, March 8, 2016 18:39
> To: development@qt-project.org
> Subject: [Development] QNX broken on 5.7
>
>
> Hello everyone,
>
> I would like to point out that QNX is unable to build the 5.7 branch. The
> commit that probably triggered the breakage is:
>
> d6bb01e1779f1840dfbab57c6ecd615587bbde62
> Force inclusion of  on QNX systems.
>
>
> This raises my first question: should this not have been reported by the CI?
> This is not the first time that changes go in and break QNX, in spite of
> having the CI in place. Would anyone have a clue about what is going on?
>
>
> Now, concerning the issue itself, it seems to be a bigger problem:
>
> /usr/include/cpp/xxatomic: In instantiation of 
> 'std::atomic<_Ty*>::atomic(_Ty*) [with _Ty = void(QtMsgType, const char*)]':
> /usr/include/cpp/xxatomic:336:3: error: invalid conversion from 'void 
> (*)(QtMsgType, const char*)' to 'void*' [-fpermissive]
> /usr/include/cpp/xxatomic:873:15: error:   initializing argument 1 of 
> 'void* std::_Atomic_address::operator=(void*)' [-fpermissive]
>
>
> Caused by the following line inside qlogging.cpp:
>
> static QBasicAtomicPointer msgHandler = 
> Q_BASIC_ATOMIC_INITIALIZER(qDefaultMsgHandler);
>
> The problem can be traced to the Dinkumware's std::atomic implementation.
> Ultimately, qDefaultMsgHandler will be passed as an argument to std::atomic's
> default ctor, which looks like this:
>
> _CONST_FUN atomic(_Ty *_Right) _NOEXCEPT
> {   // construct from _Right
> _Atomic_address::operator=(_Right);
> }
>
>
> _Atomic_address is a base class. As you can see, this ctor is implemented
> using operator=, which looks like this:
>
>
> inline _ITYPE _ATOMIC_ITYPE::operator=(_ITYPE _Value) _NOEXCEPT
> {   // assign _Value to *this
> atomic_store(this, _Value);
> return _Value;
> }
> `
>
> where _TYPE expands to (void *), thus effectively causing the conversion from
> void (*)(QtMsgType, const char*) to (void *), which is the error.
>
> Interestingly, Dinkumware's std::atomic does provide operator= in terms of
> _Ty:
>
>
> _Ty *operator=(_Ty *_Right) _NOEXCEPT
> {   // assign from _Right
> return static_cast<_Ty *>(_Atomic_address::operator=((void *)_Right));
> }
>
>
> which makes me think that the ctor is wrongly implemented, since it bypasses
> this and calls the base class operator= explicitly.
>
>
> I am not sure how to work around this. QBasicAtomicPointer won't let me
> initialize it with some ugly (void *) pointer.
>
> Does it make sense to revert this patch? Is there a way to fall back to the
> old non-C++11 implementation?
>
> Thanks,
> Rafael
>
> --
> Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts

--
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QNX broken on 5.7

[Hausmann Simon]

Hi,

When building Qt 5.7 for QNX a special patch is applied in the CI that fixes 
the Dinkumware headers. You were CCed when this was discussed (Subject was 
"‎QNX and Dinkumware support for constexpr and nullptr").

Simon

  Original Message
From: Rafael Roquetto
Sent: Tuesday, March 8, 2016 18:39
To: development@qt-project.org
Subject: [Development] QNX broken on 5.7


Hello everyone,

I would like to point out that QNX is unable to build the 5.7 branch. The
commit that probably triggered the breakage is:

d6bb01e1779f1840dfbab57c6ecd615587bbde62
Force inclusion of  on QNX systems.


This raises my first question: should this not have been reported by the CI?
This is not the first time that changes go in and break QNX, in spite of
having the CI in place. Would anyone have a clue about what is going on?


Now, concerning the issue itself, it seems to be a bigger problem:

/usr/include/cpp/xxatomic: In instantiation of 
'std::atomic<_Ty*>::atomic(_Ty*) [with _Ty = void(QtMsgType, const char*)]':
/usr/include/cpp/xxatomic:336:3: error: invalid conversion from 'void 
(*)(QtMsgType, const char*)' to 'void*' [-fpermissive]
/usr/include/cpp/xxatomic:873:15: error:   initializing argument 1 of 
'void* std::_Atomic_address::operator=(void*)' [-fpermissive]


Caused by the following line inside qlogging.cpp:

static QBasicAtomicPointer msgHandler = 
Q_BASIC_ATOMIC_INITIALIZER(qDefaultMsgHandler);

The problem can be traced to the Dinkumware's std::atomic implementation.
Ultimately, qDefaultMsgHandler will be passed as an argument to std::atomic's
default ctor, which looks like this:

_CONST_FUN atomic(_Ty *_Right) _NOEXCEPT
{   // construct from _Right
_Atomic_address::operator=(_Right);
}


_Atomic_address is a base class. As you can see, this ctor is implemented
using operator=, which looks like this:


inline _ITYPE _ATOMIC_ITYPE::operator=(_ITYPE _Value) _NOEXCEPT
{   // assign _Value to *this
atomic_store(this, _Value);
return _Value;
}
`

where _TYPE expands to (void *), thus effectively causing the conversion from
void (*)(QtMsgType, const char*) to (void *), which is the error.

Interestingly, Dinkumware's std::atomic does provide operator= in terms of
_Ty:


_Ty *operator=(_Ty *_Right) _NOEXCEPT
{   // assign from _Right
return static_cast<_Ty *>(_Atomic_address::operator=((void *)_Right));
}


which makes me think that the ctor is wrongly implemented, since it bypasses
this and calls the base class operator= explicitly.


I am not sure how to work around this. QBasicAtomicPointer won't let me
initialize it with some ugly (void *) pointer.

Does it make sense to revert this patch? Is there a way to fall back to the
old non-C++11 implementation?

Thanks,
Rafael

--
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] change log creation tool (was: Re: Qt 5.6.0 missing change files)

[Hausmann Simon]

Hi,

I think that perhaps there is a misunderstanding - the perl script didn't do 
any of these things for me.

Running this in declarative gives me:

~/dev/qtsdk/packaging-tools/create_changelog.pl $PWD 5.5.1..HEAD
push on reference is experimental at 
/home/simon/dev/qtsdk/packaging-tools/create_changelog.pl line 107.
keys on reference is experimental at 
/home/simon/dev/qtsdk/packaging-tools/create_changelog.pl line 151.

Same in other modules. What am I missing?


Simon


From: Development 
<development-bounces+simon.hausmann=theqtcompany@qt-project.org> on behalf 
of Thiago Macieira <thiago.macie...@intel.com>
Sent: Saturday, February 27, 2016 0:58
To: development@qt-project.org
Subject: Re: [Development] change log creation tool (was: Re: Qt 5.6.0  missing 
change files)

On sexta-feira, 26 de fevereiro de 2016 19:06:06 PST Hausmann Simon wrote:
> Hi,
>
> It is different in three aspects:
>
> 1. It does not require passing git revision ranges as command line
> parameters.

So you have a heuristic algorithm that tries to guess the target version and
which version was the last. You could have added this to the Perl script.

> 2. It works on a per module basis instead of from the qt5 supermodule.

So does the Perl script.

> 3. It includes the task number from the commit message.

So does the Perl script.

So we gained the ability to run without being explicit which revisions we
want, but now we need to install a compiler we didn't use before and compile
code?

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

Re: [Development] change log creation tool (was: Re: Qt 5.6.0 missing change files)

[Hausmann Simon]

Hi,

It is different in three aspects:

1. It does not require passing git revision ranges as command line parameters.

2. It works on a per module basis instead of from the qt5 supermodule.

3. It includes the task number from the commit message.


Simon

  Original Message
From: Thiago Macieira
Sent: Friday, February 26, 2016 17:59
To: development@qt-project.org
Subject: Re: [Development] change log creation tool (was: Re: Qt 5.6.0  missing 
change files)


How is this different from the tool that already exists?

On sexta-feira, 26 de fevereiro de 2016 12:34:45 PST Hausmann Simon wrote:
> Hi,
>
>
> To simplify the creation of the change files I have written a small tool
> that facilitates this job. It's written in golang and you get install it by
> simply running
>
>
> go get code.qt.io/qt/qtqa.git/src/createchangelog
>
>
> The binary will be placed in $GOPATH/bin. (If you are not familiar with go,
> then you can also "cheat" and just set GOPATH=$PWD just to get this tool)
>
> Afterwards you can go into the git directory of the module you'd like to
> create the change log, make sure you have the correct branch checked out
> and simply run the program. It will read .qmake.conf to figure out the
> version of the upcoming Qt release and it will use the output of "git tag
> -l" to determine the previous release the change log should be made
> against. Afterwards it will go through the changes between those the
> previous release and HEAD and print "preliminary" ChangeLog file to
> standard output. You can redirect the output and then do the usual manual
> editing.
>
>
> Simon
>
> 
> From: Releasing
> <releasing-bounces+simon.hausmann=theqtcompany@qt-project.org> on
> behalf of Heikkinen Jani <jani.heikki...@theqtcompany.com> Sent: Friday,
> February 19, 2016 11:42
> To: development@qt-project.org
> Cc: releas...@qt-project.org
> Subject: [Releasing] Qt 5.6.0 missing change files
>
>
> Hi all,
>
>
> We are planning to release Qt 5.6.0 RC really soon, hoping at the beginning
> of next week. Final is targeted to be released within 2 weeks as well so we
> need to get all change files done & in before it. Following change files
> are still missing:
>
>
> qtandroidextras
>
> qtbase (ongoing, see https://codereview.qt-project.org/#/c/149325/ )
>
> [https://codereview.qt-project.org/static/logo_qt.png]<https://codereview.qt
> -project.org/#/c/149325/>
>
> Qt - Gerrit Code Review<https://codereview.qt-project.org/#/c/149325/>
> codereview.qt-project.org
> Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project;
> Planet Qt; Qt Repository Browser
>
>
>
> qtdeclarative
>
> qtdoc
>
> (qtenginio)
>
> qtmacextras
>
> qtmultimedia
>
> qtquickcontrols
>
> (qtscript)
>
> qtsensors
>
> qtsvg
>
> qttranslations
>
> qttools
>
> qtwayland
>
> qtwaylandqtwebchannel
>
> qtwebsockets
>
> qtx11extras
>
> qtxmlpatterns
>
>
> Maintainers, make sure needed change files are done & in before wed 24th Feb
>
>
> br,
>
> Jani


--
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] change log creation tool (was: Re: Qt 5.6.0 missing change files)

[Hausmann Simon]

Hi,


To simplify the creation of the change files I have written a small tool that 
facilitates this job. It's written in golang and you get install it by simply 
running


go get code.qt.io/qt/qtqa.git/src/createchangelog


The binary will be placed in $GOPATH/bin. (If you are not familiar with go, 
then you can also "cheat" and just set GOPATH=$PWD just to get this tool)

Afterwards you can go into the git directory of the module you'd like to create 
the change log, make sure you have the correct branch checked out
and simply run the program. It will read .qmake.conf to figure out the version 
of the upcoming Qt release and it will use the output of "git tag -l" to
determine the previous release the change log should be made against. 
Afterwards it will go through the changes between those the previous release
and HEAD and print "preliminary" ChangeLog file to standard output. You can 
redirect the output and then do the usual manual editing.


Simon


From: Releasing 
 on behalf of 
Heikkinen Jani 
Sent: Friday, February 19, 2016 11:42
To: development@qt-project.org
Cc: releas...@qt-project.org
Subject: [Releasing] Qt 5.6.0 missing change files


Hi all,


We are planning to release Qt 5.6.0 RC really soon, hoping at the beginning of 
next week. Final is targeted to be released within 2 weeks as well so we need 
to get all change files done & in before it. Following change files are still 
missing:


qtandroidextras

qtbase (ongoing, see https://codereview.qt-project.org/#/c/149325/ )

[https://codereview.qt-project.org/static/logo_qt.png]

Qt - Gerrit Code Review
codereview.qt-project.org
Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet 
Qt; Qt Repository Browser



qtdeclarative

qtdoc

(qtenginio)

qtmacextras

qtmultimedia

qtquickcontrols

(qtscript)

qtsensors

qtsvg

qttranslations

qttools

qtwayland

qtwaylandqtwebchannel

qtwebsockets

qtx11extras

qtxmlpatterns


Maintainers, make sure needed change files are done & in before wed 24th Feb


br,

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

[Hausmann Simon]

Hi,

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?

Simon

  Original Message
From: Stephen Kelly
Sent: Saturday, February 20, 2016 11:33
To: development@qt-project.org
Subject: [Development] GCC-built Qt 5.6 can't be used with Clang


Hello,

I built Qt dev branch with GCC.

Then I tried to use it to build any trivial shared library with Clang:

stephen@hal:/tmp/qmake$ make CXX=clang++ LINK=clang++ -B
makeobj[0]: Entering directory `/tmp/qmake'
/home/stephen/dev/prefix/qtbase/bin/qmake -o Makefile qmake.pro
clang++ -c -pipe -g -std=gnu++11 -std=c++11 -Wall -W -D_REENTRANT -fPIC -
DQT_CORE_LIB -I. -I/home/stephen/dev/prefix/qtbase/include -
I/home/stephen/dev/prefix/qtbase/include/QtCore -I. -
I/home/stephen/dev/prefix/qtbase/mkspecs/linux-g++ -o thelib.o thelib.cpp
rm -f libthelib.so.1.0.0 libthelib.so libthelib.so.1 libthelib.so.1.0
clang++ -Wl,-rpath,/home/stephen/dev/prefix/qtbase/lib -shared -Wl,-
soname,libthelib.so.1 -o libthelib.so.1.0.0 thelib.o  -
L/home/stephen/dev/prefix/qtbase/lib -lQt5Core -lpthread
/usr/bin/ld: thelib.o: relocation R_X86_64_32 against `qt_version_tag' can
not be used when making a shared object; recompile with -fPIC
thelib.o: error adding symbols: Bad value
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
Makefile:147: recipe for target 'libthelib.so.1.0.0' failed
make: *** [libthelib.so.1.0.0] Error 1
makeobj[0]: Leaving directory `/tmp/qmake'


1) The qt_version_tag is new in Qt 5.6, so I assume this happens with that
Qt version too.

2) If I compile with -DQT_NO_VERSION_TAGGING, then the link succeeds.

Reading the preprocessor code in qtversiontagging, I can see why.

3) Is it deliberate that GCC-built Qt can no longer be used with Clang?

I haven't seen mailing list discussion confirming that.

4) If that should still be possible, are clients expected to add their own
define of -DQT_NO_VERSION_TAGGING?

It could be added to the qmake/cmake files if so for these mixing
conditions.

Thanks,

Steve.


___
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] Scalable UIs in QtQuick (take 2)

[Hausmann Simon]

Hi,


Yes, that is correct. But you could compare for example:


if (item.width == 5cm) {

...

}


The idea is that this it build this into the numeric literals.


Simon



From: Development 
<development-bounces+simon.hausmann=theqtcompany@qt-project.org> on behalf 
of Konstantin Ritt <ritt...@gmail.com>
Sent: Thursday, February 18, 2016 13:20
To: Sorvig Morten
Cc: Qt Project Development Mailing-List
Subject: Re: [Development] Scalable UIs in QtQuick (take 2)

Yet another question: when we write Item { id: item; width: 5cm }, what would 
item.width return? value expressed in logical pixels?


Konstantin

2016-02-18 15:05 GMT+03:00 Sorvig Morten 
<morten.sor...@theqtcompany.com<mailto:morten.sor...@theqtcompany.com>>:

> On 18 Feb 2016, at 12:35, Nikita Krupenko 
> <krne...@gmail.com<mailto:krne...@gmail.com>> wrote:
>
> 2016-02-18 12:50 GMT+02:00 Hausmann Simon 
> <simon.hausm...@theqtcompany.com<mailto:simon.hausm...@theqtcompany.com>>:
>> (1) In order to make it really easy to scale "logical" pixels without having 
>> to introduce your own context property or factor in a .qml file that you 
>> multiply everywhere, we could turn the regular "pixels" in QtQuick into 
>> truly logical pixels that scale with an application wide (or window wide) 
>> factor. So Image { width: 100 ... } will scale automatically from 100 
>> logical pixels to maybe 200 physical pixels on a x2 display. This assumes 
>> the availability of API to change this mapping.
>>
>> (2) In the events where you still _want_ to use physical pixels, you could 
>> use "px" units.
>>
>> So at first nothing would change for app developers at all because we map 
>> logical pixels to physical pixels. But
>> if you'd like to, you could opt into changing this mapping and having a 
>> relatively easy fallback to physical pixels using for example the "px" unit. 
>> We might as well offer the other physical units anyway, that probably causes 
>> little to no harm.
>
> Isn't (1) already done with Qt::AA_EnableHighDpiScaling? Though
> disabling this feature for some items would be useful, like for
> Canvas, which is broken now with this scaling.

This is indeed what is done for that flag and on OS X and iOS. In that
sense logical pixels are already supported.

"px" could be added, but what are the use cases? You almost never want to
have small content on high-DPI display. I see doing custom scaling in the
application as a possible one.

As a minor platform note, "px" would not be guaranteed to be physical pixels
on Apple operating systems. There can be further resolution virtualization,
for example when setting a scaled resolution for the display.

Morten



___
Development mailing list
Development@qt-project.org<mailto: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] Scalable UIs in QtQuick (take 2)

[Hausmann Simon]

Hi,


(1) Do I understand your question correctly in the sense that you're wondering 
if 5cm would still produce a 5cm dimension on the screen regardless of the 
scale factor? Then the answer is yes :)


(2) At first glance I do like that idea. Any other opinions?




Simon



From: Ирина Flora <ritt...@gmail.com>
Sent: Thursday, February 18, 2016 11:57
To: Hausmann Simon
Cc: development@qt-project.org
Subject: Re: [Development] Scalable UIs in QtQuick (take 2)

I like it!

Some questions though:
* Does (2) include coverage for cases like 5cm ?
* Could we have a solution for writing `width: 90%` instead of `width: 
parent.width * 0.9` as well?

Regards,
Konstantin

2016-02-18 14:50 GMT+04:00 Hausmann Simon 
<simon.hausm...@theqtcompany.com<mailto:simon.hausm...@theqtcompany.com>>:
Hi,

A little while ago Lars and I proposed to introduce physical units in the QML 
language for use in QtQuick. The idea was to make it easier to write user 
interfaces that adapt to different display resolutions by "pinning" your UI to 
physical dimensions. For example you could say

Image {
source: "mypprofilephoto.png"
width: 5cm
height: 5cm
}

and the image size in physical pixels would scale accordingly to always produce 
a 5cmx5cm profile image on the screen. The proposed units included "px", which 
was really an alias for nothing.

We've had some very good discussions around this at last year's contributor 
summit as well as in smaller face-to-face discussions. The main feedback I 
recall was that this would seem like a nice feature on paper but in practice 
people create their resolution independent interfaces using the current 
"pixels" and a scale factor that they introduce in a qml file or as a context 
property. That's another way of saying that perhaps the feature wouldn't really 
find any use, which is fair :). Instead the desire was expressed that making it 
_easier_ to scale "logical" pixels in the application would perhaps be better.

So today during a discussion another idea came up:

(1) In order to make it really easy to scale "logical" pixels without having to 
introduce your own context property or factor in a .qml file that you multiply 
everywhere, we could turn the regular "pixels" in QtQuick into truly logical 
pixels that scale with an application wide (or window wide) factor. So Image { 
width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 
physical pixels on a x2 display. This assumes the availability of API to change 
this mapping.

(2) In the events where you still _want_ to use physical pixels, you could use 
"px" units.

So at first nothing would change for app developers at all because we map 
logical pixels to physical pixels. But
if you'd like to, you could opt into changing this mapping and having a 
relatively easy fallback to physical pixels using for example the "px" unit. We 
might as well offer the other physical units anyway, that probably causes 
little to no harm.

What do you think?

Simon
___
Development mailing list
Development@qt-project.org<mailto: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] Scalable UIs in QtQuick (take 2)

[Hausmann Simon]

Hi,

A little while ago Lars and I proposed to introduce physical units in the QML 
language for use in QtQuick. The idea was to make it easier to write user 
interfaces that adapt to different display resolutions by "pinning" your UI to 
physical dimensions. For example you could say

Image {
source: "mypprofilephoto.png"
width: 5cm
height: 5cm
}

and the image size in physical pixels would scale accordingly to always produce 
a 5cmx5cm profile image on the screen. The proposed units included "px", which 
was really an alias for nothing.

We've had some very good discussions around this at last year's contributor 
summit as well as in smaller face-to-face discussions. The main feedback I 
recall was that this would seem like a nice feature on paper but in practice 
people create their resolution independent interfaces using the current 
"pixels" and a scale factor that they introduce in a qml file or as a context 
property. That's another way of saying that perhaps the feature wouldn't really 
find any use, which is fair :). Instead the desire was expressed that making it 
_easier_ to scale "logical" pixels in the application would perhaps be better.

So today during a discussion another idea came up:

(1) In order to make it really easy to scale "logical" pixels without having to 
introduce your own context property or factor in a .qml file that you multiply 
everywhere, we could turn the regular "pixels" in QtQuick into truly logical 
pixels that scale with an application wide (or window wide) factor. So Image { 
width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 
physical pixels on a x2 display. This assumes the availability of API to change 
this mapping.

(2) In the events where you still _want_ to use physical pixels, you could use 
"px" units.

So at first nothing would change for app developers at all because we map 
logical pixels to physical pixels. But
if you'd like to, you could opt into changing this mapping and having a 
relatively easy fallback to physical pixels using for example the "px" unit. We 
might as well offer the other physical units anyway, that probably causes 
little to no harm.

What do you think?

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

Re: [Development] Modify QLibraryInfo to support any default location of qt.conf

[Hausmann Simon]

You're right, the can is open right now. Apple is working on closing that can 
under our feet (see the DYLD_* variable unsetting upon exec in 10.11). I 
wouldn't be surprised if that trend continues elsewhere :)


Simon


From: Development  on behalf of Koehne Kai 

Sent: Friday, January 29, 2016 9:10
To: André Somers; development@qt-project.org
Subject: Re: [Development] Modify QLibraryInfo to support any default location 
of qt.conf

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On
> Behalf Of Andre Somers
> Sent: Friday, January 29, 2016 9:05 AM
> To: development@qt-project.org
> Subject: Re: [Development] Modify QLibraryInfo to support any default
> location of qt.conf
>
>
>
> Op 28/01/2016 om 13:00 schreef Maximilian Hrabowski:
> >> Why isn't this first ?
> >> I would generally expect an environment variable to take precedence
> >> over all other configuration options except command-line options.
> > You are right, that an environment variable should be considered first. But
> I think one of the three possible solutions is enough. I did not mean to
> implement all three in this order. For me the environment variable is the
> solution that i like least.
> >
> Wouldn't that open up a can of worms in terms of security of the
> application? If setting an environment variable is enough to change what
> libs get loaded and you can point to arbitrary different libs, that means
> injecting your own code in other peoples applications becomes really easy,
> right? I think you could use that to get rights escalation.

The can is already open in this case. You can set PATH, LD_LIBRARY_PATH, 
QML_IMPORT_PATH 

Regards

Kai
___
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] RTSP H264 under Windows

[Hausmann Simon]

Judging from responses on the internet like 
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/4ac87f5f-b8c5-471a-a424-55c0fff04eac/using-the-media-foundation-sdk-to-parse-rtsp-streams?forum=mediafoundationdevelopment
 I have the impression that the Media Foundation in Windows does not support 
h264 payloads in RTSP. Not sure there's much we can do on the Qt side about 
that :)


Simon


From: Development  on behalf of Gerhard 
Scheikl 
Sent: Friday, January 29, 2016 10:34
To: development@qt-project.org
Subject: [Development] RTSP H264 under Windows

Hi!

We are trying to display an RTSP stream under Windows.
For the video encoding, h264 is used.
On the GUI side we are using the QML MediaPlayer component.

Unfortunately, we don't see any video output nor do we get any error.
VLC is able to playback the stream on the same machine.

Should this work? Is h264 over RTSP supported under Windows?

Thanks.

Best regards
Gerhard
___
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] Setting up test server for QtNetwork tests

[Hausmann Simon]

Regarding the server that is used for Qt 5.6 and onwards: It is an exact clone 
of the virtual machine that ran in Jenkins with no changes
to the services, but it is in a different virtual network segment. The virtual 
segment is the same as the virtual machines that run the tests,
and that has proven to improve the reliability of network test execution 
dramatically.



Simon


From: Development  on behalf of Sarajärvi 
Tony 
Sent: Thursday, January 28, 2016 9:02
To: Konstantin Tokarev; development@qt-project.org
Subject: Re: [Development] Setting up test server for QtNetwork tests

Hi

That manual is probably the only official one we have. Up  until Qt 5.5 we've 
been using that one ourselves as well.
We did have a work in progress version on top of Ubuntu 12.04: 
https://gitorious.org/qtqa/tosarajas-sysadmin-nts.git/?p=qtqa:tosarajas-sysadmin-nts.git;a=blob;f=README.network_test_server.txt;h=2b745d077e98f2cf64c4ab8e0391e8e0cbf51118;hb=HEAD

But as newer versions of backend services fixed various things, our autotests 
weren't fixed to handle the situation. Thus we were stuck with the old one.

Now in Qt 5.6 we use yet another one, and sadly I have no knowledge what it 
contains. It's on my todo list to figure out. Most likely a mixture of the two 
above.

-Tony

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On
> Behalf Of Konstantin Tokarev
> Sent: 27. tammikuuta 2016 18:17
> To: development@qt-project.org
> Subject: [Development] Setting up test server for QtNetwork tests
>
> Hello,
>
> What is the recommended (and possibly easiest) way to set up test server
> for QtNetwork?
>
> I've found manual [1]. Is it the preferred way? If so, is Ubuntu 10.04 
> required,
> or other versions (e.g., 12.04 or 14.04) may be used as well?
>
> Isn't there any ready-to-use VirtualBox or Docker image with test server?
>
> [1]
> http://code.qt.io/cgit/qtqa/sysadmin.git/tree/README.network_test_serve
> r.txt
>
> --
> Regards,
> Konstantin
> ___
> 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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Setting up test server for QtNetwork tests

[Hausmann Simon]

Hi,

In principle that manual is still correct.

There was work going on towards automating the setup for everyone through the 
use of a vagrant template
that would call puppet, etc. do to the installation. I believe that was still 
part of a work-in-progress branch in qtbase,
but it hasn't hit any development branch yet.

The server used in production is basically created from this manual, but it's 
not automatically kept up-to-date
from the puppet tree in gerrit. However if you have changes to the setup there, 
please let us know (CC in gerrit) and I
think that we can apply these to the server in production.

Simon


From: Development  on behalf of Konstantin 
Tokarev 
Sent: Wednesday, January 27, 2016 17:16
To: development@qt-project.org
Subject: [Development] Setting up test server for QtNetwork tests

Hello,

What is the recommended (and possibly easiest) way to set up test server for 
QtNetwork?

I've found manual [1]. Is it the preferred way? If so, is Ubuntu 10.04 
required, or other versions (e.g., 12.04 or 14.04) may be used as well?

Isn't there any ready-to-use VirtualBox or Docker image with test server?

[1] http://code.qt.io/cgit/qtqa/sysadmin.git/tree/README.network_test_server.txt

--
Regards,
Konstantin
___
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] Status of QtMultimedia module

[Hausmann Simon]

Hi,


I can't response to the aspect of which bugs are considered and how code 
reviews happen, but regarding your statement of the development being stalled:


I'm counting 37 landed changes in January 2016 until today, that's more than a 
change per day. I can also see changes going in regularly in the months

before January.


I suspect that what's bothering you is that the focus of development is not 
where you would like it to be - is that accurate?


Simon



From: Development  on behalf of Denis 
Shienkov 
Sent: Thursday, January 28, 2016 10:46
To: development@qt-project.org
Subject: [Development] Status of QtMultimedia module

Hi Qt developers.

During a long time I see that a development of QtMultimedia module is 
stalled... Tons of bugs are not considered at all, and a code-review commits 
keeps in reviews at monts without touching/response... Besides, many of 
QtMultimedia's API are not implemented yet, and are just as stubs, that do 
nothing.

So, my question is: what state of QtMultimedia module? what are perspectives? 
Have you resources to support this module?

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

Re: [Development] qtdeclarative-5.6.0-beta build failure on rhel6

[Hausmann Simon]

Ok, I had another look. I don't think find_if is new in C++11:

‎http://en.cppreference.com/w/cpp/algorithm/find

It seems find_if_not is, but not find_if. So I think what we see here is‎ 
simply a compiler bug perhaps?

Thanks to Marco it seems that we have a workaround:

https://codereview.qt-project.org/#/c/147484/

‎So I don't have the impression that C++11 code can slip through the CI for the 
5.6 branches. However if you do discover an incidence please holler :)

Simon

  Original Message
From: Olivier Goffart
Sent: Monday, January 18, 2016 16:26
To: development@qt-project.org
Cc: Rex Dieter
Subject: Re: [Development] qtdeclarative-5.6.0-beta build failure on rhel6


On Montag, 18. Januar 2016 08:31:01 CET Rex Dieter wrote:
> I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run
> into a build failure in qtdeclarative,

> beta/tools/qmlimportscanner/main.cpp:376: error: no matching function for
> call to 'find_if(QList::const_iterator,


std::find_if is new in C++11
And it was used in https://codereview.qt-project.org/125853/ in the 5.6 which
still does not require C++11.

Apparently the CI does not try to build this with non-c++11 enabled compilers?

--
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
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] tvOS port

[Hausmann Simon]

Awesome work :)



Simon


From: Development  on behalf of Mike Krus 

Sent: Monday, January 25, 2016 21:06
To: Qt Development Group
Subject: [Development] tvOS port

Hi

during the xmas break, I took "advantage" of the dreadful weather to 
investigate porting Qt5 (dev branch) to Apple's tvOS.

Due to tvOS being mostly built upon iOS, the initial work was quite straight 
forward, adding a new mkspec, a new configure option, a CONFIG variable (tvos), 
enabling and disabling things where appropriate.  [1]

Past the initial prototyping, most of the work has been focused on reducing the 
duplication in the build configuration, following initial feedback on gerrit. 
Have learned more about prf files than I ever wanted to know :)

Most relevant modules have been updated to build for tvOS, but with very 
limited testing.

Beyond testing, key challenge remaining is the user interaction. Due to the 
lack of direct touch, or even a mouse cursor, handling focus, mouse areas, etc, 
will require more careful work.

As always, feedback and suggestions will be greatly appreciated.


Mike


[1] pending changelists:
https://codereview.qt-project.org/144800
https://codereview.qt-project.org/145174
https://codereview.qt-project.org/145519

--
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44-1625-809908Mobile +44 7833 491941
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Hausmann Simon]

Hi,

Could you elaborate where you see copy on write causing writes to shared cache 
lines? Are you concerned about the shared cache line for the reference count?

For reading MESI allows for shared cache lines and for hyper threads the shared 
l1 data cache mode favors sharing and thus CoW.

What am I missing to understand your statement?


Simon

  Original Message
From: Bubke Marco
Sent: Sunday, January 24, 2016 19:10
To: Kevin Kofler; development@qt-project.org
Subject: Re: [Development] Question about QCoreApplicationData::*_libpaths


On January 24, 2016 17:45:36 Kevin Kofler  wrote:

> Marc Mutz wrote:
>> (numThread == 2, same box)
>>
>> Copying is still not significantly slower than ref-counting, even for 4K
>> elements.
>
> But it is already slower with as little as 32 elements, and stops being
> significantly faster already at 16 elements.
>
> And now try with numThread == 1 for some extra fun. :-) A lot of code out
> there is still single-threaded.
>

 Yes but in the future the processors getting more and more parallel. If I am 
working on the bigger dataset with parallel algorithms I don't want to share 
writes to the same cache like. Something which CoW is providing.

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

--
Sent from cellphone, sorry for the typos
___
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] What kind of airplane we want to build?

[Hausmann Simon]

Hi,

I think answering the question about the kind of airplane to build is closely 
tied to another question that may be worthwhile
asking. I think it's worthwhile because I'm convinced that answers diverge 
greatly depending on who you ask.

Why are we trying to build an airplane?

Or differently put: What is our mission?

Is our mission to transport people from A to B? Is the mission to transport 
goods from A to B? Is our mission to get people from
A to B in the quickest way? Or is it about safety? The answer greatly 
influences the type of airplane to build (in the event that
the airplane is the right method of transportation).


I'm of the opinion that our mission should be to make life easier for 
programmers.

That includes also novice programmers and especially people who's first 
language is not English.

Who else agrees with me?

Ways to achieve that include tooling to increase work flow productivity, 
intuitive and consistent APIs that are easy to remember
and easy to use, especially for non-native english speakers. These are 
considerations that greatly affect the naming of functions
(which may or may not justify diverging from the STL for example).


Simon


From: Development  on behalf of Bubke Marco 

Sent: Wednesday, January 20, 2016 11:48
To: Development@qt-project.org
Subject: [Development] What kind of airplane we want to build?

Hello

After the exciting discussions in the last time with all the energy spend on 
them I want to try to make a short summary.  Maybe we can transform the heat on 
some steam to progress further. ;-)

I think many feel that C++ is rapidly changing. With C++ 17 on the horizon 
there is some excitement but also fear that Qt will not stay relevant if we not 
adapt. But there are arguments too about existing users who would be left in 
the cold we we change to much.

So let use an airplane as metaphor. We built a fine piston engine airplane on 
that little bit cumbersome piston engine called C++. But now we see Jet engines 
coming up but all our technology is built the old piston engine technology so 
the adaption of jet engines is not that cheap. The jet engines are different 
but we are not sure about their advantages but we are sure it would be a big 
investment to change to them. So people propose different designs. Some say we 
should minimize investments and only apapt slowly other proposed to build a 
hyper mach airplane.

The metaphor is not perfect but I hope it is productive enough.

I think the big elephant is the massive move of the processing technology to 
multi cores,  massive multi cores formerly known as GPUs and the new parallel 
mechanism which are proposed to utilize them. Resumable functions, ranges, 
parallel stl and how they all are called. This will change how C++ looks but 
how can we change Qt in that picture to utilize this new technologies.

I think it would be productive for the discussion to build story of what we 
want to do. A story of the big picture. Maybe as a first step we can show how 
we tackle problems with Qt 5 and what are the proposed technologies in the 
future C++ standard.

Maybewe see that we don't have to change so much.  Maybe we find out the change 
would be so massive that we cannot call it Qt 6 anymore. There are many maybes 
because the future is uncertain but we handled uncertainty in the past so why 
we should not do it in the future?

I really believe that before we make little changes like the containers etc. we 
have to find a story. A story how the future Qt should look, a story for the 
long run. In my opinion we have to build the story TOGETHER and this story 
should be build on actual experience and measured facts. We should be careful 
about emotions like doubt,  fear or excitement. I think we should be stay calm.

So we can try now this new C++ prototypes, find out how they fit with our 
technology like signal/slots,  CoW etc.. And later if they are getting momentum 
we can provide our magic sauce on top to make our users more productive.

And if we want change Qt much we have to provide a technology to make the 
adaptation of our users easy and reliable. So the gain should be bigger than 
the cost. I think Clang based technologies provide us some possible tools but 
we have to find out. It is not only about providing the tool kit for new shine 
projects but for existing ones too. Some maybe they don't want to change and 
that is a respectable decision but for the user who want and need to adapt we 
should make it easy.

I know this sounds like common sense but after all the discussions in last time 
I think we should step back and get a bigger picture before starting detailed 
discussions again.

So lets go out,  start prototypes,  gain experience and come back to fruitful 
discussions.  ;-)

--
Sent from cellphone, sorry for the typos
___

Re: [Development] V4 porting

[Hausmann Simon]

Hi,

Moth is the portable interpreter that will be used instead of the just-in-time 
compiler if your platform doesn't support it. It should be chosen automatically 
for you according to the #ifdefs in qv4global_p.h.

So if you have qtbase compiling, then qml should also work. If you want things 
to run faster, then you will have to port the JIT.

Simon

From: Dmitriy -
Sent: Thursday, December 24, 2015 10:47
To: development@qt-project.org
Subject: [Development] V4 porting


Hi!
I want to port v4 engine to the new platform. The platform is Linux OS and new 
processor. The processor looks like intel itanium. It is VLIW and EPIC.
I have a c++/c compilers for the new architecture.

I want to design qt quic qml application for the new platform. As a can see in 
code, I need v4vm backend for this purpose.

I'm see this:

case use_moth: {
QV4::EvalISelFactory* iSelFactory = 0;
if (mode == use_moth) {
iSelFactory = new QV4::Moth::ISelFactory;
#ifdef V4_ENABLE_JIT
} else {
iSelFactory = new QV4::JIT::ISelFactory;
#endif // V4_ENABLE_JIT
}

QV4::ExecutionEngine vm(iSelFactory);

QV4::Scope scope();
QV4::ScopedContext ctx(scope, vm.rootContext());



As I understand v4vm has two backends - Moth and Masm.

What is Moth?

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

Re: [Development] V4 porting

[Hausmann Simon]

Hi,

Registers that are native to the processor are saved on the regular stack.


Simon

From: Dmitriy -
Sent: Thursday, December 24, 2015 14:11
To: Hausmann Simon
Cc: development@qt-project.org
Subject: Re: [Development] V4 porting


One more question:

qt-5.5.1/qtdeclarative/src/qml/jit/qv4assembler_p.h


// V4 uses two stacks: one stack with QV4::Value items, which is checked by 
the garbage

// collector, and one stack used by the native C/C++/ABI code. This C++ 
stack is not scanned

// by the garbage collector, so if any JS object needs to be retained, it 
should be put on the

// JS stack.

//

// The "saved reg arg X" are on the C++ stack is used to store values in 
registers that need to

// be passed by reference to native functions. It is fine to use the C++ 
stack, because only

// non-object values can be stored in registers.

//

// Stack layout for the C++ stack:

//   return address

//   old FP <- FP

//   callee saved reg n

//   ...

//   callee saved reg 0

//   saved reg arg n

//   ...

//   saved reg arg 0<- SP

//

// Stack layout for the JS stack:

//   function call argument n   <- LocalsRegister

//   ...

//   function call argument 0

//   local 0

//   ...

//   local n





// First save any arguments that reside in registers, because they could be 
overwritten

// if that register is also used to pass arguments.

saveOutRegister<5>(arg6);

saveOutRegister<4>(arg5);

saveOutRegister<3>(arg4);

saveOutRegister<2>(arg3);

saveOutRegister<1>(arg2);

saveOutRegister<0>(arg1);

...


What kind of stack use for saving registers? Is it c++/ABI stack (I hope) or Js 
stack?


On Thu, Dec 24, 2015 at 5:42 PM, Dmitriy - 
<dima00...@gmail.com<mailto:dima00...@gmail.com>> wrote:
Thank.
I want to port JIT. Where should I start?
You have any roadmap for this?

Now I'm using qmljs tool for testing purpose.
I has seen in qt-5.5.1/qtdeclarative/src/qml/jsruntime/qv4script.cpp:

Script::parse():
...

RuntimeCodegen cg(v4, strictMode);

cg.generateFromProgram(sourceFile, sourceCode, program, , 
QQmlJS::Codegen::EvalCode, inheritedLocals);

if (v4->hasException) return;

QV4::Compiler::JSUnitGenerator jsGenerator();

QScopedPointer isel(...);

...

QQmlRefPointer compilationUnit = 
isel->compile();

vmFunction = compilationUnit->linkToEngine(v4);

...


Why do you compile script while parse it? Do you use AOT compiling?

On Thu, Dec 24, 2015 at 5:18 PM, Hausmann Simon 
<simon.hausm...@theqtcompany.com<mailto:simon.hausm...@theqtcompany.com>> wrote:
Hi,

Moth is the portable interpreter that will be used instead of the just-in-time 
compiler if your platform doesn't support it. It should be chosen automatically 
for you according to the #ifdefs in qv4global_p.h.

So if you have qtbase compiling, then qml should also work. If you want things 
to run faster, then you will have to port the JIT.

Simon

From: Dmitriy -
Sent: Thursday, December 24, 2015 10:47
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: [Development] V4 porting


Hi!
I want to port v4 engine to the new platform. The platform is Linux OS and new 
processor. The processor looks like intel itanium. It is VLIW and EPIC.
I have a c++/c compilers for the new architecture.

I want to design qt quic qml application for the new platform. As a can see in 
code, I need v4vm backend for this purpose.

I'm see this:

case use_moth: {
QV4::EvalISelFactory* iSelFactory = 0;
if (mode == use_moth) {
iSelFactory = new QV4::Moth::ISelFactory;
#ifdef V4_ENABLE_JIT
} else {
iSelFactory = new QV4::JIT::ISelFactory;
#endif // V4_ENABLE_JIT
}

QV4::ExecutionEngine vm(iSelFactory);

QV4::Scope scope();
QV4::ScopedContext ctx(scope, vm.rootContext());



As I understand v4vm has two backends - Moth and Masm.

What is Moth?

--
Regards,
Dmitry Bezheckov.



--
Regards,
Dmitry Bezheckov.



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

Re: [Development] V4 porting

[Hausmann Simon]

Hi,

The method parse implies a transformation from source code to a form that we 
can interpret, so technically the name of the method isn't quite accurate. 
Nevertheless it does what you can see in the implementation, which includes 
parsing into a syntax tree structure, transformation into an intermediate 
representation (codegen), optimizations in that IR and finally register 
allocation and native code generation or byte code generation.

I'm afraid that I don't have a road map for your porting efforts.

Simon

From: Dmitriy -
Sent: Thursday, December 24, 2015 12:42
To: Hausmann Simon
Cc: development@qt-project.org
Subject: Re: [Development] V4 porting


Thank.
I want to port JIT. Where should I start?
You have any roadmap for this?

Now I'm using qmljs tool for testing purpose.
I has seen in qt-5.5.1/qtdeclarative/src/qml/jsruntime/qv4script.cpp:

Script::parse():
...

RuntimeCodegen cg(v4, strictMode);

cg.generateFromProgram(sourceFile, sourceCode, program, , 
QQmlJS::Codegen::EvalCode, inheritedLocals);

if (v4->hasException) return;

QV4::Compiler::JSUnitGenerator jsGenerator();

QScopedPointer isel(...);

...

QQmlRefPointer compilationUnit = 
isel->compile();

vmFunction = compilationUnit->linkToEngine(v4);

...


Why do you compile script while parse it? Do you use AOT compiling?

On Thu, Dec 24, 2015 at 5:18 PM, Hausmann Simon 
<simon.hausm...@theqtcompany.com<mailto:simon.hausm...@theqtcompany.com>> wrote:
Hi,

Moth is the portable interpreter that will be used instead of the just-in-time 
compiler if your platform doesn't support it. It should be chosen automatically 
for you according to the #ifdefs in qv4global_p.h.

So if you have qtbase compiling, then qml should also work. If you want things 
to run faster, then you will have to port the JIT.

Simon

From: Dmitriy -
Sent: Thursday, December 24, 2015 10:47
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: [Development] V4 porting


Hi!
I want to port v4 engine to the new platform. The platform is Linux OS and new 
processor. The processor looks like intel itanium. It is VLIW and EPIC.
I have a c++/c compilers for the new architecture.

I want to design qt quic qml application for the new platform. As a can see in 
code, I need v4vm backend for this purpose.

I'm see this:

case use_moth: {
QV4::EvalISelFactory* iSelFactory = 0;
if (mode == use_moth) {
iSelFactory = new QV4::Moth::ISelFactory;
#ifdef V4_ENABLE_JIT
} else {
iSelFactory = new QV4::JIT::ISelFactory;
#endif // V4_ENABLE_JIT
}

QV4::ExecutionEngine vm(iSelFactory);

QV4::Scope scope();
QV4::ScopedContext ctx(scope, vm.rootContext());



As I understand v4vm has two backends - Moth and Masm.

What is Moth?

--
Regards,
Dmitry Bezheckov.



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

Re: [Development] wec2013 build fails with qt 5.6 beta in dbus.

[Hausmann Simon]

We ran into similar issues in a few places and the established workaround is a 
carefully placed #undef interface. Would you be able to tell us where the 
conflict happened or maybe even make a patch? (see qtnetwork for a similar 
#undef)


Simon

From: Gunnar Roth
Sent: Monday, December 21, 2015 17:44
To: development@qt-project.org
Subject: [Development] wec2013 build fails with qt 5.6 beta in dbus.


Hi,
the problem is that dbus is set to runtime instead of no for windows from 
configure when no dbus support is found. So it is being tried to build it, 
which fails,
mostly due to using 'interface' as identifier, which seems to be a define 
somewhere in the wec2013 headers. I wil add -no-dbus to my configure line.

I assume there is no ci in place for wec2013?

Regards,
Gunnar



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

Re: [Development] Review request for ArrayBuffer+WebSocket/XHR (a.k.a Introducing protobuf-qml)

[Hausmann Simon]

Hi,


I've started reviewing your series of patches. Excellent work! Thank you for 
contributing your changes back.


I also think that protobuf bindings would make a lot of sense to have in Qt 
itself. Is there any chance that you could

make it to the next Qt contributor summit and we have a chat about it there? :)



Simon



From: Development  on behalf of Nobuaki 
Sukegawa 
Sent: Saturday, December 12, 2015 12:59
To: development@qt-project.org
Subject: [Development] Review request for ArrayBuffer+WebSocket/XHR (a.k.a 
Introducing protobuf-qml)

Hello Qt team and community,

Could anyone help me with reviews on ArrayBuffer support for QtWebSockets and 
QtQuick XMLHttpRequest ?

WebSockets:
https://codereview.qt-project.org/#/c/125712/
[https://codereview.qt-project.org/static/logo_open_gov.png]

Gerrit Code Review
codereview.qt-project.org
Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet 
Qt; Qt Repository Browser



XHR:
https://codereview.qt-project.org/#/c/143732/


While I believe these features are generally useful, let me share my motivation:

I've written Protocol Buffers / gRPC bindings for QtQuick2.
https://github.com/nsuke/protobuf-qml

Main feature of this is to serialize schematized message objects to ArrayBuffer.

While it works fine for my need (plugging to proprietary RPC stack), I'd like 
to share this with others and see what they would do with this.

Unfortunately, currently ArrayBuffer is not that useful out of the box as is, 
so it's not going to be much of interest without these features.

You can find working examples of these patches here:

WebSockets
https://github.com/nsuke/protobuf-qml/blob/master/examples/WebSockets/client/client.qml#L105

XHR
https://github.com/nsuke/protobuf-qml/blob/master/examples/XMLHttpRequest/client/XhrClient.qml#L112

Best regards,

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

Re: [Development] qtdeclarative 5.6 CI status

[Hausmann Simon]

The crisis is over and resolved - happy staging :)


Simon

  Original Message
From: Hausmann Simon
Sent: Monday, December 14, 2015 15:34
To: development@qt-project.org
Subject: [Development] qtdeclarative 5.6 CI status


Hi,

I can see how people keep trying to integrate changes into qtdeclarative's 5.6 
branch. Until https://codereview.qt-project.org/#/c/143824/ lands, all those 
attempts of integrating changes are going to fail, unfortunately :)


Simon
___
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] qtdeclarative 5.6 CI status

[Hausmann Simon]

Hi,

I can see how people keep trying to integrate changes into qtdeclarative's 5.6 
branch. Until https://codereview.qt-project.org/#/c/143824/ lands, all those 
attempts of integrating changes are going to fail, unfortunately :)


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

[Development] Fw: Change in qt/qt5[dev]: Updated submodules.

[Hausmann Simon]

Hi,

It would seem that recent QPair changes have a negative impact on the ability 
to compile some existing code :)

Is this an issue in the usage or an issue with QPair?

Simon

  Original Message
From: Qt CI Bot (Code Review) <gerrit-nore...@qt-project.org>
Sent: Wednesday, November 25, 2015 07:22
To: Qi Liang
Cc: Hausmann Simon; Qt Sanity Bot; Nowacki Jedrzej; Gladhorn Frederik; 
Abrahamsen-Blomfeldt Eskil; Denis Shienkov; Kokko Antti
Subject: Change in qt/qt5[dev]: Updated submodules.


Qt CI Bot has posted comments on this change.

Change subject: Updated submodules.
..


Continuous Integration: Failed

 Module "qt/qtenginio" (ea2f8a119986979465d3679b9c03469ed529d4f6) did not 
compile:
 base\include\QtCore/qpair.h(65): error C2955: 'std::is_nothrow_assignable': 
use of class template requires template argument list
 C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): 
note: see declaration of 'std::is_nothrow_assignable'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic 
occurred in the compiler generated function 'QPair<bool,QString> 
<bool,QString>::operator =(const QPair<TT1,TT2> &) noexcept()'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT2': 
undeclared identifier
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic 
occurred in the compiler generated function 'QPair<bool,QString> 
<bool,QString>::operator =(const QPair<TT1,TT2> &) noexcept()'
 C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): 
note: see declaration of 'std::is_nothrow_assignable'
 C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): 
note: see declaration of 'std::is_nothrow_assignable'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2057: expected 
constant expression
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic 
occurred in the compiler generated function 'QPair<bool,QString> 
<bool,QString>::operator =(const QPair<TT1,TT2> &) noexcept()'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT1': 
undeclared identifier
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic 
occurred in the compiler generated function 'QPair<bool,QString> 
<bool,QString>::operator =(QPair<TT1,TT2> &&) noexcept()'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 
'std::is_nothrow_assignable': 'TT1' is not a valid template type argument for 
parameter '_From'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic 
occurred in the compiler generated function 'QPair<bool,QString> 
<bool,QString>::operator =(QPair<TT1,TT2> &&) noexcept()'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2955: 
'std::is_nothrow_assignable': use of class template requires template argument 
list
 C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): 
note: see declaration of 'std::is_nothrow_assignable'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic 
occurred in the compiler generated function 'QPair<bool,QString> 
<bool,QString>::operator =(QPair<TT1,TT2> &&) noexcept()'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT2': 
undeclared identifier
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic 
occurred in the compiler generated function 'QPair<bool,QString> 
<bool,QString>::operator =(QPair<TT1,TT2> &&) noexcept()'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 
'std::is_nothrow_assignable': 'TT2' is not a valid template type argument for 
parameter '_From'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic 
occurred in the compiler generated function 'QPair<bool,QString> 
<bool,QString>::operator =(QPair<TT1,TT2> &&) noexcept()'
 C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): 
note: see declaration of 'std::is_nothrow_assignable'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2057: expected 
constant expression
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic 
occurred in the compiler generated function 'QPair<bool,QString> 
<bool,QString>::operator =(QPair<TT1,TT2> &&) noexcept()'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT1': 
undeclared identifier
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic 
occurred in the compiler generated function 'QPair<bool,QString> 
<bool,QString>::operator =(const QPair<TT1,TT2> &) noexcept()'
 C:\Users\qt\work\qt\qtbase\include\QtCore/qpair

Re: [Development] glib's and Qt's RuntimeLocation [OS X]

[Hausmann Simon]

Hi,

I think the chances of a Qt application depending on glib on Mac OS X are 
extremely slim, given that glib is not part of the default system installation. 
I think the much more common case of a Qt application on Mac OS X is to just 
use Qt and the system APIs without any third-party library dependency. So I 
think it makes sense if our defaults align towards that use-case and with what 
apple recommends for applications. Their documentation makes a compelling case 
IMO:

https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html



Simon


From: Development  on behalf of René J. V. 
Bertin 
Sent: Tuesday, November 24, 2015 11:25
To: development@qt-project.org
Subject: [Development] glib's and Qt's RuntimeLocation [OS X]

Hello,

This is a follow-up question to one I posted yesterday.

Looking into the paths used for QSP::RuntimeLocation in more detail I noticed
that GLib has its own ideas, using $HOME/.cache on OS X:

https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-runtime-dir

I have the impression that it's not that uncommon to use glib from Qt-based
applications; how (un)likely is it that the disagreement on the location of the
user runtime directory will lead to issues?

R

PS: why did Qt choose ~/Library/Application Support for that location? Isn't the
stuff stored there supposed to be volatile that doesn't need to survive reboots
or end up in (Time Machine) backups?

___
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] Nominating Pasi Keränen for Approver status

[Hausmann Simon]

+1


Simon


From: Development  on behalf of Frederik 
Gladhorn 
Sent: Monday, November 23, 2015 12:46
To: development@qt-project.org
Subject: [Development] Nominating Pasi Keränen for Approver status

Hi all,

I'd like to nominate Pasi Keränen as Approver in the Qt Project. He is
actually already a maintainer for the Qt Canvas 3D module, so this will
actually "complete" his maintainer status with the general approver bit.

Pasi is a great colleague and fun to work with. He has a focus on 3D and
lately became more active in the Qt 3D module as well.

Gerrit dashboard:
https://codereview.qt-project.org/#/q/owner:%22Pasi+Ker%25C3%25A4nen+
%253Cpasi.keranen%2540theqtcompany.com%253E%22,n,z

Cheers,
Frederik
___
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] PSA: 5.6 branch integrations

[Hausmann Simon]

Hi,

Due to a hiccup in the qtbase build system any integrations targetting the 5.6 
branch in modules other than qtbase that depend directly or indirectly on 
qtdeclarative are going to fail until further notice. Examples of affected 
modules include qttools, qtwebengine, etc. I suggest to hold off staging 
attempts.

I'll send a follow-up email once the fix made it into qtbase.


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

Re: [Development] PSA: 5.6 branch integrations

[Hausmann Simon]

Hi,

Thanks to Ossi's analysis and efforts this is fixed now.


Simon

  Original Message
From: Hausmann Simon
Sent: Thursday, November 19, 2015 09:15
To: development@qt-project.org
Subject: [Development] PSA: 5.6 branch integrations


Hi,

Due to a hiccup in the qtbase build system any integrations targetting the 5.6 
branch in modules other than qtbase that depend directly or indirectly on 
qtdeclarative are going to fail until further notice. Examples of affected 
modules include qttools, qtwebengine, etc. I suggest to hold off staging 
attempts.

I'll send a follow-up email once the fix made it into qtbase.


Simon
___
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] New qt5.6 beta snapshot available

[Hausmann Simon]

Hi,

Namespaced builds are only tested on Linux IIRC, not os x. Similarly static 
builds happen for ios, where the plugin loading code is probably not used.

Simon

  Original Message
From: Tim Blechmann
Sent: Tuesday, November 17, 2015 05:24
To: development@qt-project.org
Subject: Re: [Development] New qt5.6 beta snapshot available


>>> These aren't yet final beta packages but please test these & report all
>>> new blocker immediately
>>
>> no new blockers, but i still need to apply these two patches to be able
>> to compile 5.6-beta on osx:
>>
>> https://codereview.qt-project.org/#/c/139577/
>> https://codereview.qt-project.org/#/c/139981/
>>
>> both issues are compile failures for statically linked qt, though for
>> some reasons gerrit cannot integrate them.
>
> Neither is a showstopper for the release and the first doesn't cause a build
> error for regular people (no -developer-build).

well, both should be trivially fixable, once CI won't fail with an FTP
timeout ;)

>> btw, would it be possible to configure gerrit to build statically linked
>> qt and possibly also namespaced qt before integrating a patch? in the
>> past it happened quite often that those two configuration options did
>> not compile ... though this is all something which could easily be
>> verified automatically ...
>
> Namespace builds are tested. I don't think static builds are.

since when are namespace builds tested? it must be something rather new,
as about a month ago i had to apply this fix [1] to compile qt-5.6-base
... and i remember similar fixes which i had to do for 5.4/5.5.

cheers,
tim

[1] https://codereview.qt-project.org/#/c/127867/


___
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] RFD: plugins vs QStringLiterals

[Hausmann Simon]

And moc data is affected in a similar way. I continue to be in favor of (3)

Simon

  Original Message
From: Thiago Macieira
Sent: Friday, November 6, 2015 00:44
To: development@qt-project.org
Subject: [Development] RFD: plugins vs QStringLiterals


Proposal: force QStringLiteral uses to always address a heap-allocated
QString, instead of pointing to the static data. Possibly, this should be an
interned atom/quark à la GQuark, so two passes on the same QStringLiteral
would result in the same heap pointers.

Alternative: force QPluginLoader / QFactoryLoader to fake unloading but not
really unload. Maybe even QLibrary, if we find people use QLibrary to load Qt-
based plugins instead of our own classes.

Background:

When we created QStringLiteral, we thought it was the best thing since sliced
bread. We started using it everywhere and so did our users, after our
recommendations. I even had a session in last years' Dev Days explaining when
to use QStringLiteral and when not to. The objective of that session was to
explain performance.

The problem we're seeing is that it's quite easy to violate the precondition
that the QStringLiteral never, ever disappears. This happens when plugins are
involved. Any QStringLiteral in a plugin or in a library that gets loaded by
that plugin is subject to disappearing before the end of the program.

[Henceforth, "plugin" is "any dynamically loaded module, whether intended as a
library or plugin, including all their dependencies that weren't loaded
before"]

I've said in the past that unloading plugins is a bad idea in C++. The case
then was that it's easy to leave objects of a polymorphic class type whose
virtual table is located in the unloaded plugin. This is not very different,
since the QStringLiteral's data is also global data not expected to
disappeaar.

We've already worked around two cases of crash-at-exit caused by this, both
coincidentally related to QtDBus's interface cache. But this can also happen
for any other types of cache, like:

QRegExp rx(QStringLiteral());
QPixmapCache::insert(QStringLiteral("foo"), px);

What do we do then?

1) Declare it SEP and only apply workarounds for the places where
QStringLiteral is used in our plugins, suggesting that people do the same in
their plugins.

Problems: libraries loaded by plugins, fragile.

2) Deep-copy the QStringLiterals
 a) with atom/quark
 b) without

Problem: performance impact, complexity of the atom/quark solution.

3) Never unload any plugins, possibly also compiling our own libraries and
plugins with -z nodelete. Solves most of the problems, including the C++
vtable case.

Problems: doesn't catch bypassing of QLibrary (dlopen/LoadLibrary calls),
prevents upgrading of plugins without restarting the host application.

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

Re: [Development] Stepping down as Windows Embedded Compact port maintainer

[Hausmann Simon]

+1x2

Simon

  Original Message
From: Thiago Macieira
Sent: Friday, October 23, 2015 22:15
To: development@qt-project.org
Subject: Re: [Development] Stepping down as Windows Embedded Compact port   
maintainer


On Friday 23 October 2015 11:49:00 Knoll Lars wrote:
> >
> >Big +1 from my side, but I'm biased as we are colleagues.
>
>
> +1 from me as well.

And +1 x 2 from me (both nominations, approver and maintainer).

Andy is one of those "he's not an approver yet" cases. He's helped me a lot
when I had questions about WinEC builds that failed :-)

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

Re: [Development] Nominating Allan Jensen as maintainer for Qt WebEngine

[Hausmann Simon]

+1


Simon


From: development-bounces+simon.hausmann=theqtcompany@qt-project.org 
 on behalf 
of Koehne Kai 
Sent: Thursday, October 15, 2015 11:25
To: 'development@qt-project.org'
Subject: [Development] Nominating Allan Jensen as maintainer for Qt WebEngine

Hi,

I hereby nominate Allan Jensen as the official maintainer for the Qt WebEngine 
module. He's been the official maintainer for Qt WebKit already, but nowadays 
works full time on Qt WebEngine, and is also the default assignee for the 
WebEngine component in JIRA.

Regards

Kai

--
Kai Köhne, Senior Software Engineer - The Qt Company

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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New Qt Modules

[Hausmann Simon]

I think code that isn't specific to the automotive industry such as as the dbus 
integration should be integrated into existing modules unless there is a good 
reason otherwise.

Just my two cents,
Simon

From: Viironen Kalle
Sent: Tuesday, October 13, 2015 09:35
To: development@qt-project.org
Subject: [Development] New Qt Modules


Hi,

We'd like to have a bunch of new modules under qt-project. These are all needed 
in Qt Automotive Suite so let's try to get this sorted out quickly to get 
things rolling nicely.

New repositories needed are:

  *
qt/qtapplicationmanager, Qt component for application lifecycle management
  *   qt/qtdbusqml, Qt QML DBus integration
  *   qt/qtivi, Qt IVI extensible platform abstraction layer
  *   qt/qtgeniviextras, Qt extras for GENIVI services
  *   qt-apps/qmllive, QmlLive live reloader environment for rapid UI 
development
  *   qt-apps/neptune-ui, The Neptune Automotive Reference UI
  *   qt-apps/neptune-appstore, The Neptune Reference Application Store Server

Best Regards,

Kalle Viironen

Senior Manager, Device Creation | The Qt Company


The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu, Finland

Email: kalle.viiro...@theqtcompany.com 
| Mobile: + 358 40 50 10989

www.qt.io | Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
@Qtproject | Facebook: www.facebook.com/qt

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

Re: [Development] QML import versions

[Hausmann Simon]

Hi,


I agree that something "new" needs to be put on the table in order to solve 
this. And "this" expands unfortunately

to a few issues at the same time.


I think that it would be a mistake of "import QtQuick" - without any version 
tag - would always import the latest available

version on the system. If we look into other development communities with 
package based environments such as Python (pip)

or Go, then we can see that the approach of automatically always importing the 
latest version is known to cause more headaches

than do good. Very quickly the users want to be able to _pin_ to a certain 
version and be themselves in control when to "upgrade"

to newer API.


I think that we should learn from this and this is why I think generally 
applying a version to the QML APIs is a good thing. I believe that what

we are missing is the convenience of making the conscious step of changing the 
of QtQuick 2.4 to 2.5 - it is incredibly tedious at this

point as it requires touching every single file.


Therefore I think that we should introduce the notion of configuration files 
that apply to an entire project. For QML modules that configuration

file is the qmldir file, although I'd prefer something different. For 
applications - the primary target audience in this thread - we are lacking a

central place where we could say that


 import QtQuick



should resolve to exactly version 2.4.


In other words: I think we should allow application developers to use just 
"import QtQuick" in their qml files - without a version. But all that

should mean is that when the engine encounters a version-less import, it should 
look for the project configuration file to pick the version the

developer would like to choose.


This way one developer can try to bump the version in their copy of the 
application source code, try the app and see if there are any property

conflicts that needs resolving. Then he can commit that version bump, possibly 
together with files to .qml files that resolve conflicts.




Simon


From: development-bounces+simon.hausmann=theqtcompany@qt-project.org 
 on behalf 
of Filippo Cucchetto 
Sent: Sunday, September 20, 2015 13:55
To: Nurmi J-P
Cc: development@qt-project.org
Subject: Re: [Development] QML import versions

I'm no troll, but i don't see any way to solve this without putting something 
new to the table

1) What about extending the a little bit the QML language itself.
Something like
import QtQuick as in 5.5
import QtQuick.Controls as in 5.5

so a way to specify to import a module at version when a specific Qt version 
was released.
Obviusly this doesn't disable the option for specifying a particular version.
So this should be fine
import QtQuick as in 5.5
import QtQuick.Controls 1.4

2) Another option is automatically use the latest version of a module if the 
version number
is not specified. So:
import QtQuick // Automatically imported with the latest version installed
import QtQuick.Controls // Automatically imported with the latest version 
installed



2015-09-20 13:43 GMT+02:00 Nurmi J-P 
>:
Hi Alan,

> On 18 Sep 2015, at 20:13, Alan Alpert 
> <4163654...@gmail.com> wrote:
>
> On Fri, Sep 18, 2015 at 8:12 AM, Nurmi J-P 
> > wrote:
>> Hi all,
>>
>> I'd like to propose that all QML imports that are part of the Qt Essentials 
>> start following the respective Qt version number.
>>
>> Let's take a look at the version history of some of the QtQml and QtQuick 
>> imports.
>
> You missed a few key ones at the beginning:
>
> ### Qt 4.7.0
>
> - Qt 4.7
>
> ### Qt 4.7.1
>
> - QtQuick 1.0
>
> ### Qt 4.7.4
>
> - QtQuick 1.1


Heh, yeah, I was focusing on how the situation looks like to a user that 
installs Qt these days, but we can bring in the whole history to the 
discussion. To me, this doesn’t make the QML versioning look anyhow better, but 
more like a way to bend the rules. Greetings to the Nokia machinery that 
desperately needed new features but couldn’t afford waiting for the next minor 
version of Qt.


>> ### Qt 5.0
>>
>> - QtQml 2.0
>> - QtQuick 2.0
>> - QtQuick.Particles 2.0
>>
>> In the beginning, everything was cute, fluffy, and consistent.
>
> QtQuick 1.1 was still around, just wholly incompatible with the
> previous modules (something we'd like to avoid in the future). That's
> why QtQuick.Particles started at 2.x, because series 1 was still
> active (and there is a QtQuick.Particles 1.0 implementation somewhere
> too).
>
> Note also that around the Qt 5.0 release, and ever since, there were a
> lot of discussions about getting back to the Qt version number. Sadly
> I can't seem to find the emails right now. I seem to recall that the
> Qt Mobility modules went that direction in Qt 4.7 times 

Re: [Development] How to speed up QML for KDE5 without QML compiler

[Hausmann Simon]

Hi,

I think there's a trade-off to be made with regards source (url) vs. 
sourceComponent.

If the component your loader is trying to load is small, then you're better off 
using sourceComponent. While
the parser and the type compiler is "warm" it should take little time to do the 
one-time work of compiling it. It
would take a fair bit of additional CPU cycles to schedule a load of an 
external file, fire up the parser and the
type compiler for just a few lines. If the component is big, then it's 
definitely worth it to use source (url) instead
of sourceComponent.

So there are two "curves" that meet at some point. As long as your component is 
small, I'd keep it inline. When it
grows, move it into a separate file.

Simon


From: development-bounces+simon.hausmann=theqtcompany@qt-project.org 
 on behalf 
of Guenter Schwann 
Sent: Wednesday, September 16, 2015 12:12
To: development@qt-project.org
Subject: Re: [Development] How to speed up QML for KDE5 without QML compiler

On Wednesday 16 September 2015 12:03:38 Leslie Zhai wrote:
> Hi great Qt and KDE developers,
>
> I like QML, it is high speed development language, easy to create candy
> UI and not difficult to debug. KDE4 began to use it in some projects,
> for example, KScreen`s kcm module, it used QML to take place of
> traditional QWidget. and KDE5, it is full of QML, for example, kwin`s
> tabbox, plasma-desktop and plasma-workspace`s applet, sddm, etc.
>
> For a new PC,  there is no sharp difference between QML and QWidget, but
> in a very very old PC, how old? about 7 years ago, QML is very slow! and
> it needs to close all effects for KDE5, even that when clicked, for
> example, calendar applet, it hang about 3+ seconds to showPopup.
>
> There is commercial QML compiler, a very small example tried to use it
> https://github.com/AOSC-Dev/AOSC-VersionHelper2
> But is it suitable for huge projects just like KDE5 if bought a
> commercial license? because not all KF5 components follow the Qt Quick
> Compiler`s resource.qrc way, so is it able to compile? for example,
> kickoff applet (the start menu of KDE5).

Hi,

One generic advise is to use the Loader item a lot. So only visible/needed
items are created.
This helps a lot for the startup performance.

And in the Loader rather use the source instead of the sourceComponent
property (or use the setSource() function). As the sourceComponent still
parses all stuff (although the binding is the biggest time consumer usually).

It will make your code more complex. And of course has it's limits and might
not be your biggest bottleneck. But usually helps a lot.

--
Guenter Schwann

___
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] Requesting New Repository - QtZeroConf

[Hausmann Simon]

Hi,

Given that mdns uses an unprivileged port, it seems like to me it should be 
possible
for just about any process to send and receive mdns queries. Which means that 
any
app could participate in the mdns groups by itself if it wanted. The primary 
advantage
that I can see with re-using a running daemon is that the daemon can detect if 
your
process crashes and clear out the distributed DNS records. If the app takes 
care of
that by itself, then it would have to deliberately use short TTLs I think.

Interestingly enough, the protocol doesn't seem to be that complicated. A 
cross-platform
implementation written in Go is under 1000 LOC (server and client, count 
includes comments):

https://github.com/hashicorp/mdns


So an alternate approach would be to try to implement the protocol by itself.


Another option that I think would be viable is to go up in the level of 
abstraction
and try to come up with an API that allows discovery and publishing of network
services on mdns as well as UPNP at the same time. Then the windows version 
could
just re-use UPNP APIs in Windows and on the other OSes we use zeroconf.

That way there's no deployment issue at all, no windows administrator rights 
are needed
to install and run a service (apple mdns), etc.


Simon

From: development-bounces+simon.hausmann=theqtcompany@qt-project.org 
 on behalf 
of dr...@infidigm.net 
Sent: Thursday, September 10, 2015 22:29
To: Knoll Lars
Cc: Thiago Macieira; development@qt-project.org
Subject: Re: [Development] Requesting New Repository - QtZeroConf

 Apple's bonjour lib is like avahi-client in that it connects to
 mDNSResponder.  mDNSResponder, or something like it is built into OSx
 and
 iOS, but on windows comes in Apple's print services.
>
> I remember that we tried using the bonjour libs for a project inside the
> Qt company, and I don't remember that we needed any print services from
> Apple. But I could very well be wrong.

I think it used to be called mDNSResponder.

>>When I briefly tried it (2 months ago) I think it was an issue with the
>>unix style sockets.  Googling didn't show much.  If it did work, I
>> suspect
>>it would be buggy as avahi really complains when it detects multiple
>> mDNS
>>stacks running.
>
> So the problem would be to detect if a mDNS stack is already running, and
> if not start the service somehow?

Hmmm, maybe mDNSResponder (or whatever it is called now) could be built
along with QtZeroConf for windows?  Seems ugly.

> Or is there a way to make it possible to run multiple stacks on one host
> (ie. Is having only one stack a limitation in the protocol or the
> implementation)? It would be great if we could simply do this in process.

Both Apple (on windows) and avahi have a daemon for the mDNS stack.  I'm
not an mDNS expert, but I really think if it could be done in multiple
processes they would have made a way for it.  This is the warning avahi
spits out when it detects another stack

*** WARNING: Detected another IPv4 mDNS stack running on this host. This
makes mDNS unreliable and is thus not recommended. ***
*** WARNING: Detected another IPv6 mDNS stack running on this host. This
makes mDNS unreliable and is thus not recommended. ***

Jon

___
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] Documentation proposal: Remove recommended reading list of 20-year-old books

[Hausmann Simon]

I think that there is a b‎ig difference between it being easy enough to find 
reading material and us - the project - making specific recommendations for 
material that we think is of particularly high quality and perhaps also 
relevance. The latter adds real value to our documentation.

I think that if there is evidence that the currently suggested material is not 
suitable anymore, then it would be great to replace it with another 
recommendation.

Simon

  Original Message
From: Sze Howe Koh
Sent: Sunday, August 30, 2015 09:49
To: development@qt-project.org
Subject: [Development] Documentation proposal: Remove recommended reading list 
of 20-year-old books


Hi all,

http://doc.qt.io/qt-5/threads.html#recommended-reading points readers
to some books about multithreading. These books were published between
1995 and 1997, and have been well and truly superseded by newer ones.

Rather than update the list, I plan to remove it completely. I don't
think this list belongs in the Qt docs, just like how we don't
maintain a list of learning C++ books. It's easy enough these days
to find reading material for these foundational topics.

Any objections?


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] 5.5 CI having problems on tst_qmimedatabase-xml

[Hausmann Simon]

Right, in 5.5 any stale state on the file system is likely to survive. In dev 
(new ci) that problem is gone.

Simon

  Original Message
From: Thiago Macieira
Sent: Thursday, August 6, 2015 18:14
To: development@qt-project.org
Subject: Re: [Development] 5.5 CI having problems on tst_qmimedatabase-xml


On Wednesday 05 August 2015 08:51:28 Thiago Macieira wrote:
 On Wednesday 05 August 2015 07:48:42 Thiago Macieira wrote:
  Uh... that indicates that the random number generator is never seeded in
  the  tests, so QTemporaryFile / QTemporaryDir always tries to create the
  same file names.
 
  256 is exactly the number of attempts qt_mkstemp tries before giving up.
  And  tst_qmimedatabase-xml is failing exactly because the QTemporaryDir
  creation failed.

 https://codereview.qt-project.org/122839

That was it.

Before the change above, integration had failed due to tst_qmimedatabase-xml
and/or tst_qfileinfo in 6 out of the 9 previous integration failures (two
others were unrelated flaky tests).

The CI passed integration on the first attempt with the change above when it
compiled.

So we now know that C:\temp is not getting cleaned in CI machines.
--
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

Re: [Development] [Releasing] HEADS-UP: Qt 5.6 feature freeze and branching coming

[Hausmann Simon]

Hi,

We can fix this. Do we just need to install recent openssl headers (no libs) 
and provide them wi‎th configure?

Simon

From: Richard Moore
Sent: Monday, August 3, 2015 14:04
To: Heikkinen Jani
Cc: development@qt-project.org; releas...@qt-project.org
Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.6 feature freeze and 
branching coming




On 3 August 2015 at 11:55, Heikkinen Jani 
jani.heikki...@theqtcompany.commailto:jani.heikki...@theqtcompany.com wrote:

Is there something which prevents us to proceed as planned? Is new CI system 
working well enough etc? Is Qt5.git update working ok in dev?


?CI for Macos is still picking up the wrong openssl (it is using 0.9.8 at run 
time). This prevents me from integrating 
https://codereview.qt-project.org/#/c/113855/ which was requested for qtcreator.

Rich.?


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

Re: [Development] HEADS-UP: Qt 5.6 feature freeze and branching coming

[Hausmann Simon]

Hi,

Qt5.git updates in dev are not working yet. We are however working on it full 
time, trying to get it done asap.


Simon

From: Heikkinen Jani
Sent: Monday, August 3, 2015 12:55
To: development@qt-project.org
Cc: releas...@qt-project.org
Subject: [Development] HEADS-UP: Qt 5.6 feature freeze and branching coming



Hi all,


According to  Qt 5.6 schedule (http://wiki.qt.io/Qt-5.6-release) feature freeze 
 branching from 'dev' to '5.6' should happen next Monday (10.8.2015). How it 
seems, are we ready for FF after a week?


- Are all new modules in 'dev' already now? should be, see 
http://lists.qt-project.org/pipermail/development/2015-June/021809.html

- Are all mandatory new features in 'dev' now or coming in within a week?

- Are new modules  features fulfilling FF criteria, see 
http://wiki.qt.io/Qt5_feature_freeze

(* List of new features in Qt 5.6 seems to be quite short, see 
http://wiki.qt.io/New_Features_in_Qt_5.6 so it should be quite easy to do the 
FF ;) Or  the page needs some updates from feature/module owners...)


Is there something which prevents us to proceed as planned? Is new CI system 
working well enough etc? Is Qt5.git update working ok in dev?


I notice from https://codereview.qt-project.org/#/c/121238/ :

Simon Hausmann
Jul 24 5:41 AM

Patch Set 31: Code-Review-2

Updates will be different


br,

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

[Development] ios build issues

[Hausmann Simon]

‎Hi,

We're seeing odd build issues on ios in declarative since this morning. The 
forwarded email below contain more details as well as a link to the complete 
build log. Does anyone have an idea what could cause this?

There is no stale state on the virtual machine, it's created and booted from 
scratch for every build (per module).

‎Any help greatly appreciated!


Simon

  Original Message
From: Qt CI Bot (Code Review) gerrit-nore...@qt-project.org
Sent: Monday, July 13, 2015 18:47
To: Hermann Ulf
Cc: Qt Sanity Bot; Hausmann Simon
Subject: Change in qt/qtdeclarative[dev]: With -no-qml-debug, don't compile 
debug plugins and tests


Qt CI Bot has posted comments on this change.

Change subject: With -no-qml-debug, don't compile debug plugins and tests
..


Continuous Integration: FAILED module qt/qtdeclarative 
(6d664f48cc3917c242759579a65ffa91c8b17f6b) Did not compile

 rsync: link_stat /Users/qt/work/qt/qtbase/qml/. failed: No such file or 
directory (2)
 make[3]: *** [iphoneos-release] Error 65
 make[2]: *** [iphoneos] Error 2
 make[1]: *** [sub-qml-make_first] Error 2
 make: *** [sub-tools-make_first] Error 2

 Integration id: _da39a3ee5e6b4b0d3255bfef95601890afd80709_1436805065

 Build log: 
http://testresults.qt.io/logs/qt/qtdeclarative/6d664f48cc3917c242759579a65ffa91c8b17f6b/osx10.9x86_64ios10.9multiclangdeveloper-build_release_disable-tests/6dcadebe5dcdd2bc8bdf92e1434cb4d89bd5bfc2/buildlog.txt.gz

 Tested changes (refs/builds/qtci/dev/1436805064):
   
https://codereview.qt-project.org/#/q/f1d1d2cf634913f31fc91574f624f90fdad1a5f2,n,z
 With -no-qml-debug, don't compile debug plugins and tests

--
To view, visit https://codereview.qt-project.org/115776
To unsubscribe, visit https://codereview.qt-project.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ib2763ed9e6580307482b885d71c1ad1010959ef2
Gerrit-PatchSet: 1
Gerrit-Project: qt/qtdeclarative
Gerrit-Branch: dev
Gerrit-Owner: Ulf Hermann ulf.herm...@theqtcompany.com
Gerrit-Reviewer: Qt Sanity Bot qt_sanity...@qt-project.org
Gerrit-Reviewer: Simon Hausmann simon.hausm...@theqtcompany.com
Gerrit-Reviewer: Ulf Hermann ulf.herm...@theqtcompany.com
Gerrit-HasComments: No
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The dark side of QtMultimedia - strikes back

[Hausmann Simon]

Hi,

Could you  elaborate how omxplayer uses gstreamer?

I only see openmax il usage, but perhaps I am missing something.

Thanks,
Simon

From: Massimo Callegari
Sent: Saturday, July 4, 2015 22:19
To: development@qt-project.org
Reply To: Massimo Callegari
Cc: thiago.macie...@intel.com
Subject: [Development] The dark side of QtMultimedia - strikes back




On Saturday 04 July 2015 18:36:35 Massimo Callegari wrote:
 I've built Qt 5.5.0 for the Raspberry Pi 2, with gstreamer-1.0 support,
 and installed the GST OMX plugin, for hardware decoding.
 Ran the player example on EGLFS and that's the result: omxplayer works
 like a charm and QtMultimedia doesn't.
 Attached the player example log with GST_DEBUG=omx:4 on.
 It shows that QtMultimedia is actually using gstreamer + OMX.

 I don't understand if things are tested before declaring them supported.
 I quote:  A lot of work has also gone into Qt Multimedia. On Linux, we
 have now added gstreamer 1.0 support and lots of bugs have been fixed
 for the other platforms.

Can you try the same on a platform that has open source drivers? The problem
may not be in QtMultimedia at all, but with those OMX plugins or the
proprietary OpenMAX backend.



Thiago, as I said the reference player, omxplayer (on which Kodi is based), 
works perfectly with the same files, and it's an open source project:

https://github.com/huceke/omxplayer

I believe it proves that gstreamer + omx is working properly.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Fwd: (QTBUG-46655) qt5base: font license files missing

[Hausmann Simon]

Make that two votes :)


Simon

  Original Message
From: Thiago Macieira
Sent: Tuesday, June 16, 2015 22:40
To: development@qt-project.org
Subject: Re: [Development] Fwd: (QTBUG-46655) qt5base: font license files   
missing


On Tuesday 16 June 2015 12:28:51 Paul Olav Tvete wrote:
 There is still code in Qt that reads and adds QPF files if they are
 installed,  but I do not believe this is commonly used. In any case,  if
 someone needs QPF fonts they can get them from other sources than the Qt
 packages.  It sounds like a good idea to remove the font files from qtbase.

One vote for removing then. The files will get removed by EOW unless someone
has a very good reason not to.

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

Re: [Development] QVariantMap - QML

[Hausmann Simon]

Hi,

This is a result of QVariant being a value type. If you make a copy and modify 
it, then the original remains as-is. The call to setContextProperty creates a 
copy. If you want explicitly shared data between the JavaScript environment and 
C++ then I would recommend using a JavaScript object - accessed from C++ as 
QJSValue, because those are explicitly shared.

Simon

  Original Message
From: Gerhard Scheikl
Sent: Sunday, June 14, 2015 19:43
To: development@qt-project.org
Subject: [Development] QVariantMap - QML


Hi

I recently discovered some unexpected behavior when exchanging a QVariantMap
with QML code:

Here's what I'm doing on the C++ side:
my_map = json_document.toVariant();
engine.rootContext()-setContextProperty(myMap, my_map);

Then on the QML side:
myMap.asdf.name = asdf

This change is not reflected in the original map.
Obviously, accessing asdf.name returns a copy.

Is this the intended behavior?
If so, how can I ensure that the data in C++ and on the QML side is always the
same?
(use QJSValue? use a QObject hierarchy with dynamic properties?)

Thanks!

Best regards
Gerhard
___
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] Avoid overloading of 'error'

[Hausmann Simon]

Hi,

Perhaps my German is rusty, but I find on error translates well to German 
with bei/beim: Beim Auftreten eines Fehlers


Simon

  Original Message
From: Konrad Rosenbaum
Sent: Saturday, June 13, 2015 12:54
To: development@qt-project.org
Subject: Re: [Development] Avoid overloading of 'error'


On Thursday 11 June 2015 07:29:51 Smith Martin wrote:
 onError is immediately understood by all sentient beings in the universe.

So, apparently either Germans are not sentient or from outside this
universe. Might explain a lot about me...

At the very least I disagree with your use of immediately.

The phrase on error has no immediate translation in some languages - e.g.
in German it has to be translated to  nach Fehler (after error) instead
of the more literal auf Fehler (on-top-of error) or the intuitive (but
very wrong) an Fehler (at/next-to error).

On the other hand onSuccess always sounds like a toast to me (Auf den
Erfolg! - To success!) and it takes me a while to understand why a
program would believe in performing rituals for good luck.

It might be this oddity of my language, but I really hate this whole
onSomething style - it reeks of hungarian notation and seems completely
superfluous.


Either way, since I don't care much about QML/JS - do whatever you like
there. But PLEASE do not ruin it for the C++ side!


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

Re: [Development] Avoid overloading of 'error'

[Hausmann Simon]

Hi,

I agree about the inconsistency in tense, that is a good argument against 
error(),
although it is similarly unfortunate that the inconsistency in tense is more 
widespread than
assumed.

I'm not sure onErred or onErrored is any better, to be honest. I think it's 
more likely
to result in a typo than the most basic form of the word - error - instead of 
some conjugation.

In the light of that I think I'd prefer onFailed or onFailure - but I think it 
would perhaps be
a mistake to make our existing APIs more inconsistent than necessary. It seems 
like an
unfortunate choice, but I think it's better to stick to error() than to have 
some QML types
have onError and some have onFailure.

Simon


From: Alan Alpert 4163654...@gmail.com
Sent: Wednesday, June 10, 2015 18:59
To: Hausmann Simon
Cc: Thiago Macieira; development@qt-project.org
Subject: Re: [Development] Avoid overloading of 'error'

On Wed, Jun 10, 2015 at 8:14 AM, Hausmann Simon
simon.hausm...@theqtcompany.com wrote:
 Hi,

 I think renaming the getter to lastError is nice! I however do like error as 
 signal name and it looks good in qml as onError:...

I disagree that it looks good in QML as onError, almost all other
signal handlers are past tense so it is visibly odd. But it's nice to
be so short, so maybe a direct past-tense-ify of onErrored? If you
don't like using error as a verb, we can use a similar (yet shorter)
verb: onErred. Not that I really mind the exact name of the new
signal.

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

Re: [Development] Specifying module dependencies

[Hausmann Simon]

Hi,

Ok :) let's try with reduced qmake syntax (just variables, no functions). We 
can still fall back to json if it's too clumsy.

I certainly prefer qmake syntax from an editing POV because I don't need to 
quote everything like crazy :)


Simon

  Original Message
From: Thiago Macieira
Sent: Wednesday, June 10, 2015 22:21
To: development@qt-project.org
Subject: Re: [Development] Specifying module dependencies


On Wednesday 10 June 2015 19:33:37 Hausmann Simon wrote:
 Any particular reason against json, btw? Qmake can read it out of the box,
 as opposed to .ini. So the only other option I can think of is a very very
 limited qmake subset (variable.subvar = value per line and # comment).

Didn't know that, but qmake .pri file is even simpler.

http://doc.qt.io/qt-5/qmake-function-reference.html#fromfile-filename-variablename
--
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

Re: [Development] Specifying module dependencies

[Hausmann Simon]

Hi,

Why do we need to pin anything beyond the regular git submodules handling of 
qt5.git (where the information is in the tree object)?

In think we should have a configuration file in each module listing required 
and optional dependencies. Qt.pro can interpret that file and so can the CI 
system. To the CI system the optional dependencies are also required ones.

Simon

  Original Message
From: Thiago Macieira
Sent: Wednesday, June 10, 2015 18:44
To: development@qt-project.org
Subject: Re: [Development] Specifying module dependencies


On Wednesday 10 June 2015 18:30:34 Frederik Gladhorn wrote:
 4) qt5.git
 in qt.pro we list all modules again, with deps:
 addModule(qtdeclarative, qtbase, qtsvg qtxmlpatterns)
 (amusingly this is not even correct, qtsvg is not a dependency of
 qtdeclarative any more)

That's an optional dependency.

Note that the qt.pro file allows us to do the full build, so unless we teach
qmake to parse any other sources, we'll need to keep it.

That said, I don't think qt.pro should keep SHA-1 of pinned revisions, so
we'll need something else anyway.
--
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

Re: [Development] Avoid overloading of 'error'

[Hausmann Simon]

Hi,

I think renaming the getter to lastError is nice! I however do like error as 
signal name and it looks good in qml as onError:...


Simon

  Original Message
From: Thiago Macieira
Sent: Wednesday, June 10, 2015 16:35
To: development@qt-project.org
Subject: Re: [Development] Avoid overloading of 'error'


On Wednesday 10 June 2015 14:20:51 Koehne Kai wrote:
 Hi,

 I'm currently converting a codebase from old-style connects to new-style
 ones. Thanks to Qt Creator's refactoring support this is actually quite
 easy ... it gets ugly though when either the signal or slot method name is
 overloaded, and you have to write nice code like

   connect(process, static_castvoid
 (QProcess::*)(QProcess::ProcessError)(QProcess::Error), this,
 MyClass::processError);

 There can be done little to avoid this in general, but actually the
 overloading of 'error' stands out: E.g. QProcess, QNetworkReply,
 QNetworkSession, QAbstractSocket all feature both an error() signal and an
 error() accessor.

 Ideas how to mitigate this:

 1. We could deprecate the error() signal, and add a failed() signal (still
 in Qt 5).
 2. We could rename error() accessor to lastError() in Qt 6.
 3. your idea goes here

 Comments?

I like both 1 and 2.

error isn't a verb in the past, so it's a bad name for a signal. failed or
another construct with a verb in the past is better. Even errorEncountered
would be fine.

Changing error to lastError for the getter also makes sense, since it
clearly indicates that it's the last error that happened. If no error
happened, then this function may or may not return anything intetersting. But
if you rename that function, you should also rename errorString to
lastErrorString.

So I recommend we begin the shift now in 5.6 and deprecate the old methods, to
be removed in 6.0.

As for the implementation, please connect one signal to the other, so we don't
need to duplicate the emissions. But note that there will be an delivery order
problem: all slots connected to one signal will be received before all slots
connected to the other. Unless Olivier adds a signal alias feature to moc :-)

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

Re: [Development] New Module for Serial Buses

[Hausmann Simon]

Good point :)

I was under the assumption that the concepts are too different, but if they 
aren't then maybe a joint module would make sense.

Simon

  Original Message
From: Thiago Macieira
Sent: Tuesday, May 26, 2015 17:06
To: development@qt-project.org
Subject: Re: [Development] New Module for Serial Buses


On Tuesday 26 May 2015 15:47:04 Simon Hausmann wrote:
 My first suggestion is to give the module a better name. Bus is an
 overloaded term with many meanings and it is IMO too close to our DBus
 module. Why not go with what your first sentence in the email used:

 We’d like to create a new Qt module for serial buses

 Call it the Qt module for accessing serial buses, QtSerialBus :)

Agreed, but why can't this be an extension of QtSerialPort?

QtSerialPort is not about just 9-pin connectors and UART, since it does
support serial over USB too.
--
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] Binary compatibility for qtestlib

[Hausmann Simon]

‎Hi,

Lately development of testlib picked up again and I've been wondering: the api 
consists of a fair amount of macros that call internal functions. It would be 
convenient to change the signature of those while maintaining source 
compatibility, however it would naturally break the ABI.

On the one hand testlib is certainly not relevant for app deployment, otoh it 
is part of binary Qt distributions.

So do we maintain binary compatibility for testlib‎?


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

Re: [Development] Binary compatibility for qtestlib

[Hausmann Simon]

Okay, thanks - that sounds good to me. The change in particular that I was 
thinking of is

‎https://codereview.qt-project.org/#/c/112690/

It could be done without breaking BC but it's easier if we can :)


Simon

From: Jason McDonald
Sent: Wednesday, May 20, 2015 13:27
To: Hausmann Simon
Cc: development@qt-project.org
Subject: Re: [Development] Binary compatibility for qtestlib


On Wed, May 20, 2015 at 9:16 PM, Hausmann Simon 
simon.hausm...@theqtcompany.commailto:simon.hausm...@theqtcompany.com wrote:
‎Hi,

Lately development of testlib picked up again and I've been wondering: the api 
consists of a fair amount of macros that call internal functions. It would be 
convenient to change the signature of those while maintaining source 
compatibility, however it would naturally break the ABI.

On the one hand testlib is certainly not relevant for app deployment, otoh it 
is part of binary Qt distributions.

So do we maintain binary compatibility for testlib‎?


In the past we haven't tried to maintain binary compatibility for testlib, on 
the premise that tests generally don't get deployed to production systems and 
that binary compatibility can sometimes be an impediment to innovation.  This 
is a decision made long, long ago (it was already well established when I 
joined Trolltech in 2005).  If the premise is no longer valid, we can revisit 
it.

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

Re: [Development] Future of Qt Quick 1 in Qt 5

[Hausmann Simon]

Hi,

Compilation wise I agree, it's low effort. But the situation is different in 
Jira IMO.


Simon

  Original Message
From: Thiago Macieira
Sent: Friday, May 8, 2015 17:37
To: development@qt-project.org
Subject: Re: [Development] Future of Qt Quick 1 in Qt 5


On Friday 08 May 2015 14:39:38 Frederik Gladhorn wrote:
 Since KDE moved over the Plasma desktop to Qt Quick 2 (on which I'm writing
 this email), I feel confident that the time has come to move everyone over.
 For the no opengl acceleration use case, we provide the Qt Quick 2D Renderer
 as backend.
 (https://blog.qt.io/blog/2015/01/22/introducing-the-qt-quick-2d-renderer/)

 In short, is there any reason not to remove Qt Quick 1 from Qt 5.6?

Do we need to do anything at all? How much effort is keeping Qt Quick 1
compiling these days? We're not doing anything besides that, are we?
--
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

Re: [Development] Future of Qt Quick 1 in Qt 5

[Hausmann Simon]

Hi,

If the public API would allow you to implement what the folks at KDAB did at 
http://www.kdab.com/creating-pdf-qtquick-2-scene-slideviewer/ ‎, would that 
help your use case?


Simon

  Original Message
From: André Somers
Sent: Friday, May 8, 2015 14:45
To: development@qt-project.org
Subject: Re: [Development] Future of Qt Quick 1 in Qt 5


Frederik Gladhorn schreef op 8-5-2015 om 14:39:
 Hi,

 I think the dust has settled quite a bit and the declarative module is
 becoming better by the day. We have seen it evolve and the new Java Script
 engine is running smoothly (and actively worked on, sadly it will have one
 known crasher in the 5.5 beta release which has been fixed in the mean time,
 so it should be good for everyone with the 5.5 RC).

 One question is if there is any reason to maintain Qt Quick 1 in the future.
 It adds burden on maintenance, needs to be patched regularly to move with
 changes in qtbase etc.

 Since KDE moved over the Plasma desktop to Qt Quick 2 (on which I'm writing
 this email), I feel confident that the time has come to move everyone over.
 For the no opengl acceleration use case, we provide the Qt Quick 2D Renderer
 as backend. 
 (https://blog.qt.io/blog/2015/01/22/introducing-the-qt-quick-2d-renderer/)

 In short, is there any reason not to remove Qt Quick 1 from Qt 5.6?

Yes, there are reasons. Qt Quick 1 is the entrancepoint to moving your
Qt 4 Application to Qt 5. In our case, we are using Quick 1 exactly
because it uses QPainter based rendering and not openGL. We are
rendering the scenes on a printer. Using Quick 1, that is easy. Using
Quick 2, that is basicaly not doable without either reimplementing the
elements you want to render or doing other major work.

So please, no. Don't remove Quick 1 before Qt 6.

André

___
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] RFC: QtQuick. Custom keys support proposal.

[Hausmann Simon]

Hi,

Let me see if I understand this correctly:

1. The Keys attached object supports _any_ key through the generic pressed and 
released signals and the event parameter that comes with them.
2. There are a couple of convenience signals for commonly used keys.

You would like to add private API to allow for custom convenience signals to be 
added?

I'll be honest: I don't like the idea of adding private API that isn't needed 
internally.

I think the existing code could be be cleaned up a little bit and with a little 
bit of trickery I suppose any Qt::Key could have a convenience signal, of we 
create a dynamic meta object at library startup time. However I'm not sure how 
is worth the cost, unless we find a way to do it lazily.


Simon

From: Dmitry Volosnykh
Sent: Friday, May 1, 2015 02:55
To: development@qt-project.org
Subject: [Development] RFC: QtQuick. Custom keys support proposal.


There are some cases when non-standard keys should be handled. Remote control 
units with custom key codes are the primary example. Existing Keys QML type 
provides a handy means of processing specific key events only for a small 
subset of Qt::Key enum, and that is true only for presses, not release events.

Here I suggest patch that allows to extend the default set of key codes. It 
heavily depends on newly added Q_ENUM macro which allows to completely drop 
then need to keep internal table sigMap up to date. Unfortunately, there seems 
to be no way to generate signal so that all the keys are provided with specific 
handlers. So, we will still have to add them manually. Getting the full list of 
signals should be a matter of playing with regular expressions, though.

Another plus is that now implementations of keyPressed/Released handlers of 
QQuickKeysAttached are merged into one auxiliary private function.

Adding new set of supported keys is a matter of inheriting QQuickKeysAttached 
with Q_ENUM of custom keys declared which should be registered with a protected 
member function provided for this purpose. Next, a set of wanted specific 
signal should be listed under 'signals' section of the class.

As for drawbacks, in order to let users inherit from QQuickKeysAttached we need 
to mark it with Q_QUICK_PRIVATE_EXPORT -- this will break ABI as far as I 
understand. QQuickKeyNavigationAttached is marked this way, already. So there 
seems to be no contradiction. And, of course, it is required to list private 
modules as your project dependencies.

Unfortunately, should have user chosen to use custom key handlers there is no 
way to disable default Keys QML type. Even that it is discouraged to mix both 
classes, this should not be a big problem which could be addressed via 
documentation on this topic.

Since newly registered set of keys is searched for key in question prior to the 
default keys from Qt namespace we can override default signals in 
QQuickKeysAttached class thus effectively renaming a key. This feature may come 
handy in some cases when RCU has domain specific buttons.

Diff of the patch and example of CustomKeys QML attached type may be viewed 
here: https://gist.github.com/dvolosnykh/65819bca1693b0e82058

In case this change is welcomed, what branch should I target?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 4.8.7 release candidate available

[Hausmann Simon]

IMO this isn't a Qt bug, I commented on Jira.

I suspect another app isn't implementing the protocol directly, but if we 
really want to protect ourselves then we should probably ditch the entire 
session management code from Qt 4 (it's gone in Qt 5, too :)

Simon

  Original Message
From: Matthew Woehlke
Sent: Thursday, April 30, 2015 16:49
To: development@qt-project.org
Cc: releas...@qt-project.org
Subject: Re: [Development] Qt 4.8.7 release candidate available


On 2015-04-30 09:17, Salovaara Akseli wrote:
 If blocker issues for Qt 4.8.7 release (i.e. new regression) are found please 
 report those to bugreports.qt.io and raise issue also (with bug id) on 
 releasing mailing list.

Is there no hope for getting https://bugreports.qt.io/browse/QTBUG-38599
fixed? This is a really nasty bug that cripples all (newly launched) Qt
applications when it happens. It's listed as P1 and has been reproduced,
but I don't know enough about the bowels of QSessionManager to suggest a
solution.

KDE4 is likely to be around for a while yet (e.g. LTS distros) and it
would be good if this can be fixed.

--
Matthew

___
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] Qt 4.8.7 release candidate available

[Hausmann Simon]

Sure, with the removal I only meant the xsm implementation :)


Simon

  Original Message
From: Samuel Gaist
Sent: Thursday, April 30, 2015 23:36
To: Hausmann Simon
Cc: Matthew Woehlke; development@qt-project.org; releas...@qt-project.org
Subject: Re: [Development] Qt 4.8.7 release candidate available


Hi,

It's back since 5.2 with an implementation for OS X waiting for Qt 5 (also for 
Qt 4 but since it's considered a new feature it won't get in)

Samuel

On 30 avr. 2015, at 19:37, Hausmann Simon simon.hausm...@theqtcompany.com 
wrote:

 IMO this isn't a Qt bug, I commented on Jira.

 I suspect another app isn't implementing the protocol directly, but if we 
 really want to protect ourselves then we should probably ditch the entire 
 session management code from Qt 4 (it's gone in Qt 5, too :)

 Simon

  Original Message
 From: Matthew Woehlke
 Sent: Thursday, April 30, 2015 16:49
 To: development@qt-project.org
 Cc: releas...@qt-project.org
 Subject: Re: [Development] Qt 4.8.7 release candidate available


 On 2015-04-30 09:17, Salovaara Akseli wrote:
 If blocker issues for Qt 4.8.7 release (i.e. new regression) are found 
 please report those to bugreports.qt.io and raise issue also (with bug id) 
 on releasing mailing list.

 Is there no hope for getting https://bugreports.qt.io/browse/QTBUG-38599
 fixed? This is a really nasty bug that cripples all (newly launched) Qt
 applications when it happens. It's listed as P1 and has been reproduced,
 but I don't know enough about the bowels of QSessionManager to suggest a
 solution.

 KDE4 is likely to be around for a while yet (e.g. LTS distros) and it
 would be good if this can be fixed.

 --
 Matthew

 ___
 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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Are SiCs through #include cleanups considered acceptable?

[Hausmann Simon]

I think that would be a good compromise.


Simon

  Original Message
From: Olivier Goffart
Sent: Friday, April 10, 2015 15:56
To: development@qt-project.org
Cc: Hausmann Simon
Subject: Re: [Development] Are SiCs through #include cleanups considered 
acceptable?


On Friday 10. April 2015 13:38:55 Simon Hausmann wrote:
 Yes, over time we will accumulate cruft. We must indeed be very careful what
 we put into public header files.

A possibility would be to put them in a

#if Q_DEPRECATED_SINCE(5,5)
#include foobar
#endif

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

Re: [Development] Why are qtbase integrations taking so long?

[Hausmann Simon]

Hi,

I believe what we are seeing is caused by instability in the network that 
connects the Jenkins service with the Jenkins slave machines. Occasionally 
network connectivity between the slaves and the master is lost, causing the 
running build as a whole to abort - all other still running builds are aborted 
and the results from builds that had already finished are discarded. In an 
attempt to recover, a whole new integration with builds for all configurations 
is started.

We have observed that this scenario repeats itself several times, causing 
overall integration of many hours.

As part of the work on the new CI system, we have observed similar network 
connectivity related symptoms. We are treating them more gracefully by not 
discarding otherwise successful results. Nevertheless it is a major annoyance.

Based on rumors and observation of symptoms it is a theory ‎of Frederik and I 
that there is a firewall service centrally installed in this virtual network. 
It shows symptoms of connection tracking and - more importantly - signs of 
being able to handle only an insufficient amount of traffic or connections. 
Beyond that limit, connection attempts time out and existing connections become 
spotty.

I would like to get to the bottom of this at some point, because it severely 
affects the efficiency of the current ci system as well.

Tony, do you happen to have any more details about this?

I'll see about filing a ticket with IT next week unless we conclude anything 
different.

Simon

  Original Message
From: Thiago Macieira
Sent: Friday, April 3, 2015 07:11
To: development@qt-project.org
Subject: [Development] Why are qtbase integrations taking so long?


qtbase integrations used to take around 3 hours as recently as two weeks ago.

In the past week, I've caught several integrations lasting more than 6 hours.
The one currently running is integrating a single commit and has been running
for 6h30. I've seen one for 12 hours.

Is this a timeout not caught by the coordinator?

http://testresults.qt.io/ci/status/ says that it is in state monitor-jenkins-
build and build_attempt: 6. For attempt 5, the only stage not to be at
SUCCESS was linux-g++_developer-build_qtnamespace_qtlibinfix_RHEL65_x64. The
same for attempts 3 and 4.
--
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

Re: [Development] bug: qmake ignores CMAKE_CC and CMAKE_CXX while building Qt 5.3.2???

[Hausmann Simon]

‎Hi,

Should bootstrap really use the mkspec compiler? I'm not sure that's always the 
right thing. Bootstrap should just use _any_ compiler.

What is the underlying problem that you are trying to solve?


Simon

  Original Message
From: René J.V. Bertin
Sent: Sunday, March 22, 2015 21:24
To: 'inter...@qt-project.org'
Cc: development@qt-project.org
Subject: Re: [Development] bug: qmake ignores CMAKE_CC and CMAKE_CXX while  
building Qt 5.3.2???


On Sunday March 22 2015 19:01:55 René J.V. Bertin wrote:

I found the immediate culprit: build/qtbase/qmake/.qmake.stash
This file sets QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_CC etc. to values that are 
completely unrelated to what's specified in the mkspec file. I think that also 
explains another issue I've had that is also due to the bootstrap qmake 
ignoring the information from the specified mkspec file.

I have not yet figured out where the .qmake.stash file is generated though 
(pbuilder_pbx.cpp?) but fortunately it appears to be possible to pre-generate a 
version with the appropriate values before calling configure.

R.

 Hi,

 How come that the bootstrap qmake ignores the mkspec's CMAKE_CC and 
 CMAKE_CXX? I see `/usr/bin/clang++` and `/Developer/usr/bin/clang` (for C and 
 ObjC++) when configure runs the config.test tests, and this causes problems 
 because I need to use the clang compiler specified in my mkspec.

 NB: build/qtbase/mkspecs/qmodule.pri does contain the correct compiler paths!
 NB2: the bootstrap qmake in fact ignore the mkspec completely: introducing a 
 syntax error in it doesn't raise an error.

 I'm OK with patching the qmake code, but will need to know where ...

 Thanks,
 R.

___
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] bug: qmake ignores CMAKE_CC and CMAKE_CXX while building Qt 5.3.2???

[Hausmann Simon]

Hi,

I think we are talking about the compiler that is used to build qmake here, not 
the tools. I agree that -platform should be used for the tools, but for qmake 
itself IMO any compiler should suffice and not require parsing of the platform 
qmake spec (yes, we have some awk hacks in configure to parse the mkspec 
without qmake, but those are hacks :)

Simon

  Original Message
From: Thiago Macieira
Sent: Monday, March 23, 2015 05:39
To: development@qt-project.org
Subject: Re: [Development] bug: qmake ignores CMAKE_CC and CMAKE_CXXwhile   
building Qt 5.3.2???


On Sunday 22 March 2015 20:33:53 Hausmann Simon wrote:
 Should bootstrap really use the mkspec compiler?

Yes, that's what the -platform option is for. The target compiler is specified
by -xplatform.
--
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

Re: [Development] Code Coverage Statistics for QtBase

[Hausmann Simon]

Why can they be ignored? When the users run Qt applications that code is 
executed, so coverage is important IMO.

However if the added code is from build tools (Code generators) then maybe it's 
not so critical, as long as the generated code is covered.

That said, the results look incomplete to me. Qxc‎bwindow.cpp surely has 
non-zero coverage when running tests on X11.

Simon

From: Paeglis Gatis
Sent: Thursday, February 19, 2015 23:45
To: Sébastien Fricker; development
Subject: Re: [Development] Code Coverage Statistics for QtBase



Many of those files are from 3rdparty code, the ones I recognize are from 
/qtbase/src/3rdparty/xkbcommon, those I think can

be ignored when thinking from code coverage point of view.



From: development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
development-bounces+gatis.paeglis=theqtcompany@qt-project.org on behalf 
of Sébastien Fricker fric...@froglogic.com
Sent: Thursday, February 19, 2015 3:51 PM
To: development
Subject: [Development] Code Coverage Statistics for QtBase

Hi,
According http://download.froglogic.com/public/qt5-squishcoco-report/ there is 
a big decrease of the code coverage between Qt5/dev and Qt5.4.
The code coverage from QtBase is decreasing from 56% to 42%.

The first reason of that, is that approximately 100 new files get added into 
the project and the code coverage of this set is near to zero (see the HTML 
attachment and the table below).
This new uncovered files are responsible of a lost of the code coverage of 3% 
approximately.
Question: are these files not tested through an unit test? If they are tested, 
I need to look why they are not taken in account by the code coverage analysis.


The main difference are caused by the code coverage of the unit tests itself.
The number of unit tests did not decrease, but the code coverage of the tests 
with the status Unknown decrease from 13% (from 43% to 30%) and this explain 
the rest of the code coverage lost.
These tests are in fact the code coverage of the code which is running before 
and after a unit test (setup the GUI, common initializations executed before 
main(), exit code, ...).
Question: are they changes between Qt5.4 and Qt5/dev in QTestLib (in the unit 
tests or in QtBase) which could explain this?

Regards,
Sébastien

List of new files:
Source  Coverage (1 means 100%)

action.c0
ast-build.c 0
atom.c  0
compat.c0
context-priv.c  0
context.c   0
expr.c  0
include.c   0
keycodes.c  0
keymap-dump.c   0
keymap-priv.c   0
keymap.c0
keysym-utf.c0
keysym.c0
keywords.c  0
parser.c0
parser.y0
qbasicfontdatabase.cpp  0
qdbusmenuadaptor.cpp0
qdbusmenuconnection.cpp 0
qdbusmenutypes.cpp  0
qdbusplatformmenu.cpp   0
qdbustrayicon.cpp   0
qdbustraytypes.cpp  0
qdevicediscovery_udev.cpp   0
qeglconvenience.cpp 0
qeglfscontext.cpp   0
qeglfsdeviceintegration.cpp 0
qeglfshooks.cpp 0
qeglfsintegration.cpp   0
qeglfsoffscreenwindow.cpp   0
qeglfsscreen.cpp0
qeglfswindow.cpp0
qeglpbuffer.cpp 0
qeglplatformcontext.cpp 0
qeglplatformcursor.cpp  0
qeglplatformintegration.cpp 0
qeglplatformscreen.cpp  0
qeglplatformwindow.cpp  0
qevdevkeyboardhandler.cpp   0
qevdevkeyboardmanager.cpp   0
qevdevmousehandler.cpp  0
qevdevmousemanager.cpp  0
qevdevtablet.cpp0
qevdevtouch.cpp 0
qeventdispatcher_glib.cpp   0
qfbbackingstore.cpp 0
qfbcursor.cpp   0
qfbscreen.cpp   0
qfbvthandler.cpp0
qfbwindow.cpp   0
qfontconfigdatabase.cpp 0
qfontengine_ft.cpp  0
qfontenginemultifontconfig.cpp  0
qgenericunixeventdispatcher.cpp 0
qgenericunixservices.cpp0
qgenericunixthemes.cpp  0
qglxconvenience.cpp 0
qinputdevicemanager.cpp 0
qopenglcompositor.cpp   0
qopenglcompositorbackingstore.cpp   0
qopenglfunctions_4_4_compatibility.cpp  0
qopenglfunctions_4_4_core.cpp   0
qopenglfunctions_4_5_compatibility.cpp  0
qopenglfunctions_4_5_core.cpp   0
qplatformgraphicsbuffer.cpp 0
qplatformgraphicsbufferhelper.cpp   0
qsslellipticcurve.cpp   0
qsslpresharedkeyauthenticator.cpp   0
qstatusnotifieritemadaptor.cpp  0
qunixeventdispatcher.cpp0
qxcbbackingstore.cpp0
qxcbclipboard.cpp   0
qxcbconnection.cpp  0
qxcbconnection_xi2.cpp  0
qxcbcursor.cpp  0
qxcbdrag.cpp0
qxcbglintegration.cpp   0
qxcbglintegrationfactory.cpp0
qxcbimage.cpp   0
qxcbintegration.cpp 0
qxcbkeyboard.cpp0
qxcbmime.cpp0
qxcbnativeinterface.cpp 0
qxcbnativeinterfacehandler.cpp  0
qxcbscreen.cpp  0
qxcbsessionmanager.cpp  0
qxcbsystemtraytracker.cpp   0
qxcbwindow.cpp  0
qxcbwmsupport.cpp   0
qxcbxsettings.cpp   0
qxdgnotificationproxy.cpp   0
qxlibeglintegration.cpp 0
rules.c 0
scanner.c   0
state.c 0
symbols.c   0
text.c  0
types.c 0
utf8.c  0
utils.c 0
vmod.c  0
xkb-compat.c0
xkb-keymap.c0
xkbcomp.c   0
forkfd.c0,2841726619
qsharedmemory_systemv.cpp

Re: [Development] Proposed syntax change for pragmas and imports in QtQuick .js files

[Hausmann Simon]

Hi,

We need a syntax that allows determining the dependencies unambiguously from 
the AST. ES 6 module import syntax allows for that, Qt.import doesn't 
unfortunately.

Simon

From: Chris Adams
Sent: Tuesday, February 17, 2015 09:31
To: Mike Verdone
Cc: development@qt-project.org
Subject: Re: [Development] Proposed syntax change for pragmas and imports in 
QtQuick .js files


Hi,

On Mon, Feb 16, 2015 at 11:34 PM, Mike Verdone 
mike.verd...@ableton.commailto:mike.verd...@ableton.com wrote:
Hi all,

This is my first post to the Qt dev list. Apologies if I say something
dumb.

I'd like to propose some changes to the meta syntax in QtQuick .js
files. I propose this in order to support JavaScript tools such as linters
and transpilers. Specifically I'd like to change:

.pragma singleton

to

pragma singleton;

and

.import foo.js as Foo

to

var Foo = Qt.import(foo.js);

This one is a bit tricky, as that sort of statement looks like it could be 
placed anywhere within a given imperative scope, but for .js files in QML we'd 
probably require that such such import only occur at the start of the file 
(otherwise such a statement might require invalidation of the evaluation scope, 
recompilation of the unit, triggering of all bindings which reference the 
import, and so on).

On the other hand, it would have one major advantage: being able to inject 
symbols into the initial evaluation scope of the import at import time, via: 
var Foo = Qt.import(foo.js, { Window: someObj, Image: function() { ... } 
}); etc, which is something which cannot be done right now, and, in my opinion, 
is the biggest barrier to adding support for the vast majority of 3rd party JS 
libraries in QML.

We really should add support for pragma threaded again, too.

Cheers,
Chris.




In the first example, the pragma is changed to something that standard
JavaScript can parse and ignore. It matches nicely with the ECMAScript
use strict; syntax.

For the import statement, I could also apply the same string-like syntax
trick, but building an actual Qt.import function allows programs to detect
that the new variable is available in the global scope.

The . meta syntax should be preserved for backwards compatibility.

Making these changes opens QtQuick's JS to a whole new world of JavaScript
libraries and tools. For instance, .js files can be validated with ESLint
for correctness. Tools like the 6to5 allow one to write ES6 JavaScript
right now, and transpile it to QtQuick-compatible ES5 JavaScript.

I'm not expecting any of you busy Qt developers to take on this work. I'm
just curious if these changes might be accepted if I manage to implement
them, or if you have other ideas for how to enable tools like linters to
process QtQuick JS.

Thanks,

Mike.

-
Mike Verdone
Ableton AG
Schoenhauser Allee 6-7
10119 Berlin, Germany

Vorstand: Gerhard Behles, Jan Bohl, Bernd Roggendorf
Aufsichtsrat: Uwe Struck (Vorsitzender)
Sitz: Amtsgericht Berlin-Charlottenburg HRB 72838
Umsatzsteueridentifikationsnummer: DE204128565

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


www.qinetic.com.auhttp://www.qinetic.com.au - Qt And QML User Experience 
Specialists

On Mon, Feb 16, 2015 at 11:34 PM, Mike Verdone 
mike.verd...@ableton.commailto:mike.verd...@ableton.com wrote:
Hi all,

This is my first post to the Qt dev list. Apologies if I say something
dumb.

I'd like to propose some changes to the meta syntax in QtQuick .js
files. I propose this in order to support JavaScript tools such as linters
and transpilers. Specifically I'd like to change:

.pragma singleton

to

pragma singleton;

and

.import foo.js as Foo

to

var Foo = Qt.import(foo.js);


In the first example, the pragma is changed to something that standard
JavaScript can parse and ignore. It matches nicely with the ECMAScript
use strict; syntax.

For the import statement, I could also apply the same string-like syntax
trick, but building an actual Qt.import function allows programs to detect
that the new variable is available in the global scope.

The . meta syntax should be preserved for backwards compatibility.

Making these changes opens QtQuick's JS to a whole new world of JavaScript
libraries and tools. For instance, .js files can be validated with ESLint
for correctness. Tools like the 6to5 allow one to write ES6 JavaScript
right now, and transpile it to QtQuick-compatible ES5 JavaScript.

I'm not expecting any of you busy Qt developers to take on this work. I'm
just curious if these changes might be accepted if I manage to implement
them, or if you have other ideas for how to enable tools like linters to
process QtQuick JS.

Thanks,

Mike.

-
Mike Verdone
Ableton AG
Schoenhauser Allee 6-7
10119 Berlin, Germany

Vorstand: Gerhard Behles, Jan Bohl, Bernd Roggendorf
Aufsichtsrat: Uwe Struck (Vorsitzender)
Sitz: Amtsgericht Berlin-Charlottenburg HRB 72838

Re: [Development] Proposed syntax change for pragmas and imports in QtQuick .js files

[Hausmann Simon]

Hi,

In principle I think that's a very good direction. However .pragma singleton 
does not exist for .js files :). Qt.import as a substitute for .pragma import 
would be great. In an ideal world we'd support es6 modules.


Simon

  Original Message
From: Mike Verdone
Sent: Monday, February 16, 2015 21:34
To: development@qt-project.org
Subject: [Development] Proposed syntax change for pragmas and imports in
QtQuick .js files


Hi all,

This is my first post to the Qt dev list. Apologies if I say something
dumb.

I’d like to propose some changes to the “meta” syntax in QtQuick .js
files. I propose this in order to support JavaScript tools such as linters
and “transpilers”. Specifically I’d like to change:

.pragma singleton

to

“pragma singleton”;

and

.import “foo.js” as Foo

to

var Foo = Qt.import(“foo.js”);


In the first example, the pragma is changed to something that standard
JavaScript can parse and ignore. It matches nicely with the ECMAScript
“use strict”; syntax.

For the import statement, I could also apply the same string-like syntax
trick, but building an actual Qt.import function allows programs to detect
that the new variable is available in the global scope.

The “.” meta syntax should be preserved for backwards compatibility.

Making these changes opens QtQuick’s JS to a whole new world of JavaScript
libraries and tools. For instance, .js files can be validated with ESLint
for correctness. Tools like the 6to5 allow one to write ES6 JavaScript
right now, and transpile it to QtQuick-compatible ES5 JavaScript.

I’m not expecting any of you busy Qt developers to take on this work. I’m
just curious if these changes might be accepted if I manage to implement
them, or if you have other ideas for how to enable tools like linters to
process QtQuick JS.

Thanks,

Mike.

—
Mike Verdone
Ableton AG
Schoenhauser Allee 6-7
10119 Berlin, Germany

Vorstand: Gerhard Behles, Jan Bohl, Bernd Roggendorf
Aufsichtsrat: Uwe Struck (Vorsitzender)
Sitz: Amtsgericht Berlin-Charlottenburg HRB 72838
Umsatzsteueridentifikationsnummer: DE204128565

___
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] why is QJSEngine not modifying metaObject

[Hausmann Simon]

Hi,

Kind of :) It works on a type level. So a new type is defined with new methods 
and a new meta object is defined. But it doesn't use a mechanism where a new 
meta object is created each time a method is added.

If we move the current engine over to generate meta objects from internal 
classes then perhaps we could create the meta objects on demand and batch them. 
That would make the example at hand work.

Of course this could also be implemented by brute force, but I'm not sure it is 
worth it.

Simon

  Original Message
From: Thiago Macieira
Sent: Wednesday, February 11, 2015 08:35
To: development@qt-project.org
Subject: Re: [Development] why is QJSEngine not modifying metaObject


On Wednesday 11 February 2015 07:11:26 Hausmann Simon wrote:
 Hi,

 The short answer to your question is that the meta object system isn't
 really designed for this. In theory this could be implemented but it would
 come at a high cost for something that rarely happens. The qml engine
 supports this, but in qml this happens at type compilation time, not fully
 dynamic.

Wasn't this how QML1 worked?
--
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

Re: [Development] QtDeclarative CI failures on Windows

[Hausmann Simon]

Hi,

Friedemann made a fix: ‎https://codereview.qt-project.org/#/c/105750/

Simon

  Original Message
From: Robin Burchell
Sent: Tuesday, February 10, 2015 21:15
To: development@qt-project.org
Subject: [Development] QtDeclarative CI failures on Windows


Can someone with Windows please take a look at unblocking
qtdeclarative/dev, or give an update if you know what's going on? It's
been failing since February 5[1](!).

The failures are consistent. See some examples: [2][3][4].

In light of it being just under a week since the last successful
integration, I think it might make sense to extend the branching
period a bit longer for qtdeclarative at least. I have a few changes I
would like to see in before branching (some of which require updates,
I've admittedly been a bit slack on that):

https://codereview.qt-project.org/97273 (needs update, I was waiting
to add QQuickParticleData and QQuickTextPrivate to it, below, but they
have not yet integrated)
https://codereview.qt-project.org/103862 (minimal risk)
https://codereview.qt-project.org/105663 (improves size for the common
case of Text)
https://codereview.qt-project.org/105665 (improves size for the common
case of Text)

Everything else on my dash I'm happy to wait for 5.6.

Robin

[1]: http://lists.qt-project.org/pipermail/ci-reports/2015-February/035268.html
[2]: http://lists.qt-project.org/pipermail/ci-reports/2015-February/035567.html
[3]: http://lists.qt-project.org/pipermail/ci-reports/2015-February/035559.html
[4]: http://lists.qt-project.org/pipermail/ci-reports/2015-February/035579.html
___
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] why is QJSEngine not modifying metaObject

[Hausmann Simon]

Hi,

The short answer to your question is that the meta object system isn't really 
designed for this. In theory this could be implemented but it would come at a 
high cost for something that rarely happens. The qml engine supports this, but 
in qml this happens at type compilation time, not fully dynamic.


Simon

  Original Message
From: Rees, Kevron
Sent: Wednesday, February 11, 2015 00:52
To: development@qt-project.org
Subject: [Development] why is QJSEngine not modifying metaObject


test:

class Test : public QObject {
Q_OBJECT
public slots:
  QObject* createQObject() { return new QObject(); }
  void checkQObjectMetaObject(QObject* obj)
  {
for(int i=0; i  object-metaObject()-methodCount(); i++)
{
  qDebug()  introspecting:   object-metaObject()-method(i).name();
}
  }
};

QJSEngine engine;
QJSValue value = engine.newQObject(new Test());
engine.globalObject().setProperty(test, value);

QString js = 
var coolObject = test.createQObject(); \
coolObject.jsFunc = function() { return true; }
test.checkQObjectMetaObject(coolObject);

engine.evaluate(js);

results:

jsFunc is not listed as a QMetaMethod.  Why?

-Kevron
___
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] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Hausmann Simon]

I suppose that it is absolutely unlikely that we are going to find a consensus 
on what is purely an aesthetic issue.

I for one am entirely with André and I do not like UPPERCASE macros in my face 
unless I can avoid them. It's aesthetics and I suppose there is little that 
will change that.

As approver I will approve code that uses Q_NULLPTR but I expect others 
reviewing my code to respect my preference to use 0 until we can use nullptr.


Simon


  Original Message
From: Marc Mutz
Sent: Wednesday, February 11, 2015 00:19
To: André Pönitz
Cc: development@qt-project.org
Subject: Re: [Development] Upgrading the sources to C++11 keywords  
(Q_NULLPTR, etc.)


On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
 On Tue, Feb 10, 2015 at 07:53:23PM +0100, Marc Mutz wrote:
  On Tuesday 10 February 2015 17:28:09 Thiago Macieira wrote:
   On Tuesday 10 February 2015 15:34:45 Knoll Lars wrote:
+1. I’m ok with us making sure our headers are clean against warnings
(if possible), but I don’t see a real need to enforce it’s usage in
implementations.
  
   Fair enough. But how about allowing people to change zeroes to
   Q_NULLPTR?
 
  Even more importantly: what about new code?

 Can't you simply wait until 'nullptr' is available?

No.

For a simple reason: using nullptr (Q_ or not) is more expressive than 0. And
why would i want to throw away information I already have?

 Do you really *need*
 to use macros instead of the core language?

Do you use 'emit' when you emit signals? Lemme tell you: It's a pesky macro
and it just adds line noise.

So tell me.. where's the difference?

Thanks,
Marc

--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
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] Deprecating modules with 5.5

[Hausmann Simon]

Hi,

Functionality wise, what type of class do you wrap with QScriptClass?


Simon

  Original Message
From: Jaroslaw Staniek
Sent: Tuesday, February 3, 2015 09:36
To: Knoll Lars
Cc: development@qt-project.org
Subject: Re: [Development] Deprecating modules with 5.5


On 3 February 2015 at 09:29, Knoll Lars lars.kn...@theqtcompany.com wrote:
 On 03/02/15 09:24, Jaroslaw Staniek stan...@kde.org wrote:

On 3 February 2015 at 08:33, Knoll Lars lars.kn...@theqtcompany.com
wrote:
 Hi,

 I’d like to mark a few modules as deprecated with 5.5, and most likely
 remove them from the binary packages with 5.6. These modules are:

 * Qt WebKit
 * Qt Declarative (Qt Quick 1)
 * Qt Script

 All of these modules are by now a couple of years old, don’t receive
 updates above the bare minimum and have a replacement that is actively
 being developed in Qt 5.

Thanks for the update.
Is there a replacement for, say, 90% of Qt Script features, including
these where performance counts?

 QtQml should with 5.5 have most of the required API and the performance
 should not be a whole lot worse than QtScript (as the JS engine in there
 is by now ~5 years old). Please let Simon and myself know if you’re
 missing some functionality or find some larger performance gap.

Thanks for the info. As for performance, I'd mention I am looking for
equivalents of QScriptClass which is a handy and light tool.

Other than that - QScriptEngineDebugger equivalents?

--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
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] CI broken

[Hausmann Simon]

Thanks Ismo, Tony, Ossi and all the people behind the scenes to get things up 
and running again!


Simon

From: Sarajärvi Tony
Sent: Tuesday, January 27, 2015 20:41
To: development@qt-project.org
Subject: Re: [Development] CI broken


I think I got everything up and running again. At least nothing is complaining 
currently.

Checking the status again in 11 hours when I get to work.

Regards,
-Tony

From: development-bounces+tony.sarajarvi=theqtcompany@qt-project.org 
[mailto:development-bounces+tony.sarajarvi=theqtcompany@qt-project.org] On 
Behalf Of Sarajärvi Tony
Sent: 27. tammikuuta 2015 15:49
To: development@qt-project.org
Subject: [Development] CI broken

Hi

The CI will remain broken at least today. We have no idea why the RSA keys are 
messed up on the servers even though we copy paste everything from a working 
server. Investigations continue tomorrow...

-Tony

Tony Sarajärvi
CI Tech Lead

The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu, Finland
Email: tony.saraja...@theqtcompany.commailto:tony.saraja...@theqtcompany.com
http://qt.io
Qt Blog: http://blog.qt.digia.com/
Qt Facebook: www.facebook.com/qthttp://www.facebook.com/qt
Qt Twitter: @QtbyDigia, @Qtproject
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.4.0 final packages to be tested

[Hausmann Simon]

Yeah, that's an unfortunate bug that slipped in. It is documented as a known 
issue and tracked in ‎QTBUG-43205


Simon

  Original Message
From: Uwe Rathmann
Sent: Wednesday, December 10, 2014 12:14
To: development@qt-project.org
Subject: Re: [Development] Qt 5.4.0 final packages to be tested


On Mon, 08 Dec 2014 08:58:57 +, Heikkinen Jani wrote:

 We have Qt5.4.0 final packages available for your testing here:

Tried to build from the source tarballs on my OpenSuSE 13.1 box, but
after some while my make runs into pkg-config issues.

Well maybe my system is not properly set up for pkg-config ( at least I'm
not taking care of it ) so I tried with -no-pkg-config:

configure -opensource -nomake examples -nomake tests -no-pkg-config -
confirm-license

Now I'm running into this one:

...
cd platformsupport/  ( test -e Makefile || /disk/qt/qt-everywhere-
opensource-src-5.4.0/qtbase/bin/qmake /disk/qt/qt-everywhere-opensource-
src-5.4.0/qtbase/src/platformsupport/platformsupport.pro -o Makefile ) 
make -f Makefile
Project ERROR: Unknown module(s) in QT: dbus

Before configure had told me:

Qt modules and options:
  Qt D-Bus ... runtime
  Qt Concurrent .. yes
  Qt GUI . yes
  Qt Widgets . yes
  Large File . yes
  QML debugging .. yes
  Use system proxies . no

Uwe







___
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] Clarification needed for Qt Script's future over QJSEngine/Value

[Hausmann Simon]

Hi,

You are right, we need to add a few more features to QJSEngine.

I'm not so much in favor of the default prototype for meta type api anymore, as 
it promotes the creation of slow conversion code I think. If you peek at my 
gerrit dashboard then you can see that I'm about 80% done with a series for 
gadget support that will allow you to expose your own value types without a 
conversion needed.

In theory we could build that up with some help from moc to the extend that the 
jit accesses your Q_PROPERTY members directly.

I'm hesitant to expose engine internals because that really hurt us last time. 
But I'm all in favor of adding some of the qml extension js APIs by default, 
such as qlocale extensions etc.

There's some low hanging fruit there, so contributions  are welcome :)

Simon

  Original Message
From: N. N.
Sent: Wednesday, November 26, 2014 19:51
To: development@qt-project.org
Reply To: N. N.
Subject: [Development] Clarification needed for Qt Script's future over 
QJSEngine/Value


I was looking at using QtScript for a project and noticed that all work has 
been ABANDONED for using the new java script engine V8 as noted in 
http://qt-project.org/wiki/V8_Port and

then pouring over other bug reports  the mailing list about QtScript and how 
QtScript won't be updated to use a newer JavaScriptCore since it would be too 
much work to maintain.

The talk is that for Qt5 there is QJSEngine/Value API instead, but, that is a 
smaller subset of features over what QtScript offers now.

Reading about QJSEngine/Value there seems to be no official API way for 
exposing a C type callback, so everything has to go through QObject bindings 
instead, correct?

Does this mean that QtScript will eventually be deprecated in favor of 
QJSEngine/Value since
QtScript will not be updated any longer with any improvements and basically be 
left in a as is state with possible bug fixes?
___
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] CI broken again

[Hausmann Simon]

Great analysis - thanks guys for fixing this!

Simon

  Original Message
From: Morten Johan Sørvig
Sent: Monday, October 20, 2014 21:06
To: Qt Development Group
Subject: Re: [Development] CI broken again


 On 20 Oct 2014, at 15:04, Saether Jan-Arve 
 jan-arve.saet...@theqtcompany.com wrote:

 Change: https://codereview.qt-project.org/97600

(comment from 97600)
// On OS X the windows might get positioned exactly on top of each other
// that means no repaint for the bottom window will ever occur

And why did this start to fail now? As of commit f5cf06f4 we are no longer 
painting obscured windows.

Morten


___
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] Fw: Change in qt/qtdeclarative[5.4]: Fix QQmlExpression/QQmlScriptString/QQmlBinding crashes

[Hausmann Simon]

‎Hi,

Does anyone know what's up with the build on windows ce? I've seen this failure 
in various integrations in the past days.

Simon

  Original Message
From: Qt Continuous Integration System (Code Review) 
gerrit-nore...@qt-project.org
Sent: Wednesday, October 8, 2014 13:19
To: Hausmann Simon
Reply To: ci-nore...@qt-project.org
Cc: Qt Sanity Bot; Knoll Lars; Michael Brasser
Subject: Change in qt/qtdeclarative[5.4]: Fix 
QQmlExpression/QQmlScriptString/QQmlBinding crashes


Qt Continuous Integration System has posted comments on this change.

Change subject: Fix QQmlExpression/QQmlScriptString/QQmlBinding crashes
..


Compilation failed :(

  corelibc.lib(mainacrt.obj) : error LNK2019: unresolved external symbol main 
referenced in function void __cdecl mainCRTStartupHelper(struct HINSTANCE__ 
*,unsigned short const *) (?mainCRTStartupHelper@@YAXPAUHINSTANCE__@@PBG@Z)
  C:\work\build\qt\qtbase\lib\Qt5QuickTest.dll : fatal error LNK1120: 1 
unresolved externals

  Build log: 
http://testresults.qt-project.org/ci/QtDeclarative_5.4_Integration/build_00228/wince70embedded-armv4i-msvc2008_Windows_7/log.txt.gz

  Tested changes (refs/builds/5.4_1412766349):
http://codereview.qt-project.org/95714 [PS5] - Doc: Updated the QML State 
Machine docs
http://codereview.qt-project.org/96339 [PS5] - Fix 
QQmlExpression/QQmlScriptString/QQmlBinding crashes

--
To view, visit https://codereview.qt-project.org/96339
To unsubscribe, visit https://codereview.qt-project.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I9111f9a3b65618e453954abcd789c039e65a94f7
Gerrit-PatchSet: 5
Gerrit-Project: qt/qtdeclarative
Gerrit-Branch: 5.4
Gerrit-Owner: Simon Hausmann simon.hausm...@digia.com
Gerrit-Reviewer: Lars Knoll lars.kn...@digia.com
Gerrit-Reviewer: Michael Brasser michael.bras...@live.com
Gerrit-Reviewer: Qt Sanity Bot qt_sanity...@qt-project.org
Gerrit-Reviewer: Simon Hausmann simon.hausm...@digia.com
Gerrit-HasComments: No
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QML] Singletons are deleted before the other objects

[Hausmann Simon]

Hi,

In gener‎al I agree with Chris. However I'm a little puzzled that this is 
happening. If you take a look at the QQmlEngine destructor you can see that 
singletons are deleted last. So I'm wondering what is happening in your app 
Bogdan. Can you create a minimal test case?

Thanks,
Simon

Fra: Chris Adams
Sendt: 05:45 mandag 22. september 2014
Til: BogDan
Kopi: Qt Development Group
Emne: Re: [Development] [QML] Singletons are deleted before the other objects


Hi,

On Fri, Sep 19, 2014 at 10:37 PM, BogDan 
bog_dan...@yahoo.commailto:bog_dan...@yahoo.com wrote:
Hello folks,

  Singletons registered using qmlRegisterSingletonType, are deleted *before*
the other active objects. I consider it to be wrong because some of the active
objects may still need to access the singletons in their destructor ...

IMHO singletons should be the very last objects deleted (also in the reverse
order).

I tend to agree that they should be deleted last.  Enforcing deletion in the 
reverse
order to how they were registered might impose some slight performance penalty
at instantiation time, however, depending on how the deletion order is 
determined
at cleanup time, since they are instantiated on demand (and hence possibly
out-of-order).


Is there any reason why they are deleted before the other active objects?
Or this is just a bug?

I don't believe that there is any particular reason for deleting them prior to 
other
active objects, but perhaps Simon or Lars can correct me on this point.
Nonetheless, I don't think that the current behaviour is a bug, per-se, as the
destruction order was never documented or guaranteed, as far as I know.

Cheers,
Chris.


Cheers,
BogDan.

___
Development mailing list
Development@qt-project.orgmailto: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] Qt WebChannel 5.5 roadmap: WebEngine, QtWebView

[Hausmann Simon]

I'm pretty sure that all the native webview APIs allow for at least 
runJavascript(string), so injection may also be an easier option.

Simon

  Opprinnelig melding
Fra: Jocelyn Turcotte
Sendt: 16:45 onsdag 27. august 2014
Til: Milian Wolff
Kopi: Development
Emne: Re: [Development] Qt WebChannel 5.5 roadmap: WebEngine, QtWebView


On Wed, Aug 27, 2014 at 04:27:35PM +0200, Milian Wolff wrote:
 Hey all,

 for Qt 5.4, the new WebChannel module will only be easily usable for WebKit
 users. For 5.5 I plan to add WebEngine integration, if Pierre is not beating
 me to it. We will simply copy the QML API, and no changes on the client-side
 HTML should be required, I think.

 Then, recently, QtWebView was announced for Android and iOS WebViews. I wonder
 if we can integrate the WebChannel nicely there as well. Instantiating a
 WebChannel internally won't be the problem, nor copying the QML API. But for
 HTML clients, I don't know if one can automatically setup the transport
 mechanism (based on WebSockets), nor whether one can even load the
 qwebchannel.js API via a qrc URL. Can someone working on QtWebView shed some
 light here please?

One thing that WebSockets do is that they are a transport layer on top of
HTTP. You can transport your qwebchannel.js or any html hook through a
non-upgraded WebSocket's HTTP response.

QtWebSocket doesn't support this at the moment and simply ignores any HTTP
request not asking for an upgrade, but I had a simple change that was
manually writing the HTTP response on the QTcpSocket and it worked pretty well.

The main issue is that you normally have websocket as part of an HTTP
server and not the other way around, so we'd have to stretch the API a
bit. I was able to hack it quickly by reusing QNetworkRequest and
QNetworkReply but we should probably duplicate their interface into some
kind of QWebSocketHttpRequest/Reply if we don't want to poison
QNetworkAccessManager's API with foreign use cases.

Cheers,
Jocelyn
___
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] Fwd: Change in qt/qtbase[5.4]: Add the QStorageInfo class

[Hausmann Simon]

Yay :)


Simon

  Opprinnelig melding
Fra: Thiago Macieira
Sendt: 21:43 onsdag 13. august 2014
Til: development@qt-project.org
Emne: [Development] Fwd: Change in qt/qtbase[5.4]: Add the QStorageInfo class


It merged.

--  Forwarded Message  --

Subject: Change in qt/qtbase[5.4]: Add the QStorageInfo class
Date: Wednesday 13 August 2014, 20:58:46
From: Qt Continuous Integration System (Code Review) gerrit-noreply@qt-
project.org
To: Ivan Komissarov abba...@gmail.com
CC: Konstantin Ritt ritt...@gmail.com, Denis Shienkov
denis.shien...@gmail.com, Shawn Rutledge shawn.rutle...@digia.com, Qt
Sanity Bot qt_sanity...@qt-project.org, Oliver Wolff oliver.wo...@digia.com,
Oswald Buddenhagen oswald.buddenha...@digia.com, Qt Doc Bot qt_docbot@qt-
project.org, Keith Gardner kreios4...@gmail.com, Andrew Knight
andrew.kni...@digia.com, Thiago Macieira thiago.macie...@intel.com, Allan
Sandfeld Jensen allan.jen...@digia.com, Marc Mutz marc.m...@kdab.com,
Andreas Holzammer andreas.holzam...@kdab.com, Björn Breitmeyer
bjoern.breitme...@kdab.com, Janne Anttila janne.antt...@digia.com, Olivier
Goffart ogoff...@woboq.com, Iikka Eklund iikka.ekl...@digia.com, Rafael
Roquetto rafael.roque...@kdab.com, Sérgio Martins sergio.mart...@kdab.com,
Jerome Pasion jerome.pas...@digia.com, Friedemann Kleint
friedemann.kle...@digia.com, Alex Char prevedt...@gmail.com, Alex Blasche
alexander.blas...@digia.com, Topi Reiniö topi.rei...@digia.com, BogDan
Vatra bog...@kde.org, Jan Arve Sæther jan-arve.saet...@digia.com

Qt Continuous Integration System has approved a build with this change and it
was merged.

Change subject: Add the QStorageInfo class
..


Add the QStorageInfo class

Allows to retrieve information about mounted volumes such as label,
total/available size, filesystem type and so on.
Possible use cases are:
- allows to do checks about filesystem before performing actual
  operation (such as available/maximum volume size)
- allows to retrive information about volume that can be shown in file
  dialogs
- allows to retrieve volume for specific path and check if two or more
  paths belong to the same volume or not

[ChangeLog][QtCore] Added QStorageInfo class to retrive information
about mounted volumes and drives

Change-Id: Ibf9c2e6b53ef39c5605894a4422acdbbca4030c4
---
A src/corelib/doc/snippets/code/src_corelib_io_qstorageinfo.cpp
M src/corelib/io/io.pri
A src/corelib/io/qstorageinfo.cpp
A src/corelib/io/qstorageinfo.h
A src/corelib/io/qstorageinfo_mac.cpp
A src/corelib/io/qstorageinfo_p.h
A src/corelib/io/qstorageinfo_stub.cpp
A src/corelib/io/qstorageinfo_unix.cpp
A src/corelib/io/qstorageinfo_win.cpp
M tests/auto/corelib/io/io.pro
A tests/auto/corelib/io/qstorageinfo/qstorageinfo.pro
A tests/auto/corelib/io/qstorageinfo/tst_qstorageinfo.cpp
12 files changed, 1,849 insertions(+), 7 deletions(-)

Approvals:
  Shawn Rutledge: Looks good to me, approved
  Qt Sanity Bot: Sanity review passed


--
To view, visit https://codereview.qt-project.org/73945
To unsubscribe, visit https://codereview.qt-project.org/settings

Gerrit-MessageType: build-approved
Gerrit-Change-Id: Ibf9c2e6b53ef39c5605894a4422acdbbca4030c4
Gerrit-PatchSet: 91
Gerrit-Project: qt/qtbase
Gerrit-Branch: 5.4
Gerrit-Owner: Ivan Komissarov abba...@gmail.com
Gerrit-Reviewer: Alex Blasche alexander.blas...@digia.com
Gerrit-Reviewer: Alex Char prevedt...@gmail.com
Gerrit-Reviewer: Allan Sandfeld Jensen allan.jen...@digia.com
Gerrit-Reviewer: Andreas Holzammer andreas.holzam...@kdab.com
Gerrit-Reviewer: Andrew Knight andrew.kni...@digia.com
Gerrit-Reviewer: Björn Breitmeyer bjoern.breitme...@kdab.com
Gerrit-Reviewer: BogDan Vatra bog...@kde.org
Gerrit-Reviewer: Denis Shienkov denis.shien...@gmail.com
Gerrit-Reviewer: Friedemann Kleint friedemann.kle...@digia.com
Gerrit-Reviewer: Iikka Eklund iikka.ekl...@digia.com
Gerrit-Reviewer: Ivan Komissarov abba...@gmail.com
Gerrit-Reviewer: Jan Arve Sæther jan-arve.saet...@digia.com
Gerrit-Reviewer: Janne Anttila janne.antt...@digia.com
Gerrit-Reviewer: Jerome Pasion jerome.pas...@digia.com
Gerrit-Reviewer: Keith Gardner kreios4...@gmail.com
Gerrit-Reviewer: Konstantin Ritt ritt...@gmail.com
Gerrit-Reviewer: Marc Mutz marc.m...@kdab.com
Gerrit-Reviewer: Oliver Wolff oliver.wo...@digia.com
Gerrit-Reviewer: Olivier Goffart ogoff...@woboq.com
Gerrit-Reviewer: Oswald Buddenhagen oswald.buddenha...@digia.com
Gerrit-Reviewer: Qt Doc Bot qt_doc...@qt-project.org
Gerrit-Reviewer: Qt Sanity Bot qt_sanity...@qt-project.org
Gerrit-Reviewer: Rafael Roquetto rafael.roque...@kdab.com
Gerrit-Reviewer: Shawn Rutledge shawn.rutle...@digia.com
Gerrit-Reviewer: Sérgio Martins sergio.mart...@kdab.com
Gerrit-Reviewer: Thiago Macieira thiago.macie...@intel.com
Gerrit-Reviewer: Topi Reiniö topi.rei...@digia.com
-
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

Re: [Development] HEADS UP: Qt 5.4 feature freeze - is frozen now

[Hausmann Simon]

Hi,

I sincerely hope that the class name will be reconsidered, given how generic 
and therefore ambiguous the term volume is. Please consider making it more 
specific by adding Storage or something else to the name and avoid that people 
guess wrongly and avoid people finding this class when they search for the 
audio volume api elsewhere in Qt. Pretty please with a cherry :)


Simon

  Opprinnelig melding
Fra: Иван Комиссаров
Sendt: 11:24 lørdag 9. august 2014
Til: Buddenhagen Oswald
Kopi: development@qt-project.org; releas...@qt-project.org
Emne: Re: [Development] HEADS UP: Qt 5.4 feature freeze - is frozen now


Thank you for notification. Please, re-rarget QVolumeInfo to 5.4 branch 
(https://codereview.qt-project.org/#/c/73945/78).
And review patchset 78, someone:)

Иван Комиссаров

09 авг. 2014 г., в 12:16, Iikka Eklund (via Oswald Buddenhagen) 
oswald.buddenha...@digia.com написал(а):

 Hi,

 the ‘dev’ branch is now temporarily closed. From now on, all changes
 targeted to Qt5.4.0 need to be pushed to ‘5.4’ branch (once available).

 Note that Ossi will continue re-staging changes on dev that fail to
 integrate for no fault of their own, until some reasonable deadline.

 We will inform you when the ‘5.4’ branch is available and when ‘dev’
 branch is opened for changes for Qt5.5.0.

 Changes intended for 5.4 which were already pushed for dev can be
 re-targeted server-side by administrative action without abandoning and
 re-pushing. Drop Ossi a line.

 Fixes for 5.3, especially those already uploaded, should NOT be
 re-targeted to 5.4 - 5.3 will be merged to 5.4 for weeks to come.

 -- Iikka
 -- (edited  sent by Ossi)

 On 07/29/2014 11:20 AM, Heikkinen Jani wrote:
 Hi,

 Please remember: Qt 5.4 feature freeze is Friday 8th August 2014 12:00
 CET. It means:

 -‘Dev’ branch will be temporarily locked 8th August 2014 12:00 CET

 oAfter that time any changes that are required for Qt 5.4.0 needs to be
 pushed to the '5.4' branch. So if your changes are not in by that time,
 please wait until the branching is done and re-target it to the '5.4'
 branch.

 -All new features/modules targeted to Qt 5.4 must be in ‘dev’ –branch at
 that time  must fulfill criteria for new features/modules (from Lars’s
 old email):

 oPlease make sure that all new functionality

 §Compiles on all reference platforms

 · (If a module/feature is only for one platform, make sure qmake/make
 does nothing on the other platforms)

 §Have tests

 ·Automated tests should cover as much as possible of the new
 functionality. If certain areas are not covered by automated tests, I'd
 like to hear how testing will be done for those

 §Have documentation

 · No undocumented public API. Basic docs have to be there, only
 polishing should still be required after the freeze

 §Have examples

 ·Have some examples showing how to use the API. Examples need to be
 linked from documentation.

 oIn addition, new modules need to

 §Follow the branching scheme

 ·A new module can be ok to only have dev, with ‘5.4’ being created at
 branching time.

 oHave a CI system

 §New modules that are going to be part of Qt releases need to have a CI
 system set up. Please contact CI team early enough….

 -Each new module needs to be a part of qt5.git already in ‘dev’ branch.
 Please notify release team about any new module for Qt 5.4 immediately!

 -‘5.4’ will be branched from ‘dev’ Mon 11^th August 2014

 Br,

 Jani



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



 --
 Br,
 Mr. Iikka Eklund
 Senior software engineer

 Elektronikkatie 10
 FI-90590 Oulu
 Email: iikka.ekl...@digia.com

 Visit us at: www.digia.com or qt.digia.com
 --
 PRIVACY AND CONFIDENTIALITY NOTICE
 This message and any attachments are intended only for use by the named
 addressee and may contain privileged and/or confidential information. If
 you are not the named addressee you should not disseminate, copy or take
 any action in reliance on it. If you have received this message in
 error, please contact the sender immediately and delete the message and
 any attachments accompanying it. Digia Plc does not accept liability for
 any corruption, interception, amendment, tampering or viruses occurring
 to this message.
 --
 ___
 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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QWebChannel setTimeout

[Hausmann Simon]

I think setTimeout would be a good function to add to qml's Javascript 
environment, as imperative js api next to the timer element.

That said, the risk is high that people use it to drive animations or work 
around other things.

Anyway, patches welcome :)

Simon

  Opprinnelig melding
Fra: Milian Wolff
Sendt: 02:33 lørdag 5. juli 2014
Til: development@qt-project.org
Emne: Re: [Development] QWebChannel setTimeout


On Friday 04 July 2014 13:41:28 Bernd Lamecker wrote:
 Hi,

 is there a special reason why you call
 setTimeout(function() { channel.exec({type: QWebChannelMessageTypes.idle});
 }, 0); (Line 179  197 in qwebchannel.js)
 via setTimeout? For me this also works without doing a singleshot.
 But the setTimeout function is not defined when including qwebchannel.js
 into a qml application.

You can have a look at what I did in Client.qml in 
https://codereview.qt-project.org/#/c/81523/13//ALL - there I implement 
setTimeout in terms of a QML
Timer object. Ugly and doesn't support multiple simultaneous calls to
setTimeout, but at least it works. I really think we should have a setTimeout
in QML, if alone to better support embedding external JavaScript libraries.

Now, on the topic of _why_ I use setTimeout there: This comes from the
original implementation of the QWebChannel we did for a customer of ours on an
embedded platform which showed serious performance issues and scheduling
problems, i.e. sending WebSocket messages repeatedly to a QtWebKit client
completely hogged up the CPU in the WebSocket code and all other applications
froze. This might need to be revisited, esp. considering that we'll get much
faster QtWebKit IPC instead of WebSockets for the common case. So maybe, all
of that is not required anymore. But before I blindly remove this stuff, I
guess we should first work on the core functionality and then eventually
cleanup such legacy code (and write more benchmarks etc. to verify we are not
breaking anything).

Bye

--
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbHCo KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QWebChannel setTimeout

[Hausmann Simon]

Let me ask the other way around: is there a special reason why you're including 
qwebchannel.js in a qml application? :)


Simon

  Opprinnelig melding
Fra: Bernd Lamecker
Sendt: 19:41 fredag 4. juli 2014
Til: development@qt-project.org
Emne: [Development] QWebChannel setTimeout


Hi,

is there a special reason why you call
setTimeout(function() { channel.exec({type: QWebChannelMessageTypes.idle}); }, 
0);
(Line 179  197 in qwebchannel.js)
via setTimeout? For me this also works without doing a singleshot.
But the setTimeout function is not defined when including qwebchannel.js into a 
qml application.

Regards,
Bernd
___
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] QtQuick QtCS Sessions

[Hausmann Simon]

The done is referring to the fact that a binding to qsTr(...) does not result 
in the creation of a Javascript binding but is treated directly by the engine 
as translation. just like the jira report indicates, support for dynamic 
re-evaluation of such bindings is not implemented yet (and was never claimed as 
done).

Simon

  Opprinnelig melding
Fra: Thomas Senyk
Sendt: 17:13 onsdag 25. juni 2014
Til: development@qt-project.org
Emne: Re: [Development] QtQuick QtCS Sessions


On Friday, 13 June, 2014 23:07:08 Alan Alpert wrote:
 Here are the results and brief summaries of the 3 QtQuick related
 sessions, where we came up with some suggested new properties and
 types for QtQuick.

 Touch and Gestures:
 http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCS14TouchAnd
 Gestures

 No real solution other than handling Mouse, Touch, and Gestures
 (system gestures, no gesture manager). Also looking into new grab
 transfer mechanisms in QtQuick, such as a MouseArea.priority property
 for automatic transfer.

 QtQuick:
 http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCS14QtQuick

 Proposed new module, QtQmlGui (working title), which exposes non-core
 stuff to QML but can be shared between QtQuick and other modules (like
 Qt3D). Proposed new types, PolarPositioner, MouseRegion,
 TextContainer.

 Declarative QML:
 http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCs14MoreDecl
 arative

 Proposed new property, deferredLoading, on Item, to solve the less
 dynamic uses of Loader. Proposed new element, StateChange, to allow
 more declarative state changing. Big solutions of pull bindings and a
 pragma strictly-declarative are a lot of work, unlikely to occur soon.

How is Translation DONE?

Just to make sure we talk about the same thing:

https://bugreports.qt-project.org/browse/QTBUG-15602

Affects version should be all I guess .. this is (was?) the same case for all
Qt versions and also QQuickView (quick2)

That's not solved .. is it?


 --
 Alan Alpert
 ___
 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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qt5.git integration failed in stable

[Hausmann Simon]

I suspect one of these three changes in qtbase:

‎Revert Fixed duplicate QMoveEvent generated for each QWidget::move call
 Fix selection by dragging after double click in QWidgetTextControl.
 QPlatformClipboard::emitChanged(): Do not emit signals when closing down.

Do those ring a bell for anyone?

The failure is in qtquick1, so not covered by revdep.


Simon
Fra: Heikkinen Jani
Sendt: 10:28 søndag 8. juni 2014
Til: development@qt-project.org
Emne: [Development] qt5.git integration failed in stable


Hi all!

Could someone check ( fix ;) )why `tst_qdeclarativetextedit' is failing in 
qt5.git stable integration.

Build log: 
http://testresults.qt-project.org/ci/Qt5_stable_Integration/build_00699/linux-g++_developer-build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64/log.txt.gz

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

Re: [Development] [HEADS UP] new branching scheme: 5.3 branches created, stable deprecated

[Hausmann Simon]

Whether or not next is a better name than dev is your opinion, it isn't 
necessarily a fact. I for one like dev and find it a name better than next.

We could run a poll and see what name comes out and change to that. But is it 
really worth the effort and disruption?‎ I'm not convinced that it is.


Simon

Fra: Yuchen Deng
Sendt: 07:23 fredag 6. juni 2014
Til: Thiago Macieira
Kopi: development
Emne: Re: [Development] [HEADS UP] new branching scheme: 5.3 branches created, 
stable deprecated


I think 'next' work tell people, it's the next release, for now it's unstable.
But 'dev' don't tell people anything.
Because all of the branch should being develop state. except the release 
branch, e.g. '5.3.x'.
Why this 'dev' branch is special?
Why don't use a better name?

2014-06-05 23:31 GMT+08:00 Thiago Macieira 
thiago.macie...@intel.commailto:thiago.macie...@intel.com:
I don't see the point in renaming from dev to next. It doesn't buy
anything new, other than confusion.




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

Re: [Development] split() and replace() methods SEGFAULT

[Hausmann Simon]

You're right, Gatis ran into the same issue. Seems arm jit specific, he made a 
nice js only test case. (see 39289)


Simon

  Opprinnelig melding
Fra: Zoltán Balogh
Sendt: 07:50 tirsdag 27. mai 2014
Til: development@qt-project.org
Emne: [Development] split() and replace() methods SEGFAULT


Hi,

During the Qt5.3 migration work we have been biten by a strange bug:
https://bugreports.qt-project.org/browse/QTBUG-39255

The issue effect armhf platforms and confirmed on Android too.

example1:
import QtQuick 2.0
Item {Component.onCompleted: bla.replace(/\w/g, function(a){ return
a.toUpperCase() })}

example2:
Button {
function split_text() { var text_to_split = 'May the 4th be with U';
return text_to_split.split(/\s/g); }
onClicked:{ label.text = split_text()[0]; }
}

I suspect that it is a bug in the QV4.

Zoltan
___
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] qt-opensource-windows-x86-msvc2012_opengl-5.3.0-RC: libegl missing

[Hausmann Simon]

Hmm I don't think the _opengl variant is supposed to contain libegl (angle) - I 
think only the angle variant is supposed to.

Simon

  Opprinnelig melding
Fra: Helmut Mülner
Sendt: 09:39 mandag 12. mai 2014
Til: development@qt-project.org
Emne: [Development] qt-opensource-windows-x86-msvc2012_opengl-5.3.0-RC: libegl 
missing


In the final RC the libegl binary files (*.lib, *.dll) are missing.
I did not have this problem with the previous snapshots.

Best regards
Helmut


___
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] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Hausmann Simon]

Oops you're right, it's there. Thanks ‎:)

Simon

  Opprinnelig melding
Fra: Alan Alpert
Sendt: 23:32 onsdag 30. april 2014
Til: Hausmann Simon
Kopi: Hartmann Thomas; development@qt-project.org
Emne: Re: [Development] Perceptions/Understandings of the QML language [was: 
Question about Qt's future]


On Wed, Apr 30, 2014 at 6:33 AM, Simon Hausmann
simon.hausm...@digia.com wrote:
 On Wednesday 30. April 2014 15.25.35 Hartmann Thomas wrote:
 Hi,

 the original idea was to get rid of the need to write Java Script to change
 a state (state = newState) and find a declarative way to change states.
 The rest then came naturally.

 Right.

 While we're on the state property: It's publically accessible through
 setProperty/property. Does anyone know a reason as to why the setState/state
 setters/getters aren't public API in QQuickItem itself? (but
 Q_PRIVATE_PROPERTY)

The QString state property and setState/state setters/getters are
public API in my checkout of QQuickItem (release branch).

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

Re: [Development] No SSL on iOS ?

[Hausmann Simon]

Unfortunately dlopen is not possible :(

Simon

  Opprinnelig melding
Fra: Thiago Macieira
Sendt: 18:14 mandag 28. april 2014
Til: development@qt-project.org
Emne: Re: [Development] No SSL on iOS ?


Em seg 28 abr 2014, às 09:44:49, Nichols Andy escreveu:
 The packaged (binary) versions of iOS do not include support for OpenSSL
 because that would require the static linking (and thus distribution) of
 OpenSSL which can be problematic due to export restrictions.  It is not
 possible to build in OpenSSL support as “runtime” on iOS with the code as
 it is now.  I explored some solutions for this involving using weak linking
 during the 5.2.0 release cycle but I was not successful.  Instead now if
 you want support for OpenSSL on iOS in Qt, you’ll need to build Qt yourself
 and provide your own static build of OpenSSL at Qt configure/build time.

Is dlopen also disabled on iOS?

If not, we could dlopen a copy of OpenSSL present inside the application's
bundle or the QtNetwork.framework bundle (is there such a bundle?).

 It is possible still in the packaged versions of Qt for iOS to make
 connections using SSL via QNetworkAccessManager as there is a backend that
 uses Apples crypto API, but without OpenSSL support you can’t use any of
 the API’s in Qt that use OpenSSL directly (like QSSLSocket).

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

Re: [Development] Question about Qt's future

[Hausmann Simon]

Hmm, but why don't you use Qml like that then? The language doesn't force you 
to use inline js code, does it?

A lot of the work that has gone into the engine lately also enables this to 
work better and reduce the use of JS. For example bindings that just consist of 
a qsTr don't actually end up creating any js bindings.

Simon

  Opprinnelig melding
Fra: Yves Bailly
Sendt: 16:52 søndag 27. april 2014
Til: development@qt-project.org
Emne: Re: [Development] Question about Qt's future


On 27/04/2014 12:55, Peter Kümmel wrote:
 Having imperative code on the JS side is also the root of the rejection of QML
 for many C++ developers. If QML would have been just a improved .ui nobody 
 would
 have complained.

+1


--
(o | Yves Bailly  | -o)
//\ | Linux Dijon  : http://www.coagul.org | //\
\_/ |  | \_/`
___
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] Qt binaries with inlined functions

[Hausmann Simon]

Hi,

Isn't this also how msvc behaves by default? Then perhaps it would make sense 
to build with those flags by default with gcc for consistency. I wonder what 
the overhead in size is.

Either way I think this should not be specific to qt-project.org binaries.

Simon

Fra: Dimitar Dobrev
Sendt: 10:44 lørdag 26. april 2014
Til: development@qt-project.org
Svar til: Dimitar Dobrev
Emne: [Development] Qt binaries with inlined functions



Hello all,

I'd like to start a discussion about 
.https://bugreports.qt-project.org/browse/QTBUG-32995. Please share your 
thoughts.

Regards,
Dimitar Dobrev


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

Re: [Development] Question about Qt's future

[Hausmann Simon]

Hi Michael,

In response to your email I have two questions:

1) As your email is addressed to the open source community working on Qt 
itself, who are you referring to with they?

2) You are saying that you want to be sure. What kind of assurance are you 
looking for?


Simon

  Opprinnelig melding
Fra: Michael Knight
Sendt: 03:45 mandag 21. april 2014
Til: development@qt-project.org
Emne: [Development] Question about Qt's future


I feel like Qt is going in the direction of being Qml and Javascript only.I
fear that they may abandon Qt Widgets in the near future,I think they are
heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I
want to be sure that they will not abandon C++ side of Qt and that they
continue to develop C++ side.It seems to me that they are developing Qml side
mostly.

What do you think about this?

___
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] Python required to build Qt from source packages

[Hausmann Simon]

No objections from my side. I just don't know yet when I'll get to it, so 
anyone feel free to beat me to it ;)


Simon


  Opprinnelig melding
Fra: Thiago Macieira
Sendt: 19:14 torsdag 20. mars 2014
Til: development@qt-project.org
Emne: Re: [Development] Python required to build Qt from source packages


Em sex 28 fev 2014, às 18:30:24, Hausmann Simon escreveu:
 Note that this is not a new dependency but has been there since Qt 5.0.0
 (when v8 required python)

Still. Can we please commit the file to the repository or generate it at
packaging time?

   Opprinnelig melding
 Fra: Thiago Macieira
 Sendt: 18:04 fredag 28. februar 2014
 Til: development@qt-project.org
 Emne: [Development] Python required to build Qt from source packages


 We went through great pains to make sure that Perl wasn't required to build
 Qt from released sources, but it looks like a dependency on Python crept
 back in, for a single file (RegExpJitTables.h in qtdeclarative/src/qml).

 Can we commit the generated file to the repository, or generate it during
 packaging?

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

Re: [Development] qt5.git integration broken again :(

[Hausmann Simon]

No worries :)

Meanwhile qt5.git integrated and we have a lot more very good content for the 
beta!:)

For this particular change it would have helped if not only the no-widget stage 
of qt5.git built tests but also the module stage.

Simon

  Opprinnelig melding
Fra: Tasuku Suzuki
Sendt: 15:57 lørdag 15. mars 2014
Til: Hausmann Simon
Kopi: Gladhorn Frederik; Heikkinen Jani; development@qt-project.org
Emne: Re: [Development] qt5.git integration broken again :(


I apologize about the breakage of the build :'(
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Python required to build Qt from source packages

[Hausmann Simon]

Note that this is not a new dependency but has been there since Qt 5.0.0 (when 
v8 required python)



Simon

  Opprinnelig melding
Fra: Thiago Macieira
Sendt: 18:04 fredag 28. februar 2014
Til: development@qt-project.org
Emne: [Development] Python required to build Qt from source packages


We went through great pains to make sure that Perl wasn't required to build Qt
from released sources, but it looks like a dependency on Python crept back in,
for a single file (RegExpJitTables.h in qtdeclarative/src/qml).

Can we commit the generated file to the repository, or generate it during
packaging?

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