search

Schneegans / Fly-Pie

:pie: Fly-Pie is an innovative marking menu written as a GNOME Shell extension.
http://schneegans.github.io/news/2021/12/02/flypie10
MIT License
1.21k stars 26 forks source link

Support for non-Gnome desktop evironments #22

Closed rolfmorel closed 4 years ago

rolfmorel commented 4 years ago

The Problem

This pie menu looks awesome. The only major problem I see is that it's for Gnome only!

This type of menu would be great for all manner of desktop environments. I myself would be interested in using it without a DE, just with a tiling window manager (i3).

The Solution

Make it not rely on Gnome. I'm not sure how heavy the dependence is. I'm not sure as to the costs of doing this, i.e. what the benefits are of building on top of the Gnome libraries.

The Alternatives

Maybe there is some hack to run Gnome extensions without running Gnome? A cursory search didn't turn up anything.

Schneegans commented 4 years ago

2024 Update:

Kando is pretty much usable by now! If you are interested in a Fly-Pie alternative which is cross-platform, you should try it!

2023 Update:

I am currently working on a platform independent successor project called "Kando"! You can follow and support the development on Ko-fi: https://ko-fi.com/schneegans

Original answer from 2020:

Thanks for the suggestion - a rather obvious one! I described here some of the reasons for making Fly-Pie a GNOME Shell extension. There are some things which are impossible for a normal Wayland client application to the best of my knowledge:

Additionally, I plan to implement opening menus based on the currently focused application (e.g. the same hotkey will open a different menus if you are currently using Firefox, Blender, ...). This wouldn't be possible as well.

Other than that, Fly-Pie does not depend on GNOME. I think it could be possible to use it as a standalone GJS application with some modifications. But it would be severely limited in what it can do. So if you are interested - fork the project and see what can be done!

BTW, if you are using X11, you could try Gnome-Pie, my predecessor project which is quite similar in many aspects. However I will not provide any new features for Gnome-Pie as it cannot work on Wayland.

Edit: Added two new limitations.

ls-1N commented 3 years ago

After reading the news/blog post linked above about this, I personally would find it satisfactory if:

  1. No client side window placement and cursor position polling - The menu always opened in the center of the screen (effectively losing the benefits of a marking menu) or if it is a fullscreen window with mostly transparency (I'm assuming this is not possible in Wayland).
  2. No global input grabbing - As long as I can drag from the spawn point on a touch-screen or with a mouse, I wouldn't mind being able to alt-tab or click on other apps. (I understand this might be a lot of extra work to get the menu even working this way).
  3. No global key bindings - Inconvenient, but workable (could have a wiki page for a list of things a user might want to add as global hotkeys). Or simply manually adding a single hotkey for launching Fly-Pie and that's all.
  4. No client side application management - I'm already used to not having that feature with Gnome-Pie and KDE - either I figure it out how to call commands for KDE's active window (via dbus or simply calling key input after half a second sleep for Gnome-Pie to close its window) or I just remove the menu that isn't working for me.

...as long as it is fast/responsive and modular/configurable. Hypothetically users could develop and share modules to handle a variety of window managers - to handle windows in them and/or import the global hotkeys.

All in all, if it magically would work as the minimum of what I described above - I would try integrating Fly-Pie to my workflows. Practically, I'm not bored enough to work on this myself any time soon (there is faint hope) and I'm not entitled enough to expect the author to spend their awesome hobby project time on a severely cut down version for a niche of potential users.

PR-s and forks and donations speak louder than internet-words.

Schneegans commented 3 years ago

I'll think about this. I also hope that some of these problems will eventually disappear as APIs evolve. For example, we now have gdk_toplevel_inhibit_system_shortcuts(), which can basically be used as a solution for problem number 2.

Problems 1, 3 & 4 could (maybe) be solved with GNOME Shell's DBus interface. Other desktop environments would need special routines....

commonalitydev commented 3 years ago

Thank you for explaining the reasons that it is GNOME-only at this time.

However, like @rolfmorel and @i-need-to-tell-you-something, I would really like to use this program on other desktop environments -- KDE, in my case -- even if it means some of the features that you mentioned would not be available (at least until the necessary APIs become available).

RaitaroH commented 2 years ago

@commonalitydev, @rolfmorel, @i-need-to-tell-you-something I can second your thoughts in regards to using this on other desktops.

If it is useful to you (pretty sure it might, as I am also using it), you may look into easystroke. Unfortunately the original is abandoned, but still works for me (tip: you can use it on touchpad alone by double taping and then drawing the gesture quickly). For wayland there is this fork, but as a Wayfire plugin. Nontheless, I hope for the opensource community will take wstroke and make it work outside of wayfire.

Schneegans commented 2 years ago

Since the question popped up in #227:

A major obstacle for creating a stand-alone version of Fly-Pie is that Fly-Pie uses Clutter for hardware-accelerated rendering. When I started writing this software, I was not aware of the fact that Clutter is not maintained as a standalone library anymore but has rather become an integral part of GNOME Shell. Therefore, a standalone version of Fly-Pie would need to be rewritten using another toolkit (most likely GTK4). And this will be a hell of work! This will take many months to complete - I haven't yet found the courage to start this ;) ... But at some point it should be done...

ghxstweb commented 1 year ago

Hi @Schneegans , any new ideas on the implementation for KDE? Can the graphics be redesigned in Qt, as KDE is a Qt based application environment? I have a fair bit of experience in Qt and C++, so please feel free to let me know how I can be of service.

Schneegans commented 1 year ago

@NIGHTWAV3, thank you very much! I did some tests with Rust/GTK4 but I think that the rendering part will be very complex. Also, Fly-Pie does an aweful lot of pretty desktop-specific stuff (registering global shortcuts, smulating keyboard events, accessing the currently focused application's name) which I would need to implement for each supported desktop environment.

Furthermore I actually want to support Windows (and maybe MacOS) as well. So I recently played around with Electron and I am pleasently surprised. It seems that most required things can be done. Wayland will need special treatment, though. But Electron it will make many things much easier! One key advantage will be that this stand-alone marking menu will be easily extensible by the user. With GTK4 and Rust this would be much harder for the average user...

I'll post an update in the near future on my Ko-fi page.

ghxstweb commented 1 year ago

@NIGHTWAV3, thank you very much! I did some tests with Rust/GTK4 but I think that the rendering part will be very complex. Also, Fly-Pie does an aweful lot of pretty desktop-specific stuff (registering global shortcuts, smulating keyboard events, accessing the currently focused application's name) which I would need to implement for each supported desktop environment.

Furthermore I actually want to support Windows (and maybe MacOS) as well. So I recently played around with Electron and I am pleasently surprised. It seems that most required things can be done. Wayland will need special treatment, though. But Electron it will make many things much easier! One key advantage will be that this stand-alone marking menu will be easily extensible by the user. With GTK4 and Rust this would be much harder for the average user...

I'll post an update in the near future on my Ko-fi page.

Thanks for responding! Would electron be able to have the full flypie experience or would it have to be some other app? i assume the app would have to draw events OVER other applications and have priority over the screen drawing events when the pie menu is toggle, right?

I'd love to help you on your electron project! I've been messing around with the new Pulsar distribution and have picked up a number of things. This would be a great way for me to assist you on things you need with flypie.

ghxstweb commented 1 year ago

@NIGHTWAV3, thank you very much! I did some tests with Rust/GTK4 but I think that the rendering part will be very complex. Also, Fly-Pie does an aweful lot of pretty desktop-specific stuff (registering global shortcuts, smulating keyboard events, accessing the currently focused application's name) which I would need to implement for each supported desktop environment.

Furthermore I actually want to support Windows (and maybe MacOS) as well. So I recently played around with Electron and I am pleasently surprised. It seems that most required things can be done. Wayland will need special treatment, though. But Electron it will make many things much easier! One key advantage will be that this stand-alone marking menu will be easily extensible by the user. With GTK4 and Rust this would be much harder for the average user...

I'll post an update in the near future on my Ko-fi page.

Also, Simon, would you be willing to help me understand what the various .js files do in your program? I've been reading through the Daemon.js, MenuItem.js, and SelectionWedges.js features and they seem incredibly complex for what I had previously believed them to be. You have a number of arc math operations (which I can understand), although I wanted to know more about this "Gio" library and how you communicate to the bus over the Daemon. Also, How exactly do you draw your Cairo/Cogl objects "over" the current applications? Thanks in advance for your time!

Schneegans commented 1 year ago

Would electron be able to have the full flypie experience or would it have to be some other app? i assume the app would have to draw events OVER other applications and have priority over the screen drawing events when the pie menu is toggle, right?

Well, I am currently working on a minimal working prototype in a private repo. Once I feel confident enough, I'll make it publicly available. It already supports drawing something (a red circle :smile:) at the mouse pointer when a global hot key is pressed. This works on Windows, X11 (most likely most Linux distributions), Wayland (for now only on GNOME via an adapter extension), and most likely on macOS (I have no means to test this).

So it will be very similar to Fly-Pie (though I have some differences in mind - for instance it will more focus on application-dependent menus). Yet there will be some limitations: As it opens a transparent window, you won't be able to open it in the overview and (most likely) it will not be able to span over multiple monitors.

Also, Simon, would you be willing to help me understand what the various .js files do in your program?

Have you had a look at this page? Maybe it clarifies a bit.

Also, How exactly do you draw your Cairo/Cogl objects "over" the current applications?

Well, as an extension, Fly-Pie is part of the Shell. I draws elements in the same way as the panel or the overview items are drawn. You can have a look here for some details. But all of this will not be of much help, as you can't use Clutter in a standalone application.

Schneegans commented 1 year ago

I just published some news regarding the platform-agnostic pie menu! At the end of the post, I wrote down some ways how you could contribute to the project. I would be more than happy if you would follow the progress and support the development along the way :smile:

D3vil0p3r commented 1 year ago

I just published some news regarding the platform-agnostic pie menu! At the end of the post, I wrote down some ways how you could contribute to the project. I would be more than happy if you would follow the progress and support the development along the way 😄

Thank you! Is there a way to import configuration files from the current Fly-Pie menu to Ken-Do?

Schneegans commented 1 year ago

I am sure that the settings formats will differ, however implementing an import functionality should be possible.

ghost commented 1 year ago

@Schneegans If FlyPie doesn't work on a normal Wayland display server, then how can it be deployed in GNOME? What is it about the GNOME desktop that makes it feasible on GNOME only? Thanks!

Schneegans commented 1 year ago

Fly-Pie is not a standalone application. As GNOME Shell extensions, it becomes basically a part of the wayland window manager. As such it has much more possibilities than an ordinary client application. Also, it uses GNOME Shell's custom hardware-accelerated library Clutter for rendering the menu which is only available inside of GNOME Shell.

ghost commented 1 year ago

Ah, I see, so it must have some very tight integration with GNOME's window manager. Would Fly-Pie (or even Ken do) work well in XFCE? XFCE doesn't have the GNOME's plug and play extension system, and most of there apps are "hardcoded" for xfce, but xfce is massively lightweight and thus might afford some benefit to the flypie menu functionality and performance

Schneegans commented 1 year ago

As noted here, just try it :wink:

ghost commented 1 year ago

As noted here, just try it wink

Wait, is it already working on KDE? Wow! I need to get started on it. I'll need electron, right? What other dependencies do I need? Thanks!

D3vil0p3r commented 1 year ago

Hey @Schneegans just one question: Kendo will work also for Window Managers like bspwn, i3, Hyprland and so on?

Schneegans commented 1 year ago

Wait, is it already working on KDE? Wow! I need to get started on it. I'll need electron, right? What other dependencies do I need? Thanks!

For now, it's only working in the X11 session of KDE. There are only very few dependencies, everything else is pulled by nodejs. So on debian-based distros this should install all you need:

sudo apt install npm libx11-dev xdotool

Then clone and launch the prototype:

git clone https://github.com/kando-menu/kando.git
cd kando
npm install
npm start
Schneegans commented 1 year ago

Hey @Schneegans just one question: Kendo will work also for Window Managers like bspwn, i3, Hyprland and so on?

Well, I hope so. As long as the window manager is X11-based and supports transparent fullscreen windows, it should work. Wayland-based compositors will require custom backends. I do not have a installation to test this right now... do you have?

D3vil0p3r commented 1 year ago

Currently no, but I can try to set one of it, or I can ask a friend using bspwn.

ghost commented 1 year ago

Currently no, but I can try to set one of it, or I can ask a friend using bspwn.

What is bspwn, and how is it different from x11? Thanks

Schneegans commented 4 months ago

Btw, Kando is pretty much usable by now! If you are interested in a Fly-Pie alternative which is cross-platform, you should try it!