Mostly unused #include's, also sort them or reduce scope.
A few namespaces, ...
Change-Id: I9ee71e07de7157c9942125672addf87dd41e78f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
When parsing the config of a nim project we may have
parser issues that might be of interest for the user.
Change-Id: Iefec8194fe625110579cda8cf840e03945e677b9
Reviewed-by: Filippo Cucchetto <filippocucchetto@gmail.com>
Reviewed-by: hjk <hjk@qt.io>
It was already only one id string with two names. Since it is not
an id for the factory but the id of the created run configuration,
settle of runConfigurationId() as accessor.
The factory and id fields in RunConfigurationCreationInfo were
redundant. factory always implies (runconfiguration)id (but not
necessarily the other way round, in theory different factories
are possible for the same runconfiguration type for different
devices). So drop the id field here.
In one case now factory pointers instead of ids are compared, but
this is neutral there as this happens in a context of a fixed Target,
device and project are fixed there, so id and factory are equally
unique.
Change-Id: I859aa91486a2dd4abfc7369540a3322d6ec6260d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This combines two of the previous three paths to create run workers,
and refers to RunConfigurations by id, not by type where possible
to decrease coupling between the classes.
Only allow "type of run configuration" and "type of device"
as the only possible kind of restriction and require a uniform
RunWorker constructor signature.
Adapt user code to fit that pattern.
Change-Id: I5a6d49c9a144785fd0235d7586f244b56f67b366
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... of SimpleRunWorkerFactory.
This requires being explicit about the SimpleTargetRunner worker
default, but makes the template re-usable for current users of
RunWorker::registerWorker() which I would like to phase out now,
for less variations in the RunWorkerFactory setup.
Change-Id: I32638437e5bb29f143650f5fde706711ab25accf
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... and use in as replacement for RunConfiguration::addRunWorkerFactory.
It is still convenient to have a simple way to set up run worker
factories for the typical "just run for this configuration" case,
but it's even better if it follows the nowadays predominant pattern
of keeping factories in the plugin's pimpl.
Also, it turned out there were two copies of
QmlProjectRunconfigurationFactory code, one is enough.
Change-Id: I0b28c4ea18d0f52165a49f6133dc8687a3b9c7cf
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This patch add basic support for completion by using
the NimSuggest executable.
The user is expected to configure the path to NimSuggest
by using the new tools configuration page in the Nim
settings.
For now we don't support advanced completion of function
parameters. This will be added in further patches.
Change-Id: I5097ee2b3992486071591109c400d9c84da5fc00
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
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>
A new set of scalable and themable icons with unified look as provided
by Diana.
Task-number: QTCREATORBUG-20325
Change-Id: I68498b034e9e43fbb61511a38d9c7fc0003ab076
Reviewed-by: hjk <hjk@qt.io>
Use the pattern that's currently being established.
Change-Id: Ib716b35473fe5060b9ba5beea240ed46cfb1c5c7
Reviewed-by: Filippo Cucchetto <filippocucchetto@gmail.com>
Reviewed-by: hjk <hjk@qt.io>
There's several hundred kBytes extra for the separate .o in a
debug build, this doesn't scale well for a handful lines of code.
As the Nim plugin is a nice template for others elsewise, it would
be nice to use scalable patterns only.
Change-Id: I78e473d28a6a63d458dcbe06a77d93221867417f
Reviewed-by: Filippo Cucchetto <filippocucchetto@gmail.com>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
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>
A lot of the target-and-tool specific run controls nowadays
have something like a single main RunWorker. This patch
removes the need to have user-implemented RunControlFactories
in those cases and adjusts local run, remote linux,
python and nim to take advantage.
There's more potential use downstream.
Change-Id: Ie2d2f839b8be1fad2be3b79e21de3c0e475d88cf
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
- Avoids the hassle of QRC files and manually registering mime types
- Avoids performance regressions because of mime types that are
registered after mime database has been used
- Makes it technically possible to detect that a disabled plugin could
handle a mime type if it was enabled
Change-Id: I373008b1b56e9c6b4853055f20b3eeb112a6eff9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Added a new entry inside the "New" menu for creating a new nim script file (*.nims)
Added support for editing them inside the editor
Change-Id: I09a514fdd4e4a0e9a78bb557db3e8c7e97683b8d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
