I don't know if its just my .ini file but on my setup on Debian Unstable and AMD r600g drivers I have not been able to get the desktop cube or expo to show by setting any keybinding as "activate."

EDIT: nothing brings them up with the default, unmodified .ini file either

• Track when a surface is on top of the other and don't get damage from the surface below

• Redraw only damaged parts of the offscreen buffer & later transforms

• Add a way for transformers to specify opaque regions after transform (for example, wf_2D_view without rotation should be able to set opaque region)

This would probably mean more careful rendering and careful usage of wlr_renderer_*()

Sometimes, we want a binding to be triggered over and over as long as a key is being held down (volume buttons), and other times we want it triggered once per key down and key up (run dialog).

Example impl:

[command]
binding_1 = KEY_VOLUMEUP
repeat_1 = true
command_1 = cSH-panel --signal volume-up

binding_2 = <super> KEY_R
repeat_1 = false # This is assumed by default
command_1 = cSH-run-dialog

Test client: swaylock

It seems like it is becoming a widely implemented protocol and there is already an increasing amount of apps using it. This makes it a good addition to wayfire.

This would also need a special protocol for enumerating windows with their title/app_id and requesting actions on them, like minimize/maximize/close, get the icon or similar. Ideally this protocol should be upstreamed to wlr-protocols

Needed by #39, ideally once the protocol has been upstreamed to wlr-protocols

Maybe use this https://github.com/smspillaz/libwobbly ?

Having a tiling support would be quite nice. It should have the following form - each workspace has a tiling and floating layer (the Z order depends on the focused view). We should also support moving views to and from the tiling layer, and add the ability to tile by default.

Some plugins aren't meant to be dynamically loadable/unloadable. Plus, unloadable plugins should be destroyed at then end (for output destruction)

Currently, views are tied to outputs in such a way that makes it impossible to render view on more than one output at a time. This is mostly noticeable when dragging windows from one output to another, the window is cut off until it is on the other output.

This isn't strictly necessary, but improves usability sometimes

So we might create a lockscreen or even try to reuse swaylock

If an offset is set on the expo plugin, animations only go out to the offset and then jump the the completed state

For example, a 3D transform can be used in conjunction with a 2D one (so, switcher should be able to use the window rotation given by e.g wrot). Also, once #20 is done, wobbly might want to extend the 2D transform as well.

There are two ways to do this - render the view with the first transform to an FBO, then render the FBO to a second FBO with the second transform, and so on. This means we could compose any number of transforms, but might mean that they might not really integrate well. And, if we had window exploding (a type of closing animation) its dubious whether we actually want to enable yet another transform.

The other way: 2D(and possibly 3D) transforms are the "base", plugins can request that they are "kept" active (like ref counting), and the transforms can be dynamically converted into a "derived" custom transform (for example wobbly or explosion transform) and then back to a plain 2D or 3D.

Ideally this could happen based on some rules like title, app-id, etc.

These have been ignored for a long time, but it would be good if they can be addressed, as some might cause bugs

Already supported in wlroots, example client: https://source.puri.sm/Librem5/virtboard

Currently, we give the plugins a shared_ptr<>. This causes many problems with ownership:

1. Plugins shouldn't have ownership of the memory, they should use view->inc/dec_keep_count().
2. There are also many lambdas which capture views (shared_ptr's) by value, which means that we leak memory.

A solution would be to use raw_pointers or an observer_ptr<> library (even the std::experimental one if it works across compiler versions), because the actual ownership belongs to the wayfire_core_t class.

Another related problem is the destruction of signal listeners throughout the different shells. They are currently removed in the destructor, but should rather be called when the shell destroy events are fired.

The leak is "quite" small, something like 1-2 MB per rotation

The core and existing plugins are in C++. However, it should be possible to create a wrapper library for C plugins, and thus allowing even using that library in a third language, like Rust.

• Switcher should act just like fast-switch (e.g we don't want to hold it open, in a state where the user is constantly in the switching mode unless he/she presses the activation binding again to close it).

• Switcher should support touch. Currently wayfire has no easy way of switching windows by using only touch

It might also make sense to add gestures and pointer buttons as activators for the command plugin

xdg-shell stable clients should use tiled edges instead of being maximized when a window is tiled to a half or quarter of the screen.

Currently, GTK Windows look broken when tiled to the screen because they are told that they are maximised. In result, elements like shadows are not rendered, and the maximise button behaves incorrectly

In some cases this even leads to the window being moved to a different workspace

• repeat rate/delay

• xkb_options/rules/etc

• touchpad options

• xcursor theme

The grid plugin is currently a mess. It needs a huge rework, and it must support the following things:

1. Support animating more than 1 window at a time
2. Restore the geometry on set_maximized(false) when maximized to any of the slots
3. Change tiled windows' geometry on the reserved-workarea signal

Another possibility is to expand the tiling plugin to tile only specific views and integrate grid and tile. However, this will require much more work to the unfinished tile plugin and possibly goes outside of its scope.

Additionally we need to transition the zoom amount when exiting

Currently this is broken in expo and cube. Should test others as well.

There should be an option to render the whole screen (not like the workspace streams, but the whole output, as the user would see it) to a texture and then allow plugins to do transforms on that.

A few possible use-cases:

1. Desktop zoom-in animation on startup (not just the current fade)
2. Rotation animation like the one Android/iOS have
3. Zoom support - the ability to zoom a part of the screen around the cursor.
4. All kinds of post-processing - color transforms (inversion, black-and-white, others), motion blur and what not.

This would actually be relatively easy to implement. We'd have to add a new type of hook - postprocessing hook. Each one should have a source framebuffer and a target framebuffer, so that they can be composed together - for example, we should have the ability to zoom and have a black-and-white output filter at the same time.

Makes much more sense and is actually better for XWayland windows, where moving the view is not as simple as changing 2 ints.

Consider adding custom data as well

Needed:

1. Install headers
2. Create a .pc file

ASAN reports several leaks, needs investigation

The built-in shell needs a proper event loop and dynamic configuration. On top of that, it'll be nice to have a better architecture for widgets.

This is a regression, and happens for all transforms - 2D, 3D and wobbly.

This would allow users to create simple scripts in the language they prefer. Of course, if #48 is solved, we can just provide bindings to common languages.

The abilities system can still be useful, but the abilities themselves aren't. Plugins should have abilities like:

1. WF_ABILITY_WORKSPACE_IMPLEMENTATION
2. WF_ABILITY_DECORATION_PROVIDER
3. WF_ABILITY_CONTROL_WM

and potentially some others.

This needs some support in core. We have core->set_default_cursor(), but in many cases we need something else, like a grab or resize cursor image.

SSD client support in wayfire will feature in-compositor decorations. Here are some of the tasks left:

• Compositor-drawn surfaces, which support pointer input
• Basic implementation of decorations
• Support kde-decoration-protocol so that we know whether the wayland client needs SSD
• Update decoration title - requires newer wlroots
• Disable/Hide frames for fullscreen surfaces

Our name is wayfire, we gotta do this animation.

This issue is to track the progress of the wlr-wayfire port(in the wlroots branch). Feature development will stop until this is complete, although bugs will be fixed in the libweston version.

• Use meson instead of cmake

• Use wlr_log instead of built-in debugging file

• Add some command line arguments (like --config)

• Separate shell background and shell panel

• Core

  • input-manager

    • keyboard
    • pointer
    • touch
    • tablet - I have no hardware, so it is useless to do this now. If there are users who want tablet, then this can be implemented.

  • render-manager

    • basic rendering with damage tracking
    • workspace_streams

  • workspace-manager

  • basic protocols

    • xdg-shell-v6
    • xwayland

  • output configuration

    • scale
    • rotation
    • coordinates

• Plugins

  • move/resize
  • command
  • autostart
  • rotator
  • screenshot - deprecated in favor of the screenshot protocol, use external utilities like https://github.com/emersion/grim + command plugin.
  • expo
  • grid
  • window-rules
  • vswitch
  • oswitch
  • switcher
  • apps-logger
  • cube
  • animate
  • backlight - deprecated, use external utilities like https://github.com/haikarainen/light + command plugin
  • tile - compiles, "works" but has many bugs, so this is a highly experimental and incomplete plugin