Re: [Interest] QML element from QWidget based class
You mean QML or QtQuick? If you want to instantiate widgets from QML then I think this should not be a problem (as you can instatiate there any QObject), just expose them to QML engine. If you mean embedding QWidget in a QtQuick application, then Olivier gave you the answer. BR, Filip On Wed, Nov 26, 2014 at 6:28 AM, Igor Mironchik igor.mironc...@gmail.com wrote: Hi guys, Is it possible to use QWidget based components in QML? What this QWidget based class have to do for it? Thanks. ___ 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] QML element from QWidget based class
On Wednesday 26 Nov 2014 09:06:25 Till Oliver Knoll wrote: Am 26.11.2014 um 06:28 schrieb Igor Mironchik igor.mironc...@gmail.com: Hi guys, Is it possible to use QWidget based components in QML? This might lead to the answer: http://qt-project.org/forums/viewthread/7893 The other way around - showing QML in a QWidget based application - is easy. Check the docs. It is also possible to use widgets declaratively with the help of https://github.com/KDAB/DeclarativeWidgets Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Keeping QML module versions up to date in a project
QML module versions is somewhat fuzzy area for me, so I'm looking for some advice. Some of my files start with a barrage of imports, like import QtQuick 2.3 import QtQuick.Controls 1.2 import QtQuick.Window 2.2 import QtSensors 5.0 import QtMultimedia 5.4 That becomes lots of versions to keep track of. I'm not sure if I do import QtQuick 2.0 will I import some bugs that would be fixed if I had done import QtQuick 2.3 How is it? Also the new file wizard seems to add older version imports, not the latest. For simplicity, I'd like to track the latest version of all the modules. Is that info centralized somewhere? Thanks, Harri ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.4 iOS as a FrameWork
No, it can't. -Richard Fra: interest-bounces+richard.gustavsen=theqtcompany@qt-project.org interest-bounces+richard.gustavsen=theqtcompany@qt-project.org på vegne av Mike Krus mike.k...@gmail.com Sendt: 25. november 2014 19:46 Til: interest@qt-project.org Emne: [Interest] Qt 5.4 iOS as a FrameWork Hi anybody know if the upcoming 5.4 version can be built as a framework when targeting iOS 8? Mike ___ 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] How to preventing Flickable to steal touch events
I have tried to get QtQuick2 maps to work with flickable. The issue is that Flickable steals touch events from Maps gesture area. There is no prevent stealing property on map component. QDeclarativeGeoMap inherits QQuickItem . QQuickItem has grabTouchPoints(const QVectorint ids) and setKeepTouchGrab(bool keep) methods. I modified QDeclarativeGeoMap::touchEvent to usegrabTouchPoints and setKeepTouchGrab but still I can't prevent flickable to steal touch events. Is there any method even in C++ level to prevent flickable to stealing events from QQuickItem ? Kate ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Keeping QML module versions up to date in a project
Hi, While I'm not aware of the versions being well documented, the autocomplete in QtCreator seems to offer all the available versions, so you can check that. The idea originally was that the versions should reflect the Qt module version, but IIRC this is not strictly true, as the version will not be bumped if the API is not actually different. The import versioning system as done by Qt is a sort of API handshake - it doesn't actually select between different implementations, you just select feature-sets. Thus, you should always import the latest (for better or worse). Unfortunately, Qt has no wildcard import syntax (or for latest). The good news is your 2.0 statement will import whatever the latest implementation registers for the 2.0 version. The ((un)intended?) side-effect of this is that the backward compatibility is not 100% - if you relied on something that has changes/fixes in the newer implementation, there is no going back other than downgrading your Qt version. If you're not bundling your Qt libs (like on Linux desktops), it gets a bit worse as there is no elegant fallback versioning mechanism, so you need to do either dynamic loaders or maintain parallel versions of your QML files. Best regards, Attila On 11/26/2014 10:04 AM, Harri Pasanen wrote: QML module versions is somewhat fuzzy area for me, so I'm looking for some advice. Some of my files start with a barrage of imports, like import QtQuick 2.3 That becomes lots of versions to keep track of. I'm not sure if I do import QtQuick 2.0 will I import some bugs that would be fixed if I had done import QtQuick 2.3 How is it? Also the new file wizard seems to add older version imports, not the latest. For simplicity, I'd like to track the latest version of all the modules. Is that info centralized somewhere? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Keeping QML module versions up to date in a project
On 26 November 2014 at 13:29, Attila Csipa q...@csipa.in.rs wrote: The good news is your 2.0 statement will import whatever the latest implementation registers for the 2.0 version. The ((un)intended?) side-effect of this is that the backward compatibility is not 100% - if you relied on something that has changes/fixes in the newer implementation, there is no going back other than downgrading your Qt version. If this is so, then I wonder if it won't be better to introduce/ change the syntax to something like this: import at least QtQuick 2.0 or (probably better) require QtQuick 2.0 meaning include the newest feature set available, while 2.0 is the absolute minimum. It describes the reality a bit better. When people see import QtQuick 2.0 they often think oh my, if I update Qt version, I will have to bump all those numbers in my code. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Keeping QML module versions up to date in a project
On 11/26/2014 1:39 PM, Tomasz Siekierda wrote: On 26 November 2014 at 13:29, Attila Csipa q...@csipa.in.rs wrote: The good news is your 2.0 statement will import whatever the latest implementation registers for the 2.0 version. The ((un)intended?) side-effect of this is that the backward compatibility is not 100% - if you relied on something that has changes/fixes in the newer implementation, there is no going back other than downgrading your Qt version. If this is so, then I wonder if it won't be better to introduce/ change the syntax to something like this: import at least QtQuick 2.0 or (probably better) require QtQuick 2.0 meaning include the newest feature set available, while 2.0 is the absolute minimum. It describes the reality a bit better. When people No, the import version specifies the exact feature set you'll get - as said, there are no wildcards/ranges/macros. I was told this is intentional, to guarantee compatibility. FWIW I still disagree with the way it's done, but there you have it, I suspect this will be coming up again and again. Some history of the matter and attemps at having this altered: http://comments.gmane.org/gmane.comp.lib.qt.devel/8464 Best regards, Attila ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt downloads now moved to qt.io
Hello, As part of the website updates, the download page on qt-project.org is now redirected to qt.io. You can read the details at the blog (which will also move to a qt.io address in the near future). http://blog.qt.digia.com/blog/2014/11/26/qt-downloads-moving-to-qt-io/ Best regards, Tero Kojo ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to preventing Flickable to steal touch events
On Wednesday, November 26, 2014 12:53:54 PM Kate Alhola wrote: I have tried to get QtQuick2 maps to work with flickable. The issue is that Flickable steals touch events from Maps gesture area. There is no prevent stealing property on map component. QDeclarativeGeoMap inherits QQuickItem . QQuickItem has grabTouchPoints(const QVectorint ids) and setKeepTouchGrab(bool keep) methods. I modified QDeclarativeGeoMap::touchEvent to usegrabTouchPoints and setKeepTouchGrab but still I can't prevent flickable to steal touch events. You could try to also set the mouse equivalents (setKeepMouseGrab iirc). Cheers, Frederik Is there any method even in C++ level to prevent flickable to stealing events from QQuickItem ? Kate ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.4 iOS as a FrameWork
that’s a pity. Apple now accepts the use of frameworks, would be nice to make easier to conform with the LGPL, not to mention not having to deploy huge binaries to the device every time you change your code and rebuild... On 26 Nov 2014, at 09:06, Gustavsen Richard richard.gustav...@theqtcompany.com wrote: No, it can't. -Richard Fra: interest-bounces+richard.gustavsen=theqtcompany@qt-project.org interest-bounces+richard.gustavsen=theqtcompany@qt-project.org på vegne av Mike Krus mike.k...@gmail.com Sendt: 25. november 2014 19:46 Til: interest@qt-project.org Emne: [Interest] Qt 5.4 iOS as a FrameWork Hi anybody know if the upcoming 5.4 version can be built as a framework when targeting iOS 8? Mike ___ 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] Keeping QML module versions up to date in a project
On Wednesday 26 November 2014 13:29:12 Attila Csipa wrote: The import versioning system as done by Qt is a sort of API handshake - it doesn't actually select between different implementations, you just select feature-sets. Thus, you should always import the latest (for better or worse). Unfortunately, Qt has no wildcard import syntax (or for latest). You should import the latest when you write the application. But if the library is updated behind your back, the import shouldn't change. Thus, if there is new behaviour you didn't test with, your application won't be affected. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Confusing activation behavior of floating windows
I am seeing confusing QEvent::WindowActivate events associated with floating
windows on Macintosh. I wonder if someone can give me an explanation. Please
excuse the length...
The code here is a vastly simplified version of actual application code.
I use code like this to make three floating windows. Note that each code block
makes a floating window, shows it and activates it. There is also code to name
everything so you can tell what you're seeing, and qDebug() statements so that
I can tell the order of what's happening. (hope it comes through readable):
void MainWindow::onGoButton()
{
Qt::WindowFlags qtflags = Qt::Tool | Qt::WindowStaysOnTopHint;
qtflags = qtflags | Qt::CustomizeWindowHint | Qt::WindowTitleHint |
Qt::CustomizeWindowHint | Qt::WindowTitleHint |
Qt::WindowMinimizeButtonHint |
Qt::WindowMaximizeButtonHint;
qDebug() About to create Window A;
QWidget * wa = new QWidget(0, qtflags);
wa-setObjectName(Window A);
wa-setWindowTitle(Window A);
qDebug() About to show Window A;
wa-show();
qDebug() About to activate Window A;
QApplication::setActiveWindow(wa);
qDebug() About to create Window B;
QWidget * wb = new QWidget(0, qtflags);
wb-setObjectName(Window B);
wb-setWindowTitle(Window B);
qDebug() About to show Window B;
wb-show();
qDebug() About to activate Window B;
QApplication::setActiveWindow(wb);
qDebug() About to create Window C;
QWidget * wc = new QWidget(0, qtflags);
wc-setObjectName(Window C);
wc-setWindowTitle(Window C);
qDebug() About to show Window C;
wc-show();
qDebug() About to activate Window C;
QApplication::setActiveWindow(wc);
}
I also use QApplication::notify() to monitor QEvent::WindowActivate:
bool myApp::notify(QObject *object, QEvent *event)
{
if (event-type() == QEvent::WindowActivate)
{
qDebug() Window activate: object-objectName() and
the active window is QApplication::activeWindow()-objectName();
}
return QApplication::notify(object, event);
}
On Macintosh using Qt 5.4 RC (which means Cocoa) on OS X 10.9.5 I get this
output:
About to create Window A
About to show Window A
About to activate Window A
Window activate: Window A and the active window is Window A
About to create Window B
About to show Window B
About to activate Window B
Window activate: Window B and the active window is Window B
Window activate: Window A and the active window is Window B
About to create Window C
About to show Window C
About to activate Window C
Window activate: Window B and the active window is Window C
Window activate: Window A and the active window is Window C
Window activate: Window C and the active window is Window C
Note that the target for the event isn't always the same as what Qt thinks is
the active window.
On Windows I get more reasonable output:
About to create Window A
About to show Window A
About to activate Window A
Window activate: Window A and the active window is Window A
About to create Window B
About to show Window B
About to activate Window B
Window activate: Window B and the active window is Window B
About to create Window C
About to show Window C
About to activate Window C
Window activate: Window C and the active window is Window C
Am I just seeing Cocoa weirdness? It looks like some of the time Qt is lying to
me about the activating window. But if it's a Qt bug, then it's been there a
long time- I also see it when building with Qt 4.8.6.
Thanks for any insight that can be offered!
-John Weeks
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt Unique Device Identifier
Hi, Is there any way of retrieving a unique device identifier with Qt? Nuno Santos ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Unique Device Identifier
On Wednesday 26 November 2014 19:30:50 Nuno Santos wrote: Hi, Is there any way of retrieving a unique device identifier with Qt? What device? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Easier access to list archives?
I wonder if there is a more user friendly site to list archives somewhere than what http://lists.qt-project.org/pipermail/ provides by default? Many posts are shown just as one very long line in my Firefox. A nice formatting for reading would good, a search feature would be even better. Maybe there is a firefox extension that handles formatting? Just wondering... Harri ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Easier access to list archives?
On Wednesday 26 November 2014 21:07:57 Harri Pasanen wrote: I wonder if there is a more user friendly site to list archives somewhere than what http://lists.qt-project.org/pipermail/ provides by default? Many posts are shown just as one very long line in my Firefox. A nice formatting for reading would good, a search feature would be even better. Maybe there is a firefox extension that handles formatting? Oh, yeah. http://blog.gmane.org/gmane.comp.lib.qt.general http://news.gmane.org/gmane.comp.lib.qt.general https://www.mail-archive.com/interest@qt-project.org/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Unique Device Identifier
Sorry, I forgot to specify. I was looking for a unified solution for iOS and Android. iOS has the identifierForVendor which gives a unique identifier per vendor. The unique device id was deprecated: [[UIDevice currentDevice] identifierForVendor]; Android seems to have a few options as well. I was wondering if this was somehow abstracted in Qt. Thanks, Regards, Nuno Santos On 26/11/2014, at 19:33, Thiago Macieira thiago.macie...@intel.com wrote: On Wednesday 26 November 2014 19:30:50 Nuno Santos wrote: Hi, Is there any way of retrieving a unique device identifier with Qt? What device? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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] Keeping QML module versions up to date in a project
On 11/26/2014 7:34 PM, Thiago Macieira wrote: On Wednesday 26 November 2014 13:29:12 Attila Csipa wrote: The import versioning system as done by Qt is a sort of API handshake - it doesn't actually select between different implementations, you just select feature-sets. Thus, you should always import the latest (for better or worse). Unfortunately, Qt has no wildcard import syntax (or for latest). You should import the latest when you write the application. But if the library is updated behind your back, the import shouldn't change. Thus, if there is new behaviour you didn't test with, your application won't be affected. Still - the only guarantee you get with a specific import version is that of the API, but not the behavior. Thus, it's perfectly possible that someone swaps the libs and your app *IS* affected. See for example the QML instantiation performance thread. You likely won't blow up, but far from can't be negatively impacted by having the lib updated behind your back. To add insult to injury, it's actually pretty hard to find out what was introduced when, so your imports will reflect which version of Qt I developed my app with rather than what Qt features does my app require. Thus, the way versioning is done, combined with a lack of conditionals is making it really hard to maintain a QML file/app when you're not the one bundling the Qt libs. I still fail to grasp why this is such a no-no. If it's okay to have a #if QT_VERSION = QT_VERSION_CHECK(5,3,0) ...why can't we have something functionally equal for QML? As it is now, whenever I decide to add support for a new feature, I make my QML incompatible with older Qt versions (which is understandable) with no way of defining a fallback or alternative (which is not OK) regardless how trivial the new feature is. Best regards, Attila ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] FOSDEM 2015
Guys, Less than 10 days for the deadline for the Desktops DevRoom at FOSDEM 2015 and not a single Qt-related talk submited. I cannot really believe nobody has anything to say! Call for Talks: http://www.elpauer.org/2014/10/fosdem-2015-desktops-devroom-call-for-talks/ -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
