schneegans / fly-pie

:pie: Fly-Pie is an innovative marking menu written as a GNOME Shell extension.

Note

I am currently working on a follow-up project called 🥧 Kando. I will continue to maintain Fly-Pie until Kando is ready for daily use. If you want to learn more, feel free to visit my Ko-fi page!

Important

The code in the main branch is for GNOME Shell 45+. For older GNOME versions, please use the gnome-3.36-44 branch.

Fly-Pie is an extension for GNOME Shell which lets you open marking menus via keyboard shortcuts. You can use it to launch applications, simulate hotkeys, open URLs and much more.

After the installation, you can open the example menu by pressing Ctrl+Space. Once you opened a marking menu, you can seamlessly transition between three alternative selection modes:

• Point-and-Click: Select items by clicking on them or anywhere in the corresponding wedges.
• Marking-Mode: Select items by drawing gestures. To do this, click anywhere and drag your mouse. Pausing or making a turn selects the currently dragged item.
• Turbo-Mode: You can also "draw" gestures while holding Ctrl, Shift, or Alt without having to press your mouse button! This is especially useful when you opened the menu with a shortcut involving such a modifier.

Do you want to learn more? Have a look at the usage guide!

❤️ Will you love Fly-Pie?

Fly-Pie is designed for you if you have one hand at the mouse most of the time. It is not designed to be used with a keyboard only; there are other applications which work better in this case (for example kupfer). Fly-Pie also works nicely with touch input.

If you want to learn more, use the links below for much more information!

Getting Started

• Installation
• First Steps
• The D-Bus Interface

Contributing to Fly-Pie

• Contributing Guidelines
• Software Architecture
• Translating Fly-Pie
• Creating New Action Types
• Creating New Menu Types

Additional Information

• Changelog
• Release Management
• Continuous Integration

💞 Show that you do love Fly-Pie!

While coding new features or translating Fly-Pie is the most awesome way to contribute, providing financial support will encourage me to invest my spare time for developing free and open-source software.

These awesome people have already donated to the development of my open-source projects:

Do you want to show that you love it too? If you donate via Ko-fi, GitHub, or PayPal, you will show up in this list as well!

fly-pie's Issues

Improve default menu icons

The default menu has some hard-coded icons which seem to be unavailable on some systems. I think the default menu should look good on

• Ubuntu 18.04
• Ubuntu 20.04
• Fedora 31
• Fedora 32
• Pop!_os 20.04

Remove unnecessary Files from the Release-Zip

This is related to #56. We have to assure that the release zip stays below a certain file size limit. I think we could move the CONTRIBUTING.md and the images required for the README.md to a separate docs/ directory which is not included in the zip. This would save ~1.2 MB. We could also remove the README.md from the zip file as we always directly link to the GitHub page anyways.

Do not differentiate between Menus and Submenus

It would be cool if any submenu (like Bookmarks, Devices, Favorites, etc.) could be a toplevel menu on its own. This would require that the menu editor allows dragging any submenus to the top level of the menu hierarchy. This would make the differentiation between toplevel menus and submenus obsolete. There would be only Actions, Custom Menus and Predefined Menus.

Allow drag'n'drop from external sources

It would be great, if desktop-files, URLs and other things could be dragged to the menu editor.

Export/Import configuration settings?

The Problem

I have configured the (great!!! 🚀) Fly-Pie on one of several computers. I'd like to have an "export/import configuration" for the extension... I do not know if it's possible now; I didn't find a straightforward way for now.

The Solution

In Settings, a menu or button that saves all the configurations, and a correspondent menu or button to load a configuration file.

The Alternatives

Re-configure the extension manually on every machine. But I have three of them... ;-)

Add CI Test for application building?

I think it would be beneficial if we had a CI test that would build the extension and check if it builds correctly.

I am not sure how this can be done in a meaningful way (not just replicating .github/workflows/deploy.yml and watch for errors - or is that sufficient?).
Is there a way to examine the created .zip file if everything works as it should and a working extension was produced?

Add Pen Support

The Proposal

This would be fantastic to use with laptops with wacom drivers built-in -- Being able to trigger a menu off of presses from a pen button would be incredible -- It would function much like the s-pen on samsung phones/laptops

The actual menu navigation works decently with a pen, but being able to trigger a menu from the pen buttons would be incredible

Refactoring / Documentation of menu description types

Currently, there are at least three types of JSON-based menu descriptions used throughout the code. This is very confusing! Here they are:

1. The JSON array which is stored in the Gio.Settings string menu-configuration. An example element of this array can be seen in the file settings/DefaultMenu.js. In this description type, each element can have these properties:

   • name: The name of the item.
   • icon: Text, image file, emoji or icon name.
   • type: Refers to one of the types registered in the ItemRegistry.
   • angle: Specifies the fixed angle.
   • children, only for type: 'Menu' and type: 'Submenu': Contains a list of child items.
   • data, only for some types: Contains information used to create an instance of this type, e.g. the shortcut to simulate when the type: 'Shortcut' is activated or the number of items in the type: 'Favorites' submenu.

   In addition, the top-level object (type: 'Menu') has these properties:

   • shortcut: This activates the menu. Something like <Primary>space.
   • centered: true or false, determines whether the menu should open in the screen center.
   • id: A unique identifier. This is required to update the live preview when the menu configuration changes.

   This JSON string is parsed by the Daemon._onMenuConfigsChanged() and stored in Daemon._menuConfigs.

2. In Daemon._openMenu() one of the Daemon._menuConfigs is transformed to a menu structure. This is similar to the one above but elements contain no type or data information but rather an activate() method. The createItem() methods of the ItemRegistry do the actual transformation. It is important to note, that this transformation potentially creates new items: while the menu configuration above only contains one item for type: 'Bookmarks', the menu structure actually contains all of the bookmarks as individual items.

   • name: Same as above.
   • icon: Same as above.
   • angle: Same as above.
   • centered: Same as above.
   • children, either this or activate has to be given: Same as above.
   • activate, either this or children has to be given: Method which is called when the user selects this item.
   • id, optional: This is actually only used in conjunction with 3) (see below). When an item is selected, this ID will be part of the path which is reported over the D-Bus signals.

   This menu structure is then passed to Menu.show(). The menu class then iterates through this hierarchy and creates MenuItems accordingly.

3. The DBusInterface.js accepts an JSON string which is the same as the description under 2), with the exception for the activate() method which is not necessary here.

How can we improve this situation? From a developer's perspective, a good documentation and clear names would make this understandable. From a user's perspective however it seems very confusing that the menu-configuration JSON string (which can be exported from the settings dialog) is something different than the JSON string which is accepted by the D-Bus interface.

Switch menu to current task

Example structure:

Home menu (opens first time you open menu after system reboot)

• Internet
• Youtube
• Photo (editing)
• Video (editing)
• Programming
• Project 1
  ...
• Project N

You select one you want to do now.
And after you call menu next time will open relevant menu.
When you end with this task you should have some way to switch back to home menu.

As solution we need API (terminal command) to change shortcut for menu.

Macros, or multi-key hotkeys

Trying to work in Houdini or other applications which I normally use the wacom software for, on windows or mac, I miss the ability to write macros, or multihotkeys. Example, . So this would hit tab, type wra then hit shift enter. I use this frequently for houdini + wacom pad. Potentially a way also to add a timer between each key, so you could say, hit Tab, wait 1 second, then enter the rest in, etc.

I tried looking around the repo but I am too new to programming to add something like this.

Thanks :D

Add more checks?

When working on the Shell scripts in this repo, I noticed that the shellcheck addon in my VS code complained about some errors/potential issues with the file. This got me thinking about adding some tests.
Do you think we should...

1. ...run shellcheck as part of the tests workflow to ensure nothing bad happens?
2. ...add a functionality test to both shell scripts (check if all files are created correctly, for example; and check the error conditions)?
3. ...add a Markdown linter check?

The last one is often personal taste, I know ;) but I think checking the shell scripts is definitely worth it.

as a little example, here are the errors and warnings that shellcheck throws at me when running it against compile_locales.sh:

$ shellcheck compile_locales.sh

In ./compile-locales.sh line 23:
for FILE in `ls $FLYPIE/po/*.po`
            ^------------------^ SC2045: Iterating over ls output is fragile. Use globs.
            ^------------------^ SC2006: Use $(...) notation instead of legacy backticked `...`.
                ^-----^ SC2086: Double quote to prevent globbing and word splitting.

Did you mean: 
for FILE in $(ls "$FLYPIE"/po/*.po)


In ./compile-locales.sh line 31:
  mkdir -p $FLYPIE/locale/$LANGUAGE/LC_MESSAGES
           ^-----^ SC2086: Double quote to prevent globbing and word splitting.
                          ^-------^ SC2086: Double quote to prevent globbing and word splitting.

Did you mean: 
  mkdir -p "$FLYPIE"/locale/"$LANGUAGE"/LC_MESSAGES


In ./compile-locales.sh line 32:
  msgfmt $FILE -o $FLYPIE/locale/$LANGUAGE/LC_MESSAGES/flypie.mo
         ^---^ SC2086: Double quote to prevent globbing and word splitting.
                  ^-----^ SC2086: Double quote to prevent globbing and word splitting.
                                 ^-------^ SC2086: Double quote to prevent globbing and word splitting.

Did you mean: 
  msgfmt "$FILE" -o "$FLYPIE"/locale/"$LANGUAGE"/LC_MESSAGES/flypie.mo

For more information:
  https://www.shellcheck.net/wiki/SC2045 -- Iterating over ls output is fragi...
  https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...
  https://www.shellcheck.net/wiki/SC2006 -- Use $(...) notation instead of le...

Add Release-Zip-Size-Check

When uploading Fly-Pie 4 to extensions.gnome.org, I received the warning that 4.4 MB is too large. I haven't found any documentation on the allowed maximum but I re-tried the upload without the README-Title-Gif. This resulted in around 3.6 MB which was accepted. So I guess that the limit is around 4 MB (maybe 4096 KB?).

It would be cool if our Check if Fly-Pie builds correctly would check this limit!

Add architecture description

For contributors, it would be great to have at least some basic architecture description. This should contain information on:

• Why is the source code split into three directories?
• What is the data flow when a menu is opened?

Toplevel pie not drawn properly

System: Fedora Workstation 32, Wayland, Gnome Shell 3.36.5

Hi Simon,

I encountered a weird bug on my system, where the toplevel pie is not drawn as intended:

• whenever a toplevel pie is launched, the background is darkened, the wedges are drawn properly, but no pie appears
• moving around the pointer reveals that the pie center will only be drawn as long as it is not hovered over, and disappears whenever the pointer is on it
• its children will only be drawn as long as they are hovered, and disappear again when they are not
• all lower level elements seem to be drawn properly
• this behaviour is persistent with all theme choices, including the light and dark presets
• also, the behaviour is there no matter how the pies are opened
• this happens to the preview pie and the tutorial as well
• in the live preview, after switching the hemisphere once, the toplevel pies are drawn correctly
• the weirdest part: I tried to record the behaviour with the screen capture instead of writing this monsterous text block, but there it appears correctly!

Let me know if you need more information.

Add/Update GitHub Actions

For some time now, I contribute German translations to the GNOME project. Recently, one of my translations failed tests when uploading - I think msgfmt -vc was the command they run when testing the uploaded translations (can't confirm it, I'm not on my coding machine(tm) for the next week). I think this would be cool for us as well!

While I'm at it - do you have ideas for other CI tests we should do? Do any existing tests need updating?
I will start working on it next weekend, so plenty of time to think ;)

Add initial README content

Support for non-Gnome desktop evironments

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.

Calling submenus from the terminal

Hello there, I would like to call a submenu (a custom menu currently contained in another custom menu) using a command in my terminal. Exactly like what is currently possible through

gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/shell/extensions/flypie \
             --method org.gnome.Shell.Extensions.flypie.ShowMenu 'MyMenu'

Is this a possibility? If so, how?

Finalize Preview-Menu

The Preview Menu should contain a proper set of emoji.

How to add comments to translatable Strings?

I am very sorry for being such a noob here, but I would love to help by improving the comments in the .pot file. Since it is generated automatically from settings.ui and other .js files, I wonder how I can add comments to translations.
For the .js files, it's easy - just add a Translators comment. But when I look at the settings.ui file, I don't really know what to do.

Yes, I see the comment="foobar", but sometimes Strings are used more than once. Do I really have to edit the comment everywhere the String occurs in settings.ui? I get the feeling this file is generated automatically. If so, how can I add the comments?

Thanks in advance!

Add Clipboard-Submenu

Gnome-Pie had a nifty action group which stored entries for the n last copied things. It would be cool to have this feature in Fly-Pie as well!

If you want to work on this feature, just drop a note here and I will point you to the parts of the code you should start to work on!

Refactoring of the ItemRegistry

The common/ItemRegistry.js file is very hard to read. It would be better if the individual items would reside in their own files!

Make Fly-Pie usable with "Animations Disabled"

Currently, if animations are globally disabled in GNOME Shell, Fly-Pie is hardly usable. It should be possible to use Fly-Pie even if animations are disabled.

🌐 Translation workflow

Continuation of the discussion from #65.

My latest message over there:

I think you missed the case in which both branches have new translations for different things.

Good catch! Yeah, this is a possible source of problems.

So, basically:

1. Add new features to develop, DO NOT touch po or pot whatsoever (apart from checking if translator comments are handled correctly, but then don't commit the file)
2. When you want to release a new version, you branch develop off to translation (name it whatever you want 😉). While, theoretically, new features can still be merged into this branch, no new strings should be added (aka String Freeze).
3. Commit the result of update-locales.sh to translation
4. Notify translators to get work done
5. Merge translation into master and upload the translated release.
6. Merge master into develop to get the updated translations in the development version.

Illustration (the branch is called release here):

Am I getting this right?

We could also consider removing the po/flypie.pot from the source tree as it can be auto-generated anyways.

When I understood your workflow suggestion above correctly, we could as well keep it and only update it on translation. This makes it easy and accessible to new translators who want to start a completely new language.

What do you think?

Item names cannot contain pango markup

This should be escaped somehow.

Installation Problem

Hi,
I cannot install Fly Pie extension in Fedora 31 and GNOME Shell 3.34.5

Alex

Allow Partial Pie

The Problem

I'd like to use Fly Pie as a mouse-only launcher. So I followed the suggestion in the README and put the activation in hot corner (bottom right). This makes submenus, which are in the direction of the corner, awkward to navigate. 1. because they are so cramped in the corner. And 2. because I have a rather large monitor, so I need to make a large wrist movement to reach the bottom right corner. Then, to navigate to apps/submenus on the right side and at the bottom I need to reset my wrist/mouse. Activating the setting "open in screen center" solves the first problem but not the second one.

The Solution

Allow partial pies. This way I can flick to the bottom right with my wrist to activate the fly pie and flick back (to the top/left) to navigate through it.

The Alternatives

None. The way it is currently, it works, just a bit awkward. So this is really just a minor QoL feature for me.

Value for some settings are cut off (regardless of the window size)

Describe the Bug

See screenshot. Setting: 'Icon scale'

Steps to reproduce the behavior:

1. Go to 'Settings' tab.
2. Click on 'Center Appearance' (for example).

Expected Behavior

Full view of setting.

System

Please complete the following information:

• Fedora 32
• Fly-Pie version: Can't find it in the settings but the current one from extensions.gnome
• Gnome Shell version: 3.36.6

Multiple hotkeys for the same menu

The Proposal

Add multiple triggers for one menu -- I.e. triggering the same menu from ctrl+space and alt+home or something like that

Cancel shortcut selection when clicking with the mouse

To cancel a shortcut selection, it should be possible to click anywhere with the mouse pointer.

Cannot delete items from the menu builder

Describe the Bug

I cannot delete any menu item.

Steps to reproduce the behavior:

1. Go to Fly Pie settings in GNOME Tweaks
2. Click on Menu Editor
3. Select item to delete
4. Click "Ok" button in confirmation dialogue

Expected Behavior

I expected the menu item to be deleted.
I expected the cancel button to close the dialog.

System

• Linux distribution [Pop!_OS 20.04 LTS]
• Fly-Pie version [Installed from GNOME Extensions on Sep 4 2020]
• Gnome Shell version: [3.36.3]

Move some content from README.md to the docs/ directory

In another project I did it like this: https://github.com/cosmoscout/cosmoscout-vr/tree/develop/docs

I think we should use a similar approach for Fly-Pie. And yes, several parts of the README.md should be moved to the docs directory! I think that only the "About Fly-Pie" section and an additional "Getting Started" section is required.

Originally posted by @Schneegans in #78 (comment)

Add more contribution documentation

For contributors it would be great to have guides on how to create new action or menu types. Templates like this could help:
#28 (comment).

Presets get overidden when extension is updated

We shouldn't store any user-generated data in the extension directory itself. I think the best would be to show a warning if the user tries to save the preset in the built-in directory...

Hide menu on escape-button-press

Adding "Main menu" crashes the extension

Describe the Bug

If I add the "Main menu" to the Example Menu,
then the menu does not show up anymore.

journalctl /usr/bin/gnome-shell | grep flypie -B 2 -A 2
JS ERROR: TypeError: invalid assignment to const `icon'
pushMenuItems@/home/bruno2/.local/share/gnome-shell/extensions/[email protected]/common/ItemRegistry.js:526:39
pushMenuItems@/home/bruno2/.local/share/gnome-shell/extensions/[email protected]/common/ItemRegistry.js:553:15
createItem@/home/bruno2/.local/share/gnome-shell/extensions/[email protected]/common/ItemRegistry.js:572:7
_transformConfig@/home/bruno2/.local/share/gnome-shell/extensions/[email protected]/daemon/Daemon.js:283:49
_openMenu@/home/bruno2/.local/share/gnome-shell/extensions/[email protected]/daemon/Daemon.js:175:20
ShowMenu@/home/bruno2/.local/share/gnome-shell/extensions/[email protected]/daemon/Daemon.js:132:17
Daemon/this._shortcuts<@/home/bruno2/.local/share/gnome-shell/extensions/[email protected]/daemon/Daemon.js:60:31
Shortcuts/this._displayConnection<@/home/bruno2/.local/share/gnome-shell/extensions/[email protected]/daemon/Shortcuts.js:42:15

Expected Behavior

I expected the Example Menu to show up with a new "Main Menu" sub item.

System

• Fly-Pie version 2 ?
  • Installed from https://extensions.gnome.org/extension/3433/fly-pie/
  • Cannot find any "About" tab with this info
  • Found "version: 2" in metadata.json ...
• Gnome Shell version: 3.36.5
• Fedora 32

Make some GtkPopovers automatically disappear

While playing around with glade, I noticed that the preset-popover and the item-application-popover do not disappear when an item is chosen from the list, unlike the item-type-popover that is shown when the user adds an item to a menu.

IMO, it would be a better experience when these two popovers would disappear once an item is selected. What do you think?

Improve touch-pad support

Currently, Fly-Pie is quite awkward to use with a touch-pad. This is mostly because dragging things with a touch-pad is slow and error-prone.

I suggest the following which would work well for menus opened with a shortcut: As long a modifier button (Ctrl, Alt, Shift, ...) is held down, the menu acts as if the left mouse button was pressed. This way, a menu can be opened and an item can be selected only by moving the pointer by mouse or touch-pad as long as a modifier is pressed.

Super Key does not seem to count as a modifier key

Not sure if this should be considered a bug or feature request but considering that the super key is almost universally considered as a modifier key, I will lean on the former in this case.

As an example use case, I want to use Super+e to invoke a pie menu and I want turbo mode to be enabled as long as I hold down the super key.

Make text-icons use the configured font and color

When an menu item shows text instead of an icon, this uses a black Sans font now. I think it should rather use the same font and color as the center item.

If you want to work on this feature, just drop a note here and I will point you to the parts of the code you should start to work on!

Start of the names in bookmarked folders...

The Problem

When I use the "bookmarked folders" menu, there are anonymous folders shown. I know that if I hover over them I'll see the name in the central folder icon, but this is a bit slow (I change often the bookmarks, so I'll not learn by muscle memory where they are...)

The Solution

Add a small text in the bookmarks with the first few letters of the name, like this:

The Alternatives

I'll learn where they are ;-)

Application window error

Describe the Bug

![bug]
(https://user-images.githubusercontent.com/60853630/92095104-ed1ede80-eddd-11ea-92fd-832c0eec339e.png)

Steps to reproduce the behavior:

1. Go to 'Menu structure'
   2.Select the emoji Click on 'backspace'
2. See error

Please complete the following information:

• Fly-Pie version [2]
• Gnome Shell version: [3.36.5]

Add System-Submenu

We could add a submenu with some of the entries from GNOME Shell's panel menu:

• Settings
• Lock Screen
• Log Out
• Suspend
• Power Off

Suggestions for Improving "Running Applications" pie menu

It would be nice to have an option to preview windows when hovering your cursor over their respective slices.

It would also be great to automatically group Windows of the same application (or possibly custom class) as their own submenus. I often have quite a few different windows for my browser for example so it can get a little crowded.

Italian translation update

Due to some changes in the code base, the Italian translation needs an update. Most importantly, there is no differentiation between top-level menus and submenu anymore. In most strings they are now both called "menu".

@albanobattistella, could you do this? Then we're close to releasing Fly-Pie 4!

Add multi monitor support

Hello, first - a great extension, but i have found a bug/feature request

Describe the Bug

When laptop connected to second monitor, fly-pie can't recognize one window resolution properly.

• menus sometime are not visible when opened in top area of screen smaller screen.
• gray background covers only part of screen. Seems like screen height is calculated from small screen and background is painted starting from bigger screen (Y axis)
  sometimes bug looks different

Steps to reproduce the behavior:

1. Connect second monitor
2. Move cursor to top area of smaller screen
3. Open menu
4. Choose sub-menu above general menu
5. Icons are displayed in not visible area of screen.

Expected Behavior

I think program should calculate position of mouse on the screen, and get current screen resolution to properly calculate UI area.

System

• Fly-Pie version 2
• Gnome Shell version: 3.36.4
• System: Ubuntu 20.04

Monitor configuration

Left smaller laptop screen: 1366x768, right bigger monitor 1920x1080

Add German translation - What to translate?

Heyho!
This looks very cool! 👍
I would like to contribute a German translation, but I have absolutely no idea where to find the Strings that need translating.
Could someone maybe point in the right direction?

Simplify addition of new action types

Adding new Actions and Menus to the source code is quite complicated as the UI file needs to be adapted as well. If the new Action requires as data something which we already have (text, command, URL, file, etc,..) this should be re-usable. It should be possible for the action to define the two labels above the data field in the settings dialog.

Add default menus

When no menus are configured, some default menus should be provided.

Add proper presets

There should be only a few, but good-looking presets.