[Development] Can I compile QtWayland module alone?
I can’t compile after git pull. I checked the followings.
Actually, I don’t know about qt_parts, so I wonder if it is possible to
compile only QtWayland without SUBDIRS.
Would you give me any advice?
Thanks.
--
commit 3ae60a1dbb397df2f293e62c3978c11a0d9c9453
Author: Oswald Buddenhagen oswald.buddenha...@nokia.com
Date: Tue Jul 3 21:43:31 2012 +0200
use centralized handling of QT_BUILD_PARTS
Change-Id: I3cf1aeeec697f39ec5fa21fe84731b12c36d54f1
Reviewed-by: Rohan McGovern rohan.mcgov...@nokia.com
diff --git a/qtwayland.pro b/qtwayland.pro
index 4a80275..fa2822b 100644
--- a/qtwayland.pro
+++ b/qtwayland.pro
@@ -2,27 +2,4 @@ load(configure)
qtCompileTest(xkbcommon)
qtCompileTest(brcm_egl)
-TEMPLATE=subdirs
-CONFIG += ordered
-
-module_qtwayland_src.subdir = src
-module_qtwayland_src.target = module-qtwayland-src
-
-module_qtwayland_examples.subdir = examples
-module_qtwayland_examples.target = module-qtwayland-examples
-module_qtwayland_examples.depends = module_qtwayland_src
-!contains(QT_BUILD_PARTS,examples) {
-module_qtwayland_examples.CONFIG = no_default_target no_default_install
-}
-
-module_qtwayland_tests.subdir = tests
-module_qtwayland_tests.target = module-qtwayland-tests
-module_qtwayland_tests.depends = module_qtwayland_src
-module_qtwayland_tests.CONFIG = no_default_install
-!contains(QT_BUILD_PARTS,tests):{
-module_qtwayland_tests.CONFIG += no_default_target
-}
-
-SUBDIRS += module_qtwayland_src \
- module_qtwayland_examples \
- module_qtwayland_tests
+load(qt_parts)
---
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
Op 16-7-2012 23:52, Thiago Macieira schreef: On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: Hello all I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. That being the case, would it be possible to at least document these issues properly then? I think it is not all that clear from the documentation that QList is so inefficient for these cases. I don't think documentation changes are binary incompatible ;-) André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Profile support on Qt
On Tuesday 17 July 2012 Jul, you wrote:
What we presently have in a local branch is:
1) Grabbing embedded color profiles from PNG and JPEG images (eventually
support for more formats will come)
That would be excellent.
2) Non-Automatic conversion of color profiles at load. This is done through
the constructor, where when loading an image you specify weather you preserve
the color profile or you convert to Screen. The default behavior keeps the
loaded image unchanged.
Hm... I would prefer to be able to specify a working space here -- not just the
screen target. That makes it possible to use a linear rgb profile to convert to
real linear rgb and actually be able to do stuff with the pixels.
What we don't have:
1) Exporting images with embedded color profiles
2) Modifying a color profile (access only to high level data such as
description and colorspace)
The API looks as follows:
enum QColorSpace {RGB, CMYK, Invalid}
QColorProfile
-
QString description()
QColorSpace colorspace()
For my applications, I would also want to be able to get the original profile
data out of QColorProfile, btw.
Especially when using the QScreen api.
QImage
-
QColorProfile colorProfile()
void setColorProfile(colorProfile)
void convertToColorProfile(colorProfile)
QScreen
-
QColorProfile colorProfile()
Windows and Mac OS X have built in support for color profile conversion. For
linux X11 supports color profiles after loading several modules, otherwise
uses sRGB. This is where the Oyranos project comes in.
On X11, you can use the X11 atom to check what the user has set -- that works
for both oyranos and colord managed desktops.
All the color profile conversion takes place using the littleCMS library
which seems to be sort of standard for that job. Oyranos is also using it.
yes, lcms2 is pretty much the standard. And it's small and excellent.
From: development-bounces+alexandros.dermenakis=nokia@qt-project.org
[development-bounces+alexandros.dermenakis=nokia@qt-project.org] on
behalf of ext Boudewijn Rempt [b...@valdyas.org]
Sent: Monday, July 16, 2012 9:15 PM
To: development@qt-project.org
Subject: Re: [Development] Color Profile support on Qt
On Monday 16 July 2012 Jul, Olivier Goffart wrote:
All QPainter operations (at least in the raster engine) assume a linear
color
space. That means that the color conversion need to hapen last, right before
being shown to the screen. After all kind of blending operations or anything
done with QPainter. (That means it could even been done in the platform
plugin)
Are you really sure about that? It's extremely unlikely that one encounters a
linear light rgb png file in the wild, for instance, most assume sRGB.
Unmanaged RGB isn't automatically linear, either -- it most likely is just a
mess.
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] buildsystem branches (about to be) integrated
Am 01.07.2012 14:36, schrieb Loaden:
But now I get the new problem:
PATH=D:\qpSOFT\Projects\BuildQt5-m64\qtbase\bin;D:\qpSOFT\MinGW\MinGW64\bin;C:\Perl64\site\bin;C:\Pe
rl64\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShe
ll\v1.0\;C:\Python27;D:\Program Files\Git\cmd
QtWidgets: created headers.pri file
QtTest: created fwd-include header(s) for srcbase/src/testlib/ {
g++ -Wl,-subsystem,console -mthreads -o ../../configure.exe main.o
configureapp.o environment.o tools.o qarraydata.o qbytearray.o
qbytearraymatcher.o qhash.o qlist.o qlocale.o qlocale_win.o
qlocale_tools.o qvector.o qutfcodec.o qtextcodec.o qglobal.o
qnumeric.o qbuffer.o qdatastream.o qdir.o qdiriterator.o
qfiledevice.o qfile.o qfileinfo.o qabstractfileengine.o
qfilesystementry.o qfilesystemengine.o qfilesystemengine_win.o
qfilesystemiterator_win.o qfsfileengine.o qfsfileengine_win.o
qfsfileengine_iterator.o qiodevice.o qtextstream.o qlogging.o
qtemporaryfile.o qsystemlibrary.o qbitarray.o qdatetime.o qmap.o
qregexp.o qstring.o qstringlist.o qvsnprintf.o qvariant.o
qsystemerror.o qmetatype.o qmalloc.o qxmlstream.o qxmlutils.o
quuid.o qcryptographichash.o registry.o -lole32 -ladvapi32 -luuid
g++: error: main.o: No such file or directory
g++: error: configureapp.o: No such file or directory
g++: error: environment.o: No such file or directory
g++: error: tools.o: No such file or directory
g++: error: qarraydata.o: No such file or directory
g++: error: qbytearray.o: No such file or directory
g++: error: qbytearraymatcher.o: No such file or directory
g++: error: qhash.o: No such file or directory
g++: error: qlist.o: No such file or directory
g++: error: qlocale.o: No such file or directory
As there is a solution now to this (thanks to Rafael Roquetto and
Friedemann Kleint), for the record:
The problem is the mingw32-make.exe that comes with 4.7.1. It seems to
be broken, refusing to build the neccessary object files. Use the
mingw32-make.exe that comes with 4.6.2 or 4.6.3.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion on QML portability
On 17.07.2012 07:47, Alan Alpert wrote: But our Qt4Support library exists and is called QtQuick1. All the old symbols should be there, if you want to take the easy road to saying done, ported to Qt 5!. Well, there is no other choice if you have a platform without hardware graphics acceleration. ;-) Sven ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Can I compile QtWayland module alone?
On Tue, Jul 17, 2012 at 03:01:17PM +0900, ext 이광웅 wrote: I can��t compile after git pull. I checked the followings. Actually, I don��t know about qt_parts, so I wonder if it is possible to compile only QtWayland without SUBDIRS. Would you give me any advice? you just need a recent enough qtbase, so pull and recompile that as well. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion on QML portability
2012/7/17 Sven Anderson sven.ander...@snom.com On 17.07.2012 07:47, Alan Alpert wrote: But our Qt4Support library exists and is called QtQuick1. All the old symbols should be there, if you want to take the easy road to saying done, ported to Qt 5!. Well, there is no other choice if you have a platform without hardware graphics acceleration. ;-) [OT] Without _OpenGL_. :-) There are other flavors of hardware acceleration APIs, I expect even more different in the future. (2D accelerators are often bundled with GPUs and perform 2D rendering ops faster than GPUs, but are unusable with QML 2 / SceneGraph; see pvr2d). -- Andreas Aardal Hanssen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Compile fails after Q_DECLARE_SHARED(QDebug)
I saw the following logs when making. And I noticed that Q_DECLARE_SHARED(QDebug) is inserted on latest commit. What am I missing? Would you give me any advice? Thanks g++ -c -m64 -pipe -I/home/kwlee/work/wayland/install/include -g -std=c++0x - fvisibility=hidden -fvisibility-inlines-hidden -D_REENTRANT -Wall -W -fPIC - DXCB_POLL_FOR_QUEUED_EVENT -DXCB_USE_XLIB -DXCB_USE_RENDER -DXCB_USE_EGL - DSUPPORT_X11 -DXCB_USE_IBUS -DQT_COMPILES_IN_HARFBUZZ -DQT_PLUGIN - DQT_PLATFORMSUPPORT_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_CORE_LIB - D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../../../mkspecs/linux-g++-64 -I. -I../../../../include -I../../../../include/QtPlatformSupport -I../../.. /../include/QtPlatformSupport/5.0.0 - I../../../../include/QtPlatformSupport/5.0.0/QtPlatformSupport -I../../../.. /include/QtDBus -I../../../../include/QtGui -I../../../../include/QtGui/5.0. 0 -I../../../../include/QtGui/5.0.0/QtGui -I../../../../include/QtCore - I../../../../include/QtCore/5.0.0 -I../../../../include/QtCore/5.0.0/QtCore -I.moc/debug-shared -I/home/kwlee/work/wayland/install/include -o .obj/debug-shared/qxcbmime.o qxcbmime.cpp In file included from ../../../../include/QtCore/qdebug.h:1:0, from qxcbmime.cpp:47: ../../../../include/QtCore/../../src/corelib/io/qdebug.h: In function ‘void qSwap(T, T) [with T = QDebug]’: ../../../../include/QtCore/../../src/corelib/io/qdebug.h:130:1: error: ‘class QDebug’ has no member named ‘data_ptr’ ../../../../include/QtCore/../../src/corelib/io/qdebug.h:130:1: error: ‘class QDebug’ has no member named ‘data_ptr’ ../../../../include/QtCore/../../src/corelib/io/qdebug.h: In function ‘void std::swap(_Tp, _Tp) [with _Tp = QDebug]’: ../../../../include/QtCore/../../src/corelib/io/qdebug.h:130:1: error: ‘class QDebug’ has no member named ‘data_ptr’ ../../../../include/QtCore/../../src/corelib/io/qdebug.h:130:1: error: ‘class QDebug’ has no member named ‘data_ptr’ make[4]: *** [.obj/debug-shared/qxcbmime.o] Error 1 make[4]: Leaving directory `/home/kwlee/src/qt5/qtbase/src/plugins/platforms/xcb' make[3]: *** [sub-xcb-make_first] Error 2 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compile fails after Q_DECLARE_SHARED(QDebug)
On terça-feira, 17 de julho de 2012 22.02.36, 이광웅 wrote:
I saw the following logs when making.
And I noticed that Q_DECLARE_SHARED(QDebug) is inserted on latest commit.
What am I missing? Would you give me any advice?
../../../../include/QtCore/../../src/corelib/io/qdebug.h: In function
‘void qSwap(T, T) [with T = QDebug]’:
../../../../include/QtCore/../../src/corelib/io/qdebug.h:130:1: error:
‘class QDebug’ has no member named ‘data_ptr’
Q_DECLARE_SHARED is now:
Q_DECLARE_TYPEINFO(TYPE, Q_MOVABLE_TYPE); \
template inline void qSwapTYPE(TYPE value1, TYPE value2) \
{ value1.swap(value2); } \
Q_DECLARE_SHARED_STL(TYPE)
There's no data_ptr in this.
Can you check the status of your headers (the include dirs)? Looks like you
have an old set of QtCore headers that are being found.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Tuesday July 17 2012, Andre Somers wrote: Op 16-7-2012 23:52, Thiago Macieira schreef: [...] That includes the fact that QListQVariant is extremely inefficient. That being the case, would it be possible to at least document these issues properly then? I think it is not all that clear from the documentation that QList is so inefficient for these cases. I don't think documentation changes are binary incompatible ;-) [...] Would a patch that makes certain QList instantiations privately inherit QVector acceptable? I'm thinking QListQModelIndex, QListQVariant, mostly, probably others. That would require a patch that made QList and QVector identical, API-wise, and that, in turn, would require using member; support in the compiler (the QT_NO_USING define is still in the code). 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
Re: [Development] Compile fails after Q_DECLARE_SHARED(QDebug)
On Tuesday July 17 2012, Thiago Macieira wrote:
On terça-feira, 17 de julho de 2012 22.02.36, 이광웅 wrote:
I saw the following logs when making.
And I noticed that Q_DECLARE_SHARED(QDebug) is inserted on latest commit.
What am I missing? Would you give me any advice?
../../../../include/QtCore/../../src/corelib/io/qdebug.h: In function
‘void qSwap(T, T) [with T = QDebug]’:
../../../../include/QtCore/../../src/corelib/io/qdebug.h:130:1: error:
‘class QDebug’ has no member named ‘data_ptr’
Q_DECLARE_SHARED is now:
Q_DECLARE_TYPEINFO(TYPE, Q_MOVABLE_TYPE); \
template inline void qSwapTYPE(TYPE value1, TYPE value2) \
{ value1.swap(value2); } \
Q_DECLARE_SHARED_STL(TYPE)
There's no data_ptr in this.
Can you check the status of your headers (the include dirs)? Looks like you
have an old set of QtCore headers that are being found.
I wonder why it's this change in particular that keeps popping up on the ML...
--
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
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
I'd just be nice to have someone actually test it. Lazlo, could you verify? Thank you for the progress! Looks like pushing works: https://codereview.qt-project.org/#change,30932 Cloning is still flaky through the init-repository perl script for webkit as the example shows above. The documentation should be extended much more. There are at least there pages: 1) Setting up Gerrit (which is still incomplete because scp'ing the commit hook should happen with the -P 443 for this case) 2) Qt5 build page: http://qt-project.org/wiki/Building-Qt-5-from-Git 3) Gerrit introduction page: http://qt-project.org/wiki/Gerrit-Introduction Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Profile support on Qt
On Monday 16 July 2012 20:49:49 Alessandro Portale wrote: On Mon, Jul 16, 2012 at 7:07 PM, Olivier Goffart oliv...@woboq.com wrote: All QPainter operations (at least in the raster engine) assume a linear color space. That means that the color conversion need to hapen last, right before being shown to the screen. After all kind of blending operations or anything done with QPainter. (That means it could even been done in the platform plugin) Good point. That way may automagically solve the issue with which screen (output-) profile to use when painting on a screen. However, color transformations are not cheap and may slow down painting. I already see all kinds of caching in that area :) I'm afraid you will have to re-do the color conversion on each frame. (for what has changed) Color conversion should probably also happen when loading images, to convert them to a linear color space. Right now, Qt do no handle color profiles at all, so it interpret png for example as plain linear RGB instead of sRGB. Would the 'linear' RGB in this case be the screen RGB? Unfortunately not. linear means you can blend images like this: dst = alpha * src + (1 - alpha) * dst Or do anti-aliasing like:dst = src * proportion_of_the_pixel Which is what QPainter does when it blends, when it interpolates, when it scales smoothly, when it does antialiasing, when it draws text, ... QPainter assumes colors are linear. (At least the raster engine do) But in most color profiles, it is not the case. But Qt has chosen to ignore the problem for the reasons of performence. (Even if you can see the difference clearly with naked eyes) But should you integrate color profile in Qt, i guess it should be done properly :-) ... QPainter would remain color profile agnostic, as it is right now. I think indeed QPainter should remain color profile agnostic. But it only gives the correct results on linear color space. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote: On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. this is absurd. we said A, now we need to say B. or unsay A, which i don't think anyone wants. i for one don't believe in qt6 anytime soon. it's the do-never release qt5 was for years. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion on QML portability
On terça-feira, 17 de julho de 2012 15.00.04, marius.storm-ol...@nokia.com wrote: Btw, does this means you are trying/wanting to run Qt 5 on PowerVR chipsets from before 2001? All the PVR chips since Feb. 2001 (Series 4 or higher) support some form of OpenGL/GLES and/or DirectX 8.0 or higher (ANGLE requires DirectX 9, but maybe it can be tweaked to use 8, Windows only of course). From what I understand from past discussions with Andreas, the GPU does exist, but it's busy with video decoding and other operations. Qt and the UI needs to run on the CPU only. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Error compiling qt-creator (from git repository)
Hi, I'm compiling qt-creator and got this error: (...) src/plugins/coreplugin/coreplugin.h:48: Error: Plugin Metadata file Core.json does not exist. Declaration will be ignored make[3]: *** [.moc/release-shared/moc_coreplugin.cpp] Error 1 make[3]: Leaving directory `/Users/leandrosales/QtCreator/src/plugins/coreplugin' make[2]: *** [sub-coreplugin-make_first] Error 2 make[2]: Leaving directory `/Users/leandrosales/QtCreator/src/plugins' make[1]: *** [sub-plugins-make_first-ordered] Error 2 make[1]: Leaving directory `/Users/leandrosales/QtCreator/src' make: *** [sub-src-make_first-ordered] Error 2 I have followed the compilation instruction in the README file and QtSDK from git (latest), in MacOS X (10.7.4). I tried two times: one using clang++ and other using g++. Thanks, Leandro. -- Leandro Melo de Sales Professor at Institute of Computing at Federal University of Alagoas, Brazil PhD candidate in Computer Science Pervasive and Embedded Computing Laboratory, UFCG Twitter: @leandrosalesal The warrior is strong in loyalty, intensity, determination, initiative, persistence, courage and willpower. The warrior is light in the soul, self-trust and compassion. The warrior is often called to take the front when other cowardly make a step backwards. There are warriors on the battlefields and in everyday life. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Profile support on Qt
Hello, All QPainter operations (at least in the raster engine) assume a linear color space. That means that the color conversion need to hapen last, right before being shown to the screen. After all kind of blending operations or anything done with QPainter. (That means it could even been done in the platform plugin) Color conversion should probably also happen when loading images, to convert them to a linear color space. Right now, Qt do no handle color profiles at all, so it interpret png for example as plain linear RGB instead of sRGB. I think QImage should always contains linear color space. I agree. Qt should convert all images to a linear color space when loading them so that this color space can be used as an immediate blending space. The final images should be converted to the device color space (printer, screen, ...) right before they are displayed. It might even be possible to make the system compositor / printer driver accept the images in this intermediate blending space. It they do, Qt does not need to know about the output color profile and the system compositor can do additional blending of output from different applications before applying color correction for the output device. This should be doable for Linux, at least. Are 32 bit ARGB is not enough for what Qt is doing? That is: show an UI on the screen. If you want to do professional image processing you would probably not use QImage, but one of those specialized image processing library that have 16bit per chanel or more capabilities. No. 8 bit per pixel works for sRGB but is not nice for linear color spaces. I think it would be best to use 16 bit per pixel for the immediate blending space. Regards, Ole signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
1) Setting up Gerrit (which is still incomplete because scp'ing the commit hook should happen with the -P 443 for this case) Oh, I am sorry. That is also achievable by the ssh config. Nevertheless, this section needs to be updated, if the existing duplication remains to be in place for good: http://qt-project.org/wiki/Gerrit-Introduction#392c991242b19a7bff02f4001278e5a3 Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion on QML portability
2012/7/17 marius.storm-ol...@nokia.com (2D accelerators are often bundled with GPUs and perform 2D rendering ops faster than GPUs, but are unusable with QML 2 / SceneGraph; see pvr2d). 2D accelerators bundled with GPUs perform 2D rendering ops faster than GPUs? Uhmm... that sentence is conflicting in my head, unless you mean that you are using highly specialized boards with multiple GPUs (n*PVR) on them to do things really really fast in parallel. [OT] No, I really mean dedicated 2D hardware chips outperform GPUs by far. It's easy to do certain common simple 2D graphics faster than most embedded GPUs I know of, even using the CPU. GPUs are built for (1) 3D transformations on textures, (2) vertex-heavy objects and (3) per-pixel shading operations. But it's easily beat for simple 2D operations like blit (e.g., DMA), filtering/scaling (e.g., FPGAs). Most mobiles / tablet UIs are 90% 2D. My point is simply that Qt 5 is best served with a painting backend for QML 2 that can support non-OpenGL technologies. -- Andreas Aardal Hanssen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Profile support on Qt
Alessandro Portale alessandro at casaportale.de writes: On Mon, Jul 16, 2012 at 7:07 PM, Olivier Goffart olivier at woboq.com wrote: All QPainter operations (at least in the raster engine) assume a linear color space. That means that the color conversion need to hapen last, right before being shown to the screen. After all kind of blending operations or anything done with QPainter. (That means it could even been done in the platform plugin) Good point. That way may automagically solve the issue with which screen (output-) profile to use when painting on a screen. However, color transformations are not cheap and may slow down painting. I already see all kinds of caching in that area :) Drawing during displaying on the fly is a typical approach. osX does this implicitly and always accelerated. On Windows conversion will happen on the CPU and only after explicitly requested. For Linux it is/will be a mixture. Color conversion should probably also happen when loading images, to convert them to a linear color space. Right now, Qt do no handle color profiles at all, so it interpret png for example as plain linear RGB instead of sRGB. Would the 'linear' RGB in this case be the screen RGB? RGB without a Sounds quite unusual. profile has little meaning in a color management workflow. Imho, agreed! QImage could continue loading the raw rgb-data as-is and additionally load/hold the profile of the image (or the very common sRgb tag) in order to use that as input profile at the end when painting. This would also make sure that there is only one color transformation in the (load - display) workflow. Two color transformations will cause quantisation artifacts, esp. with 8-data. Keeping the ICC profile around is a good entry strategy. Just a few questions: 1) Would Qt use (and ship) a color conversion library, or would the system library be used where available (e.g. on OSX and Windows)? Regarding native platform support, we should work together with Oyranos developers. While their API is horrible (maybe because it is so non-Qt'ish), they have in-depth knowledge about the theory and the praxis of color management. Maybe with their expertise, we can create a nice API for application developers to interface the platforms. agreed, a Qt specific abstraction would be desirable for C++ and QImage. I'd say Qt should use an external library for that. This problem has already been solved, and there is no reason to reinvent the wheel. That said, I'm saying that without knowing what are the available libraries. There are free libraries that do icc profile based color conversions. Qt could ship one of those as 3rd-party code. The functionality that was missing in any of these libraries -last time I looked-, is a cross platform API to get the current system profile for a screen. I did not yet look at Oyranos, though. My 2 cents. If I may sketch a very dirty, basic API set which could imho enable different cases for color savvy application develpers: QImage::QImage(...) // Constructors would load image input profile or standard profile tag (sRgb/Adobe Rgb). QICCProfile QImage::profile(); // Returns the original image input profile. (Yes, this should be part of QtColorManagement, not QtGui. This sketch *is* dirty) The QICCProfile should at least expose a QByteArray on each platform to obtain the raw ICC blob beside the internal description and ICC ID. static QICCProfile QtColorManagement::systemProfile(int screenID = 0); // Return the current system profile for a specific screen (TODO: printer?) That API would need a concept of device listings and driver contexts for display outputs, scanners, printers and cameras. static QImage QtColorManagement::profileTranformedImage(const QImage image, const QICCProfile outputProfile) // The resulting Image data is now in the colorspace of a specific screen or printer(cmyk?) void QtColorManagement::profileTranformedImage(const QImage image_in, const QICCcontext conversion, QImage image_out); // Conversions can happen in place static QImage QtColorManagement::profileTranformedColor(const QColor color, const QICCProfile inputProfile, const QICCProfile outputProfile) // Transforming single colors. ... QPainter would remain color profile agnostic, as it is right now. For the long plan, I doubt that would be useful. For now it is a big step forward to store ICC profiles along a QImage as meta data. Considered can as well a general framework to store IPC, Exif and other information additional to ICC profile for each loaded image. Such an API would avoid all automatic conversions by default, and simply provide cross platform helpers for app developers who decide to consciously do color management. QtWebkit could of course perform color management as Safari does: If a loaded image has a profile/tag match it to screen. The Quartz backend for webkit in Safari tags all
Re: [Development] Abandoning the container changes
On Tue, Jul 17, 2012 at 05:19:23PM +0200, Oswald Buddenhagen wrote: On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote: On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. this is absurd. Incidentally, I agree. [Even if I lack the skill to express myself so clearly at times ;-}] we said A, now we need to say B. or unsay A, which i don't think anyone wants. i for one don't believe in qt6 anytime soon. it's the do-never release qt5 was for years. The suggested 4 years are 3 1/2 years too much anyway. That's 3 1/2 years more of forcing people to re-invent the wheel when it comes to performance-sensitive components in a Qt environment, and it's 3 1/2 years on top of the past half decade or so where Qt containers fail to deliver on one of the original reasons to have them at all (portability, convenience of use, _and_ performance). We do have the chance to fix it _now_, and we have a fairly decent idea of how the fix looks like. The whole change is essentially source compatible, i.e. has a low probability of breaking other components, and it is very well covered by autotests. The chances to be ready before the rest (Webkit Windows? Mac?) is ready for a 5.0 release are good. To get back on the constructive side I propose to do any of the following, in decreasing order of desirability: (A) Have the QString/QByteArray related bits in 5.0. (B) Have everything in 5.0. (C) Don't do anything for 5.0, but aim for a 6.0 instead for a 5.1 next. (D) Don't do anything for 5.0, but allow 5.1 to be source compatiple but binary incompatible. (E) Don't do anything for 5.0, and provide a compile-time switch for 5.1 to select between current and patched versions, default to current. [This is probably the most expensive solution, but the one that fits best to the rules] Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Missing MacOS Qt5 beta installer (IT WAS: Experimental Qt 5 installers by Digia)
There's a mac package now at http://releases.qt-project.org/digia/2012-07-17/qt-mac-opensource-5.0.0-beta1-offline.dmg Perhaps building the mac package takes a bit longer than the others. -- Jason From: development-bounces+jason.mcdonald=nokia@qt-project.org [development-bounces+jason.mcdonald=nokia@qt-project.org] on behalf of ext Leandro Melo de Sales [leandr...@gmail.com] Sent: Tuesday, July 17, 2012 6:54 PM To: Storm-Olsen Marius (Nokia-MP/Austin) Cc: tuukka.turu...@digia.com; development@qt-project.org Subject: Re: [Development] Missing MacOS Qt5 beta installer (IT WAS: Experimental Qt 5 installers by Digia) Hi Tuukka and others, I have checked again the current directory for Qt5 beta installers and, once again, the MacOS .dmg installer was not built. Why? The latest available was compiled in 2012-07-13. Thank you, Leandro. 2012/7/15 Leandro Melo de Sales leandr...@gmail.commailto:leandr...@gmail.com Hi, Why the current installers directory (http://releases.qt-project.org/digia/2012-07-14/) does not contain a .dmg file for QtSDK? Maybe it happened an error while compiling Qt for MacOS... -- Leandro Melo de Sales Professor at Institute of Computing at Federal University of Alagoas, Brazil PhD candidate in Computer Science Pervasive and Embedded Computing Laboratory, UFCG Twitter: @leandrosalesal The warrior is strong in loyalty, intensity, determination, initiative, persistence, courage and willpower. The warrior is light in the soul, self-trust and compassion. The warrior is often called to take the front when other cowardly make a step backwards. There are warriors on the battlefields and in everyday life. 2012/7/13 Leandro Melo de Sales leandr...@gmail.commailto:leandr...@gmail.com: Ok... thanks. 2012/7/13 marius.storm-ol...@nokia.commailto:marius.storm-ol...@nokia.com When using the links below, please ensure that you are not redirected to URLs which has “origin.” prefixed. If you are on a http://origin.releases.qt-project.org/... URL, you are downloading from the “master” machine, and it will be slow. Simply remove the “origin.” prefix, and you should be using the CDN, and download the packages much much faster. We are not quite sure why this redirect is happening. -- .marius From: releasing-bounces+marius.storm-olsen=nokia@qt-project.orgmailto:nokia@qt-project.org [mailto:releasing-bounces+marius.storm-olsenmailto:releasing-bounces%2Bmarius.storm-olsen=nokia@qt-project.orgmailto:nokia@qt-project.org] On Behalf Of ext Turunen Tuukka Sent: Thursday, July 12, 2012 9:00 AM To: releas...@qt-project.orgmailto:releas...@qt-project.org; development@qt-project.orgmailto:development@qt-project.org Subject: [Releasing] Experimental Qt 5 installers by Digia Hi All, As you know we have been working in close co-operation in the Qt Project for making the installers for Qt 5 as well as the tools to create these. If you wish, you can take a look on the experimental installers we create at: http://releases.qt-project.org/digia/ Currently the installers are built each night from the latest stable Qt 5 and placed to the above mentioned location. If the build or packaging fails, then that installer is omitted. Though called beta1, these are currently made with the latest Qt 5, which as we know has not yet reached beta maturity. These are additional to the ones you can get from http://releases.qt-project.org/qt5.0/beta-snapshots/ In essence these should be identical. While we cook with the same recipes, these are baked in our kitchen that has some differences to the Qt Project build machines. So sometimes there are differences in the created installers as well. Having two different setups is good in verifying that the recipes really work and that there are not too many 'secret ingredients' in either one of the cookings. Unfortunately we can not yet provide build logs or release test results, so it may be hard to determine what is wrong based on just these. Also we are not running any automated tests to these installers like we do for the Qt 4.8 ones, so there may well be whatever regressions in these. So please regard these as experimental installers that they are. Yours, -- Tuukka Turunen Director, Qt Commercial RD Digia Plc Piippukatu 11, 40100 Jyväskylä, Finland Visit us at: www.digia.comhttp://www.digia.com or qt.digia.comhttp://qt.digia.com ___ 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] Compile fails after Q_DECLARE_SHARED(QDebug)
Exactly, you're right. The old headers has been included.
I should separate other install prefixes from Qt.
Really, thanks.
Elvis.
--
Elvis Lee (이광웅)
Software Engineer @ LG Electronics Inc.
CTO Division / SW Platform Lab. / Advanced OS Tech Team.
Yang-jae dong 221, Seoul, Korea.
-Original Message-
From: development-bounces+kwangwoong.lee=lge@qt-project.org
[mailto:development-bounces+kwangwoong.lee=lge@qt-project.org] On
Behalf Of Thiago Macieira
Sent: Tuesday, July 17, 2012 10:12 PM
To: development@qt-project.org
Subject: Re: [Development] Compile fails after Q_DECLARE_SHARED(QDebug)
On terça-feira, 17 de julho de 2012 22.02.36, 이광웅 wrote:
I saw the following logs when making.
And I noticed that Q_DECLARE_SHARED(QDebug) is inserted on latest commit.
What am I missing? Would you give me any advice?
../../../../include/QtCore/../../src/corelib/io/qdebug.h: In function
‘void qSwap(T, T) [with T = QDebug]’:
../../../../include/QtCore/../../src/corelib/io/qdebug.h:130:1: error:
‘class QDebug’ has no member named ‘data_ptr’
Q_DECLARE_SHARED is now:
Q_DECLARE_TYPEINFO(TYPE, Q_MOVABLE_TYPE); \ template inline void
qSwapTYPE(TYPE value1, TYPE value2) \ { value1.swap(value2); } \
Q_DECLARE_SHARED_STL(TYPE)
There's no data_ptr in this.
Can you check the status of your headers (the include dirs)? Looks like
you have an old set of QtCore headers that are being found.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Error compiling qt-creator (from git repository)
On 07/18/2012 02:49 AM, ext Leandro Melo de Sales wrote: I'm compiling qt-creator and got this error: (...) src/plugins/coreplugin/coreplugin.h:48: Error: Plugin Metadata file Core.json does not exist. Declaration will be ignored You're shadow building. I noticed this the other day. The problem is that the .json files are generated. You could force them to be created in the source tree (as per https://codereview.qt-project.org/#change,30732) but since creating files in the source tree is bad form, the real fix will be to have moc search in the build tree for these files. I'm not sure if there's a change for that yet. -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion on QML portability
On 07/18/2012 05:17 AM, ext Andreas Aardal Hanssen wrote: My point is simply that Qt 5 is best served with a painting backend for QML 2 that can support non-OpenGL technologies. I don't want to start a flame war here but I always wondered why QtQuick 2 had to mean SceneGraph/OpenGL and why the new/changed QML types couldn't be separate to the display engine. Obviously from a C++ perspective you have to know which engine you're using but the QML environment is insulated from the display engine, right? Maybe it's because the QML types are implemented in C++ that makes it difficult to support them across display engines... -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion on QML portability
On Wed, 18 Jul 2012 13:28:02 ext Lincoln Ramsay wrote: On 07/18/2012 05:17 AM, ext Andreas Aardal Hanssen wrote: My point is simply that Qt 5 is best served with a painting backend for QML 2 that can support non-OpenGL technologies. I don't want to start a flame war here but I always wondered why QtQuick 2 had to mean SceneGraph/OpenGL and why the new/changed QML types couldn't be separate to the display engine. QtQuick 2 has to mean SceneGraph/OpenGL because the QtQuick module provides the visual primitives. It is the display/user-input engine, thus QQuickItems need to run on a QQuickWindow and QDeclarativeItems need to run in a QGraphicsScene. QML 2, now split out into the QtQml module, is separate to the display engine. If you're more thinking widget style of a single Rectangle that chooses SGRect or GVRect behind the scenes, that's not how QML items are abstracted. QtQuick provides graphical primitives which you use to create your widgets, QtQuick 2.0's Rectangle is the SGRect and QtQuick 1.0's Rectangle is the GVRect. As people have noticed, we haven't done a great job in making it easy to choose one behind the scenes :( . But the future is clearly 3D GL in the general case, so long as niche 2D CPU applications are supported somehow the 3D display engine should be the default and supported as well as possible. Obviously from a C++ perspective you have to know which engine you're using but the QML environment is insulated from the display engine, right? Maybe it's because the QML types are implemented in C++ that makes it difficult to support them across display engines... The display engines are radically different, and we don't have some QGraphicsProxySceneGraph element to go between them. As for the QML environment, not the different display engines, implementation issues are the reason why QtQuick 1.0 can't be run in a QQmlEngine (I say can't because maybe they can, I've never tried). There have been changes to the engine and language due to V8 integration, and although these are supposed to be much more compatible there are behavioural changes. The QDeclarativeEngine is left around for QtQuick 1 because that way your QtQuick 1 applications can use the old engine for less chance of behavioural regressions. Not because QtQuick 1 is fundamentally incompatible with QQmlEngine. Theoretically you can have two different windows running the two different display engines but sharing one QML engine - I've just never tried and I doubt it would be a high priority bug if that didn't work ;) . -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
