About SpPanelWidgetPresenter window flow #80

New issue

Closed

opened 2026-04-08 12:17:20 +02:00 by ClotildeToullec · 1 comment

ClotildeToullec commented

2026-04-08 12:17:20 +02:00

Owner

To open a presenter in pulsar, we go through #asDockableWindow.

SpAbstractPresenter>>#asDockableWindow
	
	self owner ifNil: [ 
		self error: 'Dockable presenter should have an owner' ].
	
	^ (SpPanelWidgetPresenter owner: self owner)
		presenter: self;
		yourself

Then, in SpPanelWidgetPresenter:

presenter: aPresenter
	"Set the presenter to show as content of the window."

	aPresenter owner: self.
	presenter := aPresenter.
	self initializeWindow

and

SpPanelWidgetPresnter>>#initializeWindow

	super initializeWindow.
	self presenter initializePanelWindow: self

Because SpPanelWidgetPresenter inherits from SpWindowPresenter, we go through:

SpWindowPresenter>>#initializeWindow

	self presenter initializeWindow: self

So, questions:

Why should the presenter have an owner if we replace it with the SpPanelWindgetPresenter?
If the owner is a window, the presenter already went through #initializeWindow: (for nothing?)
Is it intentional to force going through #initializeWindow: with the super initializeWindow call and then #initializePanelWindow:?
If the answer is yes, how should a presenter manage a different behaviors between a initializing a window outside Pulsar and initializing a SpPanelWidgetPresenter?
For example, if the presenter were a moose presenter that usually is owned by a MiWindowPresenter that has a custom API?
Could the call to #initializeWindow: be the default behavior in #initializePanelWindow: instead?

To open a presenter in pulsar, we go through `#asDockableWindow`. ```smalltalk SpAbstractPresenter>>#asDockableWindow self owner ifNil: [ self error: 'Dockable presenter should have an owner' ]. ^ (SpPanelWidgetPresenter owner: self owner) presenter: self; yourself ``` Then, in `SpPanelWidgetPresenter`: ```smalltalk presenter: aPresenter "Set the presenter to show as content of the window." aPresenter owner: self. presenter := aPresenter. self initializeWindow ``` and ```smalltalk SpPanelWidgetPresnter>>#initializeWindow super initializeWindow. self presenter initializePanelWindow: self ``` Because `SpPanelWidgetPresenter` inherits from `SpWindowPresenter`, we go through: ```smalltalk SpWindowPresenter>>#initializeWindow self presenter initializeWindow: self ``` So, questions: - Why should the presenter have an owner if we replace it with the `SpPanelWindgetPresenter`? If the owner is a window, the presenter already went through `#initializeWindow:` (for nothing?) - Is it intentional to force going through `#initializeWindow:` with the `super initializeWindow` call and then `#initializePanelWindow:`? - If the answer is yes, how should a presenter manage a different behaviors between a initializing a window outside Pulsar and initializing a `SpPanelWidgetPresenter`? For example, if the presenter were a moose presenter that usually is owned by a `MiWindowPresenter` that has a custom API? - Could the call to `#initializeWindow:` be the default behavior in `#initializePanelWindow:` instead?

ClotildeToullec added the

question

label

2026-04-08 12:17:20 +02:00

estebanlm commented

2026-04-08 15:59:13 +02:00

Owner

uhm... some answers.

it requires an owner because your pattern is:

myPanelWindow addWindow: somePresenter asDockableWindow.

(same way as you create regular windows as somePresenter asWindow).

to fulfil that pattern you need somePresenter to have an owner. Also, because the POM needs to be always consistent because things can be slightly different depending the POM, e.g. newList can be instantiated as a SpListPresenter in morphic and SpEasyListViewPresenter in gtk.

SIDE NOTE: asDockableWindow is a bad name, from when I started the mapping. I guess it needs to be renamed as asPanelWidget to match its presenter.

the messages (there to override in your presenter as needed) initializeWindow:, initializeDialogWindow:, intiializePopover: and initializePanelWindow: are intented to initialize your "window" (or "window like", as I call both panel widgets and popovers) or presenters than otherwise can be reused in different ways... each one of them adding extra initialization depending on how will you use it.
Said that... you then do not create a SpPanelWidgetPresenter, you create a presenter and then you call asDockableWindow (to be renamed 😛) on it, the process of creating it will call initializePanelWindow: in case you need some extra plugging for them. A typical case is hanging on events that are provided by panel widgets and not windows, e.g.

initializePanelWindow: aPanelwindowPresenter

	super initializePanelWindow: aPanelwindowPresenter.
	aPanelwindowPresenter 
		whenPlacedDo: [ self panelPlaced: aPanelwindowPresenter ];
		whenTransferredDo: [ :ann | self panelTransferredFrom: ann fromWindow to: ann toWindow ]

you can initialize a PanelWidget outside Pulsar (which is an app), but you cannot initialize if not to be used on a PanelWindow (which is the workspace where you place panel widgest)... so, I think this has been explained in the point 2 ?
you do not call intiializeWindow: or initializePanelWindow:, you override them on your presenters and Spec does the calling when needed.

cheers!

ps: please close this issue if the answers are ok :)
pps: tomorrow I will be around, we can do some pair programming to show you how to do it.

uhm... some answers. 1. it requires an owner because your pattern is: ``` myPanelWindow addWindow: somePresenter asDockableWindow. ``` (same way as you create regular windows as `somePresenter asWindow`). to fulfil that pattern you need `somePresenter` to have an owner. Also, because the POM needs to be always consistent because things can be slightly different depending the POM, e.g. `newList` can be instantiated as a `SpListPresenter` in morphic and `SpEasyListViewPresenter` in gtk. **SIDE NOTE:** `asDockableWindow` is a bad name, from when I started the mapping. I guess it needs to be renamed as `asPanelWidget` to match its presenter. 2. the messages (there to override in your presenter as needed) `initializeWindow:`, `initializeDialogWindow:`, `intiializePopover:` and `initializePanelWindow:` are intented to initialize your "window" (or "window like", as I call both panel widgets and popovers) or presenters than otherwise can be reused in different ways... each one of them adding extra initialization depending on how will you use it. Said that... you then do not create a `SpPanelWidgetPresenter`, you create a presenter and then you call `asDockableWindow` (to be renamed 😛) on it, the process of creating it will call `initializePanelWindow:` in case you need some extra plugging for them. A typical case is hanging on events that are provided by panel widgets and not windows, e.g. ```smalltalk initializePanelWindow: aPanelwindowPresenter super initializePanelWindow: aPanelwindowPresenter. aPanelwindowPresenter whenPlacedDo: [ self panelPlaced: aPanelwindowPresenter ]; whenTransferredDo: [ :ann | self panelTransferredFrom: ann fromWindow to: ann toWindow ] ``` 3. you can initialize a PanelWidget outside Pulsar (which is an app), but you cannot initialize if not to be used on a PanelWindow (which is the workspace where you place panel widgest)... so, I think this has been explained in the point 2 ? 4. you do not call intiializeWindow: or initializePanelWindow:, you override them on your presenters and Spec does the calling when needed. cheers! ps: please close this issue if the answers are ok :) pps: tomorrow I will be around, we can do some pair programming to show you how to do it.

ClotildeToullec closed this issue

2026-04-09 15:24:29 +02:00