Diverts to searchInDirectory(). Use it in some places.
Change-Id: I9e5642f0ae0ed4dd9fb9f34bcaa11a25bd26c690
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... as wrapper around FileUtils::normalizePathName, and use it
in some places.
Change-Id: I42792e1f175b8119c8db930eae80a9f822ac70fa
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Get rid of <QtModule/qclass.h> style and use <QClass> directly,
like in all other places in Creator. Remove some unneeded
declarations.
Change-Id: I1b5630850c570e5d86df01a341f7352bc1971e48
Reviewed-by: hjk <hjk@qt.io>
A convenience wrapper around QProcess::startDetached().
Change-Id: If4228e8405ad4d5e172930593a6f670874211767
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
When using the same path for the anchor and the relative path
we end up in an empty path which is conceptually wrong.
Especially when passing such a result directly without further
checking may lead to bad issues.
Return a path containing just the '.' (dot) instead.
Change-Id: I86e1ab91e6610831fc05bd81776d278e9fe10105
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Jochen Becher <jochen_becher@gmx.de>
Reviewed-by: hjk <hjk@qt.io>
And implement it for the direct access docker case.
Change-Id: I5c91402630a5b010fdbcaab96c435f66a36f2e3e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Add some developer comments explaining which method
is designed to be called from a certain thread.
Add also some comments about in which thread
certain QObjects live in.
Change-Id: I38b10216cc29f8a86fd784e588e913407f0fb776
Reviewed-by: hjk <hjk@qt.io>
Pipe the error packet through the caller's handle and flush
it immediately if the caller was awaiting for any signal.
Stop awaiting for any signal when we have flushed error signal.
In this case return false from waitForSignal() method
in order to mimic the QProcess behavior.
Fixes: QTCREATORBUG-26136
Change-Id: Ie80b4a63bd19a6309d4791ad39a698bd91bb8967
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Otherwise we may end up in crashes deep inside Qt code on Windows.
Fixes: QTCREATORBUG-26112
Change-Id: Iabdd544271a99b680adad3abb84341db2bf2c1f3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Amends 3edc5673b5.
Turns out quite a few potential uses have other parents than
ICore::dialogParent().
Use a nullptr parent to mean ICore::dialogParent() to keep the
caller side simple.
Change-Id: Icfe1daafd710ae273d286679e0c8e2a3a27da552
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
In case when QtcProcess::start() is being called very early,
just after the launcher socket was started but not ready yet,
a start is being delayed. In this case doStart() isn't
called directly from the caller's thread, but it will be
invoked later from the launcher's thread, when the socket is ready.
In this case we may have a deadlock, since calling
doStart(), sendPacket(), sendData() and finally handleRequests()
results in a synchonous chain of calls in launcher's thread,
so the mutex locked in sendData() will block synchronous call to
handleRequests(). In order to fix it we unlock the mutex
in sendData() before calling handleRequests().
Change-Id: I6c13994d0b05b624567c75ffbd2ac7cc0d77df61
Reviewed-by: hjk <hjk@qt.io>
Fix "runBlockingStdOut" autotest for tst_qtcprocess.
This crazy case relies on the fact that a blocking
call to waitForFinished() lets ReadyRead signals to
be processed in meantime and the handler for ReadyRead
may terminate the process. However, when no handler
for ReadyRead canceled the process, the blocking call to
waitForFinished() should return to the awaiting state
for the remaining time. From the caller's side everything
happens during a blocking invocation of waitForFinished().
So, in order to behave like this we implement waitForSignal()
in a loop. After we have flushed all the pending signals
we check if we have flushed the signal we were awaiting for.
If so, we break the loop, otherwise we continue. In order
to detect the case when the cancel was called during flushing
we set the m_awaitingShouldContinue flag before flushing.
The cancel() method clears this flag. Then after flushing
we check if the flag was cleared - in this case we don't
continue awaiting.
We reset the m_waitingFor state always after wait condition
finishes awaiting. Before, we didn't reset it when the
wait condition timed out.
Change-Id: I210f446659cabfd89bdfdd1fc8e8396d9470effc
Reviewed-by: hjk <hjk@qt.io>
All the uses of setStd{Out,Err}Callback in the codebase call proc.stdOut/
stdErr after the execution.
This triggered a soft assertion that was apparently not noticed so far.
It broke for example prompt for conflict resolution on Git pull/rebase.
Change-Id: Ib4b8301f1f50b2b66f02fc4dc6c14d93f895ea33
Reviewed-by: hjk <hjk@qt.io>
Similar to QT_RESTRICTED_CAST_FROM_ASCII to avoid the need for
decorations in user code.
At the same time, drop some convenience constructors and functions
in CommandLine and Icon essentially serving the same purpose.
Change-Id: Ida4e5ac19c2da0a4298a97b2a8e1511d56bbb79d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Use QTC_USE_QPROCESS env var to switch back to the original
implementation based on direct use of QProcess. By default
a new implementation employing process launcher will be used.
Change-Id: I75c3efb579e26de377fc785404f1e2a08367d994
Reviewed-by: hjk <hjk@qt.io>
Makes it a bit clearer that there's no magic path use or similar
beyond this point.
Change-Id: I86c06850d16bf777db05ad23b540d8096926c059
Reviewed-by: David Schulz <david.schulz@qt.io>
The previous tighter check is actually good theoretically, but currently
ShellCommand::runFullySynchronous triggers it and disentangling there
is not trivial. So weaken it a bit for now to not annoy users.
Change-Id: Ifc6b5713b398db0af0f604834c37ff361c2a1ed3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For path choosers this makes it easier to change the actual base retrospectively
based on the device for the file path entered by the user.
In other cases "end user code" only knows that something needs to
be added to PATH to get a proper environment. This here lets this
code to specify the change alone without bothering about the base
environment this might be applied to.
Change-Id: I726aaa2fd2feb0bee7158f601aac660b0ac6327b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
