Re: [Interest] Most simple emit from singleton?
Yeah, it's a global event. Like tracking volume key events on a phone. ;-) I
guess anyone can trigger them but the platform is invoking them in the handler.
And my app is not considered to be hostile to itself.
> Sent: Wednesday, November 13, 2019 at 11:18 PM
> From: "Jérôme Godbout"
> To: "interestqt-project.org"
> Subject: Re: [Interest] Most simple emit from singleton?
>
> Q_EMIT and emit macro are blank indeed.
>
> I was under the impression, that this singleton was a global signal emiter
> where anybody could launch a signal
>
> class SingletonClass : QObject
> {
> Q_OBJECT
> public:
>void TriggerGlobalEvent() { myGlobalEvent(); }
> signals:
>void myGlobalEvent();
> }
>
> so anybody can connect to that particular event like it was some kind of
> event bus for a particular Thread only, since the SingletonClass is a QObject
> and it has his own thread affinity. So calling the signal directly or from
> the public method won't change anything as long as the current thread is the
> right thread affinity. Maybe I'm wrong on this but I think the result will be
> the exact same when calling TriggerGlobalEvent() or myGlobalEvent() on the
> object into a release build, the odds are that it will get inlined pretty
> quickly by any decent compiler.
>
> This sound like a bad design to me but could work for some application wide
> events or settings changed. Since we do not really know the real purpose,
> it's hard to have a better way.
>
> -Original Message-
> From: Interest On Behalf Of Giuseppe
> D'Angelo via Interest
> Sent: November 13, 2019 12:38 PM
> To: interest@qt-project.org
> Subject: Re: [Interest] Most simple emit from singleton?
>
> On 13/11/2019 18:11, Jason H wrote:
> > Maybe. Couldn't I just call:
> > MySingleton::Instance()->MySignal();
> >
> > and skip emit altogether? I've read that Q_EMIT and emit are just syntactic
> > sugar, and there is confusion in this stackexchange:
> > https://stackoverflow.com/questions/10160476/using-emit-vs-calling-a-s
> > ignal-as-if-its-a-regular-function-in-qt
> >
> > it seems that the simplest way is just:
> > MySingleton::Instance()->MySignal();
> >
> > but to make it clear it is emitting, the sugar comes into play. Not
> > sure if it has any affect on queued vs direct-call connections though.
> > (I'm guessing no)
>
> "emit" / "Q_EMIT" are macros that expand to nothing.
>
> Therefore, after the preprocessor runs, the compiler does not see anything;
> whether emit was there or not makes no difference and thus results in no
> behavioral changes.
>
> Still:
>
> 1) use emit every time you emit a signal; emit is not there for the compiler,
> it's there for the developer
>
> 2) use emit ONLY in front a signal emission and nowhere else
>
> 3) While signals are technically public members, I'd consider that an
> implementation detail; one should NEVER be emitting signals on behalf of
> another arbitrary class.
>
> You should protect your signal emissions, e.g. use the same undocumented
> trick that Qt uses (make them have an argument of type QPrivateSignal), and
> give friendship to the only codepaths that are supposed to emit it (and, even
> better, have a trampoline function that emits the signal that these codepaths
> can call).
>
> Clazy already checks for 1+2 and in theory can also check for 3.
>
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB
> (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53,
> http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Most simple emit from singleton?
Q_EMIT and emit macro are blank indeed.
I was under the impression, that this singleton was a global signal emiter
where anybody could launch a signal
class SingletonClass : QObject
{
Q_OBJECT
public:
void TriggerGlobalEvent() { myGlobalEvent(); }
signals:
void myGlobalEvent();
}
so anybody can connect to that particular event like it was some kind of event
bus for a particular Thread only, since the SingletonClass is a QObject and it
has his own thread affinity. So calling the signal directly or from the public
method won't change anything as long as the current thread is the right thread
affinity. Maybe I'm wrong on this but I think the result will be the exact same
when calling TriggerGlobalEvent() or myGlobalEvent() on the object into a
release build, the odds are that it will get inlined pretty quickly by any
decent compiler.
This sound like a bad design to me but could work for some application wide
events or settings changed. Since we do not really know the real purpose, it's
hard to have a better way.
-Original Message-
From: Interest On Behalf Of Giuseppe D'Angelo
via Interest
Sent: November 13, 2019 12:38 PM
To: interest@qt-project.org
Subject: Re: [Interest] Most simple emit from singleton?
On 13/11/2019 18:11, Jason H wrote:
> Maybe. Couldn't I just call:
> MySingleton::Instance()->MySignal();
>
> and skip emit altogether? I've read that Q_EMIT and emit are just syntactic
> sugar, and there is confusion in this stackexchange:
> https://stackoverflow.com/questions/10160476/using-emit-vs-calling-a-s
> ignal-as-if-its-a-regular-function-in-qt
>
> it seems that the simplest way is just:
> MySingleton::Instance()->MySignal();
>
> but to make it clear it is emitting, the sugar comes into play. Not
> sure if it has any affect on queued vs direct-call connections though.
> (I'm guessing no)
"emit" / "Q_EMIT" are macros that expand to nothing.
Therefore, after the preprocessor runs, the compiler does not see anything;
whether emit was there or not makes no difference and thus results in no
behavioral changes.
Still:
1) use emit every time you emit a signal; emit is not there for the compiler,
it's there for the developer
2) use emit ONLY in front a signal emission and nowhere else
3) While signals are technically public members, I'd consider that an
implementation detail; one should NEVER be emitting signals on behalf of
another arbitrary class.
You should protect your signal emissions, e.g. use the same undocumented trick
that Qt uses (make them have an argument of type QPrivateSignal), and give
friendship to the only codepaths that are supposed to emit it (and, even
better, have a trampoline function that emits the signal that these codepaths
can call).
Clazy already checks for 1+2 and in theory can also check for 3.
My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB
(France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53,
http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Most simple emit from singleton?
> 3) While signals are technically public members, I'd consider that an > implementation detail; one should NEVER be emitting signals on behalf of > another arbitrary class. > > You should protect your signal emissions, e.g. use the same undocumented > trick that Qt uses (make them have an argument of type QPrivateSignal), > and give friendship to the only codepaths that are supposed to emit it > (and, even better, have a trampoline function that emits the signal that > these codepaths can call). These were some of the concerns that I had but failed to articulate as well. Many thanks for the insights! ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Most simple emit from singleton?
On 13/11/2019 18:11, Jason H wrote: Maybe. Couldn't I just call: MySingleton::Instance()->MySignal(); and skip emit altogether? I've read that Q_EMIT and emit are just syntactic sugar, and there is confusion in this stackexchange: https://stackoverflow.com/questions/10160476/using-emit-vs-calling-a-signal-as-if-its-a-regular-function-in-qt it seems that the simplest way is just: MySingleton::Instance()->MySignal(); but to make it clear it is emitting, the sugar comes into play. Not sure if it has any affect on queued vs direct-call connections though. (I'm guessing no) "emit" / "Q_EMIT" are macros that expand to nothing. Therefore, after the preprocessor runs, the compiler does not see anything; whether emit was there or not makes no difference and thus results in no behavioral changes. Still: 1) use emit every time you emit a signal; emit is not there for the compiler, it's there for the developer 2) use emit ONLY in front a signal emission and nowhere else 3) While signals are technically public members, I'd consider that an implementation detail; one should NEVER be emitting signals on behalf of another arbitrary class. You should protect your signal emissions, e.g. use the same undocumented trick that Qt uses (make them have an argument of type QPrivateSignal), and give friendship to the only codepaths that are supposed to emit it (and, even better, have a trampoline function that emits the signal that these codepaths can call). Clazy already checks for 1+2 and in theory can also check for 3. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Rebuild QPA plugins
Le mer. 13 nov. 2019 à 11:06, Benjamin TERRIER a écrit : > > Now I have: > > Cannot load library > /opt/Qt/5.13.2/gcc_64/plugins/platforms/libqxcb.so: > (/opt/Qt/5.13.2/gcc_64/plugins/platforms/libqxcb.so: undefined symbol: > _ZTI26QPlatformIntegrationPlugin, version Qt_5) > QLibraryPrivate::loadPlugin failed on > "/opt/Qt/5.13.2/gcc_64/plugins/platforms/libqxcb.so" : "Cannot load library > /opt/Qt/5.13.2/gcc_64/plugins/platforms/libqxcb.so: > (/opt/Qt/5.13.2/gcc_64/plugins/platforms/libqxcb.so: undefined symbol: > _ZTI26QPlatformIntegrationPlugin, version Qt_5)" > qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even > though it was found. > > ldd has no missing libraries, but reports: > > undefined symbol: _ZTI26QPlatformIntegrationPlugin, version Qt_5 > (./libqxcb.so) > undefined symbol: > _ZN26QPlatformIntegrationPlugin6createERK7QStringRK11QStringList, version > Qt_5(./libqxcb.so) > undefined symbol: _ZN26QPlatformIntegrationPlugin16staticMetaObjectE, > version Qt_5 (./libqxcb.so) > undefined symbol: _ZN26QPlatformIntegrationPluginC2EP7QObject, version > Qt_5 (./libqxcb.so) > undefined symbol: _ZN26QPlatformIntegrationPlugin11qt_metacastEPKc, > version Qt_5(./libqxcb.so) > undefined symbol: > _ZN26QPlatformIntegrationPlugin11qt_metacallEN11QMetaObject4CallEiPPv, > version Qt_5 (./libqxcb.so) > undefined symbol: _ZN26QPlatformIntegrationPluginD2Ev, version Qt_5 > (./libqxcb.so) > > Building with CentOS 7 and g++ 4.8 solves the issues. Since Qt official releases are built with g++ 5 I tried to install "devtoolset-5", but strangely it seems it is not available. Regards Benjamin ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] XCB clipboard freeze
Le mar. 5 nov. 2019 à 17:39, Thiago Macieira a écrit : > > Probably *because* events would be processed during the wait. We all know > nested event loops are bad design. In this case, this stems from another > bad > API design: the clipboard handled synchronously, when it clearly isn't. > > Note: I don't know the QClipboard API. This could be just the backend, in > which case my explanation is wrong and the QXcbClipboard should be > refactored > to operate reactively. As Linux kernel core developer Alan Cox said, > "threads > are for people who can't program a state machine". > > I worked a little bit on QXcbClipboard and I was able to make it work asynchronously. This solves my issue of freezing. However, since the QClipboard API is synchronous there is no place and time to make the asynchronous work when the user is requesting content. So my solution is to fetch the clipboard content asynchronously when Qt receives clipboard events from X11. The drawback is that whenever a user copy something to the clipboard, the Qt application will automatically fetch this something and therefore consume memory to store the content. This might be a negligible issue when copy/pasting short texts, but this will certainly be an issue if when someone copies a 100MB image, all the Qt applications allocate 100MB. I guess unless we change QClipboard API to make it async (like in GTK) I do not see how to solve this issue. BR Benjamin ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Most simple emit from singleton?
Maybe. Couldn't I just call:
MySingleton::Instance()->MySignal();
and skip emit altogether? I've read that Q_EMIT and emit are just syntactic
sugar, and there is confusion in this stackexchange:
https://stackoverflow.com/questions/10160476/using-emit-vs-calling-a-signal-as-if-its-a-regular-function-in-qt
it seems that the simplest way is just:
MySingleton::Instance()->MySignal();
but to make it clear it is emitting, the sugar comes into play. Not sure if it
has any affect on queued vs direct-call connections though. (I'm guessing no)
> Sent: Wednesday, November 13, 2019 at 10:33 AM
> From: "Jérôme Godbout"
> To: "Jason H" , "interestqt-project.org"
>
> Subject: RE: [Interest] Most simple emit from singleton?
>
> Why not declare a signals into your singleton header and call it directly?
>
> MySingleton.h
>
> class MySingleton
> {
> signals:
>void MySignals();
> };
>
> myOtherCode.cpp
>
> Q_EMIT MySingleton::Instance()->MySignals();
>
>
> -Original Message-
> From: Interest On Behalf Of Jason H
> Sent: November 13, 2019 11:28 AM
> To: interestqt-project.org
> Subject: [Interest] Most simple emit from singleton?
>
> I've stumbled across a paradigm that I am starting to use frequently where I
> have a singleton, and I want it to emit something when I tell it to.
>
> So I've been providing a function and doing:
> MySingleton::instance()->emitMySignal();
>
> Where:
> void MySingleton::emitMySignal() {
> emit mySignal();
> }
>
> But this seems "silly". Is there a better way to do this? Ideally I'd like to
> skip creating the function and do something like:
>
> MySingleton::instance()->emit MySignal(); or emit
> MySingleton::instance()->MySignal();
>
>
> There may still be a better way?
>
> Thoughts?
>
> Thanks!
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QInputDialog as item delegate?
Hi Matthew,
I have this in a delegate and it seems to work well. I don't know about "best
way." This one intercepts the double-click event which would typically open an
editor. It could also work with a single click if you prefer (I personally found that
annoying from a user perspective). This particular delegate also re-implements the
paint() method (to show a color swatch) and a sizeHint(), but I don't see how that would
matter. Otherwise this is the only other method in it.
bool ColorDelegate::editorEvent(QEvent *e, QAbstractItemModel *mdl, const
QStyleOptionViewItem , const QModelIndex )
{
if (e->type() == QEvent::MouseButtonDblClick &&
idx.data().canConvert()) {
if ((idx.flags() & Qt::ItemIsEditable) &&
static_cast(e)->button() == Qt::LeftButton) {
QColorDialog *dlg = new QColorDialog(const_cast(opt.widget));
dlg->setColor(idx.data().value());
dlg->setModal(true);
dlg->setAttribute(Qt::WA_DeleteOnClose);
connect(dlg, ::colorSelected, this, [mdl, idx](const QColor
) {
mdl->setData(idx, QVariant::fromValue(c));
});
dlg->show();
}
return true;
}
return QStyledItemDelegate::editorEvent(e, mdl, opt, idx);
}
HTH,
-Max
On 11/12/2019 3:45 PM, Matthew Woehlke wrote:
I have a QTreeView. For one of the columns, rather than editing the data
in-place, I want to pop up a QTextEdit. (For now, I'm hoping I'll be
able to use QInputDialog, but I may end up needing to roll my own.)
Is it reasonable to execute the dialog (QDialog::exec()) in an override
of QAbstractItemDelegate::createEditor, or do I need to hook
itemActivated or some such? (Maybe QAbstractItemDelegate::editorEvent
would be better?)
What is the best way to trigger the editor?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Most simple emit from singleton?
Why not declare a signals into your singleton header and call it directly?
MySingleton.h
class MySingleton
{
signals:
void MySignals();
};
myOtherCode.cpp
Q_EMIT MySingleton::Instance()->MySignals();
-Original Message-
From: Interest On Behalf Of Jason H
Sent: November 13, 2019 11:28 AM
To: interestqt-project.org
Subject: [Interest] Most simple emit from singleton?
I've stumbled across a paradigm that I am starting to use frequently where I
have a singleton, and I want it to emit something when I tell it to.
So I've been providing a function and doing:
MySingleton::instance()->emitMySignal();
Where:
void MySingleton::emitMySignal() {
emit mySignal();
}
But this seems "silly". Is there a better way to do this? Ideally I'd like to
skip creating the function and do something like:
MySingleton::instance()->emit MySignal(); or emit
MySingleton::instance()->MySignal();
There may still be a better way?
Thoughts?
Thanks!
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] Most simple emit from singleton?
I've stumbled across a paradigm that I am starting to use frequently where I
have a singleton, and I want it to emit something when I tell it to.
So I've been providing a function and doing:
MySingleton::instance()->emitMySignal();
Where:
void MySingleton::emitMySignal() {
emit mySignal();
}
But this seems "silly". Is there a better way to do this? Ideally I'd like to
skip creating the function and do something like:
MySingleton::instance()->emit MySignal();
or
emit MySingleton::instance()->MySignal();
There may still be a better way?
Thoughts?
Thanks!
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Rebuild QPA plugins
Le mer. 13 nov. 2019 à 07:12, Simon Matthews < simon.matth...@bluepearlsoftware.com> a écrit : > You don't need RHEL, just use CentOS. > > Have you tried setting the environment variable: > > export QT_DEBUG_PLUGINS=1 > > This might give you more information on the problem. > > You might have issues with the RUNPATH in the file? > > What does > > ldd -r > > report? > > Simon > Thanks for the tips. I did have an issue with the RUNPATH. Now I have: Cannot load library /opt/Qt/5.13.2/gcc_64/plugins/platforms/libqxcb.so: (/opt/Qt/5.13.2/gcc_64/plugins/platforms/libqxcb.so: undefined symbol: _ZTI26QPlatformIntegrationPlugin, version Qt_5) QLibraryPrivate::loadPlugin failed on "/opt/Qt/5.13.2/gcc_64/plugins/platforms/libqxcb.so" : "Cannot load library /opt/Qt/5.13.2/gcc_64/plugins/platforms/libqxcb.so: (/opt/Qt/5.13.2/gcc_64/plugins/platforms/libqxcb.so: undefined symbol: _ZTI26QPlatformIntegrationPlugin, version Qt_5)" qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. ldd has no missing libraries, but reports: undefined symbol: _ZTI26QPlatformIntegrationPlugin, version Qt_5 (./libqxcb.so) undefined symbol: _ZN26QPlatformIntegrationPlugin6createERK7QStringRK11QStringList, version Qt_5(./libqxcb.so) undefined symbol: _ZN26QPlatformIntegrationPlugin16staticMetaObjectE, version Qt_5 (./libqxcb.so) undefined symbol: _ZN26QPlatformIntegrationPluginC2EP7QObject, version Qt_5 (./libqxcb.so) undefined symbol: _ZN26QPlatformIntegrationPlugin11qt_metacastEPKc, version Qt_5(./libqxcb.so) undefined symbol: _ZN26QPlatformIntegrationPlugin11qt_metacallEN11QMetaObject4CallEiPPv, version Qt_5 (./libqxcb.so) undefined symbol: _ZN26QPlatformIntegrationPluginD2Ev, version Qt_5 (./libqxcb.so) ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
