[Development] Modifying QQmlFileSelector selector at runtime without Loader or Component
Hello,
I would like to modify the extraSelectors of QQmlFileSelector at runtime
and have QML load the new QML file from the appropriate selector folder.
I have gotten this to work by calling setExtraSelectors() from a C++
object I have exposed to QML and then forcing a re-evaluation of the
Loader's source property:
Loader {
id: myLoader
source: Qt.resolvedUrl(MyItem.qml)
}
Connections {
target: myCppObject
onSelectorChanged: myLoader.source = Qt.resolvedUrl(MyItem.qml)
}
Now, for my use case I really need the ability to achieve the same
behavior without using Loader or Component. I essentially want something
like this:
MyItem { }
Connections {
target: myCppObject
onSelectorChanged: // when selector changes, the MyItem instance
above is automatically resolved to the MyItem definition in the
appropriate selector folder.
How can this be accomplished?
Thanks!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Stopping a QProcess gracefully
Hello, I am trying to find the proper way to gracefully exit a QProcess. The particular process that I am running does some work and then is in a waiting state, exiting only when the user presses the Enter key. This works fine when the executable is run from the command line. The problem I am having is that every way I have tried to stop the QProcess results in the error signal being emitted; in such cases, errorString() always returns Process crashed. I have tried: (1) Calling QProcess::terminate() (2) Calling QProcess::kill() (3) Writing the return key to the process with QProcess::write(\r) and QProcess::write(\\r) (4) Sending a Qt::Key_Return using qApp-sendEvent() to the QProcess object (though it's not clear to me that QKeyEvents sent to the QProcess get automatically forwarded to the executable they have spawned). In summary, how can I stop this QProcess properly without having the error signal emitted? Thanks! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Stopping a QProcess gracefully
On Wed, Aug 06, 2014 at 11:19:49PM -0700, achart...@fastmail.fm wrote: (3) Writing the return key to the process with QProcess::write(\r) and QProcess::write(\\r) you need to use waitForBytesWritten() (or actually wait for the signal to be delivered). Thanks! Forgot write was asynchronous. Using waitForBytesWritten() and sending \u000A instead of \r or \\r did the trick. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Development Digest, Vol 32, Issue 29
Em ter 13 maio 2014, ?s 12:28:11, achart...@fastmail.fm escreveu: Hi all, I would like to enable the -Weverything and -Werror Clang compiler flags for my application code to treat all warnings as errors. Please note that Qt compiles mostly cleanly with -Wall -Wextra -Werror. We do not support -Weverything, since it produces warnings that are, well, stupid. Unfortunately, Qt itself generates a large number of warnings. I would like to suppress the warnings generated for Qt code but have Clang report all the warnings (errors) in my application code. I have searched a lot on this subject and have not found a solution that really works. The proper way to do this is to use the -isystem flag and specify the Qt include directories so they may be treated as system headers, however qmake seems to always pass the Qt include directories with the -I argument no matter what I do (I even tried INCLUDEPATH -= Qt_include_dirs to no avail). Make sure you're using 5.3. If so, qmake will automatically use -isystem for all system header paths. Note: *system* header paths. You need to install Qt in one of the system header paths for that to take effect. That is, /usr/include or /usr/local/include or one of the rest listed in: $ grep DEFAULT_INCDIRS mkspecs/qconfig.pri QMAKE_DEFAULT_INCDIRS = /usr/include/c++/4.8 /usr/include/c++/4.8/x86_64- suse-linux /usr/include/c++/4.8/backward /usr/lib64/gcc/x86_64-suse- linux/4.8/include /usr/local/include /usr/lib64/gcc/x86_64-suse- linux/4.8/include-fixed /usr/x86_64-suse-linux/include /usr/include The only approach that has worked so far is to use the -Wno flag to disable certain warnings. This is far from desirable, as then the warning checking in my application code is tied to the quality of the Qt codebase. We only need -Wno-error=deprecated-register and that's because of a macro from glibc (Linux). No other flags are necessary with -Wall -Wextra. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Thanks Thiago, I'm glad to hear -isystem is supported. I'll give this a try with the Qt 5.3 release. Regarding QMAKE_DEFAULT_INCDIRS: is it possible to append additional paths to this variable from within project files? Thanks again! Alfonso ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt warnings and -Weverything/-Werror
Hi all, It looks like Thiago Macieira committed a fix for this back in January (just add paths to QMAKE_DEFAULT_INCDIRS). I am currently using Qt 5.2.1. Does this mean that this fix is present in the upcoming Qt 5.3 release? Also, with the QMAKE_DEFAULT_INCDIRS approach, is the path addition logic recursive (i.e., -isystem will apply to all subfolders) or do child folders need to be listed explicitly (I'm hoping it's recursive)? Thanks, Alfonso On Tue, May 13, 2014, at 12:28 PM, achart...@fastmail.fm wrote: Hi all, I would like to enable the -Weverything and -Werror Clang compiler flags for my application code to treat all warnings as errors. Unfortunately, Qt itself generates a large number of warnings. I would like to suppress the warnings generated for Qt code but have Clang report all the warnings (errors) in my application code. I have searched a lot on this subject and have not found a solution that really works. The proper way to do this is to use the -isystem flag and specify the Qt include directories so they may be treated as system headers, however qmake seems to always pass the Qt include directories with the -I argument no matter what I do (I even tried INCLUDEPATH -= Qt_include_dirs to no avail). The only approach that has worked so far is to use the -Wno flag to disable certain warnings. This is far from desirable, as then the warning checking in my application code is tied to the quality of the Qt codebase. This bug report (https://bugreports.qt-project.org/browse/QTBUG-7220) seems to indicate that this is currently not possible with qmake. I hope this isn't the case and that someone has a solution for this problem. Any help is greatly appreciated. Thanks, Alfonso ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QSGNode::markDirty no longer works?
Hi,
I had a QQuickItem-based 2D linegraph working fine in prior versions of
Qt 5. This code does not seem to work with Qt 5.2 RC 1. Below is the
relevant code of my QQuickItem-based linegraph:
QSGNode* Linegraph::updatePaintNode(QSGNode* oldNode,
UpdatePaintNodeData* updatePaintNodeData)
{
Q_UNUSED(updatePaintNodeData);
QSGGeometryNode* node = nullptr;
QSGGeometry* geometry = nullptr;
QSGFlatColorMaterial* material = nullptr;
if (!oldNode)
{
node = new QSGGeometryNode();
geometry = new
QSGGeometry(QSGGeometry::defaultAttributes_Point2D(), 1000);
geometry-setLineWidth(1);
geometry-setDrawingMode(GL_LINE_STRIP);
geometry-allocate(1000);
node-setGeometry(geometry);
node-setFlag(QSGNode::OwnsGeometry);
material = new QSGFlatColorMaterial();
node-setMaterial(material);
node-setFlag(QSGNode::OwnsMaterial);
}
else
{
node = static_castQSGGeometryNode*(oldNode);
geometry = node-geometry();
material = static_castQSGFlatColorMaterial*(node-material());
}
const QRectF bounds = boundingRect();
const float horizontalPointSpacing = (float)bounds.width() / (1000 -
1.0f);
QSGGeometry::Point2D* vertices = geometry-vertexDataAsPoint2D();
float currentX = 0.0f;
float currentY = 0.0f;
for (quint32 pointIndex = 0; pointIndex m_numOfTracePoints;
++pointIndex)
{
currentX = 1.0f + pointIndex * horizontalPointSpacing;
currentY = qBound(0.0f, (m_data[pointIndex] * (-1)) / 10.0f,
1.0f) * (float)bounds.height();
vertices[pointIndex].set(currentX, currentY);
}
node-markDirty(QSGNode::DirtyForceUpdate);
return node;
}
In prior versions of Qt, the second to last line
(node-markDirty(QSGNode::DirtyForceUpdate)) was needed, otherwise
updates to the vertices point array would not be reflected in what
gets drawn. Now, with Qt 5.2 RC 1, changes made to the points stored in
the vertices point array are never reflected in what is drawn:
whatever the array is initialized with is what is drawn in all
subsequent updates.
Is this a user error on my part? Should I be using something other than
QSGNode::markDirty to force the vertices point array changes to take
effect? Or is this perhaps a bug in Qt 5.2 RC 1?
Any help is greatly appreciated.
Thanks.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSGNode::markDirty no longer works?
It looks like using QSGNode::DirtyGeometry did the trick. I would have
expected QSGNode::DirtyForceUpdate to work though. Is this a bug?
On Wed, Dec 4, 2013, at 02:14 PM, achart...@fastmail.fm wrote:
Hi,
I had a QQuickItem-based 2D linegraph working fine in prior versions of
Qt 5. This code does not seem to work with Qt 5.2 RC 1. Below is the
relevant code of my QQuickItem-based linegraph:
QSGNode* Linegraph::updatePaintNode(QSGNode* oldNode,
UpdatePaintNodeData* updatePaintNodeData)
{
Q_UNUSED(updatePaintNodeData);
QSGGeometryNode* node = nullptr;
QSGGeometry* geometry = nullptr;
QSGFlatColorMaterial* material = nullptr;
if (!oldNode)
{
node = new QSGGeometryNode();
geometry = new
QSGGeometry(QSGGeometry::defaultAttributes_Point2D(), 1000);
geometry-setLineWidth(1);
geometry-setDrawingMode(GL_LINE_STRIP);
geometry-allocate(1000);
node-setGeometry(geometry);
node-setFlag(QSGNode::OwnsGeometry);
material = new QSGFlatColorMaterial();
node-setMaterial(material);
node-setFlag(QSGNode::OwnsMaterial);
}
else
{
node = static_castQSGGeometryNode*(oldNode);
geometry = node-geometry();
material = static_castQSGFlatColorMaterial*(node-material());
}
const QRectF bounds = boundingRect();
const float horizontalPointSpacing = (float)bounds.width() / (1000 -
1.0f);
QSGGeometry::Point2D* vertices = geometry-vertexDataAsPoint2D();
float currentX = 0.0f;
float currentY = 0.0f;
for (quint32 pointIndex = 0; pointIndex m_numOfTracePoints;
++pointIndex)
{
currentX = 1.0f + pointIndex * horizontalPointSpacing;
currentY = qBound(0.0f, (m_data[pointIndex] * (-1)) / 10.0f,
1.0f) * (float)bounds.height();
vertices[pointIndex].set(currentX, currentY);
}
node-markDirty(QSGNode::DirtyForceUpdate);
return node;
}
In prior versions of Qt, the second to last line
(node-markDirty(QSGNode::DirtyForceUpdate)) was needed, otherwise
updates to the vertices point array would not be reflected in what
gets drawn. Now, with Qt 5.2 RC 1, changes made to the points stored in
the vertices point array are never reflected in what is drawn:
whatever the array is initialized with is what is drawn in all
subsequent updates.
Is this a user error on my part? Should I be using something other than
QSGNode::markDirty to force the vertices point array changes to take
effect? Or is this perhaps a bug in Qt 5.2 RC 1?
Any help is greatly appreciated.
Thanks.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Quick Controls native styling on mobile platforms?
Hi, In BogDan's blog post about Qt for Android (http://www.kdab.com/qt-on-android-episode-1/), in the first table he mentions that native styling for Android will be available in Qt 5.2. Using Qt 5.2 RC1, it doesn't seem like native styling is available. Is this something still planned for Qt 5.2 final, has it been pushed out to a later release, or do I need to explicitly enable it in some way? I am also very much interested in iOS development with Qt and have the same questions for that platform It would be great to have tables detailing the available features by module for iOS just like the ones BogDan made for Android, as they do a great job of succinctly communicating what is and is not supported on these new platforms and what can be expected in upcoming releases. Thanks, Alfonso ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Validating JSON with schema?
Hello, I am wondering if there are any plans to support the validation of JSON data in Qt using a JSON schema. Qt supports the validation of XML using an XML schema with QtXmlPatterns (example: http://qt-project.org/doc/qt-4.8/xmlpatterns-schema.html). What is the likelihood that we will see similar functionality for JSON in the near future? Thanks, Alfonso ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] constexpr and qMetaTypeId()
Message: 1
Date: Wed, 11 Sep 2013 19:12:26 -0700
From: Thiago Macieira thiago.macie...@intel.com
Subject: Re: [Development] constexpr and qMetaTypeId()
To: development@qt-project.org
Message-ID: 3962396.DaoebYs1tu@tjmaciei-mobl2
Content-Type: text/plain; charset=us-ascii
On quarta-feira, 11 de setembro de 2013 14:29:44, achart...@fastmail.fm
wrote:
Hello,
I'd like to use qMetaTypeId() in a constexpr expression.
You can't. The types are registered at runtime.
Any help is greatly appreciated.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Message: 5
Date: Thu, 12 Sep 2013 09:47:26 +0200
From: Stephen Kelly stephen.ke...@kdab.com
Subject: Re: [Development] constexpr and qMetaTypeId()
To: development@qt-project.org
Message-ID: 6202252.jE7UbQaEne@hal
Content-Type: text/plain; charset=us-ascii
On Wednesday, September 11, 2013 14:29:44 achart...@fastmail.fm wrote:
Hello,
I'd like to use qMetaTypeId() in a constexpr expression. I have my own
custom type declared as such:
class MyCustomClass : public QObject
{
Q_OBJECT
// ...
};
Q_DECLARE_METATYPE(MyCustomClass*)
Unless you need to stay Qt 4 compatible, you can remove this line.
Pointers to
QObject derived types are automatically treated as metatypes if needed.
I then try the following:
constexpr qint32 metaTypeId = qMetaTypeIdMyCustomClass*();
This only works for built-in metatypes which have an id value defined in
the
QMetaType::Type enum.
Thanks,
--
Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com
Stephen Kelly stephen.ke...@kdab.com | 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
Thank you Thiago and Stephen for the information. I am, however, still
confused by both of your responses.
Thiago - The qMetaTypeId documentation
(http://qt-project.org/doc/qt-5.1/qtcore/qmetatype.html#qMetaTypeId)
specifically states that the type registration using this function is
resolved at compile-time, not run-time.
Stephen - The qMetaTypeId documentation goes on to provide a code
snippet where a custom type (MyStruct) is registered, so it would seem
this should work for non-built-in types as well.
As such, the documentation leads one to believe that qMetaTypeId can be
used to register one's custom type at compile-time, as I tried to do in
the code snippet in my original query.
Is the documentation completely wrong or is a compile-time type
registration still possible in some way? I am very interested in this,
as the system I am working on would greatly benefit from this
functionality.
Thanks again,
Alfonso
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] constexpr and qMetaTypeId()
Hello,
I'd like to use qMetaTypeId() in a constexpr expression. I have my own
custom type declared as such:
class MyCustomClass : public QObject
{
Q_OBJECT
// ...
};
Q_DECLARE_METATYPE(MyCustomClass*)
I then try the following:
constexpr qint32 metaTypeId = qMetaTypeIdMyCustomClass*();
static_assert(metaTypeId != 0, boo, qMetaTypeId failed);
and I get the following compiler errors:
/opt/Qt/Qt5.1.1/5.1.1/gcc_64/include/QtCore/qmetatype.h:640: error:
'static constexpr int QMetaTypeId2T::qt_metatype_id() [with T =
MyCustomClass*]' called in a constant expression
return QMetaTypeId2T::qt_metatype_id();
^
/opt/Qt/Qt5.1.1/5.1.1/gcc_64/include/QtCore/qmetatype.h:532: 'static
constexpr int QMetaTypeId2T::qt_metatype_id() [with T =
MyCustomClass*]' is not usable as a constexpr function because:
static inline Q_DECL_CONSTEXPR int qt_metatype_id() { return
QMetaTypeIdT::qt_metatype_id(); }
^
/opt/Qt/Qt5.1.1/5.1.1/gcc_64/include/QtCore/qmetatype.h:532: error: call
to non-constexpr function 'static int
QMetaTypeIdMyCustomClass*::qt_metatype_id()'
static inline Q_DECL_CONSTEXPR int qt_metatype_id() { return
QMetaTypeIdT::qt_metatype_id(); }
^
Looking at the definitions for these functions in qmetatype.h, many of
these have the Q_DECL_CONSTEXPR macro, so I'm assuming this should work,
but it looks like QMetaTypeIdT::qt_metatype_id() is not marked
constexpr even though all the other functions that rely on it in this
case are.
Question: is this a bug? Is a Q_DECL_CONSTEXPR missing somewhere? I was
unable to find the definition of QMetaTypeIdT::qt_metatype_id() to
verify whether or not it is marked as constexpr. Given the prevalence of
Q_DECL_CONSTEXPR for many of these functions, I'm assuming the intent is
to be able to write something like the code I have written above, but
clearly, something isn't quite right.
Any help is greatly appreciated.
Thanks,
Alfonso
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] constexpr construct QObject?
Hi all, I'm wondering if QObject could be made to be constexpr constructable. I haven't taken a look at the QObject source code, so it may not be possible given the types of operations that need to be performed when constructing a QObject, but I thought I'd ask anyway. I have seen some cases in our team's code where we have potentially hundreds of objects that need to be constructed. The initial data for these classes is known at compile-time and it would be really nice to be able to constexpr construct these objects to avoid the run-time object instantiation overhead. At the same time, it's desirable for these same objects to derive from QObject to make use of signals/slots, properties, Qt parent-child memory management, etc. as well. Hence, my original question of whether QObject could be made constexpr constructable. :) Has anyone already looked into this? Is it even possible? Thanks! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
