This saves some unneeded file path conversion and lookups in the
python settings.
Change-Id: I8647858320183dc1da027363b4ab265f6c75e1ae
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Checks if the document imports PySide and whether the selected python
interpreter can find a PySide installation. If not show a global info
bar that can install PySide via pip like the python lsp server.
Task-number: PYSIDE-1742
Change-Id: I02c0d5f6eb268f3d8826d4fb9d9ec3c7c48b8638
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There will be more lsp specific functionality so moving it into its own
space is reasonable.
Change-Id: Ic87d437182d68673b53f662c804707138fef5b6c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
In favor of the FilePath/Link ones.
Change-Id: I5caf9e0f8de304ff4ee12329557aa50a6f3a0c69
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Schulz <david.schulz@qt.io>
There was a vicious cycle started when loading a runconfig pointing
to an interpreter with an id that was not present in the combobox.
Amends 9decfcb151.
Change-Id: I77595795eb825bde55919c8d8dd632f3bf397578
Reviewed-by: David Schulz <david.schulz@qt.io>
The python interpreter aspect relyed on having a combo box setup when
looking up the current interpreter. This combo box is just initialized
when the widget is shown since recently. Using the current id that is
valid all the time instead to get the correct interpreter.
Change-Id: I0a6bde46864c44c9408d0d7331164b49da65c7df
Reviewed-by: hjk <hjk@qt.io>
Makes the code on the user side somewhat more symmetric and is a
bit more flexible, even if that's not used right now.
Change-Id: I29a5182463ead0e4a39fcb51ecf4fdd5adf2a203
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
- the var args template for addItems was overkill creating a lot of
instantiations. Use a temporary list instead.
- allow default constructed LayoutItems to be used for an empty cell,
avoiding the use of a QLabel with empty text
- add an addRow({...}) overload as convenience shortcut for
.startNewRow().addItems({...}
- rename startNewRow() to finishRow()
Change-Id: I6d49dacbac3d7acf140ca526884ba1ceeeca2e0d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Classes involved are BaseAspect and some derived classes,
LayoutBuilder and VariableChooser.
This is mostly mechanical, with various include/using changes
to make it compile.
Change-Id: I624a457f3555f102e541c4c71e33a9423af32250
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
In most cases they are used directly, so there's not much Base* in that.
Added the old name as alias as porting help for a while.
Change-Id: I494a8a560b8996bcf74915ea3570b504df6a6b4c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
(cherry picked from commit 430a33dcd9)
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
We'd like to create more useful tasks from compiler output, that is, try
harder to identify consecutive lines that refer to the same issue and
create one task for them, rather than one for each line. In such
"aggregate" tasks, the first line will not necessarily carry the main
information. Therefore, we make it explicit what this main information
is by introducing a dedicated summary member.
Also streamline the font handling for compile tasks.
Change-Id: I933f2643a13c710dab1ab548c56669b129026eb5
Reviewed-by: hjk <hjk@qt.io>
... when creating a run control for a Qt project. Now tasks will appear
in the issues pane for QtTest application output in the app output pane.
Task-number: QTCREATORBUG-22665
Change-Id: I2674f3d4f9aabc0a4db4178dcd5495b822f14022
Reviewed-by: hjk <hjk@qt.io>
Now only one piece of code needs to be written to both linkify output in
an output pane and create tasks for it in the issues pane.
The calling sites are also simplified. For instance, until now, build
steps had to feed their output parsers manually and then push the
created tasks up the signal stack in parallel with the actual output,
which the build manager relied upon for cross-linking the output pane
content. Afterwards, the output would get forwarded to the formatter
(and parsed for ANSI escape codes a second time). In contrast, a build
step now just forwards the process output, and task parsing as well as
output formatting is done centrally further up the stack.
Concrete user-visible improvements so far:
- File paths in compiler/linker messages are clickable links now.
- QtTest applications now create clickable links also when run
as part of a build step, not just in the app output pane.
Task-number: QTCREATORBUG-22665
Change-Id: Ic9fb95b2d97f2520ab3ec653315e9219466ec08d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
An OutputFormatter takes some string and prints it into a text edit.
In addition, it can ask any number of registered OutputLineParsers
whether they think any special formatting should be applied to the
current line.
This mechanism is now properly modeled by our class design, rather than
being hidden in a monolithic class where everything had the same type,
no matter what its purpose was.
Prospective contributors can now simply be pointed to the
OutputLineParser class and will see at one glance what they have to do.
Change-Id: I9844499f062c94fb038ce73fd6f26576910148c2
Reviewed-by: hjk <hjk@qt.io>
Instead of working directly on the text edit, the specialized
OutputFormatter classes now simply ask the base class to do it for them.
In practice, the request currently always is "turn this part of the text
into a link", but the interface can be extended to other types of
formatting, should that ever be required.
This is a win/win situation: Derived classes no longer have to fiddle
with QTextCursor & friends (nor do they have to call any base class
functions), while the base class can make strong assumptions about what
the derived class does to the text edit (i.e.: nothing).
Change-Id: Icc4bc52d4001b0359247563e39a206fa274833d7
Reviewed-by: hjk <hjk@qt.io>
Introduce an aggregating output formatter that forwards its input to a
sub-formatter that feels responsible for it, or otherwise lets the base
class handle it.
Our output panes now use such an aggregating formatter.
In particular, this means that in the future, we won't have to stuff all
run control output formatting into the Qt output formatter anymore.
Change-Id: I5498f200a61db10ccff3ec8974c6825da7f7072d
Reviewed-by: hjk <hjk@qt.io>
All output formatters are line-based, and they all did their own line
splitting and, if they didn't entirely ignore it, handling of partial
lines.
Instead, we now do all the book-keeping in the base class, and the
subclasses always work with complete lines.
Change-Id: I0b0df7951d0e4f6601f4d912230071784c87b3d3
Reviewed-by: hjk <hjk@qt.io>
Presumably, they were intended for output that shouldn't get an
automatic newline, but if there ever was such a thing as automatic
newlines, it must have evaporated over time. All users of
OutputFormatter provide a newline if they want one.
Change-Id: Ibd219b7305fd503ce075d6f77930d2b538d5e2e8
Reviewed-by: hjk <hjk@qt.io>
That's where it belongs: The logic there is applicable to all output
formatters, not just those used via an output window.
Change-Id: Idf4ca8d22631ca96feb97553f28724c0275e0bf8
Reviewed-by: hjk <hjk@qt.io>
Merge QtOutputFormatter::linkFormat and
PythonOutputFormatter::linkFormat to OutputFormatter::linkFormat because
these two functions were identical.
Fixes: QTCREATORBUG-23562
Change-Id: I1337b2fd66fc7d7b6742eb5e9c1a2caf1dc6b5bd
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: André Hartmann <aha_1980@gmx.de>
... by an explicit update() call. This is what effectively done in
most cases, and should be harmless and reasonably cheap in most other
cases.
Change-Id: I323112ec7cdbccf19050ac54466d8e1d97a0516e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... or Target.
This patch moves build system from conceptually "one per project"
to "one per target (i.e. per project-and-kit)" or "per
BuildConfigurations" for targets where the builds differ
significantly.
Building requires usually items from the kit (Qt version, compiler,
...) so a target-agnostic build is practically almost always wrong.
Moving the build system to the target also has the potential
to solve issues caused by switching targets while parsing, that
used Project::activeTarget() regularly, with potentially different
results before and after the switch.
This patch might create performance/size regressions when several
targets are set up per project as the build system implementation's
internal data are duplicated in this case.
The idea is to fix that by sharing per-project pieces again in
the project implementation once these problems occur.
Change-Id: I87f640ce418b93175b5029124eaa55f3b8721dca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Add the WorkingDirectoryAspect to prevent running the
main script in an unpredictable location.
Change-Id: I1be206261b7983e933b53ccd57c93089154d8417
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
After opening a document or project the directory hierarchy is looked up
for a Scripts/(activate && python.exe) on windows or bin/(activate &&
python) on unix. This is the usual structure of python virtual
environments. If such a folder is found add the python from that folder
to the list of configured interpreters in the settings, set it as the
current interpreter for the project and try to open the corresponding
language server.
Change-Id: I038c309ea2988f9370194330d250d1515beac0a0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This hides the explicit use of a QFormLayout from the aspect
interface in a new LayoutBuilder class. That currently works
only on a QFormLayout in the back, but opens the possibility
to use e.g. a QGridLayout as use on the Kits and some option
pages.
The aspects now only announce sub-widgets they like to add,
actuall positioning is does by a new LayoutBuilder class,
also cramming several widgets in an hbox in the right column
of the QFormLayout is done there.
Change-Id: I2b788192c465f2ab82261849d34e514697c5a491
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
