VDBThreadGroupPresenter.st
author Jan Vrany <jan.vrany@fit.cvut.cz>
Fri, 27 Feb 2015 13:19:41 +0100
changeset 35 f6e4876af2e7
parent 34 cda31dfd5386
child 38 9b861cb882c8
permissions -rw-r--r--
Fix in debugger console: properly handle errors Must signal that command completed and nil-out outstanding command caches even if command endup with an error

"{ Package: 'jv:vdb' }"

VDBModelPresenter subclass:#VDBThreadGroupPresenter
	instanceVariableNames:'threadGroup'
	classVariableNames:''
	poolDictionaries:''
	category:'VDB-Presentation'
!

!VDBThreadGroupPresenter methodsFor:'accessing'!

icon
    threadGroup isRunning ifTrue:[ ^ VDBIconLibrary threadGroupRunning16x16 ].
    threadGroup isStopped ifTrue:[ ^ VDBIconLibrary threadGroupStopped16x16 ].
    threadGroup isDead    ifTrue:[ ^ VDBIconLibrary threadGroupTerminated16x16 ].
    ^ nil

    "Created: / 22-09-2014 / 22:13:03 / Jan Vrany <jan.vrany@fit.cvut.cz>"
    "Modified: / 30-09-2014 / 00:55:06 / Jan Vrany <jan.vrany@fit.cvut.cz>"
!

label
    ^ threadGroup displayString

    "Created: / 22-09-2014 / 00:14:26 / Jan Vrany <jan.vrany@fit.cvut.cz>"
!

threadGroup
    ^ threadGroup
! !

!VDBThreadGroupPresenter methodsFor:'initialization'!

setThreadGroup: aGDBThreadGroup
    threadGroup := aGDBThreadGroup

    "Created: / 21-09-2014 / 23:38:56 / Jan Vrany <jan.vrany@fit.cvut.cz>"
! !

!VDBThreadGroupPresenter methodsFor:'protocol-accessing'!

fetchChildren
    "should compute the list of children via the model.
     Be aware, that the somewhat stupid 'optimization' of how the model is fetched may lead to
     a O(n*log n) or even O(n^2) behavior here.
     *** to optimize: redefine by subClass"

    ^ threadGroup threads collect:[ :t | VDBThreadPresenter new setThread: t; parent: self ]

    "Created: / 21-09-2014 / 23:41:57 / Jan Vrany <jan.vrany@fit.cvut.cz>"
! !

!VDBThreadGroupPresenter methodsFor:'testing'!

isThreadGroupPresenter
    ^ true

    "Created: / 21-09-2014 / 23:54:23 / Jan Vrany <jan.vrany@fit.cvut.cz>"
! !