Since switching to a QProcess based implementation a different
code path is used to interrupt processes (QProcessImpl::sendControlSignal, instead of ProcessLauncherImpl::sendControlSignal).
The QProcess path still used outdated ProcessHelper::interruptProcess.
This patch removes the old path and replaces it with the correct
"ProcessHelper::interruptPid" for QProcess based processes.
This also fixes GdbEngine::interruptInferior2 which could not interrupt
processes during "Attach to running server"
Change-Id: I9e1917100acf89c07cab0d9c687e57bb555d9d83
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Qt Creator is using the following scheme to generate a build directory:
"../%{JS: Util.asciify("build-%{Project:Name}-%{Kit:FileSystemName}-%
{BuildConfig:Name}")}"
This implies that for docker devices the parent directory for the
project needs to mounted in order to have write access rights.
This is usually not the case and docker fails to configure projects.
Changing the template to "./build/%{JS: Util.asciify(%
{Kit:FileSystemName}-%{BuildConfig:Name}")}" makes sure that the build
directory is created
into a directory that has write access for docker.
Fixes: QTCREATORBUG-29972
Change-Id: I4839d76bf272ed7e59c60446636e4a394a0dea24
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Before we were deleting the SyntaxHighlighterRunnerPrivate
from the caller thread. However, in case of
ThreadedSyntaxHighlighterRunner the private objects
lives in m_thread thread, so delete it from there.
Change-Id: I4e6d57ef1840a9d34ce02f2bb4423e9e47550f4d
Reviewed-by: Artem Sokolovskii <artem.sokolovskii@qt.io>
The plugin class is not meant to be accessed from other plugin items
nowadays.
Change-Id: Iffb295cd80bd4dd8799c8a1329dd016bf7dd167e
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Qt Creator offers to install them if it finds the NPM package
manager on the computer.
Task-number: QTCREATORBUG-30209
Change-Id: I2ab147dfae6a639b2b9f21acabd6f4d2ec339ac6
Reviewed-by: David Schulz <david.schulz@qt.io>
This limits the number of signals being sent.
Change-Id: Ie4b0661571a9d1bbd5708e33e21e0911e7a9fcbd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Github and others turn `[^footnote]` into anchor links to the next
occurrence of `[^footnote]: Description`.
Task-number: QTCREATORBUG-30119
Change-Id: Ieebcad8ef58ccd8c7faa6aa83a165ce3f7ea1a01
Reviewed-by: David Schulz <david.schulz@qt.io>
Plan is to hide the plugin class definition to the .cpp later.
Change-Id: I27f6d2dd23adb4f3ab47d99b0626956889d2750f
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
In this way we don't construct a giant recipe
(~7000 tasks for Creator project) but simply repeat
the task execution many times.
Change-Id: I06758e2afa721f73e28adb42e6fccee0f955e01f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The current code updates the application icon for every task added to
the progressmanager. There are cases were we add a lot of tasks in one
go, for example when receiving diagnostics from the code model. This
might not even change the application icon (since it only updates for
errors), but we never the less create a new icon and send it to the os.
Optimization 1: Only trigger an update if the text differs from the
previous icon detail text.
Optimization 2: Do not directly update the icon but start a timer to
collect multiple updates and update the icon when the event loop is re-
entered.
This only affects Windows and Mac since the progressmanager_x11
implementation does not update the application icon.
Change-Id: I80cbb6f2520a83e79e2dba1b4079ab77fb7bf453
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
