Not perfect, e.g. one would probably expect the items to
appear in the context menu of the header views, too, not
just on the main background of the view, but better than
nothing.
Task-number: QTCREATORBUG-23342
Change-Id: Ifdc44dcfd390112faa7b15bb8a51d809e42d7b29
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The two plugins plugins added resource files which were referenced with
the same name, namely
:/unit-tests
Make the names unique.
Change-Id: If63e762663f3f61b15f826d76ffcd2eb66873db7
Reviewed-by: hjk <hjk@qt.io>
To avoid confusion regarding context menu items limit the
selection mode to single selection.
Change-Id: I220d97fee65180a497f21e5921f832076235acb5
Reviewed-by: hjk <hjk@qt.io>
Using QObject::connect without capturing 'this'.
Change-Id: I64e61e897760002888d7a11771bd2dc36e640c72
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
A bit closer to where the functions are used. No real change.
Change-Id: Icbad68bd31d85caa59980316537ee532faf2d7ef
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This spares us the typical r = runnable(); modify(r); setRunnable(r)
roundtrip and the m_runnable storage that might or might not
be the same as runControl->runnable. Similar for m_device.
Change-Id: I8300260dd8dd7cd395e40bcd3d2ae45089085008
Reviewed-by: Christian Stenger <christian.stenger@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>
For some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The regular one with icon display is good enough nowadays.
Change-Id: I9a511c9975ceaeae0bb8005ac647fa710bf9d900
Reviewed-by: David Schulz <david.schulz@qt.io>
Tab titles of the application output pane for attach
to running and unstarted applications had been present
a long time ago.
Change-Id: I0a4f18438bef967ad60c447c81d58fec6aa830ae
Reviewed-by: hjk <hjk@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 6 API will move away from it.
Use QVector for API and some std container for internal things.
Change-Id: Iff14d48a47d5ac52ade875d9c8c84ad8a4f577d8
Reviewed-by: hjk <hjk@qt.io>
Since it also is used much for managing the breakpoints, i.e. selecting
and deleting with the delete key, and then single-click activation is
annoying since it moves the focus to the editor.
Change-Id: Ic05ec525f146e2363c4984095b9792973caa1ac6
Reviewed-by: hjk <hjk@qt.io>
Looks like the mainwindow cannot be convinced to handle multiple
sets of dockwidgets.
So switch back to a single set containing everything and keep
track of non-default visibility in the perspectives, and persist
these sets.
The following pass:
1.
Start Creator with new settings
Goto Debug Mode
Move Break dock widget to right, switch on Global log widget
Leave Creator
Start Creator
Goto Debug Mode
Check: Debugger Selected, Break on right, Global log visible
2.
Start Creator with new settings
Goto Debug Mode
Move Break dock widget to right, switch on Global log widget
Switch to QmlProfiler sub-perspective
Leave Creator
Start Creator
Goto Debug Mode
Check QmlProfiler selected
Switch to Debugger sub-perspective
Check: Debugger Selected, Break on right, Global log visible
3.
Start Creator with new settings
Use any C++ test project
Start debugging / stop at main() (F10)
Wait for stop
Switch to Edit mode
Switch back to Debug mode
Check: Only "running" debugger dock widget layout present
(not the normal + preset at the same time)
Quit Qt Creator while this debugger is running
Check: Shuts down without crash
4.
Use any C++ test project
Start debugging
Switch to Debugger Preset perspective
Start a second debugger
Kill either instance
Check: Application dies, Debugger Preset perspective gets displayed
Switch to perspective of second instance
Check: Perspective looks ok (docks visible as before)
Task-number: QTCREATORBUG-21083
Task-number: QTCREATORBUG-21669
Task-number: QTCREATORBUG-21668
Task-number: QTCREATORBUG-21813
Task-number: QTCREATORBUG-21851
Task-number: QTCREATORBUG-22110
Task-number: QTCREATORBUG-22169
Task-number: QTCREATORBUG-22189
Change-Id: Ic9eb41ff7699ac0f48a85e68376daa80b2b6847e
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
That big Icon was always there, but unused. add it to the
"Debugger.Stop" (in addition to the toolbar sized one), so that it looks
good when it appears in the mode bar.
For the "Classic" variant, I needed to add a @2x variant of the non-flat
icon.
Change-Id: Iea7200c7821b3780ff11a17b3ec74c44e06ba8d1
Reviewed-by: hjk <hjk@qt.io>
Also, construct the KitManager implicitly when the first
KitAspect is created. Ramp-down is still explicit and
somewhat odd.
Change-Id: If1506e1d0789ecabbaad2d8008851d0b42c5218b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It should not make and I do not observe a difference, but it seems
the better thing to do.
Change-Id: I1f1f9fba72c2b20f24ebde04cf4ec3711d77d476
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
For cases where no genuine RunConfiguration is available.
Use it in the debugger for the cases triggered from the menu.
Change-Id: I5671f4f5db2547c4a7a70bd34292bb6ccc8e6bf4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Into a trivial bit and two setters. Plan is to use it only with information
that is truly there (e.g. kit/device only) at the user side without having
to invent a RunConfiguration "handle".
Also remove some dead code in the test runner.
Change-Id: I987881e41722178b14b91f973b84cbdb67a9f85e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's off by default anyway, and in case when one wants to see it
the previous position was not providing enough space.
Change-Id: Ie5c6f56f482a8ca59fd47a534bbae70721313e0b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Move some constants to internalconstants.h or remove them entirely.
Change-Id: Iecd4def3b48130fb390bddf420da672d44e3d6b8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
A KitAspectWidget class is tightly coupled with the respective
KitAspect, and no one else ever needs to see any KitAspectWidget
subclass at build time.
Change-Id: I1883af3b054c225e1ff5dd913118715bfdbaacfc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@qt.io>
The file containing debug information is needed, this is typically
the executable, but other setups are possible.
Also make it a bit clearer in the code by using 'symbol' in a few
places that previously used 'localExecutable'.
Task-number: QTCREATORBUG-21910
Change-Id: I5c61bc03302c06baa58f82e1d5097f425f8936a8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
The different default positions of the "Breakpoint Preset" and the
"Breakpoint" views seem to cause confusion. They are apparently
perceived to be the same, and people file complaints about position
switching.
Change-Id: I29104552291f4e7f057ff8765243592da0b4cf74
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
