- We forgot to adapt to the introduction of the "config" key.
- The space character was missing before the QML debugging property.
Task-number: QTCREATORBUG-20024
Change-Id: Ie4a94a04989caa14b1ddc11c8595d679d1871625
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
Make sure the Qnx RCs only get triggered for qmake-based projects and defend
against broken set-ups using QTC_ASSERT.
Task-number: QTCREATORBUG-19755
Change-Id: If64b73de49b0199308f767151d68909dc8b1bc53
Reviewed-by: hjk <hjk@qt.io>
In line with addSupportedProjectType, saves a few cycles due to the
non-use of the temporary list, and in theory more flexible than the
existing set...(QList<Id>) as it potentially allows dependent plugin
to declare support for already existing configurations instead of
re-implementing their own.
Change-Id: I2b83e90de49daa9bfce6f780c5f51c2e971eb7d1
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>
All the KitInformation methods need to gracefully handle a kit that is
a nullptr. Ensure this is indeed the case.
This might fix the actual trigger for QTCREATORBUG-19469.
Change-Id: Id78ac8a26c1be908f41a425ff1935b86888e4b8b
Reviewed-by: hjk <hjk@qt.io>
These still assumed we can only multiplex on profiles.
Change-Id: Ice3dfe06c1be732ecae42db75155e930b0554b6f
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
QtQuick1 is no longer supported by Qt Creator.
Change-Id: I684ac12bca29779a18cc870e94071412edd29985
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The DebuggerRunConfigurationAspect uses this property to decide
whether to enable QML debugging by default.
Task-number: QTCREATORBUG-19655
Change-Id: I71cc1127ee9d470a7cfedd424f8487f83d38db67
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This is needed later to auto-detect whether to enable QML debugging.
Task-number: QTCREATORBUG-19655
Change-Id: I9f33119c20299cd0a2e77727bbe4396fb6eb9b12
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The module property override needs a "modules." prefix these days.
Task-number: QTCREATORBUG-19655
Change-Id: I4d6025c479a65cf94968338884f80b0ffa5ac141
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Due to a typo in the code, it was almost never shown, except initially
when it shouldn't have been.
Change-Id: I8d5ab3f28fddde7b996d3ca74bc69f2f549bedc1
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... when building with qbs. Optionally also update the copies in the
repository.
Change-Id: I4604eff6de95101a8cb086708d5a9ef24af0fd32
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Kits are a central concept and structure in anything build and run
related in Creator, their organization is crucial for the functionality
of Creator and deserve to be emphasized over other, often more cosmetic
settings.
This is the first step of two, the second step would be moving
the Device (list) page also in this category, possibly after some
reorganization in the Device category.
Change-Id: I4abc89472d0575c691fc9e5051397833126e5456
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... with the ability to opt out, as in the qmake run configuration.
Task-number: QTCREATORBUG-19274
Change-Id: If4e996a974a82080bb09f2971b0bb5df9173fb14
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
To HEAD of 1.11 branch. Also do the adaptations necessary because of the
branch switch.
Change-Id: Ief69ef014c10397c14fcd68a9ca770d1391d5491
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The build list names are always the ones determined from the
build list id. No need to do that on the caller side.
Change-Id: Icc21ef355de535af21215819fe04daa76fed0d9c
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Similar to 85206e216a for qmake.
Unify the lookup logic in BaseQtVersion.
Change-Id: Id0b0ff3127f0561ac36610ada16110b55252eb31
Reviewed-by: Tobias Hunger <tobias.hunger@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>
After switching to a different build configuration, property changes in
the build config widget would no longer cause project reparsing. Likely
caused by e52ebbf217.
Change-Id: Ifebec74475def49885232ad71d4de01f51568fcb
Reviewed-by: hjk <hjk@qt.io>
While the base function is not virtual the "hiding" re-implementation
effectively appears to do the same. So drop it.
Change-Id: I4ab0e0690b948ce3f590c87262d10622b169450e
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>
The mapping was not quite right. In particular, cpp.cCompilerName needs
to be set if the compiler name is not the default.
Task-number: QTCREATORBUG-19467
Change-Id: I6c190fdda98ff15dce6066bfb082d24853538a78
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
... by additionally keeping local (currently non-owning) pools per
"interesting" type.
Current situation:
- The global object pool does not scale well for looking up
objects, as iteration plus qobject_cast typically iterates
over all pooled objects.
- User code that can use typed results from the object
pool need to have access to the full type definition anyway,
i.e. depend on the plugin of the target class anyway.
The patch here solves the scaling problem is to have local
type-specific pools to which objects register in their
constructors and deregister in their destructors.
This patch here does *not* change the ownership model of the
pooled objects, however, it opens the possibility to change
the ownership model per type (e.g. by not putting things into
the global pool at all anymore and make the local pool 'owning')
and the intent is to handle that in later patchs.
Even without the follow-up patches this here is a performance
improvement for the cases that access the local pools instead
the global one, i.e. "practically all".
Change-Id: Ib11a42df2c4ecf5e1155534730083a520dd1995b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Do no longer expose Nodes from the SessionManager's API. These are now
exclusively handled by the ProjectTree.
Change-Id: I585c2ac919462073870363436e767640775d9045
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>
