Skip to content
GitLab
Select Git revision
  • dev default
  • 6.2
  • 6.2.2
  • 5.12.12
  • 5.12
  • 6.1
  • 6.2.1
  • 6.2.0
  • 6.1.3
  • 6.0
  • 6.1.2
  • 6.1.1
  • 5.12.11
  • 6.1.0
  • 5.15
  • 6.0.0
  • 5.15.2
  • 5.12.10
  • 5.15.1
  • 5.12.9
  • v5.15.0-alpha1
  • v5.12.7
  • v5.14.1
  • v5.9.9
  • v5.14.0
  • v5.14.0-rc2
  • v5.14.0-rc1
  • v5.12.6
  • v5.14.0-beta3
  • v5.13.2
  • v5.14.0-beta2
  • v5.14.0-beta1
  • v5.14.0-alpha1
  • v5.12.5
  • v5.13.1
  • v5.13.0
  • v5.13.0-rc3
  • v5.12.4
  • v5.13.0-rc2
  • v5.13.0-rc1
  1. 05 Feb, 2018 - 4 commits
  3. 04 Feb, 2018 - 1 commit
  5. 03 Feb, 2018 - 1 commit
  7. 02 Feb, 2018 - 1 commit
  9. 01 Feb, 2018 - 9 commits
    • Liang Qi's avatar
      Merge remote-tracking branch 'origin/5.10.1' into 5.10 · 15ae7949
      Liang Qi authored 
      Change-Id: Ibbe355f5e8ef12e5ffeb4e33b6a80760c3e2b464
      15ae7949
    • Thiago Macieira's avatar
      Revert "QVariant: convert QDateTime and QTime to string with milliseconds" · 69d2501e
      Thiago Macieira authored 
      This reverts commit ab1e5075

. That was
supposed to be a minor behavior change, but ends up having visible
effects such as QtXmlPatterns xs:dateTime type now reporting sub-second
fractions. So we're reverting in 5.10 and re-applying in 5.11.

Change-Id: I741e49459c9a688c1c329d6cbd521cd4a0b2aa84
Reviewed-by: default avatarLars Knoll <lars.knoll@qt.io>
      69d2501e
    • Christian Strømme's avatar
      Android: Don't rely on QDir::homePath() to get the application directory · eadf9e54
      Christian Strømme authored 
      
If the QLoggingRegistry gets called as part of the static initialization
phase, it would call into Android's QStandarPaths implementation, which
assumed that the HOME env. variable was already set. Since the variable
isn't set before main is called, QDir::homePath() returns the root path,
which would be cached and always returned.

With this fix we now call Android's getFilesDir() directly, which will
always return the right path. Since the font locations are also relying
on an environment variable being set, we no longer cache that either.

Task-number: QTBUG-65820
Change-Id: If45f3d5f0e87b808a62118ae95c31b492885646a
Reviewed-by: default avatarTor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: default avatarEskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
      eadf9e54
    • Edward Welbourne's avatar
      Clean-up in QDateTime's parsing of ISODate{,WithMs} · b44df993
      Edward Welbourne authored 
      
Actually check that there's a T where ISO 8601 wants it (instead of
just skipping over whatever's there), with something after it; move
some declarations later; add some comments; and use the QStringRef API
more cleanly (so that it's easier to see what's going on).  Simplify a
loop condition to avoid the need for a post-loop fix-up.

This incidentally prevents an assertion failure (which brought the
mess to my attention) parsing a short string as an ISO date-time; if
there's a T with nothing after it, we won't try to read at index -1 in
the following text.  (The actual fail seen had a Z where the T should
have been, with nothing after it.)

Add tests for invalid ISOdate cases that triggered the assertion.

Task-number: QTBUG-66076
Change-Id: Ided9adf62a56d98f144bdf91b40f918e22bd82cd
Reviewed-by: default avatarIsrael Lins Albuquerque <israelins85@yahoo.com.br>
Reviewed-by: default avatarThiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit a9c111ed)
      b44df993
    • Nathan Collins's avatar
      Fix QFileDialog::defaultSuffix on macOS · 9b291337
      Nathan Collins authored 
      
Don't prepend the default suffix to the NSSavePanel allowedFileTypes.
"If no extension is given by the user, the first item in the
allowedFileTypes array will be used as the extension for the save
panel." The user expects to get the suffix displayed to them in the
drop down filter, not the default suffix set by the developer.

Apply the default suffix if neither the user or the NSSavePanel
provide a suffix.

Task-number: QTBUG-66066
Change-Id: I64093b9f3178bd2377a7b65d6f23aed6214a4119
Reviewed-by: default avatarMorten Johan Sørvig <morten.sorvig@qt.io>
      9b291337
    • Tor Arne Vestbø's avatar
      Android: Defer initialization of logging rules until qApp construction · 538b1b50
      Tor Arne Vestbø authored 
      On Android, we load the application library, and its dependencies (Qt),
on Android's main thread (thread 0), and then spin up a secondary
thread (thread 1), that we call main() on.

If any QObject is constructed during loading of the application library
or any of Qt's libraries, via static initializers or constructor
functions, we will set QCoreApplicationPrivate::theMainThread to
thread 0, which will confuse Qt later on when it's being run on
thread 1, and will result in a warning during QCoreApplication
construction:

 QApplication was not created in the main() thread

This situation can easily lead to a crash as well.

Unfortunately logging via qDebug/qCDebug and friends will trigger
this too, as they internally use QObject.

Fixing the root cause of this is under investigation, but for now
we will partially revert fa2a653b for Android. The effect
is that any qCDebug with a "qt.*" category before qApp construction
will turn into a no-op, like it was before fa2a653b.

This patch does not cover the case of a regular qDebug, or a qCDebug
with a non-Qt category. Those will still produce the same symptom,
as before fa2a653b

.

Task-number: QTBUG-65863
Change-Id: I95675731d233244530d0a2a1c82a9578d5599775
Reviewed-by: default avatarEskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: default avatarTor Arne Vestbø <tor.arne.vestbo@qt.io>
      538b1b50
    • Tor Arne Vestbø's avatar
      macOS: Handle update requests via setNeedsDisplay more carefully · 7d1962ca
      Tor Arne Vestbø authored 
      
Instead of trying to detect situations where we need to send a real
expose event instead of an update request in response to a drawRect
call, we keep track of when we've asked the view to display due to
a requestUpdate call, and only deliver the corresponding drawRect
as an update request if no other code has asked the view to
display.

This should cover all cases of asking the view to display, issued
from our code or from AppKit, such as the view changing its backing
scale factor, or otherwise needing a real expose event.

Task-number: QTBUG-65663
Change-Id: I1783787823aee889dad8e48f34a1cb0f1b7b06bd
Reviewed-by: default avatarShawn Rutledge <shawn.rutledge@qt.io>
      7d1962ca
    • Alex Richardson's avatar
      Fix native QFileDialog initial selection for remote URLs · 4cd90a35
      Alex Richardson authored 
      When using QFileDialog::getOpenFileUrl() with dir set to e.g.
"sftp://foo/bar.cpp" we call q->selectDirectoryUrl("sftp://foo")
followed by q->selectFile("bar.cpp").
Inside  QFileDialog::selectFile() we unconditionally convert "bar.cpp"
to an absolute URL and then call d->selectFile_sys("$CWD/bar.cpp")
This then calls platform integration that detects that an absolute URL
is being passed to selectFile() and therefore overrides the initial
directory.

Initially reported as https://bugs.kde.org/show_bug.cgi?id=374913

This is a regression that appeared some time between Qt 5.7.0 and 5.7.1.
I have not had time to bisect this but the only commit that may have
change behavior in that time range appears to be
007f92c6

.

Change-Id: I6968abe9ed5c5b9de067c453a7e9d2c5cdb3a190
Reviewed-by: Christoph Resch
Reviewed-by: default avatarDavid Faure <david.faure@kdab.com>
      4cd90a35
    • Eike Hein's avatar
      QSimpleDrag: Fix mouse release coords for delayed event transmission · 4a7771f2
      Eike Hein authored 
      
On platforms such as XCB, the drag cursor pixmap is shown via a window
(a QShapedPixmapWindow) under the cursor.

The mouse button release event at the end of the drag is received in
this QXcbWindow, but intercepted by an event filter that QSimpleDrag
installs on the QApplication. It then resends it unmodified(!) after
the drag has ended and the drag pixmap window destroyed, causing it to
be delivered to the new top-level window.

The local coordinates in the unmodified QMouseEvent are local to the
drag pixmap window and don't match the window it is delayed-transmitted
to.

This ends up having fatal, user-visible effects particularly in Qt
Quick: QQuickWindow synthesizes a hover event once per frame using
the last received mouse coordinates, here: the release posted by
QSimpleDrag. This is done to update the hover event state for items
under the cursor when the mouse hasn't moved (e.g. QQuickMouseArea::
containsMouse). The bogus event coordinates in the release event then
usually end up causing an item near the top-left of the QQuickWindow
to assume it is hovered (because drag pixmap windows tend to be small),
even when the mouse cursor is actually far away from it at the end of
the drag.

This shows up e.g. in the Plasma 5 desktop, where dragging an icon
on the desktop will cause the icon at the top-left of the screen (if
any) to switch to hovered state, as the release coordinates on the
drag pixmap window (showing a dragged icon) fall into the geometry
of the top-left icon.

QSimpleDrag contains a topLevelAt() function to find the top-level
window under the global cursor coordinates that is not the drag
pixmap window. This is used by the drop event delivery code.

This patch uses this function to find the relevant top-level window,
then asks it to map the global cusor coordinates to its local
coordinate system, then synthesizes a new QMouseEvent with local
coordinates computed in this fashion. As a result the window now
gets a release event with coordinates that make sense and are
correct.

Task-number: QTBUG-66103
Change-Id: I04ebe6ccd4a991fdd4b540ff0227973ea8896a9d
Reviewed-by: default avatarEike Hein <hein@kde.org>
Reviewed-by: default avatarShawn Rutledge <shawn.rutledge@qt.io>
      4a7771f2
  11. 29 Jan, 2018 - 3 commits
  13. 27 Jan, 2018 - 8 commits
  15. 26 Jan, 2018 - 5 commits
  17. 25 Jan, 2018 - 8 commits