The icons seem to have gone missing due to the changes in commit b25824e010604f57 and Spec commit 1e0ba07e672b77af: #initializeFor: on TaskbarItemMorph was changed to send #taskbarIconName instead of #taskbarIcon, and the implementation of #taskbarIcon on SystemWindow was replaced by an implementation of #taskbarIconName that sends the same message, but the implementation of #taskbarIcon on SpWindowPresenter was not replaced by an implementation of #taskbarIconName. Implementing #taskbarIconName on SpWindowPresenter as follows restores the icon for a debugger (it’s only a partial fix as it ignores the send of #windowIcon in #taskbarIcon for which there is no equivalent #windowIconName yet):

taskbarIconName

	^ self presenter
		ifNil: [ super taskbarIconName ]
		ifNotNil: #taskbarIconName

Note that the change to #initializeFor: on TaskbarItemMorph in this pull request reverses the use of the FormSet for the icon introduced in pull request #16316.

Thanks for the explanation.

Do you think TaskbarTask should not be the model of the TaskbarItemMorph?
Maybe we could modify TaskbarTask by changing the icon attribute by iconName, and so keeping the usage of FormSet?

I would suggest to maybe first fix the missing #taskbarIconName on SpWindowPresenter and to then check whether it would still make sense to change the model passed to the TaskbarItemMorph.

A change in commit 09f40b6 that is not so clear to me is the removal of the send of #taskbarButtonFor: from #taskbarButtonFor: on TaskbarTask which seems to not take into account that there are other implementations of #taskbarButtonFor: besides the one on SystemWindow. The implementation of #performAction: on TaskbarItemMorph seems to be a copy of the one inherited from PluggableButtonMorph with model replaced by model morph, that may need to be abstracted better.

I try to do this in an image based on the code of #taskbarIcon. But it does not fix the issue.

I would suggest to maybe first fix the missing #taskbarIconName on SpWindowPresenter and to then check whether it would still make sense to change the model passed to the TaskbarItemMorph.

I agree that model morph is strange and we should find a better solution

I updated the code to use only iconName instead of icon and so to use a iconSetForm.

So I imagine that now I can merge?

@badetitou: Regarding your third comment, I’m not quite sure what you tried and why that wouldn’t have worked. Try implementing the following on SpWindowPresenter in Pharo 13 build 97:

windowIconName

	^ self windowIcon ifNotNil: [ :form |
		Smalltalk ui icons icons keyAtValue: form ifAbsent: [ #notFound ] ]

taskbarIconName

	^ self windowIconName ifNil: [
		self presenter
			ifNil: [ super taskbarIconName ]
			ifNotNil: #taskbarIconName ]

This implementation of #windowIconName is a hack (not to be committed!). I’m assuming that, following the changes in commit b25824e010 and Spec commit 1e0ba07e67, the idea is that #windowIcon: should be reworked to #windowIconName: so that #windowIconName would just be an accessor.

One case in which this won’t work is the icon created in #iconForWindow on IceTipGitHubRepositoryPanel. That could be solved by adding it to the ThemeIcons as is done in #iconName for StRewriterMatchToolPresenter. But that seems like a hack as well, it would be better to have those two icons added to the icon pack.

I opened a pull request to add the two icons to the icon pack: pharo-icon-packs pull request #13.