... and adapt constructors to not take the now-unneeded
RunConfiguration pointer.
Change-Id: I53ff338f51334ff7b0c22d4bed92bfcfc8225ea7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
To remove the last user of IRCAspect::runConfiguration.
Change-Id: I1390166730112008a4050877f96bb29f274e7ef1
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>
This replaces various versions of the key name of the arguments,
working directory, use terminal and use dyld image suffix fields
by unified versions ("RunConfiguration.Arguments",
"RunConfiguration.WorkingDirectory", "RunConfiguration.UseTerminal",
"RunConfiguration.UseDyldImageSuffix").
The different names for the fields are technically not needed
(as proven by several cases that already now used the same key),
partially outdated ("Qt4ProjectManager.MaemoRunConfiguration.Arguments")
make RunConfiguration constructors less uniform and more complex
than needed.
The "RunConfiguration." prefix in the new names is not needed, but used
by several other settings, so having it there looks more uniform now.
In (the unexpected case) that different keys would ever be necessary,
the default key name could still be overridden by using setSettingsKey
from user code.
Change-Id: Ifb74ad74e0a9c724c8bf5e71e1bb2424d5d1831b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@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>
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>
Remove some unnecessary #include and use a recently introduced
RunConfiguration::builtTargetInfo() convenience function.
Change-Id: I76750fd66ae2c268b68d225c62aad7d880256d07
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Include interpreter and main script settings.
Change-Id: I91c19ef124ff8b7da34bc67fb1a5ef054c3499b8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Use the common pattern for PythonEditorPluginPrivate.
Change-Id: Icec8d975e0ab921be7121d123af4dddecd7d0384
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It's what the base class requires, and opens the possibility to
have several factories creating the same type of run configuration.
Also move ios, winrt and android factories closer to their products,
it's the predominant pattern nowadays.
Change-Id: Iad48152f02a248d22cb18dd435a2fc34d73c7077
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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>
... in preparation of upcoming OutputFormatter creation reorganization.
Also, replace a raw string literal by a normal one to accommodate moc
and remove an unused member.
Change-Id: I416bb20afd891717fcb4f449955b4e46e5c05590
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Add an output formatter that captures stack traces and adds them
as tasks.
This helps to speed up fixing syntax errors.
Change-Id: I8a4fa77d0f87b4d16f4bb780b15ec06154a52441
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Use new wrapWidget() convenience function and don't use
members for locally used items.
Change-Id: Ia063501a124a56d0ade82dbc17d1087b11d4a88e
Reviewed-by: Eike Ziller <eike.ziller@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>
It's not an *I*nterface anymore
Also, remove the in-all-but-one case unused QObject parent and the
object name that was only there for debugging purposes. The class
type serves the same purpose in the debugger.
Change-Id: I0dafb01e6b4fd7c7df04a63aaa3ef3e4bd693f6f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... at RunConfig Creation time. This eases the id mangling case.
Use it in the PythonProject.
Change-Id: I9a7e2c90997ed5ab737cd4fa68895217bdbe1dfe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead of calling twice for AutoCreated and UserCreated, call once
and record to which case it belongs. Only the 'both' and
'user only' combination are ever used.
Change-Id: I9c15085bcbb4bf6584a6156135f2084dbfc51c1c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... including build target name and display names instead of
returning QString build target names and producing display names
via displayNameForBuildTarget()
This is a mechanical intermediate step on the road to use
Target::applicationTargets().list uniformly as source of build
targets.
Change-Id: I7b0b1fb398d5061b0cec0b86890f9eaf0bb53a19
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The possibly intented flexibility e.g. to have different project types
share the same idea of a common context was never used, in all cases
we had a 1:1 relation ship between project ids and ids that were used
as context. This led to oversights like the one fixed in 60fb35a2.
This patch here uses the project id unconditionally as context and
drops all context ids. If we'll ever have the situation where the
original flexibility was needed, Project::projectContext() could be
made virtual and overridden were needed.
Also, the context was never modified for any given project, so the
updating machinery is not needed.
Change-Id: I3f7fac0ed5e4704e126558987c48577f26082dfd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This follow the rough pattern of recent *RunConfigurationFactory changes
for build and deploy configurations.
- Collapse the two lines of constructors similar to what
890c1906e6 did for RunConfigurations
* Deploy* was purely mechanical
* Build* ctors are split in connects() in the ctor body
to create "empty shell for clone" etc
and build step additions in initialize() functions which
are only used in the create() case.
-- Allows to collapse the shared 'ctor()' functions, too.
- Move FooBuildConfigurationFactory::create() implementations
to FooBuildConfiguration() constructor. That was a strange
and unneeded ping-pong between factories and objects, and
furthermore allows one level less of indirection (and for a
later, left out here, some reduction of the
FooBuildConfiguration interfaces that were only used to
accommodate the *Factory::create() functions.
- Most {Build,Deploy}Configuration{,Factory} classes had a canHandle(),
but there wasn't one in the base classses. Have one there.
- Most canHandle() functions were checking simple restrictions on
e.g. project or target types, specify those by setters in the
constructors instead and check them in the base canHandle()
- clone() is generally replaced by a creation of a "shell object"
and a fromMap(source->toMap()), implemented in the base, there
are two cases left for Android and Qbs that needed(?) some extra
polish
- generally use canHandle() in base implementation, instead
of doing that in all Derived::canFoo()
- as a result, canCreate/create/canClone/clone reimplementations
are not needed anymore, keep the base implementation for
now (could be inlined into their only users later), but
de-virtualize them.
- Combine Ios{Preset,DSym}BuildStepFactory. There was only one
'dsym' build step they could create.
- Split the 'mangled' id into the ProjectConfiguration subtype
specific constant identifier, and a QString extraId() bit.
Only maintain the mangled id in saved settings.
- Make ProjectConfiguration::m_id a constant member, adapt
all constructors of derived classe.
Not done in this patch:
- Finish possible cosmetic changes on top
- Add a way to specify restrictions to supported Qt versions
(used in Android/Ios), as the base implementation does not
depend on the qtsupport plugin
- Combine the QList<X> availableFoo() + createFoo(X) function
pairs to somthing like a direct
QList<struct { X; std::function<X()>; }> fooCreators()
to avoid e.g. the baseId.withSuffix() <-> id.suffixAfter(base)
pingpong
- Remove the *Factories from the global object pool
- Do something about priority(). Falling back to plain
qmake in android+qmake setup is not helpful.
Change-Id: I2be7d88d554c5aa8b7db8edf5b93278e1ae0112a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This shifts the resposibility of creation/splitting of RunConfiguration
ids into what are essentially "type ids" and "build targets" to the base
implementation, possibly opening the path of abandoning the mangled ids
in favor of explicitly storing their constituent parts.
Take advantage of base id split in RunConfigurations for availableIds
/displayNameForId and for canCreate/canRestore/canClone.
Change-Id: I19fefb32757407ab5053a2ae0e5a79438659f6ec
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Filippo Cucchetto <filippocucchetto@gmail.com>
All RunConfiguration factories had some kind of canHandle(Target *)
implementation. Centralize this notion.
Change-Id: Ie24a355e857bddfd76b866859b8c7a42ffc83840
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Moving aspect data closer to real Value semantics fixes
the regression introduced by 890c1906e.
Task-number: QTCREATORBUG-19186
Task-number: QTCREATORBUG-19192
Change-Id: Ieaeef3995ae06a817f266c1e2514f9e5793bd4e8
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Opening a python project created an empty 'Custom RunConfiguration'
the first time it had been opened.
Avoid this by re-ordering and simplifying the processing of the
project and its respective settings.
Change-Id: I0c0f71e0dab6f03df46e5ddbdc7e1dbf73e8bef8
Reviewed-by: hjk <hjk@qt.io>
The idea is to massage the setup in a way to make implementation
of new configurations less error prone by identifying recurring patterns
and sharing repetitive code that tends to be forgotten (see Android cloning).
The former two lines of constructors (owner-and-id, owner-and-source)
are split into a simple, shared, constructor and new setId() and
copyFrom() functions.
The change is mostly mechanical, some multiple calls to fromMap
have been removed, though, some consts added.
Otherwise, to keep the patch small it temporarily introduces two
helper templates in IRunConfigurationFactory. Also, setId() signatures
have not been unified yet. These won't be needed in the final setup.
Change-Id: I8c0734496caae744a9883fe6d92c1d8f8e0234ea
Reviewed-by: hjk <hjk@qt.io>
Centralize handling of enabled state of RunConfiguration widgets.
Remove code that does the same thing in all the different run configuration
widgets.
Change-Id: I175d7e19d031bd28a2b19cd825e0b6568da19bc3
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
... and use this as a base for all RunConfigurations.
Clean out code in the individual run configurations dealing with their
enabled/disabled state.
Change-Id: Icc2ea136b056f7aea7ce96480b4402459d7ac0ce
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Get rid of duplicated code to do such signaling in derived Project types.
Change-Id: I26914a1d751d72ee65c15a7943e0e7f34978f042
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
