| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
The exact storage type does not really matter here.
Change-Id: Iefec40f0f5909c8e7ba3415db4a11962694e1b38
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
|
| |
|
|
|
|
|
| |
Would be useful for https://github.com/JakeSays/QtCreatorTerminalPlugin/
Change-Id: I6629c95535b5ce7af8f9d486005f41598b8dff47
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
|
|
|
|
|
|
| |
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Qt Creator extracts file names from the output of external processes in
various places, for instance from compilers during the build. It often
happens that such file names are not absolute, so they cannot be
directly opened in an editor when the user clicks on their
representation in some widget. That's why they are processed by the
FileInProjectFinder facility first.
This patch enhances the FileInProjectFinder to be able to return more
than one candidate for a relative file path, and allows the user to
choose between these candidates where possible. This way, we won't open
a random file anymore when a project contains more than one file with
the same name.
Fixes: QTCREATORBUG-13623
Change-Id: Id19c9eace3e6b3dbde89f6528e6d02b55872d747
Reviewed-by: hjk <hjk@qt.io>
|
|
|
The more specific output parsers often fail to resolve relative file
paths, so add a fallback that attempts to find the corresponding file in
the current session.
A follow-up patch should add support for manual ambiguity resolving.
Change-Id: If0aecbab0f3bf1aa779f4a538076c87ae6bf22d4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
|
