Re: [Development] QtQuick TestCase with other top windows
yes i'm 2015-07-30 8:49 GMT+02:00 Curtis Mitch : > I thought that you were writing tests within Qt? > > > > *From:* Filippo Cucchetto [mailto:filippocucche...@gmail.com] > *Sent:* Thursday, 30 July 2015 8:41 AM > *To:* Curtis Mitch > *Cc:* development@qt-project.org > *Subject:* Re: [Development] QtQuick TestCase with other top windows > > > > I wrote that and i basically broke the one definition rule of C++ since in > the .pro > <http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/menubar.pro> > file > > i added the plugin cpp files. This results in one definition of > QQuickMenuBar > > inside the plugin and one inside the test. > I think that this could be solved if we export those classes from the > plugin and > > the test links to it (see the point (3) of my previous email). > > > > > > > 2015-07-30 8:09 GMT+02:00 Curtis Mitch : > >*From:* development-bounces+mitch.curtis= > theqtcompany@qt-project.org [mailto:development-bounces+mitch.curtis= > theqtcompany@qt-project.org] *On Behalf Of *Filippo Cucchetto > *Sent:* Wednesday, 29 July 2015 9:53 PM > *To:* development@qt-project.org > *Subject:* [Development] QtQuick TestCase with other top windows > > > > Hi everyone this is my first post on the mailing list so please bear with > me. > > Currently i'm trying to create some tests for the qtquick menuba. > For achieving this i need to create an ApplicationWindow and sending > events to it. > > Currently the TestCase qml component sends all the events to the Test > window. > > This obviously doesn't fit my use case. > > I investigated a little how to fix that: > > > 1) Add a battery of overloads for the mouseClick and keyPress functions > that take > > a QWindow* parameter. > Pros: the current tests are not effected by the change and it's a more > general approach (useful in some particular cases like mine). > > Cons: a new set of functions. In particular from the qml side we will have > the pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] > etc. > > > > 2) Make the TestCase send the events to the window where a particular item > belongs. > > However this works with the functions that take a QQuickItem as a > parameter (like mouseClick(item, x, y, ...) but not for keyPress(...) since > it doesn't > have a QQuickItem argument. The idea is to forward the key events to the > currently active window (so the one that has the keyboard focus). > Pros: no API bloat > > Cons: i implemented it and a lot of test cases broke. Basically most of > them rely to the current TestCase behaviour to send > events to the testcase window. This change broke some test where we have > popups, like in the ComboBox tests. > > 3) Make a standalone C++ app for making such tests without touching the > TestCase code. > > Pros: Current tests are not effected. > > Cons: Some code duplication. Furthermore, currently, most of classes > inside the QtQuickControls plugin aren't exported so even if my app is > linked to it i cannot use them. > > To be honest, i basically tried all the previous 3 options and if i'm the > one to choose i would go with the option (1) > > since i don't want to break everyone's code. > > > > > > -- > > Filippo Cucchetto > > > > I’m probably missing something, but what’s wrong with extending the > existing tst_menubar? > > > > > http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/tst_menubar.cpp > > > > > > > -- > > Filippo Cucchetto > -- Filippo Cucchetto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick TestCase with other top windows
I thought that you were writing tests within Qt? From: Filippo Cucchetto [mailto:filippocucche...@gmail.com] Sent: Thursday, 30 July 2015 8:41 AM To: Curtis Mitch Cc: development@qt-project.org Subject: Re: [Development] QtQuick TestCase with other top windows I wrote that and i basically broke the one definition rule of C++ since in the .pro<http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/menubar.pro> file i added the plugin cpp files. This results in one definition of QQuickMenuBar inside the plugin and one inside the test. I think that this could be solved if we export those classes from the plugin and the test links to it (see the point (3) of my previous email). 2015-07-30 8:09 GMT+02:00 Curtis Mitch mailto:mitch.cur...@theqtcompany.com>>: From: development-bounces+mitch.curtis=theqtcompany@qt-project.org<mailto:theqtcompany@qt-project.org> [mailto:development-bounces+mitch.curtis<mailto:development-bounces%2Bmitch.curtis>=theqtcompany@qt-project.org<mailto:theqtcompany@qt-project.org>] On Behalf Of Filippo Cucchetto Sent: Wednesday, 29 July 2015 9:53 PM To: development@qt-project.org<mailto:development@qt-project.org> Subject: [Development] QtQuick TestCase with other top windows Hi everyone this is my first post on the mailing list so please bear with me. Currently i'm trying to create some tests for the qtquick menuba. For achieving this i need to create an ApplicationWindow and sending events to it. Currently the TestCase qml component sends all the events to the Test window. This obviously doesn't fit my use case. I investigated a little how to fix that: 1) Add a battery of overloads for the mouseClick and keyPress functions that take a QWindow* parameter. Pros: the current tests are not effected by the change and it's a more general approach (useful in some particular cases like mine). Cons: a new set of functions. In particular from the qml side we will have the pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] etc. 2) Make the TestCase send the events to the window where a particular item belongs. However this works with the functions that take a QQuickItem as a parameter (like mouseClick(item, x, y, ...) but not for keyPress(...) since it doesn't have a QQuickItem argument. The idea is to forward the key events to the currently active window (so the one that has the keyboard focus). Pros: no API bloat Cons: i implemented it and a lot of test cases broke. Basically most of them rely to the current TestCase behaviour to send events to the testcase window. This change broke some test where we have popups, like in the ComboBox tests. 3) Make a standalone C++ app for making such tests without touching the TestCase code. Pros: Current tests are not effected. Cons: Some code duplication. Furthermore, currently, most of classes inside the QtQuickControls plugin aren't exported so even if my app is linked to it i cannot use them. To be honest, i basically tried all the previous 3 options and if i'm the one to choose i would go with the option (1) since i don't want to break everyone's code. -- Filippo Cucchetto I’m probably missing something, but what’s wrong with extending the existing tst_menubar? http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/tst_menubar.cpp -- Filippo Cucchetto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick TestCase with other top windows
I wrote that and i basically broke the one definition rule of C++ since in the .pro <http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/menubar.pro> file i added the plugin cpp files. This results in one definition of QQuickMenuBar inside the plugin and one inside the test. I think that this could be solved if we export those classes from the plugin and the test links to it (see the point (3) of my previous email). 2015-07-30 8:09 GMT+02:00 Curtis Mitch : >*From:* development-bounces+mitch.curtis= > theqtcompany@qt-project.org [mailto:development-bounces+mitch.curtis= > theqtcompany@qt-project.org] *On Behalf Of *Filippo Cucchetto > *Sent:* Wednesday, 29 July 2015 9:53 PM > *To:* development@qt-project.org > *Subject:* [Development] QtQuick TestCase with other top windows > > > > Hi everyone this is my first post on the mailing list so please bear with > me. > > Currently i'm trying to create some tests for the qtquick menuba. > For achieving this i need to create an ApplicationWindow and sending > events to it. > > Currently the TestCase qml component sends all the events to the Test > window. > > This obviously doesn't fit my use case. > > I investigated a little how to fix that: > > > 1) Add a battery of overloads for the mouseClick and keyPress functions > that take > > a QWindow* parameter. > Pros: the current tests are not effected by the change and it's a more > general approach (useful in some particular cases like mine). > > Cons: a new set of functions. In particular from the qml side we will have > the pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] > etc. > > > > 2) Make the TestCase send the events to the window where a particular item > belongs. > > However this works with the functions that take a QQuickItem as a > parameter (like mouseClick(item, x, y, ...) but not for keyPress(...) since > it doesn't > have a QQuickItem argument. The idea is to forward the key events to the > currently active window (so the one that has the keyboard focus). > Pros: no API bloat > > Cons: i implemented it and a lot of test cases broke. Basically most of > them rely to the current TestCase behaviour to send > events to the testcase window. This change broke some test where we have > popups, like in the ComboBox tests. > > 3) Make a standalone C++ app for making such tests without touching the > TestCase code. > > Pros: Current tests are not effected. > > Cons: Some code duplication. Furthermore, currently, most of classes > inside the QtQuickControls plugin aren't exported so even if my app is > linked to it i cannot use them. > > To be honest, i basically tried all the previous 3 options and if i'm the > one to choose i would go with the option (1) > > since i don't want to break everyone's code. > > > > > > -- > > Filippo Cucchetto > > > > I’m probably missing something, but what’s wrong with extending the > existing tst_menubar? > > > > > http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/tst_menubar.cpp > > > -- Filippo Cucchetto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick TestCase with other top windows
From: development-bounces+mitch.curtis=theqtcompany@qt-project.org [mailto:development-bounces+mitch.curtis=theqtcompany@qt-project.org] On Behalf Of Filippo Cucchetto Sent: Wednesday, 29 July 2015 9:53 PM To: development@qt-project.org Subject: [Development] QtQuick TestCase with other top windows Hi everyone this is my first post on the mailing list so please bear with me. Currently i'm trying to create some tests for the qtquick menuba. For achieving this i need to create an ApplicationWindow and sending events to it. Currently the TestCase qml component sends all the events to the Test window. This obviously doesn't fit my use case. I investigated a little how to fix that: 1) Add a battery of overloads for the mouseClick and keyPress functions that take a QWindow* parameter. Pros: the current tests are not effected by the change and it's a more general approach (useful in some particular cases like mine). Cons: a new set of functions. In particular from the qml side we will have the pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] etc. 2) Make the TestCase send the events to the window where a particular item belongs. However this works with the functions that take a QQuickItem as a parameter (like mouseClick(item, x, y, ...) but not for keyPress(...) since it doesn't have a QQuickItem argument. The idea is to forward the key events to the currently active window (so the one that has the keyboard focus). Pros: no API bloat Cons: i implemented it and a lot of test cases broke. Basically most of them rely to the current TestCase behaviour to send events to the testcase window. This change broke some test where we have popups, like in the ComboBox tests. 3) Make a standalone C++ app for making such tests without touching the TestCase code. Pros: Current tests are not effected. Cons: Some code duplication. Furthermore, currently, most of classes inside the QtQuickControls plugin aren't exported so even if my app is linked to it i cannot use them. To be honest, i basically tried all the previous 3 options and if i'm the one to choose i would go with the option (1) since i don't want to break everyone's code. -- Filippo Cucchetto I’m probably missing something, but what’s wrong with extending the existing tst_menubar? http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/tst_menubar.cpp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtQuick TestCase with other top windows
Hi everyone this is my first post on the mailing list so please bear with me. Currently i'm trying to create some tests for the qtquick menuba. For achieving this i need to create an ApplicationWindow and sending events to it. Currently the TestCase qml component sends all the events to the Test window. This obviously doesn't fit my use case. I investigated a little how to fix that: 1) Add a battery of overloads for the mouseClick and keyPress functions that take a QWindow* parameter. Pros: the current tests are not effected by the change and it's a more general approach (useful in some particular cases like mine). Cons: a new set of functions. In particular from the qml side we will have the pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] etc. 2) Make the TestCase send the events to the window where a particular item belongs. However this works with the functions that take a QQuickItem as a parameter (like mouseClick(item, x, y, ...) but not for keyPress(...) since it doesn't have a QQuickItem argument. The idea is to forward the key events to the currently active window (so the one that has the keyboard focus). Pros: no API bloat Cons: i implemented it and a lot of test cases broke. Basically most of them rely to the current TestCase behaviour to send events to the testcase window. This change broke some test where we have popups, like in the ComboBox tests. 3) Make a standalone C++ app for making such tests without touching the TestCase code. Pros: Current tests are not effected. Cons: Some code duplication. Furthermore, currently, most of classes inside the QtQuickControls plugin aren't exported so even if my app is linked to it i cannot use them. To be honest, i basically tried all the previous 3 options and if i'm the one to choose i would go with the option (1) since i don't want to break everyone's code. -- Filippo Cucchetto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
