Merge branch '4.7' of scm.dev.nokia.troll.no:qt/oslo-staging-1 into 4.7-integration

* '4.7' of scm.dev.nokia.troll.no:qt/oslo-staging-1:
  Cocoa: revert parts of cc6dc0aeefde881a95f5fea2b26f2f3d7bdc6e15
  Cocoa, Autotest: disable autotest that was added a bit premature
  make error messages consistent
  Add tests/benchmarks/README
  qgrayraster: Remove unnecessary indirection in QT_FT_Outline_Decompose
  Cocoa: add autotest to be more safe regarding child window stacking
  Fix compilation: QT_NO_TEXTSTREAM
  exclude QtXmlPatterns from the completeness assessment
  fix QMAKE_SUBSTITUTES with shadow builds
  Outline / fill inconsistency in X11 paint engine.
  Cocoa: parent windows shows on screen when they should be hidden
  Prevented Xorg crash in qtdemo when running corkboards example.

7 files changed, 184 insertions, 0 deletions

diff --git a/tests/auto/macnativeevents/tst_macnativeevents.cpp b/tests/auto/macnativeevents/tst_macnativeevents.cpp
index ffd0596..d582417 100644
--- a/tests/auto/macnativeevents/tst_macnativeevents.cpp
+++ b/tests/auto/macnativeevents/tst_macnativeevents.cpp
@@ -67,6 +67,11 @@ private slots:
     void testDragWindow();
     void testMouseEnter();
     void testChildDialogInFrontOfModalParent();
+#ifdef QT_MAC_USE_COCOA
+    void testChildWindowInFrontOfParentWindow();
+//    void testChildToolWindowInFrontOfChildNormalWindow();
+    void testChildWindowInFrontOfStaysOnTopParentWindow();
+#endif
     void testKeyPressOnToplevel();
 };
 
@@ -308,6 +313,82 @@ void tst_MacNativeEvents::testChildDialogInFrontOfModalParent()
     QVERIFY(!child.isVisible());
 }
 
+#ifdef QT_MAC_USE_COCOA
+void tst_MacNativeEvents::testChildWindowInFrontOfParentWindow()
+{
+    // Test that a child window always stacks in front of its parent window.
+    // Do this by first click on the parent, then on the child window button.
+    QWidget parent;
+    QPushButton child("a button", &parent);
+    child.setWindowFlags(Qt::Window);
+    connect(&child, SIGNAL(clicked()), &child, SLOT(close()));
+    parent.show();
+    child.show();
+
+    QPoint parent_p = parent.geometry().bottomLeft() + QPoint(20, -20);
+    QPoint child_p = child.geometry().center();
+
+    NativeEventList native;
+    native.append(new QNativeMouseButtonEvent(parent_p, Qt::LeftButton, 1, Qt::NoModifier));
+    native.append(new QNativeMouseButtonEvent(parent_p, Qt::LeftButton, 0, Qt::NoModifier));
+    native.append(new QNativeMouseButtonEvent(child_p, Qt::LeftButton, 1, Qt::NoModifier));
+    native.append(new QNativeMouseButtonEvent(child_p, Qt::LeftButton, 0, Qt::NoModifier));
+
+    native.play();
+    QTest::qWait(100);
+    QVERIFY(!child.isVisible());
+}
+
+/* This test can be enabled once setStackingOrder has been fixed in qwidget_mac.mm
+void tst_MacNativeEvents::testChildToolWindowInFrontOfChildNormalWindow()
+{
+    // Test that a child tool window always stacks in front of normal sibling windows.
+    // Do this by first click on the sibling, then on the tool window button.
+    QWidget parent;
+    QWidget normalChild(&parent, Qt::Window);
+    QPushButton toolChild("a button", &parent);
+    toolChild.setWindowFlags(Qt::Tool);
+    connect(&toolChild, SIGNAL(clicked()), &toolChild, SLOT(close()));
+    parent.show();
+    normalChild.show();
+    toolChild.show();
+
+    QPoint normalChild_p = normalChild.geometry().bottomLeft() + QPoint(20, -20);
+    QPoint toolChild_p = toolChild.geometry().center();
+
+    NativeEventList native;
+    native.append(new QNativeMouseButtonEvent(normalChild_p, Qt::LeftButton, 1, Qt::NoModifier));
+    native.append(new QNativeMouseButtonEvent(normalChild_p, Qt::LeftButton, 0, Qt::NoModifier));
+    native.append(new QNativeMouseButtonEvent(toolChild_p, Qt::LeftButton, 1, Qt::NoModifier));
+    native.append(new QNativeMouseButtonEvent(toolChild_p, Qt::LeftButton, 0, Qt::NoModifier));
+
+    native.play();
+    QTest::qWait(100);
+    QVERIFY(!toolChild.isVisible());
+}
+*/
+void tst_MacNativeEvents::testChildWindowInFrontOfStaysOnTopParentWindow()
+{
+    // Test that a child window stacks on top of a stays-on-top parent.
+    QWidget parent(0, Qt::WindowStaysOnTopHint);
+    QPushButton button("close", &parent);
+    button.setWindowFlags(Qt::Window);
+    connect(&button, SIGNAL(clicked()), &button, SLOT(close()));
+    parent.show();
+    button.show();
+    QPoint inside = button.geometry().center();
+
+    // Post a click on the button to close the child dialog:
+    NativeEventList native;
+    native.append(new QNativeMouseButtonEvent(inside, Qt::LeftButton, 1, Qt::NoModifier));
+    native.append(new QNativeMouseButtonEvent(inside, Qt::LeftButton, 0, Qt::NoModifier));
+
+    native.play();
+    QTest::qWait(100);
+    QVERIFY(!button.isVisible());
+}
+#endif
+
 void tst_MacNativeEvents::testKeyPressOnToplevel()
 {
     // Check that we receive keyevents for
diff --git a/tests/auto/qmake/testdata/substitutes/sub/test2.in b/tests/auto/qmake/testdata/substitutes/sub/test2.in
new file mode 100644
index 0000000..78a6069
--- /dev/null
+++ b/tests/auto/qmake/testdata/substitutes/sub/test2.in
@@ -0,0 +1 @@
+heya
diff --git a/tests/auto/qmake/testdata/substitutes/test.in b/tests/auto/qmake/testdata/substitutes/test.in
new file mode 100644
index 0000000..2fa05e0
--- /dev/null
+++ b/tests/auto/qmake/testdata/substitutes/test.in
@@ -0,0 +1,2 @@
+test
+tst
diff --git a/tests/auto/qmake/testdata/substitutes/test.pro b/tests/auto/qmake/testdata/substitutes/test.pro
new file mode 100644
index 0000000..5bce312
--- /dev/null
+++ b/tests/auto/qmake/testdata/substitutes/test.pro
@@ -0,0 +1,2 @@
+QMAKE_SUBSTITUTES += test.in
+# doesn't work for the time being: sub/test2.in
diff --git a/tests/auto/qmake/testdata/substitutes_build/README b/tests/auto/qmake/testdata/substitutes_build/README
new file mode 100644
index 0000000..81dc596
--- /dev/null
+++ b/tests/auto/qmake/testdata/substitutes_build/README
@@ -0,0 +1 @@
+Placeholder file to ensure this directory exists
diff --git a/tests/auto/qmake/tst_qmake.cpp b/tests/auto/qmake/tst_qmake.cpp
index 5efe714..825e49b 100644
--- a/tests/auto/qmake/tst_qmake.cpp
+++ b/tests/auto/qmake/tst_qmake.cpp
@@ -90,6 +90,7 @@ private slots:
     void bundle_spaces();
 #endif
     void includefunction();
+    void substitutes();
 
 private:
     TestCompiler test_compiler;
@@ -477,6 +478,21 @@ void tst_qmake::includefunction()
     QVERIFY(test_compiler.commandOutput().contains(warningMsg));
 }
 
+void tst_qmake::substitutes()
+{
+    QString workDir = base_path + "/testdata/substitutes";
+    QVERIFY( test_compiler.qmake( workDir, "test" ));
+    QVERIFY( test_compiler.exists( workDir, "test", Exe, "1.0.0" ));
+    //QVERIFY( test_compiler.exists( workDir, "sub/test2", Exe, "1.0.0" ));
+    QVERIFY( test_compiler.makeDistClean( workDir ));
+
+    QString buildDir = base_path + "/testdata/substitutes_build";
+    QVERIFY( test_compiler.qmake( workDir, "test", buildDir ));
+    QVERIFY( test_compiler.exists( buildDir, "test", Exe, "1.0.0" ));
+    //QVERIFY( test_compiler.exists( buildDir, "sub/test2", Exe, "1.0.0" ));
+    QVERIFY( test_compiler.makeDistClean( buildDir ));
+}
+
 QTEST_MAIN(tst_qmake)
 #include "tst_qmake.moc"
 
diff --git a/tests/benchmarks/README b/tests/benchmarks/README
new file mode 100644
index 0000000..d437299
--- /dev/null
+++ b/tests/benchmarks/README
@@ -0,0 +1,81 @@
+The most reliable way of running benchmarks is to do it in an otherwise idle
+system. On a busy system, the results will vary according to the other tasks
+demanding attention in the system.
+
+We have managed to obtain quite reliable results by doing the following on 
+Linux (and you need root):
+
+ - switching the scheduler to a Real-Time mode
+ - setting the processor affinity to one single processor
+ - disabling the other thread of the same core
+
+This should work rather well for CPU-intensive tasks. A task that is in Real-
+Time mode will simply not be preempted by the OS. But if you make OS syscalls, 
+especially I/O ones, your task will be de-scheduled. Note that this includes 
+page faults, so if you can, make sure your benchmark's warmup code paths touch 
+most of the data.
+
+To do this you need a tool called schedtool (package schedtool), from 
+http://freequaos.host.sk/schedtool/
+
+From this point on, we are using CPU0 for all tasks:
+
+If you have a Hyperthreaded multi-core processor (Core-i5 and Core-i7), you 
+have to disable the other thread of the same core as CPU0. To discover which 
+one it is:
+
+$ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
+
+This will print something like 0,4, meaning that CPUs 0 and 4 are sibling 
+threads on the same core. So we'll turn CPU 4 off:
+
+(as root)
+# echo 0 > /sys/devices/system/cpu/cpu4/online
+
+To turn it back on, echo 1 into the same file.
+
+To run a task on CPU 0 exclusively, using FIFO RT priority 10, you run the 
+following:
+
+(as root)
+# schedtool -F -p 10 -a 1 -e ./taskname
+
+For example:
+# schedtool -F -p 10 -a 1 -e ./tst_bench_qstring -tickcounter
+
+Warning: if your task livelocks or takes far too long to complete, your system 
+may be unusable for a long time, especially if you don't have other cores to 
+run stuff on. To prevent that, run it before schedtool and time it.
+
+You can also limit the CPU time that the task is allowed to take. Run in the 
+same shell as you'll run schedtool:
+
+$ ulimit -s 300
+To limit to 300 seconds (5 minutes)
+
+If your task runs away, it will get a SIGXCPU after consuming 5 minutes of CPU 
+time (5 minutes running at 100%).
+
+If your app is multithreaded, you may want to give it more CPUs, like CPU0 and 
+CPU1 with -a 3  (it's a bitmask).
+
+For best results, you should disable ALL other cores and threads of the same 
+processor. The new Core-i7 have one processor with 4 cores, 
+each core can run 2 threads; the older Mac Pros have two processors with 4 
+cores each. So on those Mac Pros, you'd disable cores 1, 2 and 3, while on the 
+Core-i7, you'll need to disable all other CPUs.
+
+However, disabling just the sibling thread seems to produce very reliable 
+results for me already, with variance often below 0.5% (even though there are 
+some measurable spikes).
+
+Other things to try:
+
+Running the benchmark with highest priority, i.e. "sudo nice -19" 
+usually produces stable results on some machines. If the benchmark also 
+involves displaying something on the screen (on X11), running it with 
+"-sync" is a must. Though, in that case the "real" cost is not correct, 
+but it is useful to discover regressions.
+
+Also; not many people know about ionice (1)
+      ionice - get/set program io scheduling class and priority