Re: [Interest] Android will require 64bit soon
On 02/01/19 08:16, m...@herrdiel.de wrote: I am developing on windows. That means that I will no longer be able to provide acceptable apps with Qt Creator soon, am I right? I hope to be wrong... What is that? You "can" develop 64-bit (only) stuff, it's just that some don't seem to be doing it... ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] lists.qt-project.org SSL problem
On 10/24/18 15:36, Andy wrote: Were you using https? https://lists.qt-project.org This was the full URL: https://lists.qt-project.org/pipermail/releasing/2018-October/thread.html It doesn't work on any browser I have. Yeah, same here. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QTimer at 30Hz interval?
On 04/04/18 09:52, Daniel Engelke wrote: What about QElapsedTimer you can get nanoseconds out of it. Yeah, but it doesn't have signals to fire on a timeout... QElapsedTimer's major purpose is measuring time, not sending (repeated) signals. So it's more like QTime, not like QTimer. Cheers, René ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QTimer at 30Hz interval?
On 04/04/18 09:33, Ola Røer Thorsen wrote: is there some nice trick to make a QTimer trigger at 30 Hz? This interval can't be expressed properly in milliseconds (1000/30 = 33.33...) My use case is for Linux only so I'd be happy with some Linux-specific way of triggering a signal at 30 Hz too. It won't have to be very precise for each trigger as long as the average frequency is 30 Hz. Not sure (and I haven't tried it myself), but maybe this class can help: https://github.com/rsmz/qnanotimer HTH, René ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5: how to disable single-click activation in QAbstractItemView's?
Am 27.12.2012 22:14, schrieb Bache-Wiig Jens:
That said, it should be relatively easy to work around this in an application
by creating a custom proxy style:
class MyProxyStyle : public QProxyStyle
{
public:
int styleHint(StyleHint hint, const QStyleOption *option = 0,
const QWidget *widget = 0, QStyleHintReturn *returnData =
0) const {
if (hint == QStyle:: SH_ItemView_ActivateItemOnSingleClick)
return 0;
return QProxyStyle::styleHint(hint, option, widget, returnData);
}
};
Just set this as your application style and it should revert to the old
behaviour regardless what your existing application style is.
Thanks for that. Yes, I think it should work. However, as I offer all
available styles to my users for selection I'd have to do this for every
single style... and it's probably not really usable when querying them
via QStyleFactory::keys(). I actually don't want to change them
hard-coded, but it seems there's no other solution...
It might simply be a bug in which case I'd gladly file a bug report, but
I would like to hear some developer's opinions on it before I do so... I
think it's pointless to file a bug if it's wanted behavior - for
whatever weird reason.
@Andreas: yes, I'm sure about this. Changing the default in KDE (or any
other desktop environment) doesn't change the situation. I haven't yet
tried it on anything else than Linux, though.
Not using the activated() or itemActivated() signals is pointless IMHO
because it would mean a drastic change in *many* parts of the code and
doesn't really sound like the way to go, simply because of API
compatibility (which according to the docs hasn't changed in this
area)... also, note that I'm still using Qt 4 primarily.
Thanks again for your replies!
Cheers, René
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5: how to disable single-click activation in QAbstractItemView's?
Am 28.12.2012 00:25, schrieb René Reucher:
Am 27.12.2012 22:14, schrieb Bache-Wiig Jens:
That said, it should be relatively easy to work around this in an
application by creating a custom proxy style:
class MyProxyStyle : public QProxyStyle
{
public:
int styleHint(StyleHint hint, const QStyleOption *option = 0,
const QWidget *widget = 0, QStyleHintReturn *returnData
= 0) const {
if (hint == QStyle:: SH_ItemView_ActivateItemOnSingleClick)
return 0;
return QProxyStyle::styleHint(hint, option, widget, returnData);
}
};
Just set this as your application style and it should revert to the old
behaviour regardless what your existing application style is.
Thanks for that. Yes, I think it should work. However, as I offer all
available styles to my users for selection I'd have to do this for every
single style... and it's probably not really usable when querying them
via QStyleFactory::keys(). I actually don't want to change them
hard-coded, but it seems there's no other solution...
Nevermind... I somehow overlooked the words regardless what your
existing application style is :). I'll try it and let you know the results!
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
