SDL2 host: Click on an unfocused space doesn't dispatch a click event

[tinchodias]

This doesn't happen in Morphic host, and the following steps show this seems to be the behavior of SDL2, as I traced low-level events as they come from the SDL2 event loop: @ELePors

1. Add in the block closure of OSSDL2Driver>>#processEvent: this sentence: Stdio stdout << mappedEvent asString; lf; flush.
2. Evaluate in a Workspace:

spaceA := BlSpace new.
spaceB := BlSpace new.

{ spaceA. spaceB } do: [ :each |
	each root
		addEventHandlerOn: BlClickEvent
		do: [ :evt |
			each root background: Color random.
			evt traceCr ].
	each extent: 100 asPoint.
"	each useMorphicHost."
	each show ]

3. Result:

Screen.Recording.2026-02-02.at.16.29.35.mov

[tinchodias]

Good news, there is a way to enable the expected behavior:

https://github.com/libsdl-org/SDL/blob/99eca2ca0d1386a0c6ab983a2fee5413a5cd081c/include/SDL_hints.h#L1566-L1576

It worked on Mac: Insert self setHint: 'SDL_MOUSE_FOCUS_CLICKTHROUGH' value: '1'. in SDL2 class>>#initLibrary.

[tinchodias]

Expected behavior:

Screen.Recording.2026-02-02.at.17.30.06.mov

[tinchodias]

Full code for SDL2 class>>#initLibrary:

initLibrary
	Session == Smalltalk session ifTrue: [ ^ 1 ].
	"Configure SDL2 in 'application mode', to let the screen to turn off on inactivity.
	 But we let the user to restore 'game mode' on screen, by using #disableScreenSaver"

	self initPlatformSpecific.

	self
		setHint: SDL_HINT_VIDEO_ALLOW_SCREENSAVER value: '1';
		setHint: SDL_HINT_NO_SIGNAL_HANDLERS value: '1';
		setHint: SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH value: '1'.

	self init: SDL_INIT_NOPARACHUTE.
	Session := Smalltalk session

Better example, to test also click position is right:

spaceA := BlSpace new.
spaceB := BlSpace new.

{ spaceA. spaceB } withIndexDo: [ :each :index |
	each root
		addEventHandlerOn: BlClickEvent
		do: [ :evt |
			each root addChild: (BlElement new
				position: evt position;
				background: Color random;
				extent: 5 asPoint;
				yourself).
			evt traceCr ].
	each extent: 100 asPoint.
	each position: (100 * index) asPoint.
	each show ].

Recording:

firstclickpositions.mov

[tinchodias]

This fix would impact Pharo, not only Bloc, as it is a change in SDL2 initialization. I'm in favor of dispatching the focus-gain click (Let's call this click the "focus-gain" click). But I would like to know opinions, for the case there is some argument against it.

For example, I observe that in Mac file browser, the focus-gain click doesn't change the selected item in the list (i.e. it is selected on the "second" click like currently on Pharo) . On the right, Pharo has the HINT ENABLED:

Screen.Recording.2026-02-02.at.17.50.23.mov

However, the buttons on top of the file list do handle the on-focus click:

Screen.Recording.2026-02-02.at.18.00.30.mov

[tinchodias]

The file browser in Windows 11 behaves different than Mac's file browser: the items in the file list ARE selected with the focus-gain click. This is a point in favor of enabling SDL_MOUSE_FOCUS_CLICKTHROUGH.

[tinchodias]

I observe the same behavior in the Gnome's file browser in my Debian 12: the items in the file list ARE selected with the focus-gain click. Another point in favor of enabling SDL_MOUSE_FOCUS_CLICKTHROUGH

[ELePors]

I agree with you the "focus click" shall be forwarded... if the application does not want the focus click active it shall call a test to the focus state which should be false ... will it be the case ?

in fact the "focus click" shoud be forwarded or dispached to the application before the focus state change...

[tinchodias]

@ELePors yes, you are right. The Bloc handler could register the focus gained event and then consider that information in the click handler.

(My screen recording in Mac OS, you get first the "focus gain event" and the click comes afterwards:)

[tinchodias]

This would be fixed by pharo-project/pharo#19302 in Pharo 14, and may be back-ported to Pharo 13

[tinchodias]

This is fixed on Pharo 14. We have to decide if it's backported to Pharo 13 as well.