It would be cool to have a component for input number like in HTML5.

It would accept only numbers and would have two arrows to go up or down.

MenuSpec API should be sync a bit more with MenuMorph and MenuItemSpec

I have the impression it could help the users of Spec to get a visual information about what is a presenter.

I propose to change the icons of the presenter like this:

Objections?

The name of the adapter is duplicated in the hierarchy of leaf presenters. We can remove this duplication.

Maybe we should have a ListPresenter>>#whenSelectedItemChanged:ifNoItemSelected: as well to manage correctly the case when no item is selected and not having nil provided as argument to the Block.

And hacks like:

ListPresenter new
	items: #(1 2 3 4 5);
	setSelectionStateFor: 1 at: true;
	setSelectionStateFor: 3 at: true;
	setSelectionStateFor: 4 at: true;
	changed: #listElementAt:
	openWithSpec.

do not work.

There is this piece of code in the spec interpreter but I checked with the tools in the image and all the tests, if there is a string here, it is always #model.

(aFragment isString or: [ aFragment isText ])
		ifTrue: [ 
			^ aFragment == #model
				ifTrue: [ self presenter ]
				ifFalse: [ self convertSymbolOfClassToInstance: aFragment ] ].

We can simplify the code

See for example DiffPresenter or TableContainerPresenter.

Currently, #aboutTitle uses #respondsTo: to check if a tool defines a specific tool name.

Instead of this, we could implement a #toolName method directly on the abstract presenter of Spec.

I added the possibility to use spacers in layouts. We should add a demo of it.

We currently can use #model in the layouts to target the current presenter. Since all Models were renamed Presenter we should update that to be able to use #model and #presenter the time everyone migrates.

I think current mechanism is very restrictive.
Can we think in a better one?

I think we may benefit a lot by using slots instead populating all presenters with value holder objects all around.
Yes, this is just a way to "hide" the behaviour. But having a property slot will make everything cleaner.

All subclasses of the abstract spec bindings have a method #defaultFont

IMO it's not the responsibility of the adapter bindings to know the font.

Anyone thinking like that?

I the CI often get some error saying that taskbarIcon was not understood by smallinterger.

I cannot reproduce on my laptop.

I'll probably do a fake PR with logs.

https://pharo.manuscript.com/f/cases/reopen/20501/Strange-that-ComposableModel-initialExtent-returns-nil

I have the impression that ComposablePresenter>>windowIcon is just a duplication of Object>>taskbarIcon mechanism.

I propose to deprecate it.

Do we really need it?

In the SpecInterpreter there is this code:

selector isArray
		ifFalse: [ selector := selector asSymbol.
			numArgs := selector numArgs.
			args := arrayToInterpret copyFrom: index + 1 to: index + numArgs ]
		ifTrue: [ "Here I assume that if it's not a symbol, it's a collection"
			| array |
			array := selector.
			selector := array first.
			numArgs := 0.
			args := array allButFirst ].

But in all tests and interfaces present in the image, the selector is never an array. I'll remove this check and add an assertion to point to this issue if one day we get an array.

I'll do a first PR with some cleaning for the spec interpreter.

SpecInterpreter returns instances of SpecWrapper but I have the impression this is useless.

I'll do a PR to remove it and I would like someone with some Spec knowledge (Esteban?) to review it.

We have presenters for the menu but apparently, they might return directly a Morph after the building.

Currently, all tests are in one package. Do we really want only one?

It can remove a lot of useless code from the interpreter to remove it.

I'll do a PR to remove multiple dead code and variables

This implementation:

registerKeyStrokesForNextFor: aWidget

	aWidget ifNil: [ ^ self ].
	
	self eventKeyStrokesForNextFocus do: [:each |
		aWidget bindKeyCombination: each toAction: [ self giveFocusToNextFrom: self ] ]

Assumes "widget" is a Morphic widget.
While we can demand that api from any component we use, I think this violates proper layering.

Maybe we should kick this into the adapter?
Or we just accept is like that?

Don't forget the deprecation to not break current UIs

There is currently some tests that are not packaged in a test package. Check UIThemeDecoratorTests.

The current interpreter needs to be improved. Maybe we could get a new implementation.