[wip] wl: Add CogWlPlatform::resized-window signal

[psaavedra]

The resized-window signal is emitted when the window is resized.

Handling this signal allows to react to changes in the geometry of the window and decouples the CogWlView from the CogWlPlatform internal logic.

The view (or the views in the future) is now connected to this signal and reacts according.

This change is motivated towards the progress of being able to have more than one view.

DEPENDS ON: #625

[aperezdc]

I have doubts about this...

Handling this signal allows to react to changes in the geometry of the window and decouples the CogWlView from the CogWlPlatform internal logic.

This is changing how internal parts of the Wayland platform plug-in interact with each other. As this is all internal, it is okay for the code to rely on internals from some other parts of the code. In this particular situation, we do not need to avoid coupling 🤔️

The view (or the views in the future) is now connected to this signal and reacts according.

This change is motivated towards the progress of being able to have more than one view.

Why is this needed when there is more than one view? You say multiple views motivate the change, but don't explain why in the commit message.

Wouldn't it be enough for each viewport/window to track the list of CogViews it can display, and notify them about the resizing directly?

Why is a signal concerning a viewport/window attached to the CogPlatform class? In my mind, it does not belong there, but rather it should be in a belongs in a new CogWlSurfacetype, which contains thewl_surface` used to display web view contents and all the related functionality.

[psaavedra]

I have doubts about this...

Handling this signal allows to react to changes in the geometry of the window and decouples the CogWlView from the CogWlPlatform internal logic.

This is changing how internal parts of the Wayland platform plug-in interact with each other. As this is all internal, it is okay for the code to rely on internals from some other parts of the code. In this particular situation, we do not need to avoid coupling 🤔️

I don't think. Actually the logic remains untouched. Just that now the resize of the window uses the signal mechanism instead of doing explicit calls to the cog_wl_platform_resize_window()

The view (or the views in the future) is now connected to this signal and reacts according.
This change is motivated towards the progress of being able to have more than one view.

Why is this needed when there is more than one view? You say multiple views motivate the change, but don't explain why in the commit message.

... this comes from the exploration done here in the PR Extend the Multiple Views support on Wayland. Since we are going to have 1-to-many relationships we are going to transitioned naturally to a events-signal logic to avoid repetitive for-each loops.

Wouldn't it be enough for each viewport/window to track the list of CogViews it can display, and notify them about the resizing directly?

Ditto.

In the future it will make things easier. It reduces the complexity of the code as it defines well an event and the responsibility to react to the event (this applies from just one View or to a doxens of them).

Of course, this change could be done by just calling the cog_wl_view_resize_window() at https://github.com/Igalia/cog/pull/620/files#diff-7342248ee4ad822cd294d9c8341a52fd10b3d1df4dd2a202ccb926df67d51034R223 directly, instead of emitting the signal.

Precisely, it is the signal what decouples the Platform from the View in the sense of the Platform notifies that the geometry of the window has changed, but it is not the platform's responsibility to know what to do or how to do the internals (calls to wpe_view_backend_* functions).

Why is a signal concerning a viewport/window attached to the CogPlatform class? In my mind, it does not belong there, but rather it should be in a belongs in a new CogWlSurfacetype, which contains thewl_surface` used to display web view contents and all the related functionality.

Yes, I agree, the natural place would be something like the ViewPort/ViewGroup/Stack or even Window ... but right now it is CogWlPlatform the one acting as the View container since there is not yet a ViewPort/ViewGroup/Stack implemented. The signal will be moved to this container later.

Having said all this if you prefer. I can just just ignore the signal-event change until the ViewPort/ViewGroup/Stack is implemented and just call cog_wl_view_resize_window(). I've created this new PR for this idea: wl: Move cog_wl_platform_resize_window() to View as cog_wl_view_resize()

[psaavedra]

Discarded for now