[Interest] saving data using QtSql during shutdown
Hi, I am finishing an embedded system, using Linux and Qt as the base of the application that manages the system, and as a manager to a SQLite database for this application. As it will be using a flash SATA module, I would not like to do many and frequent write operations to it. So, I would like to know, on a ACPI shutdown request, how to safely commit the remaining data to the database. Thanks Francisco ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] saving data using QtSql during shutdown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is the closeEvent called when the application shuts down? That would be my first guess. Emmanuel Bourgerie Web developer Dublin, Ireland (+353) 8 144 5278 http://bourgerie.fr/ Confus avec BEGIN PGP SIGNED MESSAGE ? http://weusepgp.info/fr Confused with BEGIN PGP SIGNED MESSAGE? http://weusepgp.info/ On 11/11/2013 12:16, Francisco Ares wrote: Hi, I am finishing an embedded system, using Linux and Qt as the base of the application that manages the system, and as a manager to a SQLite database for this application. As it will be using a flash SATA module, I would not like to do many and frequent write operations to it. So, I would like to know, on a ACPI shutdown request, how to safely commit the remaining data to the database. Thanks Francisco ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) iQEcBAEBAgAGBQJSgMsUAAoJEKKGwafy1e1+q8oIAKgtLkVbtCt9TVwv0AJxn/kx FYauq/uWFRxCrw4CyTh5K6FfLyRe/PWSnXPNWZj+tpThPyrsWstpIcm4RkCYUrlQ oK7WnvwjkS1KjrybEN+6PDNARye1nX3AEDW++LAr35Vr9xmEryZaWZ3dCamxAc9Z bK5W8PheE78l7+p86WMSf/hwCzYybREJlrXmMiq0EIR8f/V7RGh2QM8tbcYyVinQ wYEZOl3ozGnt6Pu+WHSNkKSb/wsnJe+ViwtPk1HNLWFnFcT4KYoIbqm/1YtlvlkC p6lu0P9PGumeOpTwvBcfUff3CEzSWX2jVmx+F76bn1DJkYgkuDtdRQ+cGZK8cw8= =R98A -END PGP SIGNATURE- ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QStringList, takeFirst and order of execution
Hi, I have been experiencing a strange behavior with QStringList and the order of execution of takeFirst. The following code: QString line = file.readLine(); // line contains 46 71\n QStringList lineData = line.split(); // lineData contains (46, 71\n) qDebug() lineData.takeFirst() lineData.takeFirst(); behaves differently on two computers. The first one is a MacOS X 10.8.5 with Xcode 4.6.3 installed and using the 5.2.0 alpha package with gcc The second one is a MacOS X 10.8.5 with Xcode 5.0.1 installed and a developer build (no special configuration) of the latest stable branches from git with clang The first computer outputs 71\n 46 and the second one 46 71\n The same happens if I build e.g. a QSize using: QSize mySize = QSize(lineData.takeFirst().toInt(), lineData.takeFirst().toInt()); on the other hand, if I call qDebug() lineData.takeFirst(); qDebug() lineData.takeFirst(); The order is correct on both of them. What could explain the difference ? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] saving data using QtSql during shutdown
On segunda-feira, 11 de novembro de 2013 10:16:18, Francisco Ares wrote: Hi, I am finishing an embedded system, using Linux and Qt as the base of the application that manages the system, and as a manager to a SQLite database for this application. As it will be using a flash SATA module, I would not like to do many and frequent write operations to it. So, I would like to know, on a ACPI shutdown request, how to safely commit the remaining data to the database. Make the ACPI shutdown request cause some noticeable change in the application state. For example, a SIGTERM, which you can catch and cause the data to be saved. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QStringList, takeFirst and order of execution
On segunda-feira, 11 de novembro de 2013 13:37:20, Samuel Gaist wrote: Hi, I have been experiencing a strange behavior with QStringList and the order of execution of takeFirst. qDebug() lineData.takeFirst() lineData.takeFirst(); The problem is not takeFirst. behaves differently on two computers. Correct. You have undefined behaviour. Both calls to takeFirst() are in the same sequence-point. That means the compiler is allowed to execute in any order. It would be the same if you had written: f(lineData.takeFirst(), lineData.takeFirst()); qDebug() lineData.takeFirst(); qDebug() lineData.takeFirst(); The order is correct on both of them. What could explain the difference ? In the second case, there are two sequence points (they are separated by a ;). In C++11-speak, the first line of the second example is guaranteed to happens- before the second line. In the first example, there's no happens-before, therefore any one can happen before the other, or after. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QStringList, takeFirst and order of execution
Il 11/11/2013 13:37, Samuel Gaist ha scritto: Hi, I have been experiencing a strange behavior with QStringList and the order of execution of takeFirst. The following code: QString line = file.readLine(); // line contains 46 71\n QStringList lineData = line.split(); // lineData contains (46, 71\n) qDebug() lineData.takeFirst() lineData.takeFirst(); I've already explained this in the past but I can't find the relevant email. This last line is parsed as operator( operator( qDebug(), lineData.takeFirst() ) , lineData.takeFirst() ) (operator is left associative). Take the outer operator. C++ does not define the order of evaluating its parameters. That means that either lineData.takeFirst() can be called before evaluating the inner operator, or vice-versa. Depending on what the compiler chooses to do, you'll have a different result. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Issue with the app on the omap4
Hi, all! I'm trying to run my app on the omap4 module (it's variscite var-som-om44 with the ubuntu 12.04 on it). I cross-compiled qt5 (tryed 5.0.2, 5.1.0, 5.2.0) and cross-compiled my app. It builds well, but when I tried to run it on the device I got an error: http://pastebin.com/GYHPE34P Then I tried to run GLAndsTest (builded in the same way) and got black screen and this errors: http://pastebin.com/KFBKxn5L I'm ran out of the options, so I need an advice. What can be the problem? How can I fix it? -- Best regards, *Alexander Chapkin, System Engineer* i-camp engineering, THRONE BMS Office: +7 4852 77 06 77 Skype: alexander.chapkin www.throne-bms.com THRONE Project Blog: www.throne-bms.com/pro/blog ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] correct d_ptr implementation
Hi
I am developing a library and in Qt Tradition I want to use the d_ptr pattern.
I have no previous experience of using this pattern and have a simple example
working but wanted to check that my implementation is correct.
To that end I have set out my classes below and would be grateful if anyone
could confirm that my approach is correct(or not)
Thanks
Header file
#ifndef DISPLAYWIDGET_H
#define DISPLAYWIDGET_H
#include DisplayWidgetsGlobal.h
#include QWidget
class DisplayWidgetPrivate;
class DISPLAYWIDGETS_EXPORT DisplayWidget : public QWidget
{
Q_OBJECT
public:
DisplayWidget(QWidget *parent);
~DisplayWidget();
private:
DisplayWidgetPrivate* d_ptr;
Q_DECLARE_PRIVATE(DisplayWidget)
};
#endif // DISPLAYWIDGET_H
Private Header file
#include DisplayWidget.h
class QLabel;
class DisplayWidgetPrivate
{
public:
DisplayWidgetPrivate (DisplayWidget* parent);
void init();
QLabel* m_label;
DisplayWidget* const q_ptr;
Q_DECLARE_PUBLIC(DisplayWidget)
public:
DisplayWidgetPrivate();
};
Implementation file
#include QLabel
#include DisplayWidget.h
#include DisplayWidget_p.h
DisplayWidgetPrivate::DisplayWidgetPrivate(DisplayWidget* parent)
: q_ptr(parent)
{
}
void DisplayWidgetPrivate::init()
{
m_label = new QLabel(This is a label,q_ptr);
}
DisplayWidget::DisplayWidget(QWidget *parent)
: QWidget(parent),
d_ptr(new DisplayWidgetPrivate(this))
{
Q_D(DisplayWidget);
d-init();
}
DisplayWidget::~DisplayWidget()
{
}
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QStringList, takeFirst and order of execution
On 11 nov. 2013, at 13:42, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 11 de novembro de 2013 13:37:20, Samuel Gaist wrote: Hi, I have been experiencing a strange behavior with QStringList and the order of execution of takeFirst. qDebug() lineData.takeFirst() lineData.takeFirst(); The problem is not takeFirst. behaves differently on two computers. Correct. You have undefined behaviour. Both calls to takeFirst() are in the same sequence-point. That means the compiler is allowed to execute in any order. It would be the same if you had written: f(lineData.takeFirst(), lineData.takeFirst()); qDebug() lineData.takeFirst(); qDebug() lineData.takeFirst(); The order is correct on both of them. What could explain the difference ? In the second case, there are two sequence points (they are separated by a ;). In C++11-speak, the first line of the second example is guaranteed to happens- before the second line. In the first example, there's no happens-before, therefore any one can happen before the other, or after. I see, thanks for the explanation ! ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QStringList, takeFirst and order of execution
On 11 nov. 2013, at 13:50, Giuseppe D'Angelo giuseppe.dang...@kdab.com wrote: Il 11/11/2013 13:37, Samuel Gaist ha scritto: Hi, I have been experiencing a strange behavior with QStringList and the order of execution of takeFirst. The following code: QString line = file.readLine(); // line contains 46 71\n QStringList lineData = line.split(); // lineData contains (46, 71\n) qDebug() lineData.takeFirst() lineData.takeFirst(); I've already explained this in the past but I can't find the relevant email. This last line is parsed as operator( operator( qDebug(), lineData.takeFirst() ) , lineData.takeFirst() ) (operator is left associative). Take the outer operator. C++ does not define the order of evaluating its parameters. That means that either lineData.takeFirst() can be called before evaluating the inner operator, or vice-versa. Depending on what the compiler chooses to do, you'll have a different result. Ok, with that and the explanation of Thiago, it's crystal clear. Thanks ! ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] OpenGL under QML example does not work with dynamic object creation
Good morning, Does anyone have time to help debug a problem? I’m trying to get the OpenGL under QML example to work with dynamic object creation with no luck. *The setup:* I’ve partitioned the app window into a status bar and a display area. The display area will be used to render output from various Qt plugins. I’ve tried using the QML Loader object and Qt.createComponent() to dynamically load the objects from the plugins as needed. *The problem:* I’ve duplicated the opengl rendering with qml example. If I load it into the display area directly it works perfectly. If I load it into the display area using a Loader it displays nothing. I’ve logged debugging messages and it’s definitely running. I’ve debugged the app using GDebugger and it appears to be sending OpenGL calls. Any ideas? I was careful to use the correct signal/slot property when connecting the rendering up; 1. connect( win, SIGNAL( beforeRendering() ), this, SLOT( paint() ), Qthttp://qt-project.org/doc/Qt.html ::DirectConnection ) My guess was that it's running the code in the wrong thread but I'm not seeing any error indication that there's no OpenGL context present. Being new to OpenGL can I assume that I'll get some indication that I'm doing something obviously wrong? Thanks Jay -- *http://xkcd.com/1156/ http://xkcd.com/1156/* ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Android's Google Maps and order of rendering
Hi all, I would like to embed a Google Map using Native SDK on Android. Now I am able to construct the Map using Java code. However, it has problem to interact with QML. The Google Map library (part of Google Play Services) render its content on an android.view.View object. As QML do not support the control of render / layout of an android.view.View object , I just want them to draw on two different layer: The QML layer draw on the top of the MapView . However, the real situation is : The view object draw on top of QML. My question - Is there any method to control the order of rendering between QML and android.view.View objects? Anybody has experience on communication between Qt and android.view.View objects can share the experience? Any advice would be appreciated! Thanks. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] correct d_ptr implementation
1) put your 'd_ptr' into a smart pointer of some kind (usually
QScopedPointer), your example leaks memory;
2) placing 'q_ptr' in the public section doesn't make much sense because
it's supposed to be used only by the DisplayWidgetPrivate instance to
access its owner (DisplayWidget doesn't need any external information
to access itself :) );
3) I guess the second public section in DisplayWidgetPrivate was
supposed to be private :) .
Other than that, your example looks OK to me.
On 11/11/2013 06:40 PM, Graham Labdon wrote:
Hi
I am developing a library and in Qt Tradition I want to use the d_ptr
pattern.
I have no previous experience of using this pattern and have a simple
example working but wanted to check that my implementation is correct.
To that end I have set out my classes below and would be grateful if
anyone could confirm that my approach is correct(or not)
Thanks
Header file
#ifndef DISPLAYWIDGET_H
#define DISPLAYWIDGET_H
#include DisplayWidgetsGlobal.h
#include QWidget
class DisplayWidgetPrivate;
class DISPLAYWIDGETS_EXPORT DisplayWidget : public QWidget
{
Q_OBJECT
public:
DisplayWidget(QWidget *parent);
~DisplayWidget();
private:
DisplayWidgetPrivate* d_ptr;
Q_DECLARE_PRIVATE(DisplayWidget)
};
#endif // DISPLAYWIDGET_H
Private Header file
#include DisplayWidget.h
class QLabel;
class DisplayWidgetPrivate
{
public:
DisplayWidgetPrivate (DisplayWidget* parent);
void init();
QLabel* m_label;
DisplayWidget* const q_ptr;
Q_DECLARE_PUBLIC(DisplayWidget)
public:
DisplayWidgetPrivate();
};
Implementation file
#include QLabel
#include DisplayWidget.h
#include DisplayWidget_p.h
DisplayWidgetPrivate::DisplayWidgetPrivate(DisplayWidget* parent)
: q_ptr(parent)
{
}
void DisplayWidgetPrivate::init()
{
m_label = new QLabel(This is a label,q_ptr);
}
DisplayWidget::DisplayWidget(QWidget *parent)
: QWidget(parent),
d_ptr(new DisplayWidgetPrivate(this))
{
Q_D(DisplayWidget);
d-init();
}
DisplayWidget::~DisplayWidget()
{
}
signature.asc
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] correct d_ptr implementation
Constantin Makshin schreef op 11.11.2013 18:33:
1) put your 'd_ptr' into a smart pointer of some kind (usually
QScopedPointer), your example leaks memory;
2) placing 'q_ptr' in the public section doesn't make much sense
because
it's supposed to be used only by the DisplayWidgetPrivate instance to
access its owner (DisplayWidget doesn't need any external information
to access itself :) );
3) I guess the second public section in DisplayWidgetPrivate was
supposed to be private :) .
Other than that, your example looks OK to me.
How much sense does it make to have a private section in the private
DisplayWidgetPrivate class at all? Everything in there is private for
DisplayWidgets use anyway, right?
André
On 11/11/2013 06:40 PM, Graham Labdon wrote:
Hi
I am developing a library and in Qt Tradition I want to use the d_ptr
pattern.
I have no previous experience of using this pattern and have a simple
example working but wanted to check that my implementation is correct.
To that end I have set out my classes below and would be grateful if
anyone could confirm that my approach is correct(or not)
Thanks
Header file
#ifndef DISPLAYWIDGET_H
#define DISPLAYWIDGET_H
#include DisplayWidgetsGlobal.h
#include QWidget
class DisplayWidgetPrivate;
class DISPLAYWIDGETS_EXPORT DisplayWidget : public QWidget
{
Q_OBJECT
public:
DisplayWidget(QWidget *parent);
~DisplayWidget();
private:
DisplayWidgetPrivate* d_ptr;
Q_DECLARE_PRIVATE(DisplayWidget)
};
#endif // DISPLAYWIDGET_H
Private Header file
#include DisplayWidget.h
class QLabel;
class DisplayWidgetPrivate
{
public:
DisplayWidgetPrivate (DisplayWidget* parent);
void init();
QLabel* m_label;
DisplayWidget* const q_ptr;
Q_DECLARE_PUBLIC(DisplayWidget)
public:
DisplayWidgetPrivate();
};
Implementation file
#include QLabel
#include DisplayWidget.h
#include DisplayWidget_p.h
DisplayWidgetPrivate::DisplayWidgetPrivate(DisplayWidget* parent)
: q_ptr(parent)
{
}
void DisplayWidgetPrivate::init()
{
m_label = new QLabel(This is a label,q_ptr);
}
DisplayWidget::DisplayWidget(QWidget *parent)
: QWidget(parent),
d_ptr(new DisplayWidgetPrivate(this))
{
Q_D(DisplayWidget);
d-init();
}
DisplayWidget::~DisplayWidget()
{
}
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] correct d_ptr implementation
Right, but:
1) classes derived from DisplayWidget may want to derive their *Private
counterparts from DisplayWidgetPrivate — in this case private section
will make DisplayWidgetPrivate's internals accessible only to this class
itself and its friend DisplayWidget;
2) since not all compilers support = delete from C++11, placing an
intentionally-unimplemented constructor[s] and/or assignment operator
into the private section is the most common way to mark them as unavailable.
On 11/11/2013 10:22 PM, an...@familiesomers.nl wrote:
Constantin Makshin schreef op 11.11.2013 18:33:
1) put your 'd_ptr' into a smart pointer of some kind (usually
QScopedPointer), your example leaks memory;
2) placing 'q_ptr' in the public section doesn't make much sense
because
it's supposed to be used only by the DisplayWidgetPrivate instance to
access its owner (DisplayWidget doesn't need any external information
to access itself :) );
3) I guess the second public section in DisplayWidgetPrivate was
supposed to be private :) .
Other than that, your example looks OK to me.
How much sense does it make to have a private section in the private
DisplayWidgetPrivate class at all? Everything in there is private for
DisplayWidgets use anyway, right?
André
On 11/11/2013 06:40 PM, Graham Labdon wrote:
Hi
I am developing a library and in Qt Tradition I want to use the d_ptr
pattern.
I have no previous experience of using this pattern and have a simple
example working but wanted to check that my implementation is correct.
To that end I have set out my classes below and would be grateful if
anyone could confirm that my approach is correct(or not)
Thanks
Header file
#ifndef DISPLAYWIDGET_H
#define DISPLAYWIDGET_H
#include DisplayWidgetsGlobal.h
#include QWidget
class DisplayWidgetPrivate;
class DISPLAYWIDGETS_EXPORT DisplayWidget : public QWidget
{
Q_OBJECT
public:
DisplayWidget(QWidget *parent);
~DisplayWidget();
private:
DisplayWidgetPrivate* d_ptr;
Q_DECLARE_PRIVATE(DisplayWidget)
};
#endif // DISPLAYWIDGET_H
Private Header file
#include DisplayWidget.h
class QLabel;
class DisplayWidgetPrivate
{
public:
DisplayWidgetPrivate (DisplayWidget* parent);
void init();
QLabel* m_label;
DisplayWidget* const q_ptr;
Q_DECLARE_PUBLIC(DisplayWidget)
public:
DisplayWidgetPrivate();
};
Implementation file
#include QLabel
#include DisplayWidget.h
#include DisplayWidget_p.h
DisplayWidgetPrivate::DisplayWidgetPrivate(DisplayWidget* parent)
: q_ptr(parent)
{
}
void DisplayWidgetPrivate::init()
{
m_label = new QLabel(This is a label,q_ptr);
}
DisplayWidget::DisplayWidget(QWidget *parent)
: QWidget(parent),
d_ptr(new DisplayWidgetPrivate(this))
{
Q_D(DisplayWidget);
d-init();
}
DisplayWidget::~DisplayWidget()
{
}
signature.asc
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtDBus interface design question
On quinta-feira, 7 de novembro de 2013 19:01:57, Roland Winklmeier wrote:
Hey there,
Hello Roland
As promised, I have found time to read your email and reply.
I have a daemon application built with C++/Qt. It is a client for a
network and should run in the background. The plan was to connect the UI
via DBus to this daemon in order to make the objects inside the daemon
also available to other external tools/addons. So far nothing special,
this is done in many places in KDE.
When discussing D-Bus, please don't mention network :-)
People might jump at you and say that D-Bus isn't meant to be used across a
network. That's not what you're trying to do -- your application just happens
to do networking somewhere else in it.
The thing is , the object hierarchy is quite deep and complicated. The
best example is the object managing the applications settings, lets call
it CSettingsManager : public QObject. It holds several client QObjects,
representing each a different setting group:
CSettingsManager
|--- CServerSettings
|--- CUserSettings
|--- CLoggingSettings
|--- CGuiSettings
Now we want to expose these hierarchy via DBus. After reading thousands
of DBus applications and their interfaces, we decided to try the
following interface:
/CSettingsManager
/CSettingsManager/CServerSettings
/CSettingsManager/CUserSettings
/CSettingsManager/CLoggingSettings
/CSettingsManager/CGuiSettings
Sounds reasonable.
I think up to now its convenient. Instead of passing custom classes via
DBus, I thought its better to register the child objects too and just
point to the object via a QDbusObjectPath argument. So anyone can act
and react on the real object via DBus.
For example I can call CSettingsManager::getServerSettings() {return
QDBusObjectPath /CSettingsManager/CServerSettings } and create a
QDbusAbstractInterface with the returned objectpath and call methods on
the child object. So far so good. I have to mention here, the number of
CServerSettings is dynamic and decided during runtime (based on what is
specificed in the configuration file).
I'm not sure I understood what you meant here.
If the path is fixed and known to all clients, there's no point in adding a
method that returns it. If it's always going to be the same, the clients
should just avoid the extra round-trip and should send the request directly.
Maybe what you meant is because of what follows:
The DBus interface for example could look like:
/CSettingsManager/CServerSettings/Server1
/CSettingsManager/CServerSettings/Server2
...
/CSettingsManager/CServerSettings/ServerN
Sounds good. Your first idea has probably been to register one QObject per
path. That's a valid solution. However, do it only if you had those QObjects
(one per path) anyway, to hold the data and to control the lifetime.
Otherwise, there's another trick: you can register the same QObject multiple
times and simply get the targeted path from the incoming QDBusMessage (which
you can get by deriving that class multiply from QObject and from
QDBusContext).
The issue is now, I want to have a table view displaying the properties
for each Server and let the user edit it.
--
|Server 1 | IP address | port | name |
|Server 2 | IP address | port | name |
|Server 3 | IP address | port | name |
--
Why do you want to have that table? Is that normal activity in your service?
Or is this something that you'll use once in a blue moon, to test how it's
going?
The reason I ask is that the answer will determine whether you should have a
fast API to retrieve everything, or if it's acceptable that the client must do
multiple calls to collect all the information.
I could get a list of all objects and start retrieving their properties,
but lets suppose I have 1000 rows with 4 properties each = 4000 Dbus
calls to build the table. The performance would be horrible.
Indeed, hence the question above.
The only solution I can imagine is to pass the entire table in one DBus
message, but how. I cannot pass the objects itself, because I cannot
transfer an QObject via DBus. Creating plain structs and pass them is an
option but is rather dirty to me.
Creating structs and passing an array of structs is the only way.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] correct d_ptr implementation
Ok, but if your 'private' class is designed to be derived from, then I
guess it was not all that private after all. It is more like it is to be
protected instead of private. If the class really is private (for
instance by not using a displaywidget_p.h for declaring it, but by just
forward-declaring it from the private section of DisplayWidgets
declaration in displaywidget.h and keeping all the rest in
displaywidget.cpp instead), then I fail to see the point of either.
There is no need for a private constructor or assignment operator then,
as nobody can access them anyway, right?
If you want to allow subclassing the private part (like Qt does), then I
guess you're right. But IMHO that means that the d_ptr isn't really
private, but rather it has become protected instead.
André
Constantin Makshin schreef op 11.11.2013 19:42:
Right, but:
1) classes derived from DisplayWidget may want to derive their *Private
counterparts from DisplayWidgetPrivate — in this case private section
will make DisplayWidgetPrivate's internals accessible only to this
class
itself and its friend DisplayWidget;
2) since not all compilers support = delete from C++11, placing an
intentionally-unimplemented constructor[s] and/or assignment operator
into the private section is the most common way to mark them as
unavailable.
On 11/11/2013 10:22 PM, an...@familiesomers.nl wrote:
Constantin Makshin schreef op 11.11.2013 18:33:
1) put your 'd_ptr' into a smart pointer of some kind (usually
QScopedPointer), your example leaks memory;
2) placing 'q_ptr' in the public section doesn't make much sense
because
it's supposed to be used only by the DisplayWidgetPrivate instance to
access its owner (DisplayWidget doesn't need any external
information
to access itself :) );
3) I guess the second public section in DisplayWidgetPrivate was
supposed to be private :) .
Other than that, your example looks OK to me.
How much sense does it make to have a private section in the private
DisplayWidgetPrivate class at all? Everything in there is private for
DisplayWidgets use anyway, right?
André
On 11/11/2013 06:40 PM, Graham Labdon wrote:
Hi
I am developing a library and in Qt Tradition I want to use the
d_ptr
pattern.
I have no previous experience of using this pattern and have a
simple
example working but wanted to check that my implementation is
correct.
To that end I have set out my classes below and would be grateful if
anyone could confirm that my approach is correct(or not)
Thanks
Header file
#ifndef DISPLAYWIDGET_H
#define DISPLAYWIDGET_H
#include DisplayWidgetsGlobal.h
#include QWidget
class DisplayWidgetPrivate;
class DISPLAYWIDGETS_EXPORT DisplayWidget : public QWidget
{
Q_OBJECT
public:
DisplayWidget(QWidget *parent);
~DisplayWidget();
private:
DisplayWidgetPrivate* d_ptr;
Q_DECLARE_PRIVATE(DisplayWidget)
};
#endif // DISPLAYWIDGET_H
Private Header file
#include DisplayWidget.h
class QLabel;
class DisplayWidgetPrivate
{
public:
DisplayWidgetPrivate (DisplayWidget* parent);
void init();
QLabel* m_label;
DisplayWidget* const q_ptr;
Q_DECLARE_PUBLIC(DisplayWidget)
public:
DisplayWidgetPrivate();
};
Implementation file
#include QLabel
#include DisplayWidget.h
#include DisplayWidget_p.h
DisplayWidgetPrivate::DisplayWidgetPrivate(DisplayWidget* parent)
: q_ptr(parent)
{
}
void DisplayWidgetPrivate::init()
{
m_label = new QLabel(This is a label,q_ptr);
}
DisplayWidget::DisplayWidget(QWidget *parent)
: QWidget(parent),
d_ptr(new DisplayWidgetPrivate(this))
{
Q_D(DisplayWidget);
d-init();
}
DisplayWidget::~DisplayWidget()
{
}
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Replicate QML Listview in QtCpp and widgets
Hello all, For a customer specific application we are forced to use only C++ code without QML. Up to here there are no problems, except that in this new software, we need massive use of listview (finger-scrollable, with text and image objects, smooth moving). So, the QML Listview is exactly what we are looking for, but for political questions we can't use QML. There is an alternative? I saw that QlistWidget is not really perfect and simple like the Qml object.. Does someone have some code or examples (or maybe web articles) to share? Many Thanks Simone ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] correct d_ptr implementation
Yes, I meant the private subclassing in a way like the one used by Qt
where it's used to both hide internals from the outer world and reduce
memory overhead by sharing one 'd_ptr' field between many classes.
But no, 'd_ptr' must be private to prevent classes derived from
DisplayWidget from changing the pointer after the object has been
constructed (DisplayWidget may still need to have that ability for
copy/move operators or something like that), Q_DECLARE_PRIVATE and Q_D use
small inline wrapper methods to give access to the object 'd_ptr' points to
without giving [direct] access to the pointer itself.
On Nov 12, 2013 12:11 AM, an...@familiesomers.nl wrote:
Ok, but if your 'private' class is designed to be derived from, then I
guess it was not all that private after all. It is more like it is to be
protected instead of private. If the class really is private (for
instance by not using a displaywidget_p.h for declaring it, but by just
forward-declaring it from the private section of DisplayWidgets
declaration in displaywidget.h and keeping all the rest in
displaywidget.cpp instead), then I fail to see the point of either.
There is no need for a private constructor or assignment operator then,
as nobody can access them anyway, right?
If you want to allow subclassing the private part (like Qt does), then I
guess you're right. But IMHO that means that the d_ptr isn't really
private, but rather it has become protected instead.
André
Constantin Makshin schreef op 11.11.2013 19:42:
Right, but:
1) classes derived from DisplayWidget may want to derive their *Private
counterparts from DisplayWidgetPrivate — in this case private section
will make DisplayWidgetPrivate's internals accessible only to this
class
itself and its friend DisplayWidget;
2) since not all compilers support = delete from C++11, placing an
intentionally-unimplemented constructor[s] and/or assignment operator
into the private section is the most common way to mark them as
unavailable.
On 11/11/2013 10:22 PM, an...@familiesomers.nl wrote:
Constantin Makshin schreef op 11.11.2013 18:33:
1) put your 'd_ptr' into a smart pointer of some kind (usually
QScopedPointer), your example leaks memory;
2) placing 'q_ptr' in the public section doesn't make much sense
because
it's supposed to be used only by the DisplayWidgetPrivate instance to
access its owner (DisplayWidget doesn't need any external
information
to access itself :) );
3) I guess the second public section in DisplayWidgetPrivate was
supposed to be private :) .
Other than that, your example looks OK to me.
How much sense does it make to have a private section in the private
DisplayWidgetPrivate class at all? Everything in there is private for
DisplayWidgets use anyway, right?
André
On 11/11/2013 06:40 PM, Graham Labdon wrote:
Hi
I am developing a library and in Qt Tradition I want to use the
d_ptr
pattern.
I have no previous experience of using this pattern and have a
simple
example working but wanted to check that my implementation is
correct.
To that end I have set out my classes below and would be grateful if
anyone could confirm that my approach is correct(or not)
Thanks
Header file
#ifndef DISPLAYWIDGET_H
#define DISPLAYWIDGET_H
#include DisplayWidgetsGlobal.h
#include QWidget
class DisplayWidgetPrivate;
class DISPLAYWIDGETS_EXPORT DisplayWidget : public QWidget
{
Q_OBJECT
public:
DisplayWidget(QWidget *parent);
~DisplayWidget();
private:
DisplayWidgetPrivate* d_ptr;
Q_DECLARE_PRIVATE(DisplayWidget)
};
#endif // DISPLAYWIDGET_H
Private Header file
#include DisplayWidget.h
class QLabel;
class DisplayWidgetPrivate
{
public:
DisplayWidgetPrivate (DisplayWidget* parent);
void init();
QLabel* m_label;
DisplayWidget* const q_ptr;
Q_DECLARE_PUBLIC(DisplayWidget)
public:
DisplayWidgetPrivate();
};
Implementation file
#include QLabel
#include DisplayWidget.h
#include DisplayWidget_p.h
DisplayWidgetPrivate::DisplayWidgetPrivate(DisplayWidget* parent)
: q_ptr(parent)
{
}
void DisplayWidgetPrivate::init()
{
m_label = new QLabel(This is a label,q_ptr);
}
DisplayWidget::DisplayWidget(QWidget *parent)
: QWidget(parent),
d_ptr(new DisplayWidgetPrivate(this))
{
Q_D(DisplayWidget);
d-init();
}
DisplayWidget::~DisplayWidget()
{
}
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Re: [Interest] Replicate QML Listview in QtCpp and widgets
Depending on what political reasons means, you could do stuff like
QQmlComponent c;
c.setData(import MyApp 0.1; import QtQuick 2.2; ListView{model:
MyModel{}; delegate: MyDelegate{}});
inside your C++ implementation. MyModel being your custom
QAbstractItemModel and MyDelegate being a custom QQuickItem written in
C++ for the delegate. If you're willing to use private APIs (which has
massive drawbacks when you don't bundle a specific Qt build with your
app) you can even skip the component and create a QQuickListView
directly.
A QWebView would also be fairly easy, but HTML is even worse than QML
for most of the reasons that people want to ban QML.
If you really can't use QML or QtQuick, you can implement such a
widget with QtWidgets but there's no real help for that. Just do all
your own touch handling and painting and it's still easier than a raw
opengl app,
--
Alan Alpert
On Mon, Nov 11, 2013 at 12:27 PM, Simone cjb.sw.nos...@gmail.com wrote:
Hello all,
For a customer specific application we are forced to use only C++ code
without QML.
Up to here there are no problems, except that in this new software, we need
massive use of listview (finger-scrollable, with text and image objects,
smooth moving).
So, the QML Listview is exactly what we are looking for, but for political
questions we can't use QML.
There is an alternative?
I saw that QlistWidget is not really perfect and simple like the Qml object..
Does someone have some code or examples (or maybe web articles) to share?
Many Thanks
Simone
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Why are QUuid saved as blobs and not strings in QSqlite driver?
Is there a reason why UUIDs are not saved using toRfc4122().toLatin1() in the database? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] R: Replicate QML Listview in QtCpp and widgets
Hello Alan,
thank you.
The customer don't want QML because for some strange reason he don't want to
use it. I don't know much more, anyway I have to adapt..
And of course we cannot force him to use QML.
I've saw your example but seems that is only for qt5, we are currently using
qt4.8.5
Let's see if I can find something on the web..
However, I am waiting for some good soul who wants to help me :-)
Regards
Simone
-Messaggio originale-
Da: Alan Alpert [mailto:4163654...@gmail.com]
Inviato: lunedì 11 novembre 2013 23:01
A: Simone
Cc: interest@qt-project.org
Oggetto: Re: [Interest] Replicate QML Listview in QtCpp and widgets
Depending on what political reasons means, you could do stuff like
QQmlComponent c;
c.setData(import MyApp 0.1; import QtQuick 2.2; ListView{model:
MyModel{}; delegate: MyDelegate{}});
inside your C++ implementation. MyModel being your custom QAbstractItemModel
and MyDelegate being a custom QQuickItem written in
C++ for the delegate. If you're willing to use private APIs (which has
massive drawbacks when you don't bundle a specific Qt build with your
app) you can even skip the component and create a QQuickListView directly.
A QWebView would also be fairly easy, but HTML is even worse than QML for
most of the reasons that people want to ban QML.
If you really can't use QML or QtQuick, you can implement such a widget with
QtWidgets but there's no real help for that. Just do all your own touch
handling and painting and it's still easier than a raw opengl app,
--
Alan Alpert
On Mon, Nov 11, 2013 at 12:27 PM, Simone cjb.sw.nos...@gmail.com wrote:
Hello all,
For a customer specific application we are forced to use only C++ code
without QML.
Up to here there are no problems, except that in this new software, we
need massive use of listview (finger-scrollable, with text and image
objects, smooth moving).
So, the QML Listview is exactly what we are looking for, but for political
questions we can't use QML.
There is an alternative?
I saw that QlistWidget is not really perfect and simple like the Qml
object..
Does someone have some code or examples (or maybe web articles) to share?
Many Thanks
Simone
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QtCreator complains about .pro file could not be parsed for Qt5
Hello everyone, I have a very simple .pro file: #- # # Project created by QtCreator 2013-11-12T09:49:29 # #- QT += core gui greaterThan(QT_MAJOR_VERSION, 4): QT += widgets TARGET = testQtContainer TEMPLATE = app SOURCES += main.cpp\ widget.cpp HEADERS += widget.h FORMS+= widget.u When I load this project in QtCreator 2.8.1 using Qt5 buildkit, I can't start the program or debug the program since the start/debug button is grayed, If I move the mouse on the button, a tooltip will show up which says: .pro file could not be parsed. But building of the project works fine, I just can't start or debug it. And if I change build kit to qt 4.8 everything works fine. Qt5 in my machine is built by myself, I got the source from git and checkout to stable branch. Build environment: windows 7 x64, msvc2010 BTW: in the past, it works fine with Qt5, this issue occurred recently. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why are QUuid saved as blobs and not strings in QSqlite driver?
Probably because binary representation is more space-efficient. On Nov 12, 2013 11:32 AM, Philipp Kursawe phil.kurs...@gmail.com wrote: Is there a reason why UUIDs are not saved using toRfc4122().toLatin1() in the database? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] R: Replicate QML Listview in QtCpp and widgets
I think you might be interested in this:
https://blog.qt.digia.com/blog/2008/11/15/flick-list-or-kinetic-scrolling/
You have the source code and all, it's a good way to learn new things :-)
2013/11/12 Simone cjb.sw.nos...@gmail.com
Hello Alan,
thank you.
The customer don't want QML because for some strange reason he don't want
to
use it. I don't know much more, anyway I have to adapt..
And of course we cannot force him to use QML.
I've saw your example but seems that is only for qt5, we are currently
using
qt4.8.5
Let's see if I can find something on the web..
However, I am waiting for some good soul who wants to help me :-)
Regards
Simone
-Messaggio originale-
Da: Alan Alpert [mailto:4163654...@gmail.com]
Inviato: lunedì 11 novembre 2013 23:01
A: Simone
Cc: interest@qt-project.org
Oggetto: Re: [Interest] Replicate QML Listview in QtCpp and widgets
Depending on what political reasons means, you could do stuff like
QQmlComponent c;
c.setData(import MyApp 0.1; import QtQuick 2.2; ListView{model:
MyModel{}; delegate: MyDelegate{}});
inside your C++ implementation. MyModel being your custom
QAbstractItemModel
and MyDelegate being a custom QQuickItem written in
C++ for the delegate. If you're willing to use private APIs (which has
massive drawbacks when you don't bundle a specific Qt build with your
app) you can even skip the component and create a QQuickListView directly.
A QWebView would also be fairly easy, but HTML is even worse than QML for
most of the reasons that people want to ban QML.
If you really can't use QML or QtQuick, you can implement such a widget
with
QtWidgets but there's no real help for that. Just do all your own touch
handling and painting and it's still easier than a raw opengl app,
--
Alan Alpert
On Mon, Nov 11, 2013 at 12:27 PM, Simone cjb.sw.nos...@gmail.com wrote:
Hello all,
For a customer specific application we are forced to use only C++ code
without QML.
Up to here there are no problems, except that in this new software, we
need massive use of listview (finger-scrollable, with text and image
objects, smooth moving).
So, the QML Listview is exactly what we are looking for, but for
political
questions we can't use QML.
There is an alternative?
I saw that QlistWidget is not really perfect and simple like the Qml
object..
Does someone have some code or examples (or maybe web articles) to share?
Many Thanks
Simone
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
