anchors.centeredIn has become anchors.centerIn

When trying to debug qmake or another bootstrapped application loading the
dumpers failed as they are binarily incompatible. So failing is expected and
fine. However, gdb 6.8-debian produces in this case _two_ responses for
'-exec-continue produces' ('^running' and '^error,msg="Cannot find new threads:
generic error"') which is impossible according to the MI docs. In theory...

jom can be found at http://qt.gitorious.org/qt-labs/jom



Reviewed-by: Daniel Molkentin <daniel.molkentin@nokia.com>

INT_MAX needs limits.h

Consistent with the way the summary is written.

Task-Nr: 259513

... by storing the children information in an additional watchdata
source bit, thus being able to prove the model wrong in case it
claims children are needed.

Fix "displayedtype" in CDB, display it elsewhere.
Log debugger settings in DebuggerManager startup.
Acked-by: hjk <qtc-committer@nokia.com>

Reviewed-by: hjk

add/remove.

This isn't a nice fix but the least evil version of a hack i could come
up. The source of the flickering is: We have a deeply nested structure
of widgets on the project pane. If we call hide() on such a deeply
nested widget, it will activate() it's parent layout synchronously.
That will then post an event (via updateGeometries() ) to its parent
layout that it needs relayouting. Which then will post to its parent
layout the same. And for each LayoutRequested, there's a painting in
between. The fix instead calls activate() up the chain until we are at
the viewport. This immediately relayouts everything. This adds a non
obvoius potentially for breakeage if the widgets are embedded in a
different widget hierarchy. But well, that's life.

Make sure that we give the QMainWindow always a valid layout before
restoring settings, so if something goes wrong with that, we don't end
up with a broken layout.

... to accommodate for the setup at Nokia.

QListWidget forward declaration was not namespaced.

...and give it some color and formatting.