Should fix a lot of corner cases, might introduce a few bugs.
Also rename functions/slots to be better named.

Generic Project Manager and CMake Project Manager are missing from this
patch.

Also rename some methods/signal to make clearer that those only are
relevevant for user changes not for all arguments.

Fix for that will come later

Note: I didn't fix all the connects and there are a few missing things.
This compiles, more work is coming.

The pointers can be used to distinguish BuildConfigurations

Each project has it's own BuildConfiguarion * classes, they'll get a
decent type safe interface and the setValue/value stuff will be removed.

Separate category and trCategory and introduce sorting characters
to the categories. Same for id/name.

Enables users to change which buildsteps get run per buildconfiguration.
Some further tweaks are probably necessary. This is a rather big
change, though it should work. :)

Also ensure that Qt4ProjectConfigWidget does not emit any signals from
it's init method.

That is we actually parse the mkspec and evaluate QMAKE_CXX (and a few
other variables) to figure out the correct mkspec. This makes using
custom mkspecs easier and is also cleaner. I also changed mkspec() and
mkspecPath() to behave a little diffrent, essentialy mkspec() will
return only the name (the actual dir name) of the mkspec. That is in
general not sufficient for passing on to qmake. mkspecPath() only
returns the correct path to mkspecs/default.
Hopefully I haven't broken WinCE/Maemo/MinGW.

Also move Designer::Internal::FormWindowEditor ->
Designer::FormWindowEditor.

Instead use the BuildConfiguration class methods directly.

Builds, but I'm pretty sure it doesn't *work* :)

This splits up the edit and active settings. Let people try it and
report usability problems. I'm not 100% convinced of the layout either.

Rationale: The concept of a "Qt Dir" is dead ever since Qt can be
installed. Specifying the qmake location otoh makes it possible to
unambigously detect all parts of a Qt installation.

Reviewed-by: dt

Reviewed-by: dt

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.

This has still a few missing things, but this enough to start getting
some feedback. Missing are non qt projects, a solution for the
runconfiguration, a missing black line between the treeview on top and
the project settings at the bottom. Some flickering with removing/adding
widgets to the QScrollArea and not showing the expanded widget if the
Details button is right at the bottom.