Transactions attempt #2

[ammen99]

A second attempt at bringing transactions to Wayfire, as the previous attempts were not successful due to the lack of scenegraph. Plan:

• Update the transactions API with a simpler interface, the old one was overengineered.
• Rewrite xdg-shell views with the new API (without changing view_interface_t)
• Rewrite layer-shell views with the new API (without changing view_interface_t)
• Rewrite xwayland views with the new API (without changing view_interface_t)
• Split view_interface_t into view_t and toplevel_t and update all usages in the codebase

[ammen99]

Major breaking change no. 1: #1309. Explanation:

The current view_interface_t (most commonly used as observer_ptr, i.e wayfire_view) combines multiple view types, which however do not all have the same structure. For example, layer-shell panels don't have minimized, fullscreen, etc. states, neither can/should they be moved or resized by plugins. The view API however did not reflect this.

This PR splits the view_interface_t in two classes: view_interface_t and toplevel_view_interface_t, the latter being a subclass of the former. view_interface_t and wayfire_view now support only querying their app-id/title, view role and adding/removing transformers - operations common for all views.

The derived interface toplevel_view_interface_t and the corresponding wayfire_toplevel_view type contain methods specific to toplevel views, e.g. getting/setting geometry, minimized/tiled/fullscreen state, view children, etc.

Updating plugins is usually relatively straightforward, as most plugins do not care about non-toplevel views anyway:

• Replace wayfire_view with wayfire_toplevel_view in case the plugin deals with toplevel views only.
• Use toplevel_cast to try and convert a wayfire_view to a wayfire_toplevel_view (returns null for non-toplevel views) where needed, for example when querying the active view on an output, since this view might not necessarily be a toplevel view.
• view::get_output_geometry() has been completely removed, because it is usually not the geometry plugins need. In the context of transformers, it is usually better to use the scenegraph bounding box functions, for toplevel views we generally want the wm_geometry. Should the information about the position of the top-left corner of the main surface of a view really be needed, it can be computed as view->get_surface_root_node()->to_global({0, 0}).

[ammen99]

(Relatively) Minor breaking change no. 2: The *_request functions (move_request, tile_request, etc.) have been moved from the toplevel view interface to a new helper class window-manager, which is meant to accumulate window-management operations and requests over time. Adapting plugins is quite straightforward, simply change for example view->move_request() to wf::get_core().default_wm->move_request(view).

[mark-herbert42]

applied the patchset - compiled well finally. the main issue i see so far - animation on close window works terrible. Openin is fine ad smooth, but when closing it closes like skipping the frames - and finally get stuck. A small window (zoom) or transparent window (fade) remains on screen until some activity like mouse move happens. Fire is the only one working OK as the close animation.

[ammen99]

applied the patchset - compiled well finally. the main issue i see so far - animation on close window works terrible. Openin is fine ad smooth, but when closing it closes like skipping the frames - and finally get stuck. A small window (zoom) or transparent window (fade) remains on screen until some activity like mouse move happens. Fire is the only one working OK as the close animation.

@mark-herbert42 The problem should be fixed with the latest commits.

[ammen99]

Major breaking change no. 3: Transactions are finally here. This means some changes in how toplevel view state is handled:

• Toplevel views have a toplevel object associated with them, which can be accessed with toplevel_view_interface_t::toplevel(). Toplevels are transactional objects, that is, they have two states: current and pending. The pending state is that which the compositor wants to apply next, current is what the client has provided the compositor with so far. The pending state is applied atomically and becomes current when the client submits a new buffer. Example:

  • Toplevel is with geometry 100, 100 500x500.
  • Compositor wants to fullscreen it. Pending state of the toplevel is marked as fullscreen with geometry 0, 0 1920x1080. The compositor starts a new transaction. The client is notified of the change, but the current state remains the same.
  • Clients later on submits a new buffer with the requested state. The toplevel object becomes ready (in terms of transactions), and the transaction is applied. Current toplevel state now is also 0, 0 1920x1080 and fullscreend.

• Most plugins only change the state of a single view, for these cases the helper functions move(), resize(), set_geometry() are still available, but they simply set the pending attributes and start a new transaction.

• Plugins that want to change multiple view states at once can also do that by manually creating a transaction and adding all participating toplevels to it.

• Important breaking changes: get_wm_geometry() is to be replaced with either get_geometry() (gets the currently configured geometry of the toplevel) or get_pending_geometry(). fullscreen and tiled_edges can be accessed either directly via view->toplevel().{current,pending}().{fullscreen, tiled_edges} or with the helpers view->pending_{fullscreen, tiled_edges}(). The latter functions work as fullscreen and tiled_edges were used previously.

[mark-herbert42]

now woks perfectly for me, thank you!

[mark-herbert42]

found one issue - when making server-decorated window fullscreen it is full-screened with decorations. Decorations themselves do not show up - but the space is taken and look transparent. last 2 patches in the series did nod fix it so far.

[ammen99]

found one issue - when making server-decorated window fullscreen it is full-screened with decorations. Decorations themselves do not show up - but the space is taken and look transparent. last 2 patches in the series did nod fix it so far.

Thanks for the heads up, I will have to rework decorations (which I will do soon).

[mark-herbert42]

I've dropped using tilda in favor of xfce4-terminal which suits wayland better. But still some windows opening like tiny squares - for example skype. This comes with transaction patches - before that all worked.

[mark-herbert42]

Modified get_margins() in deco-subsurface. I do no feel qualified enough to commit working code as it looks ugly and i bet it is not optimal - but it fixes fullscreen with server decorations.

virtual wf::decoration_margins_t get_margins() override
{
if (!view->pending_fullscreen()) {
return wf::decoration_margins_t{
.left = deco->current_thickness,
.right = deco->current_thickness,
.bottom = deco->current_thickness,
.top = deco->current_titlebar,
}; } else {
return wf::decoration_margins_t{
.left = 0,
.right = 0,
.bottom = 0,
.top = 0,
};
}
}

[ammen99]

@mark-herbert42 I pushed a few updates, can you tell me which of the problems are still reproducible? I hope that decorations at least are fixed now.

[ammen99]

Breaking change no. 4: The decorations API has been changed completely to work with transactions. Key differences:

• There is no more view->set_decoration(), as it was superfluous.
• Decorators are encouraged to listen for new transactions, and if there are toplevels in them, update the margins in the pending state. This way core will know how to resize the windows for this transaction.
• The visual part of the decorations remains as before, since decorations can be simple scenegraph nodes attached when mapping the view.

[mark-herbert42]

Just a question - id it possible in new decoration design wrap decoration it another "decoration" like was done in window shadows plugin? I do not uderstand this transaction topic at all so may have stupid questions... That design was interesting as it allowed to draw shadows over CSD decorated windows as well like telegram-desktop, which is decorated terribly ugly in Wayland (in Xord it can be server-side decorated).

[ammen99]

Just a question - id it possible in new decoration design wrap decoration it another "decoration" like was done in window shadows plugin? I do not uderstand this transaction topic at all so may have stupid questions... That design was interesting as it allowed to draw shadows over CSD decorated windows as well like telegram-desktop, which is decorated terribly ugly in Wayland (in Xord it can be server-side decorated).

It should be possible to decorate a window twice, even though I don't think the results will be very good .. but you could try patching the decoration plugin to ignore the should_be_decorated() property.

[mark-herbert42]

so looks that the best way is to look at should_be_decorated() and if should - do full decoration, else - only paint shadow. So only one decoration (CSD is not a "real" decoration ) will be created, and the appearance will be handled by renderer. Still not sure if i ever be able to code such thing...