There are no external users left, so there's no need to expose
it in the header anymore. Also saves a cast.
Change-Id: I1ced368ebc9588cbc0058cc7d37f39ab80f9c595
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The only ever user (AppManager) doesn't need it for disambiguation
anymore.
Change-Id: Iea2f4d545bf9afb0610bf73c4ec7b2f29357edc0
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Do not add newlines when remote process output gets flushed.
Task-number: QTCREATORBUG-19367
Change-Id: I9e878695279404d436264abd580884fb6a9e91ad
Reviewed-by: hjk <hjk@qt.io>
... into items that can be used generically in project configurations
(ProjectConfigurationAspect) and items that have a choice between
global and project settings (GlobalOrProjectAspect)
Change-Id: I94831237bdbb18c339eb76eba131bf7f928933d6
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
None of the run configuration aspects that are added to each runconfig
depend on the actual runconfig, only two need the target, the rest
nothing at all. So use target as common denominator.
Change-Id: I31829e63ac79d5c707bb068d73fc6a4687cb4c47
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
... and adapt constructors to not take the now-unneeded
RunConfiguration pointer.
Change-Id: I53ff338f51334ff7b0c22d4bed92bfcfc8225ea7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Not really needed, a QWidget does the job, too, and de-emphasizes
then 'Run' bit. The display name is now taken always from the
aspect, but that's what was the practically the case before,
albeit with different implementations.
Change all names to *[cC]onfigWidget* (in line with ISettingsAspect).
Change-Id: Ida0409a2dd0b175dd5ce4202f9b9e94b3f2db421
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
To remove the last user of IRCAspect::runConfiguration.
Change-Id: I1390166730112008a4050877f96bb29f274e7ef1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
... when needed to avoid a use of IRCAspect::runConfiguration.
Change-Id: I0bdae0a2a1aad4475dd3225e6ae71da7bfd9513f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Instead of using a hard-coded list of well-known (optional) aspects,
add all aspects, so there is no need for special treatment of
RunConfiguration with unusual/custom aspects needed.
Price and benefit is that the individual run configs are again
responsible for the aspect display order which is determined
from the aspect construction order.
Change-Id: Iff2656b2e358c0f0f789d4c006a5c44d0a1536a5
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It has been an obsolete alias for setId for a while and downstream
uses have been adapted.
Change-Id: I467370aa67054599c7771e8275d28e62ddc461fa
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use unique_ptr for all *Private classes, except for those
in singletons.
Change-Id: Ib56c31ddedc6e9cf321f15de1f1e697a27ad4089
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The actual remaining use was to pop up a terminal in some
setups where Mode == Console, with a default of Gui meaning
"no console". In some downstream uses it was used set to
Console (probably to mean "this helper process does not need
a gui") but then luckily ignored when actually starting the
helper processes.
All cases where the console is useful and requested are
nowadays RunWorkers belonging to RunConfigurations with
a TerminalAspect, so they can directly get the relevant bit
from their RunConfiguration without having it part of
all StandardRunnables.
Change-Id: I1368d5968da5cf672656aebf200ccac8d45335d0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There is a recurring special case that certain run controls depend
on the presence of specific RunConfiguration (which in turn has
it's own restriction on e.g. target or project types) but have no
further restrictions.
Make it easy to handle that case.
Change-Id: I2e86f366591b02003f720dcc00b4c52bb2f34e00
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
As all Runnables are known to be StandardRunnables, this here
essentially replaces all .is<StandardRunnable> by 'true'.
.as<StandardRunnable> by no-op, and fixes the fallout.
Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
With AndroidRunnable gone, there is only one incarnation of
a Runnable left - the StandardRunnable.
It is not expected to ever need a different runnable again,
as platform differences are now handled in the platform specific
RunConfigurations and RunWorkers created there locally, and
global information is typically communicated via
RunConfigurationAspects, so there is no point in keeping the
Runnable::{Concept,Model} machinery.
This patch here essentially makes StandardRunnable a type alias
for Runnable, to allow downstream changing all
if (r.is<StandardRunnable>()) { ... r.as<StandardRunnable>(); }
one by one.
When all downstream is adjusted, the alias can go completely.
Change-Id: I86aa92c7fae8d54ca603484b7e1746c126b0bddb
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
A RunWorker can in theory (and will in practice) support several
run modes. Also, it has turned out to be beneficial to specify
restrictions on a fine grained level, so re-use the idea from
the RunConfigurationFactory etc. constraints setup here.
Creation of RunWorkerFactories can be made protected at some time.
Change-Id: I9e2a84abfd7377c5bf0bbe84e0c7940b1317dc10
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... to the plugins providing them.
To allow this being done one-by-one in the plugins, allow both
central and per-plugin ownership, and clean up the central instances
centrally. This step will be removed again once the transition
is complete.
Change-Id: Ica7786012e05ab83a0784448f2f8b3b781fe2167
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This paddles back a bit on the RunWorker creation setup mainly
to get a more flexible setup when it comes to share RunWorkers
between different setups.
Change-Id: I263742cb1df3689f133a2f6f948ed59a2a52d383
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
In remote setups without proper run configuration (e.g. attach
using the menu) there was no device available. In some situation
there's access to a kit, though, containing the right device.
Use it.
Task-number: QTCREATORBUG-20331
Change-Id: I54523f71fc10c9959901f36f3d62872d139279e5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Move some commonly used functions to the base,
The plan is to identify aspects by Id instead of type more often,
so avoid casts proactively.
Change-Id: I1b94b858a4491a0e31cedc788ded643a82242b2a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Names are easier to follow than positions in long argument lists.
Change-Id: Ia0ace9d864a1100e649f6725e7de338ab2653d05
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
As convenience function, and use it in some places.
Change-Id: I02e49f2cdc301bbf1261836032d3fa3a5b188446
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Any SettingsAspect that doesn't refer to the global settings has a
specific RunConfiguration it is about. This can be very handy to know
when constructing the actual settings. Right now there is no way to find
out about it.
Drop the clone() and create() methods. They weren't used anywhere and a
proper implementation should take care of the runConfiguration member.
Change-Id: Ie505a9b19707f8a1b6bf9cae73513cd3c30d0bca
Reviewed-by: hjk <hjk@qt.io>
The parent widget is always given by the layout, no need to pass
it as separate parameter.
Change-Id: I9e7ed3a89eb63b78a549471d839060131737ff78
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
DesktopQmake, CMake, Qbs, Nim, RemoteLinux and Qnx now have a common
understanding what should be in a runnable and how their
configuration widget should be set up. So move them over to
using shared code, too.
Several others runconfigs only lack a one or two more aspects
to follow suit in later patches.
Change-Id: Ia862c95c97d63bd0a0f2dc303435775a2fc530d3
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Report project-specific warnings about the kit used in Project Mode.
E.g. a python project should not complain about missing toolchains,
while a qmake project should.
Change-Id: I5ce6742683cdeffc7ff3f1a3e8f0b89aee9aa0b4
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
Note that the concept of a single monolithic OutputFormatter per
RunConfiguration (and why RunConfiguration, not RunControl to start
with?) is unchanged and suboptimal as one cannot easily combine
existing use cases, e.g. Python_and_Qt.
Change-Id: Ibeb8191020387324f22ed313230293597f96e36a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The previously per-Project/RunConfiguration changing meanings of
BuildTargetInfo::buildTarget have by now been split
into separate values in BuildTargetInfo:
- buildKey a handle to one item in Target::applicationTargetList
- displayName a user-visible string in the run settings page
The buildKey was tweaked to coincide with the previous 'extraId',
i.e. the non-RunConfiguration-type part of the project configuration
id that (still) use id mangling.
This allows replacing the cases of locally stored seven different
versions of buildKey(-ish) data by one RunConfiguration::m_buildKey,
and do all remaining extraId handling in RC::{from,to}Map only,
i.e. remove the base ProjectConfiguration::extraId() virtual and
remove the "re-try fromMap with mangled id" hack entirely.
The id mangling is still used to temporarily maintain .user file
compatibility in some cases for now, but should be replaced by
storing the build key and the RunConfiguration type soon. Qbs
already changes in here to only use the uniqueProductName as
buildKey, without the previously added display name which is
stored as part of the ProjectConfiguration already.
It turns out that RunConfiguration::buildSystemTarget was intended
and used to retrieve an item from the Target::applicationTargetList
for some configurations, coinciding with what buildKey does always.
So use that insteand and drop RunConfiguration::buildSystemTarget.
There is clearly is further consolidation potential left.
handling of (default)displayNames is still a per-runconfiguration
mess and there is further consolidation potential left.
Change-Id: I448ed30f1b562fb91b970e328a42fa5f6fb2e43e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Margins and layout style widely differ so far. Start moving everything
to a QFormLayout with the same margin and growth policy.
Change-Id: I0bd1d8b2ec9830be56354be1376a2a24eebb8845
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Some translations moved over to the corresponding RunConfigurations,
one setParent() replaced by direct deletion.
Change-Id: Ib5e527b71353a6be70b332ac2dfd2f5cd2499a60
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
canHandle() is only used locally in the implementation, so
make it private and de-virtualize.
canCreateHelper() did nothing except returning true anymore,
so remove it.
Change-Id: Ifac39e077e3c296b2b2dfc9fbb29c20884e056a3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This removes the outermost layer of widget-vbox and moves some
common code into a helper function.
The pattern repeats (with variations) a few more times, that's
left for later patches.
Change-Id: I8c98229cf41d03d5330c896ec9fa0965bfc65602
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Change-Id: I0ba784a4d775730277ec0b21aef649011f37b739
Reviewed-by: Alexander Drozdov <adrozdoff@gmail.com>
Reviewed-by: David Schulz <david.schulz@qt.io>
Physical existence of a file is not strictly needed for something
being runnable, e.g. 'foo' can be used to start a process on windows,
even when only 'foo.exe', but not 'foo' itself exists.
On the other hand, the existence of the file is not sufficient either
to run it, so the check was too weak and too strict at the same time.
Change-Id: I4a41d2f5cbb0cb471023a8bc23628072b28a5984
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Funnel all relevant data through target.applicationTargets() as
done for the non-local CMake-supporting setups and QBS already.
There is cleanup potential left for later changes.
Change-Id: I49ed6abd98c058a7fd1545e41b3bcd6ecb758a8b
Task-number: QTCREATORBUG-19985
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
A for (f : X.allFs()) if (f.canHandle(t)) { f.doIt() ... } }
pattern can be replaced by some static X.doIt(t), and
item.factory->create(target, item) by some item.create(target).
Change-Id: I65df8b71e03272d60f41a16795ea43a0fdb262ef
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is unused here by will be used in subsequent changes.
Project parsing yields information on whether there's a console
requested and whether the "magic" qtc_runnable flag for primary
executables has been seen.
Also, the current "targetname" is taking different roles in
different context, try to split-off the pure visual aspect
by allowing to specify an explicit displayName, with fallback
to the current decorated targetName if empty.
Task-number: QTCREATORBUG-19985
Change-Id: I11edfcaafd17972f6a78aeff3fbbf3d7eb91a213
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
