wayfirewm / wayfire Goto Github PK
View Code? Open in Web Editor NEWA modular and extensible wayland compositor
Home Page: https://wayfire.org/
License: MIT License
A modular and extensible wayland compositor
Home Page: https://wayfire.org/
License: MIT License
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
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.
Additionally we need to transition the zoom amount when exiting
Needed:
It might also make sense to add gestures and pointer buttons as activators for the command plugin
Makes much more sense and is actually better for XWayland windows, where moving the view is not as simple as changing 2 ints.
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.
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
Some plugins aren't meant to be dynamically loadable/unloadable. Plus, unloadable plugins should be destroyed at then end (for output destruction)
ASAN reports several leaks, needs investigation
Currently this is broken in expo and cube. Should test others as well.
Needed by #39, ideally once the protocol has been upstreamed to wlr-protocols
Our name is wayfire, we gotta do this animation.
The abilities system can still be useful, but the abilities themselves aren't. Plugins should have abilities like:
and potentially some others.
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)
Currently, we give the plugins a shared_ptr<>. This causes many problems with ownership:
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.
Consider adding custom data as well
Test client: swaylock
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.
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
render-manager
workspace-manager
basic protocols
output configuration
Plugins
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
So we might create a lockscreen or even try to reuse swaylock
These have been ignored for a long time, but it would be good if they can be addressed, as some might cause bugs
The leak is "quite" small, something like 1-2 MB per rotation
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.
This would probably mean more careful rendering and careful usage of wlr_renderer_*()
This isn't strictly necessary, but improves usability sometimes
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
If an offset is set on the expo plugin, animations only go out to the offset and then jump the the completed state
Ideally this could happen based on some rules like title, app-id, etc.
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.
repeat rate/delay
xkb_options/rules/etc
touchpad options
xcursor theme
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
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.
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.
SSD client support in wayfire will feature in-compositor decorations. Here are some of the tasks left:
The grid plugin is currently a mess. It needs a huge rework, and it must support the following things:
reserved-workarea
signalAnother 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.
This is a regression, and happens for all transforms - 2D, 3D and wobbly.
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.
Already supported in wlroots, example client: https://source.puri.sm/Librem5/virtboard
Maybe use this https://github.com/smspillaz/libwobbly ?
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:
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.
In some cases this even leads to the window being moved to a different workspace
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.