1. 07 Jul, 2017 1 commit
    • 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>
  2. 27 Jun, 2017 1 commit
  3. 16 Jun, 2017 2 commits
  4. 12 Jun, 2017 1 commit
  5. 30 May, 2017 1 commit
  6. 15 May, 2017 1 commit
  7. 10 May, 2017 1 commit
  8. 09 May, 2017 1 commit
    • Ulf Hermann's avatar
      QmlProfiler: Fix flame graph context menu test · a6c3b576
      Ulf Hermann authored
      The context menu event can be generated multiple times within one loop
      of QTRY_VERIFY. The result is that multiple showFullRange() signals can
      be generated before we check again for spy.count() == 1. Thus, the check
      never succeeds and the number of signals keeps growing.
      We connect the showFullRange() signal to the model manager in order to
      get a more realistic test setup. This way the action that generates the
      showFullRange() signal is disabled in any further context menus, just as
      it is supposed to be. In addition we can now check for the manager to
      actually show the full range.
      Change-Id: I5e13c2666ce1a15c7a5fad57affd4274d9656656
      Reviewed-by: Christian Stenger's avatarChristian Stenger <christian.stenger@qt.io>
  9. 24 Apr, 2017 1 commit
    • Alessandro Portale's avatar
      Reduce usage of qApp in favor of static function calls · 3624a663
      Alessandro Portale authored
      Q*Application classes have unusually many static functions. In many
      cases in our code, these functions are unnecessarily called as instance
      functions, using the qApp helper.
      This patch replaces many occurencies of qApp with the according
      Q*Application classname.
      Change-Id: I6099a419fa7bf969891269c37ed7a9e817ef5124
      Reviewed-by: default avatarhjk <hjk@qt.io>
  10. 05 Apr, 2017 1 commit
    • hjk's avatar
      ProjectExplorer: Merge AnalyzerRunControl into RunControl · 112e3222
      hjk authored
      The change is "conceptually wrong", the AnalyzerRunControl derived
      classes' functionality should be provided by ToolRunners based classes
      encapsulating/"being" the current Analyzer*Runner classes.
      However, the AnalyzerRunControl is only three (empty even) virtual
      functions, but a big obstacle in merging attempt due to a lot of
      mechanical followup changes in downstream users.
      The current construction mechanism of analyzer run controls is actually
      two different mechanisms (locally direct RunControlFactories, and a
      "generic" createAnalyzerRunControl wrapper for remote cases). The generic
      createAnalyzerRunControl makes it difficult to migrated them one-by-one,
      due to the various downstream users.
      So instead of merging the per-analyzer two uses directly reduce
      the "indirection" distance by removing the AnalyzerRunControl
      intermediate layer. After that the createAnalyzerRunControl mechanism
      can be dissolved by using normal RunControlFactories also for
      the remote cases. After that, porting to ToolRunner, and combining
      with ther local equivalent can be done one by one.
      Change-Id: I0ddace33fcce210cf3a547ac5bb23b3d85013934
      Reviewed-by: Ulf Hermann's avatarUlf Hermann <ulf.hermann@qt.io>
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
  11. 03 Apr, 2017 1 commit
  12. 24 Mar, 2017 1 commit
    • hjk's avatar
      ProjectExplorer: Run RunControl::{start,stop} always asynchronously · 2360a2d7
      hjk authored
      This introduces a mini-state-"machine" to handle RunControl states
      Needing time between trying to start and getting feedback is nowadays
      the normal setup for all remote targets as well as for most local tools.
      Making that the default for all runs simplifies the code and provides an
      opportunity to (a) fix some currently wrong reports of "stopped
      immediately" and (b) to remove target-specific (WinRT) or tool-specific
      (Valgrind, GammaRay) state members doing essentially the same.
      Change-Id: I7f52fee41144188ee8389e922fdc265f8c0a6459
      Reviewed-by: David Schulz's avatarDavid Schulz <david.schulz@qt.io>
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
  13. 24 Feb, 2017 1 commit
  14. 22 Feb, 2017 1 commit
  15. 15 Feb, 2017 2 commits
  16. 10 Jan, 2017 2 commits
  17. 04 Jan, 2017 1 commit
  18. 19 Dec, 2016 1 commit
  19. 24 Nov, 2016 1 commit
  20. 10 Nov, 2016 1 commit
  21. 27 Sep, 2016 1 commit
  22. 11 Aug, 2016 1 commit
  23. 08 Aug, 2016 1 commit
  24. 05 Aug, 2016 2 commits
  25. 26 Jul, 2016 2 commits
  26. 25 Jul, 2016 2 commits
  27. 22 Jul, 2016 2 commits
  28. 20 Jul, 2016 2 commits
  29. 14 Jul, 2016 1 commit
  30. 13 Jul, 2016 3 commits