[Development] QtQuick TestCase with other top windows

[Filippo Cucchetto]

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 <mitch.curtis at theqtcompany.com>:

>    *From:* development-bounces+mitch.curtis=
> theqtcompany.com at qt-project.org [mailto:development-bounces+mitch.curtis=
> theqtcompany.com at qt-project.org] *On Behalf Of *Filippo Cucchetto
> *Sent:* Wednesday, 29 July 2015 9:53 PM
> *To:* development at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150730/2209c6cc/attachment.html>