Execute inUIProcessDo: when even there is no process

[labordep]

The method BlElement>>inUIProcessDo: aBlock cannot value block when there is no uiProcess (nil).
This is the case when I'm writing basic unit tests.
I think it should be great to value block in all cases.
This can be use to build from the same way a BlElement inside or outside the graphic tree.

A fix can be:

inUIProcessDo: aBlock
	"Run the supplied block in the UI process.
	If the active process is already the UI process, evaluate immediately. 
	Otherwise, queue up for the next frame."

	| uiProcess |
	self isAttachedToSceneGraph ifTrue: [ 
		self space host uiProcessDo: [ :uiProc | uiProcess := uiProc ] ].

	(uiProcess  isNil or:[ uiProcess = Processor activeProcess ])
		ifTrue: [ aBlock value ]
		ifFalse: [ 
			self enqueueTask: (BlTaskAction new
					 action: aBlock;
					 yourself) ]

[labordep]

@tinchodias @plantec do you have an opinion?

[tinchodias]

Hello Pierre. I've found the diff! you suggest changing the if receiver from uiProcess = Processor activeProcess by (uiProcess isNil or:[ uiProcess = Processor activeProcess ]). I don't realize on my head what's the effect / why it fixes your test.

I imagine you are testing on a space that's not open, right? I mean, you didn't send show to it (+ wait afterwards so it has effect).

I always considered this API as a patch/workaround to be removed one day (I don't know its origin, it was already there).

I have the impression the API exists because of "low-level" graphics libraries that have global state that is broken if you do the FFI calls from Pharo from different Processes (the C library is not aware of them, it just has a global state). In particular, I think this happens in https://freetype.org/.

[labordep]

This is very practical for write some graphic tree edition code. Sometimes you create something that is not already open in a Space (for example initialization of graphic resources) and sometimes you are editing objects that are display on a Space. With this method (and my suggestion) this is transparent. This is difficult for dev to learn and use the concept of "if I edit an object that is show I need to do that on a bltask", I see mistakes about that every days and we have concurrency access problem.

[plantec]

I agree with Martin. this seems to be a workaround

[plantec]

this kind of facility can be overused very easily. it can lead to bad effect on performance because a task can be launched on each use

[labordep]

But this is not possible to edit BlElement without bltask without concurency risk, I dont see the difference.

[plantec]

ok, I understand the context. But in that case, use a task explicitly