1. 25 May, 2016 1 commit
  2. 19 Jan, 2016 1 commit
  3. 03 Sep, 2015 1 commit
  4. 16 Jan, 2015 1 commit
  5. 09 Oct, 2014 1 commit
  6. 06 May, 2014 1 commit
  7. 08 Jan, 2014 1 commit
  8. 28 Aug, 2013 1 commit
  9. 18 Feb, 2013 1 commit
  10. 01 Feb, 2013 1 commit
  11. 29 Jan, 2013 1 commit
  12. 05 Oct, 2012 1 commit
  13. 19 Jul, 2012 1 commit
  14. 03 Apr, 2012 1 commit
  15. 29 Mar, 2012 1 commit
  16. 22 Mar, 2012 1 commit
  17. 16 Mar, 2012 1 commit
  18. 15 Feb, 2012 1 commit
  19. 26 Jan, 2012 1 commit
  20. 23 Nov, 2011 1 commit
  21. 16 Nov, 2011 1 commit
  22. 03 Nov, 2011 1 commit
  23. 30 Sep, 2011 1 commit
  24. 01 Sep, 2011 1 commit
  25. 08 Jul, 2011 1 commit
  26. 06 May, 2011 1 commit
  27. 13 Apr, 2011 1 commit
  28. 16 Mar, 2011 1 commit
  29. 12 Jan, 2011 2 commits
  30. 17 Dec, 2010 3 commits
  31. 15 Nov, 2010 1 commit
    • hjk's avatar
      debugger: Refactor breakpoint handling. · 8ae541b3
      hjk authored
      The breakpoints are now (fairly) tightly guarded by the BreakpointHandler.
      Engines and Views are only supposed to refer to them by id. They also have
      individual states now. The breakpoint data is split into a "user requested"
      "fixed" part in BreakpointData and the engines' acknowledged data in a new
      struct BreakpointResponse.
      
      TODO: Move m_state and m_engine members to BreakpointResponse. Fix regressions
      in the marker handling.
      8ae541b3
  32. 10 Nov, 2010 1 commit
  33. 08 Nov, 2010 2 commits
  34. 02 Nov, 2010 1 commit
  35. 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).
      6a6cba55
  36. 16 Apr, 2010 1 commit