1. 20 Oct, 2010 1 commit
  2. 13 Sep, 2010 1 commit
  3. 11 Sep, 2010 1 commit
  4. 24 Aug, 2010 1 commit
  5. 20 Aug, 2010 4 commits
  6. 16 Aug, 2010 2 commits
  7. 10 Aug, 2010 1 commit
  8. 03 Aug, 2010 1 commit
  9. 02 Aug, 2010 1 commit
    • Tobias Hunger's avatar
      Refactor deployment · ee4a04a2
      Tobias Hunger authored
       * Add a DeployConfiguration class to hold settings related
         to deployment.
       * Add BuildStepsList to hold a list of buildsteps
       * Update BuildConfiguration to use BuildStepLists instead of
         manageing lists of buildsteps itself.
       * Update BuildManager to use BuildStepLists in its interfaces
       * Fix fallout introduced by API changes
       * Update .user file to new way of storing settings
      Task-number: QTCREATORBUG-1427
      Task-number: QTCREATORBUG-1428
      Task-number: QTCREATORBUG-1811
      Task-number: QTCREATORBUG-1930
  10. 26 Jul, 2010 2 commits
  11. 22 Jul, 2010 1 commit
    • Pawel Polanski's avatar
      Refactor deployment for Symbian OS · 647b91c7
      Pawel Polanski authored
       * Add buildstep to handle the deployment
       * Remove deployment code from the runconfiguration
       * Update .user files to add new deployment step into existing setups
      Reviewed-by: Tobias Hunger
  12. 14 Jul, 2010 1 commit
    • dt's avatar
      Refactor OutputFormatter · 7862e312
      dt authored
      Move link handling code to outputwindow from OutputFormatter
      Move createOutputFormatter to the RunConfiguration
      That makes it easier for Qt4RunConfiguration et all.
      This also fixes that each time a runcontrol was rerun a new
      OutputFormatter was created without deleting the old one, thus
      increasing the memory usage.
  13. 06 Jul, 2010 1 commit
  14. 02 Jul, 2010 1 commit
  15. 23 Jun, 2010 1 commit
  16. 22 Jun, 2010 1 commit
    • hjk's avatar
      debugger: The DebuggerEngine refactoring. · 6a6cba55
      hjk authored
      This replaces the (de facto) singleton engines and data handlers by classes
      that are instantiated per run. The DebuggerRunControl will now create an
      object of (a class derived from) DebuggerEngine that contains all the relevant
      "dynamic" data.
      DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin,
      whereas the data bits went to DebuggerEngine.
      There is no formal notion of a "current" DebuggerEngine. However, as there's
      only one DebuggerEngine at a time that has its data models connected to the
      view, there's still some "de facto" notion of a "current" engine. Calling
      SomeModel::setData(int role, QVariant data) with custom role is used as the
      primary dispatch mechanism from the views to the "current" data models
      (and the engine, as all data models know their engine).
  17. 14 Jun, 2010 1 commit
    • hjk's avatar
      debugger: start 'runcontrol-ification' of the debugger plugin. · 97edcb79
      hjk authored
      This replaces most uses of DebuggerStartParameters by DebuggerRunControl
      which is a simple RunControl with a DebuggerStartParameters member.
      Plan is to move all global state to the run controls, and possibly
      introduce specialized ones for core debugging etc.
  18. 10 Jun, 2010 1 commit
  19. 21 May, 2010 1 commit
  20. 14 May, 2010 1 commit
  21. 07 May, 2010 1 commit
  22. 03 May, 2010 1 commit
    • dt's avatar
      Add a runMode method to the RunControl · f4ea0d79
      dt authored
      And use it to implement changing the run icon in the application output.
      That implementation does only support the two run modes run and debug
      for now. Further abstraction for more run modes to be done once needed.
      Task-Nr:   QTCREATORBUG-1232
  23. 22 Apr, 2010 1 commit
  24. 19 Apr, 2010 1 commit
  25. 16 Apr, 2010 1 commit
  26. 01 Apr, 2010 1 commit
    • con's avatar
      Agree on a default sis package name. · 1d663484
      con authored
      Instead of renaming it first. We agree on always deploying
      target.sis (where target is the qmake TARGET).
      For older Qt for Symbian versions we rename to match this.
  27. 25 Mar, 2010 3 commits
  28. 23 Mar, 2010 1 commit
  29. 17 Mar, 2010 1 commit
  30. 16 Mar, 2010 1 commit
  31. 11 Mar, 2010 2 commits
  32. 10 Mar, 2010 1 commit
    • dt's avatar
      Use exact and aysnc .pro file evaluate · ab8fc52d
      dt authored
      This is a big change touching almost all of our .pro file parsing.
      With this patch we only evaluate once exact for all needs and once
      greedy for the filelist. That is the qt runconfigurations don't have own
      evaluaters but reuse the project wide exact evaluation.
      We reevaluate if the user changes the build directory, the qmake
      buildconfiguration or the qmake arguments. That is if you open src.pro
      (or projects.pro) of qt with a shadow build you still don't get all the
      files, but after correcting the build directory, we reevaluate the .pro
      files and find all files. So for a suitable definition of fixed, that
      bug is now fixed.
      We now get the exact defines of all .pro files instead of all defines for all
      buildconfigurations. We still don't distinguish in which
      .pro file a DEFINE is set. So the code model now knows about all the
      defines set for the given configuration but not for which files it is
      actually set. Also that includes all DEFINES set in .qmake.cache or the
      mkspecs. This means all defines from .pro files should now work.
      The intial loading is still synchronous. I haven't looked into it to
      deeply, but it seems possible to make it also async.There are probably a
      few issues which need to be solved fist.
      Also due to the asynchronous nature of the code, the executable is
      updated a few seconds after actually changing the build configuration