Tooltip model is based on blockClosure outside context

[Nyan11]

The tooltips in are managed by the trait TToElementWithTooltip.

When you add a tooltip, you use one of the following methods:

• tooltipString:
• tooltipText:
• tooltipContent:

All the methods use the tooltipContent:.
Here is the source code of tooltipContent:.

tooltipContent: anElement

	anElement ifNil: [
		self removeTooltipWindowManager.
		^ self ].
	self tooltipBuilder: [ :win :requestEventt |
		win root addChild: anElement ]

anElement here is the BlElement we want to display in the tooltip.
The element is not added directly in a "tooltip model" but as an outter context variable of a blockClosure.

• It make it difficult to try to work with tooltip.
• It is hard to understand what is the tooltip of an element using only the inspector.
• It make it difficult to retreive information about the tooltip.

The advantage of having a BlockClosure is that you can generate on the fly the content of the tooltip.
This effect could be achieve by adding new event for tooltip:

• An event that is trigger just before the tootltip is shown.
• We could add an event that trigger after the tooltip is hidden in order to manage the destruction of the generated content.

[plantec]

the benefit of current implementation is that is is stateless
one can store the element in the user data maybe

[Nyan11]

Why being stateless is a benefit ?

[plantec]

the trait is used by ToElement level as TToElementWithContextMenu so, I guess one have to limit the number of inst variables for a ToElement.

[plantec]

" The advantage of having a BlockClosure is that you can generate on the fly the content of the tooltip. "
yes, exactly

"This effect could be achieve by adding new event for tooltip:
An event that is trigger just before the tootltip is shown.
We could add an event that trigger after the tooltip is hidden in order to manage the destruction of the generated content."
I don't get what you mean

[Nyan11]

I try to explain 2 things:

first

What i try to explain is that you could have the same on the fly generation with events.
If you have an event that is trigger before the popup become visible, you could use the event to modify the content of the popup.

Pros of using events is:

• You have BlEventHandler to manage and not the BlockColsure (BlockClosure are difficult to manage in Pyramid and to serialize).
• I personnaly found the API more explicit with an object than BlockClosure.
• The developper is limited in what he can do with a dedicated object (You can do everything in blockClosure, source of bugs)

Cons of using events is:

• It is longer and more verbose to write down a BlEventHandler than a BlockClosure.

If we choose to use BlEventHandler to manage the tooltips we could add events when the tooltip is not yet visible, when the tooltip is visible, when the tooltip is about to be hidden and when the tooltip is hidden.

You could use all this event to manage the panel inside the tooltip.
For example:

• Modify on the fly the panel.
• Create a form that is validated only when the tooltip is hidden.
• Generate and destruct object only when the tooltip is shown.
• Request the focus inside the tooltip when open.
• ...

second

The current implementation of tooltip in Toplo relies on BlockClosure with an outside context.

tooltipContent: anElement

	anElement ifNil: [
		self removeTooltipWindowManager.
		^ self ].
	self tooltipBuilder: [ :win :requestEventt |
		win root addChild: anElement ]

anElement is a reference inside the BlockClosure ( [ :win :requestEventt | win root addChild: anElement ]) and also the arguments of the method (tooltipContent: anElement).

This create high complexity for Pyramid or serialization.

Conclusion

I really do not like the BlockClosure, it is difficult to manage with the serialization and with Pyramid.

I personally think that a block closure add hidden states to the UI that cannot be seen while reading the code.

I would like to have simple Object with a simple API to manage my UI and not a BlockClosure that can do everything.

But maybe there are strong arguments in favor of BlockClosure that i do not see yet.

[tinchodias]

@Nyan11 what are the serializer(s) that Pyramid uses to serialize?

I'm analysing a possible solution in Fuel using "clean" blocks. But not sure if you use Fuel.

[Nyan11]

Hello,

I used a custom one that generate executable code: https://github.com/Nyan11/Stash
It is inspired from STON.

Currently i only check if the block closure is clean before serializing it.
If it is not, i raise an Error.

[tinchodias]

Stash looks nice! But I only saw it in the web browser. I guess I have to load Pyramid to see it in action.

[Nyan11]

If you want to use it without loading Pyramid, you will need https://github.com/OpenSmock/Bloc-Serialization
Bloc-Serialization contains all the methods needed to serialize with Stash and Ston the BlElement and their properties (except for the grid layout that is still mssing).

Once loaded, you can open a new space with BlElement inside, inspect one of the BlElement and modify it using the inspector.
For example:

BlElement new
background: (BlPaintBackground new
paint: (BlColorPaint new
color: (Color r: 1.0 g: 0.0 b: 0.0 alpha: 1.0);
yourself);
opacity: 1.0;
yourself);
border: (BlBorderBuilder new
paint: (BlColorPaint new
color: (Color r: 0.0 g: 1.0 b: 0.0 alpha: 1.0);
yourself);
width: 7;
build);
yourself

You have a similar project for Toplo: https://github.com/OpenSmock/Toplo-Serialization