Commit Graph

14 Commits

Author SHA1 Message Date
Rachit Keerti Das
a67877f520 dash: Use pin instead of favorites
Use the term 'pin' for adding new items to the dash
Note that this is only a string change.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4976

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2136>
2022-02-07 14:12:04 +00:00
Florian Müllner
414ed9128f appMenu: Support launching on the non-default GPU
Changing the GPU to launch an app on is the last feature from the
app context menu that is still missing. Add support for it now,
and we are ready for some unifying cleanup!

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
bba799a70c appMenu: Remove separator between "new window" and actions
We hide our own "New Window" item if the app itself includes a
"new-window" action. That means that the separator between the
built-in item and desktop actions introduces a small inconsistency
depending on whether a "New Window" item is provided by the desktop
action or ourselves. There's no good reason for that from a user's
perspective, so remove the separator.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
0cde447891 appMenu: Optionally include favorites section
The context menu in the overview includes actions for managing
favorites. Add those to the AppMenu class, but make it another
option as the actions would be slightly weird in the top bar menu.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
e3c06e3c77 appMenu: Update "new-window" item on state changes
Stopped apps can *always* open a new window, so before we start
using the menu for non-running apps, make sure to hide the menu
item as necessary.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
321e07c3c6 appMenu: Only show 'Quit' for running apps
The top bar menu always corresponds to a running app, so it made
sense to include the 'Quit' item unconditionally. That won't be
the case for the overview context menus, so handle app state changes
and show/hide the item as necessary.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
991d9597e0 appMenu: Allow showing the window section for all windows
Since commit fd0da9606f, we only show the "Open Windows" section
if there are at least two windows. That's another subtle difference
with the overview context menus, but while limiting the section to
a minimum of two windows makes sense where the menu always represents
a running app, it is useful to show the section even for single windows
in the dash/app grid.

Account for both uses cases by adding a corresponding option to the
constructor.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
8b1e1834f0 appMenu: Only include non-skip-taskbar windows
There's a subtle difference between the top bar menu and the app
icon context menus in the overview regarding the "Open Window"
section.

The former includes skip-taskbar windows, the latter doesn't. It
clearly doesn't make sense for the context menu to include windows
that aren't shown in the overview, but skip-taskbar windows are
likely also less useful in the top bar menu.

Just settle on the behavior of the context menus and move on.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
c809a87412 appMenu: Do launch animation if supported by source
Likewise any launch actions should animate the corresponding launcher
(if the menu is associated with a launcher).

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
b3861ca693 appMenu: Hide overview when activating apps
This is the expected behavior when activating a window or app. Until
now we could rely on the menu being hidden in the overview, but as
that is about to change, make sure the menu behaves as expected.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
958fb6fddc appsMenu: Add side parameter
In order to re-use the menu in the overview, we must be able to
change the side of the arrow, so expose the parent class parameter.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
0f5881788c appMenu: Delay window sections update when selecting window
App windows are ordered by recency, so a focus change (correctly)
triggers the ::window-changed signal. If we rebuild the section
immediately in response, the activating item will be destroyed
before the menu's ::activate handler, with the result that the
menu remains open.

Defer the section update in that case to allow the menu to process
the ::activate signal first.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
07daa95393 appMenu: Clean up on destroy
For now the menu is only used in the top bar, where we can assume
that it exists "forever". This won't be the case when we start
reusing it elsewhere, so make sure we clean up after ourselves.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00
Florian Müllner
1550976c51 appMenu: Split out from panel
There is a big overlap between the app menu in the top bar and the
context menu of app icons. It makes sense to unify the two both
from a design- and from a code perspective, so split out the more
modern one into a separate module as basis for a shared class.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1948>
2021-08-16 21:28:22 +00:00