Document non-intuitive behavior of QTreeWidgetItem::setHidden().

Task-number: QTBUG-30366
Change-Id: I02e098fbf0e3a44794ed0e1b1bf533c1c9ad5632
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Fix crash in QNetworkAccessCacheBackend::closeDownstreamChannel

device is private, always null and class has no friends, so no need to have it at all

Change-Id: I320d47f1a712a3202c08b494563533e29d185501
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
Add backslash to the list of word separator.

Task-number: QTBUG-40384
Change-Id: I16ae1432f3bdd7e577593fc43336bf29c735a66b
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Fix a mishandling of the fd returned by socket(2)

socket(2) is allowed to return 0, so 0 should not be included
when checking for errors.

Change-Id: I0454ea60347d90078d3ab3046969add8d5c37935
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make sure we don't delete child QWindows if they have WA_NativeWindow set

Deleting a QWindow automatically deletes its child windows because
they are in the QObject hierarchy. However, if the user sets both
WA_NativeWindow and WA_DontCreateNativeAncestors, we can't just
delete that widget's QWindow. First because the widget doesn't get
notified (and maybe it should be), and then because we may invalidate
any reference to the QWindow the user may have kept.

Our solution is to reparent the child QWindows into the new parent's
closest QWindow. We must, however, take the precaution of not keeping
any reference to the backing store in the platform window. Reparenting
operations can trigger repaints on the platform window, but the backing
store is not set and flushed until later.

Task-number: QTBUG-38377
Change-Id: I353f5528f227a227b6d10419367cbe1d5d07a94e
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
OS X: Fix menu item shortcuts without modifiers

A regression was introduced by bdebec4e2ef79f1771d2dcc22f9a919eb4487567.
The intention of the change was to avoid using Qt's shortcut mechanism
to trigger menu items which were already triggered through the regular
menu API in Cocoa. However, Cocoa has trouble with key equivalents that
do not have any keyboard modifiers. Thus, we have to allow these
particular key sequences to go through the regular system. I've verified
that the original bug is still fixed with this change.

[ChangeLog][OS X] Fixed menu item shortcuts without keyboard
modifiers.

Task-number: QTBUG-41192
Change-Id: I8f5a9cbc7a448b3cb0519baed95be5cbb630205c
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
OS X: main window doesn't become key.

When ordering a key window out Cocoa
tries to find a new KEY window. Looks like it prefers the current MAIN
window and since QNSPanel is never a main window, Cocoa is breaking
the stack order. To avoid this - try to change the key
window BEFORE ordering out a window.
The application has a stack of all open windows (visible and hidden),
we iterate through this stack starting from our current key window
and look for the nearest window below, that can become a new key window.
Most probably, it will be our transient parent :)
This code will change (potentially) the key window _only_
if there is a transient parent.

Task-number: QTBUG-39809
Change-Id: I96b630799341875fc7e38dabf1ff6416338e687b
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
OS X: File dialog does not show "Media" section.

This bug can be reproduced (AFAIK) only on 10.9. To fix it I suggest we create
NSOpenPanel/NSSavePanel
_every_ time it must be displayed. Actually, that's what I've seen in all code samples
I was able to found - nobody tries to retain this panel and re-use it.
If we re-use it, "Media" section magically disappears.
I believe this bug is not Qt's bug, but something weird in Cocoa.

Task-number: QTBUG-40655
Change-Id: Ic0e76e0a9a5444a76f336d511c0ff93f9fd05797
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
GTK syle: initialize all members of GdkColor

Coverity rightfully complains that we're copying a struct with an
uninitialized member, triggering undefined behavior.

Change-Id: I7635b859eb11e5eb9b825df8e23b453116059892
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
XCB: fix a memory leak

An early return caused a leak of a new'd allocated object.

Change-Id: I9fbc37238dd49066d24363a2e8ee8bf35b155301
Reviewed-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@digia.com>
XCB: fix a possible array overflow leading to a crash

The QClipboard::Mode returned from modeForAtom should be checked
everywhere because values greater than Selection (i.e. FindBuffer)
aren't supported on X and should mean error conditions.

The lack of such a check did an out-of-bounds array access, which
could lead to a crash.

Change-Id: I70f70b5f713ab2f892e258d4df2f7afeb434f0c1
Reviewed-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Gatis Paeglis <gatis.paeglis@digia.com>
QRegion: fix a memory leak

An early return in case of errors leaked memory tracked in a variable
in scope.

Change-Id: I68cd77890608caff54df7476d38850e5541ce76e
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@digia.com>
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
QObject: fix a memory leak in moveToThread

For some reason it seems to be supported to call moveToThread(0).
That call will allocate a new QThreadData for the object. However,
if we then detect that we're calling moveToThread from a thread
which is not the one the QObject has affinity with,
we error out leaking that QThreadData object.

Change-Id: I0fe6625a2a9887535e457f3897b514d2a03d1480
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
QTransform: initialize the d member

Although never used, the d member triggers all sorts of warnings
when copying a QTransform around because it's technically
undefined behavior (reading from an uninitialized variable).

Change-Id: If06b6bea6f0ec0623c38ba330d46958b373cdc65
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
Prevent a Coverity warning about a dangerous code path

Coverity warns that we may access the gray array without initializing
it. The array is initialized if d (the source image depth) is 8.

However, when doing ordered dithering, we don't check that depth
any more and just use the array. There are instead checks in place
for the other dither modes; the one for ordered has been commented
out before public history.

So, for the love of kittens, put the check back.

Change-Id: I1cc5ced8edbb626777e54e9f4e58f152c6b28ddc
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
QFile: fix undefined behavior when closing a buffered file

C11 §7.21.3.4 [Files] says that

    The value of a pointer to a FILE object is indeterminate
    after the associated file is closed

POSIX.1-2013 reinforces by saying that

    After the call to fclose(), any use of stream results
    in undefined behavior.

This means we can't call fclose() again on a FILE *,
even if fclose() returned EOF and set errno to EINTR.

Change-Id: I282f4ff926e3c134729defa290c80d42431e97ce
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Refactor some loops over EINTR

QT_CLOSE is #defined to be qt_safe_close which already performs
the EINTR loop. So there's no need of doing other loops
(either by hand or by the EINTR_LOOP macro).

Change-Id: Icca256124def5ab5d79c2ba101c6f889c85d19da
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Document that default-constructed QFuture are canceled

Task-number: QTBUG-40680
Change-Id: Idee9ff75c89c8349be779b90ee9c34a899d92c0c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Martin Smith <martin.smith@digia.com>
QSettings: Don't chop off trailing tabs that were actually part of a value.

This was done wrong when using the ini format.

Task-number:  QTBUG-22461
Change-Id: Ib9390460bce6138659cceac7e3cd25339ba5e9bb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Cocoa: Properly remove content view from its superview in setNSWindow()

-[NSWindow setContentView:] doesn't make assupmtions about where that
view comes from, and just attaches it to the window. We need to make
sure we detach it from its previous window by calling -[NSView
removeFromSuperview], or the previous NSWindow may keep references to
the view. This can be an  issue if the view is deleted right after.

Task-number: QTBUG-39628
Change-Id: I152dedcb64ac044d8ca290c9996b388809e2477b
Reviewed-by: Timur Pocheptsov <Timur.Pocheptsov@digia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>