GitLab

Task-number: QTCREATORBUG-3782

Task-number: QTCREATORBUG-3771

Done-with: Leandro Melo

if the exact evalution fails (possibly because of a parser error), then
still use the cumulative evaluation to construct the project tree. only
the target information won't be updated and the code model will be left
in the dark.

todo: the errors are dumped only to the (unnumbered) "general messages"
output pane, which makes them practically invisible.

Task-number: QTCREATORBUG-3093

it would collect global values instead.

special-casing it makes no sense, as all other values from the
project would be mismatched and thus worthless for code validation
anyway.

the node updater would check if the cumulative and exact evalutor
returned the same project type and would discard the cumulative one if
they didn't. this was pointless, as a) it would practically never happen
and b) it would be without much consequence anyway.

... otherwise oldValues equals newValues.
the signal is currently not connected anyway, but whatever.

Reviewed-by: Kai Koehne

Old logic was too fragile to maintain.
Now it's  PointMixed -> PointPlain -> RangeMixed -> RangePlain.

Now using an explicit Mode (generated, imported) instead of empty
or set filename convention. Just like in Html5App.

AbstractFormEditorTool -> AbstractLiveEditTool
LayerItem -> LiveLayerItem
SelectionIndicator -> LiveSelectionIndicator
SelectionRectangle -> LiveSelectionRectangle
SelectionTool -> LiveSelectionTool
SingleSelectionManipulator -> LiveSingleSelectionManipulator
RubberBandSelectionManipulator -> LiveRubberBandSelectionManipulator

Task-number: QTCREATORBUG-2968
Reviewed-by: Alessandro Portale

All type information should be now available.

Changing this field will not have an effect anyway.

All this environment setting was just an approximation of what the
"mad" script does better.

This simplifies the call and also fixes a bug along the way.

Task-number: QTCREATORBUG-3589

When closing the app via the WM the status of the services change
to 'not available'. We used to log this as an error to the debugger
log, causing the log to 'magically' pop up.

Reviewed-by: Christiaan Janssen

No need to add random '1' if there's only one.

We used to only fallback at start time from a invalid/empty setting
to the cmake in path. Now we do that even if the setting is later
edited.

Task-Nr: QTCREATORBUG-3739

For this option it would actually be better to reapply the state of the
toggle button to the restarted QtQuick application rather than resetting
the state of the button.

* Renamed Toolbar to ToolBar
* Use mass-disconnect instead of duplicating all connect calls
* Split up setupToolbar(bool)