This changes the tutorial described in the Creator docs
for the UI-based Python application.
The main reason is that loading an ui file is not recommended,
and discouraged over using uic tools to generate Python code
from ui files.
Some changes to code styling were included to the file as well,
mainly the exec_() to exec() changes.
Change-Id: Ibe1f4d62d2252edecd5f3475250f1287d8213faa
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Without a transaction we will reparse the document for each reparent.
This will make the process very slow if there are e.g. 20 materials
in the document.
The new parent has to be created first. This cannot be part of the same
transaction, because of limiations in the rewriter.
Change-Id: Ie2c587d0f072b8163846c660dc2dd66bee7146c1
Reviewed-by: Mahmoud Badri <mahmoud.badri@qt.io>
Use explicit type for local variable to have a consistent
approach. Amends 6469f99.
Change-Id: I6b7612e1f646e497699e278e4538f9cb4ae37c64
Reviewed-by: Samuel Ghinet <samuel.ghinet@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
New implementation of mcu support plugin is not yet finished
so we should use legacy implementation for QtMCUs 2.2 JSON kits.
Change-Id: I8e6a8b7af2c3b4683bb19a5f05edd6ff5df46e5b
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Generating ui headers in a well-known path and then including that one
in the compilation database does not work in the presence of multiple ui
files with the same name.
As it turns out, we don't have to generate any files at all; instead, we
pass the file contents directly to clangd, which then uses them when
parsing includes of the respective header.
User-visible behavior change apart from the abovementioned bug fix:
Tooltips and "follow symbol" on the include directive now always use the
actual location of the header provided by the build system.
Fixes: QTCREATORBUG-27584
Change-Id: I6b13e12cb3a365199567b0bc824d12b373117697
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@qt.io>
We need a somewhat more wholistic approach on how to communicate
environment data and changes in the code, a single fixed map
doesn't cut it.
Change-Id: Ifbed254e7e0f4a76f8627e77030889c326f551d4
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Just run and host is not enough, build device is needed, too.
This fixes the MakeInstall step for remote linux.
Change-Id: I3ec797379b7d0d5842780d505d8b87a91286e460
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
To be able to autocomplete code from .ui forms we need to feed the
python language server the compiled form. The uic extra compiler
generates a temporary ui_name.py file for uncompiled or unsaved ui
files. These files are inside a folder that gets appended to the python
path environment variable for the python language server.
Change-Id: I9f48d2012162f33986639315189c41e0a7e0dad2
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This includes a new template that allow users to create
a UI based project, but without a dynamic loading.
To get the initial empty window, the user needs to use
a 'uic' tool to generate Python code from a UI file first.
This tool is different for PySide2, PySide6, PyQt5 and PySide6.
Change-Id: Ic12fe23696bf3b18eaf240ffac03e9bd92a5455b
Reviewed-by: David Schulz <david.schulz@qt.io>
The patch breaks several plugin unit tests; at the very least QtSupport,
AutoTest and ClangCodeModel.
This reverts commit 72aa77ced7.
Change-Id: Iaa7f452d0f43d0072b0bbcf8934fa0dcd6f9b240
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Remove AbstractRemoteLinuxPackageInstaller, as we have
only one subclass.
Don't export RemoteLinuxPackageInstaller, as it's used
only by TarPackageDeployStep.
Rename RemoteLinuxPackageInstaller into TarPackageInstaller
and hide it inside tarpackagedeploystep.cpp.
Change-Id: I1dacdeda58378911cc322b9991f4f584c074db1b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
The RemoteLinuxEnvironmentAspectWidget subclass was
overloading it, however, it was returning the
subclass of EnvironmentAspect (i.e. returning
RemoteLinuxEnvironmentAspect).
Instead, we use the base aspect() method in
RemoteLinuxEnvironmentAspectWidget subclass and we
cast it into expected RemoteLinuxEnvironmentAspect class.
Move some methods into protected section, as they
are used only in subclass.
Use qobject_cast instead of dynamic_cast inside
UploadAndInstallTarPackageStep.
Change-Id: Ic3119ca15d46187e0aa7b8b4013e7fc4efec4bd9
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
- Updated the current code to use recommended code style
- Modify description of current wizards
- Adapt the documentation to reflect the new names of the applications
- Adapt exec() call for PySide6 (and leave exec_() for PySide2)
Change-Id: Iad662523b8a0e56ac622b21cee60f7928d419354
Reviewed-by: David Schulz <david.schulz@qt.io>
Make it behave more like QProcess::kill().
Before, when QtcProcess::kill() has been called,
the process launcher was putting the process into the
reaper and notified the QtcProcess that it was already killed,
while in fact it could still be alive for a while since it
was in reaper's hands. The current fix makes the behavior
similar to what QProcess does when calling kill(). So now,
in case of a call to kill() the process isn't put into the reaper yet,
so it has a chance to report back the finished signal when the
process was really stopped.
We still use the old behavior of putting the running process
into the reaper in case of a call to QtcProcess::close() and
when d'tor of QtcProcess was called. We don't report back the
confirmation about putting the process into the reaper, since
close() is always called from ProcessLauncherImpl d'tor, so
there is no one to receive this confirmation anyway.
Change-Id: I665e7c8fb1a391dda30c86389259961e715926d6
Reviewed-by: hjk <hjk@qt.io>
Calculating new diagnostics after a document change can take a while.
The old ClangCodeModel disabled diagnostics (changed the color to gray)
that were reported before the last document change after some time.
Adapt this behavior to Clangd and other LSP based codemodels.
Change-Id: I0589ba0d0c023f6e7ea3e97fc5b45eb156ddcd37
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
qmake is a "build tool", and it is also a "query tool" when called with
parameter "-query". Qt Creator, so far, assumes that building and
querying with a Qt installation are done with one and the same tool:
qmake. This change adds the ability to register a Qt version vie either
qmake or qtpaths and still build with qmake, if that is installed (which
is not anymore mandatory from Qt 6 on).
1) Distinguish between Qt query tool and qmake build tool:
Add QtVersion::queryToolFilePath() to the existing
QtVersion::qmakeFilePath(), and use queryToolFilePath in most "query"
related code, and qmakeFilePath when building with qmake (e.g. in
QmakeProjectManager).
Also, a couple of functions and variables were renamed from *qmake* to
*queryTool* in order to express that the affected code is about
querying/managing Qt versions rather than about building with qmake.
2) Support manual Qt Version adding by qtpaths via file dialog
This change adds qtpaths to the "Add" Qt Version file picker filter.
After selection, "qtpaths -query" is executed for testing purposes. If
that fails, (e.g. because it is an older Qt version), qmake is instead
chosen, silently.
Task-number: QTCREATORBUG-22175
Task-number: QTCREATORBUG-25546
Change-Id: I4d9c1e7eec7d5ae7c5a8d2e1a1ed95addff69966
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Since we define an import for QtQuick to distinguish between
Qt 6.2 and Qt 6.3, the way we determine "IsQt6Project" was broken.
This patch reuses "IsQt6Project" now to determine the default style name
and if we need a versions for imports.
Task-number: QDS-7053
Change-Id: I7b5fc0b76e71c2874f5e6ac8457ba1deb87bb999
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io>
This was a left-over from times where we had a QShortcut variant of
Command, which was removed in Qt Creator 3.2.
Change-Id: I62a728f3af352c61bc137461232fc1ed8debccf2
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
