* Ignore steData calls that do not actually change any data
   in the EnvironmentEditorModel. This prevents all variables
   touched from getting marked up as changed.

Reviewed-By: con

unavailable

Reviewed-by: Maurice Kalinowski

Merge-request: 2140
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>

Merge-request: 2131
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>

by Ben & Pierre

Merge-request: 2131
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>

Merge-request: 2131
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>

Reviewed-by: con

Reviewed-by: con
Task-number: QTCREATORBUG-245

Change the translateable string not to contain a blank.

Task-number: QTCREATORBUG-299
Reviewed-by: Thorbjorn Lindeijer <thorbjorn.lindeijer@nokia.com>

Merge-request: 2115
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>

Task-number: QTCREATORBUG-282

The final dot was confusing qmake, apparently considered part of the
variable name.

This reverts commit 6a9e7ab0.

When we meet /* we look for closing */ and continue processing from the next char, not from '/' which was a part of the closing comment

Reviewed-by: dt

Reviewed-by: Oswald Buddenhagen

Reviewed-by: Robert Loehning

Fixes a bug that after package installation the debugging helpers are
sometimes marked as invalid.

Reviewed-By: hjk

Fails for system Qt on 10.6.

Reviewed-By: hjk <qtc-committer@nokia.com>

The problem is that the shlib events disturb bounded execution requests
and there is no way to recover from this - the debugger will effectively
turn "step over" into "continue". this is nicely explained in
http://vladimir_prus.blogspot.com/2007/12/debugger-stories-pending-breakpoints.html

Merge-request: 2065
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>

Reviewed-By: con

Add changed signals to IVersionControl and
VCSManager and wire them to the update methods. Add a menu action for
manually updating. Improved version of reverted
7aa24116

.

Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>

this ensures that, among other things, we won't get into this scenario:
- process is running
- interrupt is requested by user
- termination is requested by user
- before interrupt takes effect, the process terminates
=> shutdown is called
=> exit is also queued, as there is already a queued kill
=> nothing happens, as there will never be a stop response

Reviewed-by: hjk

archer reports stops at tbreaks properly, so checking for an empty stop
reason is no particularly good idea. instead, we simply skip *all* stops
at the entry point, assuming the user will not really set a breakpoint
there anyway.

Reviewed-by: hjk