Skip to content
Snippets Groups Projects
  1. Oct 29, 2010
  2. Oct 18, 2010
  3. Oct 15, 2010
  4. Oct 13, 2010
  5. Oct 11, 2010
  6. Oct 06, 2010
  7. Oct 05, 2010
  8. Oct 04, 2010
  9. Sep 28, 2010
  10. Sep 21, 2010
  11. Sep 13, 2010
  12. Sep 08, 2010
  13. Sep 01, 2010
  14. Aug 12, 2010
  15. Jul 14, 2010
  16. Jul 07, 2010
  17. Jun 25, 2010
  18. Jun 22, 2010
    • hjk's avatar
      debugger: more breakpoint management related fixes · fadac800
      hjk authored
      fadac800
    • hjk's avatar
      c5c0dc76
    • hjk's avatar
      debugger: properly clone breakpoints · b01a622f
      hjk authored
      b01a622f
    • 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
  19. Jun 11, 2010
  20. May 20, 2010
Loading