Mostly Q_DISABLE_COPY that were covered by the un-copy-ability of the
respective base classes. Includes a few "stylistic" whitespace changes.
Change-Id: I31ca0e7bada5ed0f34776976efe22ddc444a5bf2
Reviewed-on: http://codereview.qt.nokia.com/1609
Reviewed-by: hjk <qthjk@ovi.com>
No change in functionality for now. More support for generic remote
Linux support is planned to be added.
The changes in decreasing order of magnitude:
1) Move contents of qt4projectmanager/qt-maemo to new "RemoteLinux" plugin.
2) Make some classes in qt4nodes public for now. More decoupling
in that area will follow.
3) Fix some minor problems uncovered by the move.
Change-Id: I51d0c7977c10019eb6080cd6620bc28ecebad3c4
Reviewed-on: http://codereview.qt.nokia.com/106
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Also adjust qmldumptool to remove the dependency on qt4project/qmlproject, by
passing in the qtversion instead of figuring it out in qmldumptool.
Change-Id: Ie6ac582d36bfef290313c0716b33b62fcf42630c
Reviewed-on: http://codereview.qt.nokia.com/70
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
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
That is tell the user that those files need not be added to any project,
and show "<Implicitly Add>" for them on the last wizard page.
This fixes Add/New for the QML/OTHER_FILES folder structure, except for
the virtual folder itself.
Reviewed-By: Jarek Kobus <jaroslaw.kobus@nokia.com>
Reviewed-By: con
Reviewed-By: Friedemann Kleint
We now support renaming files. The version control system tries first to
rename, if that doesn't support or can't rename the file we do a normal
rename. (Note: git, hg, perforce > 2009.02 support renaming, cvs not.
(perforce untested)). We correctly notify all editors of the renamed
file and tell the project manager to rename the file in the project.
Note: Only the qt4projectmanager knows how to rename files.
Note: renaming folders, moving files to different folders, renaming
.pro/.pri files is not supported. Those things can be later added after
this has proven to work correctly in the simple case.
Also we don't do any actions based on the renaming like renaming
classes, changing include guards or #include lines.
The UI_DIR and MOC_DIR weren't added to the includepath for new
projects, since at the time of parsing the directories don't exist yet.
We now always add UI_DIR and MOC_DIR to the include path, without caring
whether they exist.
Task-Nr: QTCREATORBUG-1064
Reviewed-By: ossi
On windows when linking to a library via -L/some/path, the library is
found in /some/path while linking. But running that app fails, since it
can't find the library. We now adjust PATH to include all paths from
LIBS and thus the library is found.
This is a big change touching almost all of our .pro file parsing.
With this patch we only evaluate once exact for all needs and once
greedy for the filelist. That is the qt runconfigurations don't have own
evaluaters but reuse the project wide exact evaluation.
We reevaluate if the user changes the build directory, the qmake
buildconfiguration or the qmake arguments. That is if you open src.pro
(or projects.pro) of qt with a shadow build you still don't get all the
files, but after correcting the build directory, we reevaluate the .pro
files and find all files. So for a suitable definition of fixed, that
bug is now fixed.
We now get the exact defines of all .pro files instead of all defines for all
buildconfigurations. We still don't distinguish in which
.pro file a DEFINE is set. So the code model now knows about all the
defines set for the given configuration but not for which files it is
actually set. Also that includes all DEFINES set in .qmake.cache or the
mkspecs. This means all defines from .pro files should now work.
The intial loading is still synchronous. I haven't looked into it to
deeply, but it seems possible to make it also async.There are probably a
few issues which need to be solved fist.
Also due to the asynchronous nature of the code, the executable is
updated a few seconds after actually changing the build configuration
Pass around contents as string, saving repeated
invocation of FormWindowEditor::contents().
Remove dependency to FormWindowEditor.
Reviewed-by: dt <qtc-committer@nokia.com>
