This way the CMake Project Manager will behave in the same way as QMake
Project Manager!
Change-Id: I3c4bd6b2f4f0f5d4dfc73edb2049d6e251154d54
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Amends 76dcc069d6
As a user I expect that the "Forms" and "State charts" source groups
should go away if I select the filter "Hide Source and Header Groups" in
Projects view.
They are not meant to be user defined source groups.
Change-Id: I17db9eb7e1da17b93a45f6093782add19c2b5cb1
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
All CMakeLists.txt from the Project view are marked as generated, except
the root one. This means that in normal case they will be hidden.
Every CMake Target (except Utility) will get a CMakeLists.txt:<number>
entry with the definition line of the target.
The CMake Folders will get an entry with the CMakeLists.txt which can be
accessed via context menu and "Open...".
The CMake Folder that only had a CMakeLists.txt will be removed when the
filter "Hide Empty Directories" is checked. This for example makes a
reduced plugin Qt Creator only display the enabled plugins, and not all
plugins!
With this change the "Simplify Tree" view will no longer have many
CMakeLists.txt entries, which makes the view more useful.
Fixes: QTCREATORBUG-31362
Change-Id: I708171e4b114100fae6fb592044a19fc36239261
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
... in the bundle itself, whenever possible.
It's very annoying to have to add this stanza in all places where
bundling takes place, and it's also easily forgotten, introducing memory
leaks.
This also nicely self-documents the expectations of the calling code as
to whether new toolchains can or cannot be created in the given context
as a side effect of bundling.
Change-Id: I78d2d4cdfc1010568f61f201b0d930b01f79a88b
Reviewed-by: hjk <hjk@qt.io>
Effectively from container of pairs to pairs of containers.
Saves a few transformations and temporary lists at the price of
effectively storing the keys twice. This is all small stuff, so
it should not matter performance or memory-wise at all, but helps
me to reason about potential complexity on higher levels.
Change-Id: Idf9e235b64d97b1168278ea3dcda34a476c20c08
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
`EditorManager::activateEditor` assumes that the editor is already known
to the editor manager.
Add a dedicated `EditorManager::addEditor` method for making an IEditor
instance known to the editor manager and activating it (if wanted).
Change-Id: I0c1632b6a3b32f54a01da0ad632fa17e2b1a850f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... when auto-detecting kits.
Take the entire ABI into account, including binary format and word
width.
Fixes: QTCREATORBUG-31119
Change-Id: I495faf3c54738750bddac65f5a1919144b9fecd4
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
In Projects view you can right click on a CMake target and select
"Open...", in the context menu you will have a stack of functions that
were used in the creation of the target.
If you are using a custom CMake API you would want the highlevel
function on top, and not on bottom.
Task-number: QTCREATORBUG-31362
Change-Id: I42e436d99f6c5f7a8d1cd67da84a6087bc18e8cd
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Do not react on activated signal as this triggers also for
selecting the current item again.
Instead only react when the index does really change.
Change-Id: I6591f711ce7d3c2c4fc5a79a2c2de0d748d9d774
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
The source id contains already the source context id.
Change-Id: I1bdb5d4c7fb054c0a208816623e099902ee86e63
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Saving the source context id as part of the source id simplyfies file
path handling. It is now very easy to see if a two source ids have the
same source context id.
Change-Id: I6c86942d9f026fc047c49bbde3fffd6af14d81de
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
It also can be overwritten by option:
IS_SUPPORTED_PROJECTSTORAGE_QT
or environment variable:
QTC_IS_SUPPORTED_PROJECTSTORAGE_QT
Change-Id: Iabc7d59ff100017811167a6ec4e7447ccc3e55ee
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Project type traits are increasing the code complexity in the updater by
quite lot. The discover can be done in an other way too.
Change-Id: Ied9b7df445e854c76243ece6666690ea10b8d33d
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This reverts commit 364beabcf1.
Reason for revert: Not needed anymore after bf823eb581
Change-Id: I8f1d4db7d8b3a216e808ec431f002c1199fb919c
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: André Hartmann <aha_1980@gmx.de>
- Use toolchain bundles, ensuring compatible C/C++ toolchains
- Try harder to match Qt and toolchains
Change-Id: I8739a5e1e75d08df4346d51cb0ee7704ca072489
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Make the aspects private, but provide accessors to value and
defaultValue as needed. This allows setters to be kept protected
when wanted.
Change-Id: I26f93f62d4ac2e7346f95543c38d8ac9156348c2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Set the Qt version as a property on QDesignerIntegration
on form window change or when saving for Qt Designer
to know which version to write.
Task-number: PYSIDE-2492
Task-number: QTBUG-118473
Task-number: QTBUG-127179
Change-Id: I1281287147e8d4108a321570785c0287ef18230c
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
While the HistoryCompleter did have private functions to
change the History List length, these were not used or
accessible. This change adds an argument to allow the
caller to change the maximum size of the list.
Its used by the Lua REPL pane.
Change-Id: I6baf260db5da9d8fe58a37ff0af3ec59396a5be0
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Close is already deleting the instance.
Fixes: QDS-13268
Change-Id: I95998d6c11f6824386d109ae1f622d022a59ce7f
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Motivation:
a) It was ridiculous that when users wanted to manually
add a new toolchain, they had to do the entire setup twice.
b) It was equally weird that users had to take care to choose
matching toolchains when setting up a kit, or indeed that it was
even possible to mix random toolchains in the first place.
User-visible changes:
- The "C" and "C++" categories in the toolchain settings page have
been merged into a single "C/C++" category.
- When adding a new toolchain, the "C" and "C++" sub-menus are gone.
Instead, the toolchain config widget offers two path choosers if
the respective toolchain type supports C and C++ compilers.
- By default, the C++ compiler file path is derived from the C
compiler file path automatically, so the user usually has
to enter only the former.
- In the kit settings page, the "C" and "C++" toolchain combo boxes
have been replaced by a single "C/C++" combo box, relieving the user
of the responsibility to choose two matching toolchains.
Implementation:
The notion that a Toolchain object corresponds to a single compiler is so
deeply engrained in the code that it cannot realistically be changed in
the short term. We therefore introduce the concept of a "toolchain
bundle" as an additional layer that groups matching C and C++ toolchains
together. This way, most code dealing with toolchains stays unchanged,
and only the presentation layer (i.e. the toolchain and kit settings
pages) needed to be rewritten. Once set up in a bundle, toolchains stay
implicitly linked together so the matching only needs to be done once.
In follow-up patches, we will make use of toolchain bundles in all the
places where kits are auto-created, eliminating the risk of mixing
incompatible toolchains in a kit.
Change-Id: Ie6c5add9963e7c1096268dd77acd624671b2674f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
... and IDevice::qmlRunCommand, currently for storage only.
Leave the GUI side as-is for now, as this synchronizes the widget
content with the local copy of the device data to allow the
device tester to be run with the visible data.
Change-Id: Ie8fb967c9a7f8246eec71d52c9b714ca3b3f5acd
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
