> Currently Qt ships with 32-bit binaries for MSVC 2015, but not for
> MSVC 2017. The Qt Company have received requests for adding prebuilt
> 32-bit binaries also for MSVC 2017. By adding more prebuilt binaries,
> we increase the complexity, and add to the overall maintenance of our
> QA system.
fwiw, to get this thread back to the main topic, i still fail to see
how
root_ptr deals with objects which are reachable from multiple roots,
which have independent lifetime
>>>
>>> Please provide an example.
>>
>> i've posted some already
>
> I'm working on the parser right
>> fwiw, to get this thread back to the main topic, i still fail to see how
>> root_ptr deals with objects which are reachable from multiple roots,
>> which have independent lifetime
>
> Please provide an example.
i've posted some already
___
> Oh sorry they did invent Minesweeper and Basic, I give them that...
https://en.wikipedia.org/wiki/Dartmouth_BASIC
--
fwiw, to get this thread back to the main topic, i still fail to see how
root_ptr deals with objects which are reachable from multiple roots,
which have independent lifetime
> On the other hand, I have good news as I think I have found a way to
> simulate functions that return a function.
how to you cope with structures like:
function foo( outObject )
{
var object = {}
outObject.object = object
outObject.result = function() { return object }
return
> - the parameters of the function will remain unaffected if they are used as
> r-values
> - the parameters of the function will require a deep copy of the expression
> if they are used as l-values
https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing
function foo( arg )
{
var
> If there is one root_ptr per
> Javascript function then all local variables are guaranteed to be
> destroyed. And closures aren't too big of a deal either because child
> objects can easily refer to their parent.
>
> But returning local variables might need some work on root_ptr such as
>
> All known blockers should be fixed in these packages and we are
> targeting to release Qt 5.8.0 Tue 17^th January if nothing really
> serious found during testing. So please inform me immediately if there
> is some new blocker in the packages.
QTBUG-56163 is the main blocker for me, which
>>> cd gui/ && ( test -e Makefile ||
>>> /Users/tim/dev/qt3rd/build-Qt-5.x-dev-macx-clang-static/qtbase/bin/qmake
>>> -o Makefile /Users/tim/dev/qt3rd/qtbase/src/gui/gui.pro -qtconf
>>> /Users/tim/dev/qt3rd/build-Qt-5.x-dev-macx-clang-static/qtbase/bin/qt.con
>>> f -- -qt-zlib -qt-harfbuzz
>> like with 5.8-beta, i'm still having issues when linking statically
>> against a prebuilt static library of libpng (because libpng depends on
>> zlib). compare: https://bugreports.qt.io/browse/QTBUG-56163
>>
>> in short, it gives me:
>>> ERROR: Feature 'system-png' was enabled, but the
> We have released Qt 5.8.0 RC today, see
> http://blog.qt.io/blog/2016/12/22/qt-5-8-0-release-candidate-available/
> Thanks to everyone involved.
hi all,
like with 5.8-beta, i'm still having issues when linking statically
against a prebuilt static library of libpng (because libpng depends on
hi all,
>>> The currently sold CPU's are not really the measurement stick here. The
>>> measurement stick is actually installed Win 32 systems.
>> Yes, but what's the 32-bit Windows install base which is capable of running
>> Qt? We only support Windows 7 and above now, so I can't imagine it's
>> We’re working on an update to the macOS/Cocoa platform plugin,
>> and I would like to request a WIP branch where the changes can
>> be finalized:
>>
>>wip/remac
>>
> you have Good Reasons (TM) for creating a branch according to
>
>> the 5.7.1 release was scheduled for sept/oct ... october is almost over,
>> so i wonder what's the state of it?
>>
>> thanks a lot,
>> tim
>
> Hi Tim,
>
> I don't know the exact release plan either, but I guess they want to get
> 5.6.2 released first. The branch 5.7.1 already exists, so this
hi all,
the 5.7.1 release was scheduled for sept/oct ... october is almost over,
so i wonder what's the state of it?
thanks a lot,
tim
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
> Are you trying out of the source builds ?
that's my usual workflow as i need to compile static and dynamic libs
from the same source folder ...
> I opened a ticket yesterday for this, specifically Qt3D, but it can
> compiles if you run from the root tree on the source.
it also compiles fine
hi all,
compiling 5.7.0-rc (sometimes) fails with the following error when
building qt as static library:
> error 15-Jun-2016 20:04:06make[4]: *** No rule to make target
> `/Volumes/build/bamboo-build/THIRDP-QT9-BUILDMAC/build-Qt-5.7.0-rc-macx-clang-static/qt3d/lib/libQt53DQuick_debug.a',
>
> Might be a bit premature, but is anyone opposed to dropping OS X 10.9
> and iOS 7.x in Qt 5.8?
yes: it will prevent some users (including me) to update to qt-5.8, as
our minimum osx requirement is still 10.9.
___
Development mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> Before Qt 5.0 was released, the CMake helper files included a
> useful feature that read .prl files in order to find and include
> Qt dependencies (such as, say, libqtpcre, but also dynamic system
> libraries, and whatever else) in CMake builds
>>> I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and
>>> confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present
>>
>> ah, thanks for the pointer ... importing qt tarballs into git repos is
>> full of surprises: qtgamepad/.gitignore ignores 'include'
>>
>> my
>>> I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and
>>> confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present
>>
>> ah, thanks for the pointer ... importing qt tarballs into git repos is
>> full of surprises: qtgamepad/.gitignore ignores 'include'
>>
>>
> I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and
> confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present
ah, thanks for the pointer ... importing qt tarballs into git repos is
full of surprises: qtgamepad/.gitignore ignores 'include'
my usual workflow
compiling the qt-5.7-beta tarball with msvc2013/64bit/static libraries,
out-of-tree build gives me:
---
cl -c -FIQtGamepadDepends -YuQtGamepadDepends
-Fp.pch\debug\Qt5Gamepadd_pch.pch -nologo -Zc:wchar_t -FS -Zi -MDd
-D_HAS_EXCEPTIONS=0 -GR -W3 -w34100 -w34189 -w44996
>> * legacy code using deprecated sdk functions might not compile a certain
>> codebase (depending on the age of your codebase this maybe lead to
>> significant effort)
>
> Is that because of bugs you talked about below, or is there another reason
> why
> this would happen? Why would it not
>>> r.h:759:21: error: destination for this 'memmove' call is a pointer to
>>> class containing a dynamic class>
>>> 'QPixmap'; vtable pointer will be overwritten
>>> [-Werror,-Wdynamic-class-memaccess]>
>>> memmove(abegin, aend, (d->size - itemsToErase -
>>>
compiling the 5.7-beta tarball with xcode-6.4 fails with:
> In file included from /Users/tim/dev/qt3rd/qtbase/src/gui/image/qicon.cpp:1:
> In file included from
> /Users/tim/dev/qt3rd/qtbase/src/gui/kernel/qt_gui_pch.h:69:
> In file included from
hi all,
it seems that i cannot integrate changes into 5.6 anymore:
> http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1456811813.thrift_bin
seems that i'm always hitting a timeout somewhere ... is this a known
issue? i was hoping that the following changes could make it into 5.6:
> We have finally packages for testing,
>
>
> Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/335/
>
> Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/331/
>
> Mac:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/271/
>
>
>> we have seen funny toolchain bugs, with 10.10 sdk and 10.8 deployment
>> target on 10.8, where std::exceptions could not be caught ... compiling
>> against 10.8 sdk solved that issue.
>
> Regardless of whether that is a valid approach or not, the fact that people
> are doing that poses a
>> Does anyone see any issues with this going forward?
>
> We need to be sure Qt compiles with the latest Xcode available on each of the
> OS X versions that Qt can be developed on. Since 10.8→10.11 updating is free,
> the only extra test is 10.7.
we have seen funny toolchain bugs, with 10.10
>> ... or newer toolchains can introduce regressions ...
>
> But we usually detect those and work around them.
qt is a framework, toolchain bugs may pop up in user code ...
___
Development mailing list
Development@qt-project.org
> I found out that the % is due to using jom in 5.5.1 and nmake in 5.6.1.
> I looked into the Makefiles and bot had the same term. When i use jom
> for 5.6 i see (set
> QT_PLUGIN_PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\plugins)
> & (set
>
> The thing is that in Qt 5.5.1, uic.exe and qlalr.exe were also build
> using qtcore dll, but there this was not a problem.
> In wec build they are always build statically, i think that should be
> made uniform.
>
> Now that I look closer i see the cause of the problem:
> set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
>> Image { id: gicon source: qrc:/img/test.svg anchors.fill: parent
>> }
>>
>> Pro File:
>>
>> QT += svg
>>
>> Outside of the app, in the Android Manifext.xml and IOS, you need
>> to provide pre-generated launcher PNG icons, but inside the app
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Your thoughts on projects that use ONLY SVG image resources
and not PNG/JPEG?
>>>
>>> But the above:
>>>
>>> 1) already works
>>
>> kind of ... the above will rasterize the svg for the resolution
>> of the Image which is then upscaled,
> 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.
ah, that explains why all namespaced build failures that i saw were on
osx :)
___
Development
>>> 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/
>>
> 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/
On 17/10/15 01:27, Thiago Macieira wrote:
> FYI
>
> Please report any issues you have with broken compilers that did not
> implement
> std::atomic properly. I'd like to include them in the release notes.
>
> These are already known to fail, so please don't report them:
> - Xcode 5.0's clang
> https://bugreports.qt.io/browse/QTBUG-48079
>
> Looks like Apple began removing deprecated functions.
>
> Since 4.8 is now closed for changes that aren't security-related, that means
> 4.8 will not compile on OS X 10.11.
apple continuously evolves their API (read: break old code), but afaict
hi!
> We have finally Qt 5.5.1 snapshot available for your testing in
> http://download.qt.io/snapshots/qt/5.5/5.5.1/
i'm wondering, would it be possible to provide source snapshots as well?
this would help those people to 'quickly test' a snapshot, whose build
infrastructure requires tarballs.
We are quite close to Qt 5.5.0 RC final releases. Plan is to put RC
out Thu 11.6.2015 Final Tue 23.6.2015. To be able to keep the schedule
we need to make sure all real blockers are fixed in RC so that it will
be really RC there won't be so much changes between RC Final. So
following
I'm attempting to use libQt5Core with self compiled qt5.5 snapshot,
which is a couple of weeks old. The link fails, complaining about
missing libpcre16.
I believe that is not standard on iOS, at least it does not come up when
looking for Other Libs pcre in XCode. There does seem to be
I'm attempting to use libQt5Core with self compiled qt5.5 snapshot,
which is a couple of weeks old. The link fails, complaining about
missing libpcre16.
I believe that is not standard on iOS, at least it does not come up when
looking for Other Libs pcre in XCode. There does seem to be
Hello, I have a problem with event loop. I am creating DLL which I am
injecting into MFCapplication – my dll spawns a qt window. it works fine,
except ‘input’ to spawned window is blocked: for ex. i have edit box, i am
typing into it and nothing happens – unless, I resize / minimalzie window
but 5.3 hasn't compass (for ios and android) and not webkit for
android?
N.
... and no Qt3D!?
And still no skynet like AI that predict the future?
These questions about the features may seem silly to some, but some of
them are critical for any of us. If I'm Developing an
Qt 5.3 Alpha is now out and plan is to release Beta1 during the next few
weeks. That’s why it is really important to recognize the issues which
must be fixed before we can put beta1 out. There is already some issues
linked in the beta1 metabug, see
In QtQuick, QSGRenderLoop::instance() can create a QSGWindowsRenderLoop
using new that it never destroys. The memory is always pointed to by a
static member pointer, so it's never lost exactly, but the memory is
never freed by Qt (but hopefully will be by any decent OS). Is this a bug?
Should
hi,
in order to compile qt-5.2.0-rc1 as static library with c++11 on osx, i
need to apply the attached patch.
the issue had been reported in a comment in [1], but i guess the issue
was missed, because the bug was closed before.
iac, attached patch fixes the issue, would be great if it can be
hi,
in order to compile qt-5.2.0-rc1 as static library with c++11 on osx, i
need to apply the attached patch.
the issue had been reported in a comment in [1], but i guess the issue
was missed, because the bug was closed before.
iac, attached patch fixes the issue, would be great if it can
50 matches
Mail list logo
