1. 28 Jul, 2017 1 commit
  2. 19 Jul, 2017 1 commit
  3. 18 Jul, 2017 1 commit
  4. 17 Jul, 2017 5 commits
  5. 12 Jul, 2017 2 commits
  6. 11 Jul, 2017 1 commit
  7. 10 Jul, 2017 2 commits
  8. 07 Jul, 2017 3 commits
    • hjk's avatar
      ProjectExplorer: Remove RunControl::notifyRemote* function · 9c738cea
      hjk authored
      As promised in 112e3222
      . The temporary workaround can go now.
      Change-Id: Ia98abfb21577ff073b069eaaf0edb5fb1227114d
      Reviewed-by: Christian Kandeler's avatarChristian Kandeler <christian.kandeler@qt.io>
    • hjk's avatar
      ProjectExplorer: Remove RunControl::worker<Type>() · 8376afd9
      hjk authored
      It looks like the case where workers need talk to each other by
      only knowing the type of the 'partner' does not exist in practice
      anymore. With the now-common setup of a 'primary' worker that one
      can introduce the 'lesser' workers to each other directly.
      That's also conceptually more robust that picking a partner by
      type only only from some 'pool' (all the workers in a runcontrol),
      scales better (it e.g. is imaginable that a RunControl needs
      more than one PortGatherer in complex setups where more than one
      device is involved) saves a few cycles, and even removes the need
      for workers to be qobject_cast-able.
      Change-Id: Ib3d8c942c893d6c198d9813cce7df28ba3260ce8
      Reviewed-by: Christian Kandeler's avatarChristian Kandeler <christian.kandeler@qt.io>
      Reviewed-by: default avatarhjk <hjk@qt.io>
    • hjk's avatar
      ProjectExplorer: Remove Connection as concept · f82bb1ec
      hjk authored
      It turns out that one "Connection" per RunControl doesn't map
      well to the uses we have. Instead, RunWorkers need to know
      individually how to connect to the place where they can work,
      but they are already specific enough to be able to use a
      standard class (like QUrl) as their way to specify the needed
      entry point.
      In theory one could see a RunControl's connection as an
      aggregation of its workers connection bits, but that does
      not really seem to be needed in code.
      As consequence, replace UrlConnection by a plain QUrl, and also
      the HostName connection by a QUrl with hostName set.
      Change-Id: I40c97e37779314ac0a77041e864a18eadb78f987
      Reviewed-by: Vikas Pachdha's avatarVikas Pachdha <vikas.pachdha@qt.io>
  9. 05 Jul, 2017 1 commit
    • hjk's avatar
      ProjectExplorer: Fix recent indeterministic state of stop button · d857fa52
      hjk authored
      The recent RunControl related changes have led to several regressions
      in the fragile handling of button states in the output pane.
      Take advantage of the new Starting phase to fix disabling of the
      run and enabling of the stop button at reasonable times.
      Change-Id: Iae191a840484dd08d61facf6b9f439bfafcbbcb0
      Task-number: QTCREATORBUG-18508
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
  10. 04 Jul, 2017 1 commit
  11. 03 Jul, 2017 1 commit
  12. 30 Jun, 2017 1 commit
  13. 29 Jun, 2017 1 commit
  14. 28 Jun, 2017 1 commit
  15. 27 Jun, 2017 2 commits
  16. 20 Jun, 2017 1 commit
  17. 15 Jun, 2017 1 commit
  18. 13 Jun, 2017 1 commit
  19. 29 May, 2017 1 commit
  20. 15 May, 2017 1 commit
  21. 12 May, 2017 1 commit
    • Kevin Funk's avatar
      Fix crash when attaching GammaRay to running proc · 65234d36
      Kevin Funk authored
      Backtrace (excerpt):
      Thread 1 "qtcreator" received signal SIGSEGV, Segmentation fault.
      0  0x00007fffe2a809d0 in ProjectExplorer::Runnable::Runnable (this=0x7fffffffc5c0, other=...) at /home/kfunk/devel/src/qt-creator-4.3/src/plugins/projectexplorer/runconfiguration.h:175
      1  0x00007fffe2a81eab in QPair<ProjectExplorer::Runnable, Utils::ProcessHandle>::QPair (this=0x7fffffffc5c0, t1=..., t2=...) at ../../../../qt5.8/qtbase/include/QtCore/../../../../../src/qt5.8/qtbase/src/corelib/tools/qpair.h:61
      2  0x00007fffe2a81f04 in qMakePair<ProjectExplorer::Runnable, Utils::ProcessHandle> (x=..., y=...) at ../../../../qt5.8/qtbase/include/QtCore/../../../../../src/qt5.8/qtbase/src/corelib/tools/qpair.h:151
      3  0x00007fffe2a6e74a in ProjectExplorer::ProjectExplorerPlugin::runningRunControlProcesses () at /home/kfunk/devel/src/qt-creator-4.3/src/plugins/projectexplorer/projectexplorer.cpp:2568
      4  0x00007fffdfcfef4e in GammaRayIntegration::Internal::ProcessTrackerBackendQtCreator::checkProcess (this=0x555556240c10, pid=6881) at ../../../src/qtauto/kdab-plugin-gammaray-qtas1.2/gammarayprocesstrackerbackendqtc.cpp:112
      5  0x00007fffdf943b6a in GammaRay::ProcessTracker::D::requestUpdate (this=0x555556230800) at /home/kfunk/devel/src/qtauto/gammaray-qtas1.2/common/processtracker.cpp:72
      6  0x00007fffdf943548 in GammaRay::ProcessTracker::D::qt_static_metacall (_o=0x555556230800, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fffffffc800) at common/processtracker.moc:77
      7  0x00007ffff66cf95a in QMetaObject::activate (sender=0x555556230900, signalOffset=3, local_signal_index=0, argv=0x0) at /home/kfunk/devel/src/qt5.8/qtbase/src/corelib/kernel/qobject.cpp:3743
      (gdb) frame 0
      0  0x00007fffe2a809d0 in ProjectExplorer::Runnable::Runnable (this=0x7fffffffc5c0, other=...) at /home/kfunk/devel/src/qt-creator-4.3/src/plugins/projectexplorer/runconfiguration.h:175
      (gdb) p other.d
      8 = std::unique_ptr<ProjectExplorer::Runnable::Concept> containing 0x0
      Fixed both locations where there's a potential nullptr derefence in this
      Change-Id: I23f7db6f18675470b19cdf39dce449c5b694160d
      Reviewed-by: Christian Stenger's avatarChristian Stenger <christian.stenger@qt.io>
      Reviewed-by: default avatarhjk <hjk@qt.io>
  22. 05 May, 2017 1 commit
  23. 04 May, 2017 2 commits
  24. 03 May, 2017 1 commit
  25. 02 May, 2017 2 commits
  26. 26 Apr, 2017 1 commit
    • hjk's avatar
      RemoteLinux: Base AbstractRemotetLinuxRunSupport on PE::TargetSupport · 59535078
      hjk authored
      This essentially just puts the data members and most of the original
      interface on the proper, i.e. the 'target', side of the tool/target
      divide. Since the SimpleTargetRunner base already has an
      ApplicationLauncher member, this can be used directly.
      State handling and coordination between tool and target runner parts
      stays as before for now, with unchanged 'custom' transition logic.
      The plan here is to remove the custom state handling later, including
      the two remaining cases of direct targetRunner->toolRunner calling
      (startExecution, and adapterSetupFailed) for which this patch here
      temporarily uses signal/slot connections.
      Change-Id: I664f2e333b48b582befd0531a17d4008acac7c4c
      Reviewed-by: Christian Kandeler's avatarChristian Kandeler <christian.kandeler@qt.io>
  27. 24 Apr, 2017 1 commit
  28. 21 Apr, 2017 1 commit
  29. 12 Apr, 2017 1 commit