1. 27 Jun, 2017 1 commit
  2. 16 Jun, 2017 2 commits
  3. 12 Jun, 2017 1 commit
  4. 30 May, 2017 1 commit
  5. 15 May, 2017 1 commit
  6. 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>
      3624a663
  7. 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>
      112e3222
  8. 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
      Intialized->[Starting->Running->Stopping->Stopped->]*->Finished.
      
      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>
      2360a2d7
  9. 11 Aug, 2016 1 commit
  10. 26 Jul, 2016 1 commit
  11. 25 Jul, 2016 1 commit
  12. 22 Jul, 2016 1 commit
  13. 05 Jul, 2016 1 commit
  14. 14 Jun, 2016 1 commit
  15. 10 Jun, 2016 1 commit
  16. 06 Jun, 2016 1 commit