The RenameFolderMenu uses the internal box as a menu item, while PopupMenu
expects to have PopupBaseMenuItem based children with a delegate set.
Instead of using a custom menu with a customized box acting as menu
item,just add a RenameFolderMenuItem that inherits from the parent,
adjusting the features as we need them. In fact, the rename folder menu item
doesn't need any label, padding or default styling so we can reuse
PopupMenuBaseItem after we use our styling properties and we set the
Ornament to HIDDEN.
To get the proper style in place, define rename-folder-popup and
rename-folder-popup-item to override the default popup-menu-item rule
padding instead of using margins.
Pass the menu item as menu's focusActor as this will key-focus it on pop-up,
by overriding the key_focus_in() vfunc we can then delegate the focus
handling to the entry's clutter-text.
Also override the map() vfunc in order to update the entry's content before
mapping the entry.
Finally, use the item's activate method in order to tell the parent menu
we're done with it and that the menu can be closed.
As consequence we can also remove the menu's popup() method, and just use
the default open().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/720
When the rename folder menu is opened the text entry is expected to be
focused and selected for a quick editing.
While this is required it doesn't actually happens since PopupMenu by
default gives the key focus to the source actor, that is then free to pass
the key focus to the menu if there's an user interaction.
In this case however, we want the text entry to be focused once we prompt
the menu, so just use the PopupMenu's focusActor property to ensure it will
handle it for us.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1604https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/720
Add a `animateLaunchAtPos()` method to the AppIcon class to animate the
launch of an app at a given position. This allows for a visual
indication of whether dropping an app icon using DnD was successful at
the position the drop happened in a later commit.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
`AppIcon.shellWorkspaceLaunch()` can easily be replaced by checking for
`AppIcon.app` and calling `AppIcon.app.open_new_window()` directly.
For compatibility and to prevent breaking extensions implementing the
function, keep supporting the `shellWorkspaceLaunch` API in AppIcon
while logging a deprecation warning. Also keep supporting the API on
drag sources (without deprecating it) to allow extensions to define
custom actions on their drag sources.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
As arrow functions have an implicit return value, an assignment of
this.foo = bar could have been intended as a this.foo === bar
comparison. To catch those errors, we will disallow these kinds
of assignments unless they are marked explicitly by an extra pair
of parentheses.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/731
We are currently inconsistent whether to put the operators in front
of the corresponding line or at the end of the preceding one. The
most dominant style for now is to put condition and first branch on
the same line, and then align the second branch:
let foo = condition ? fooValue
: notFooValue;
Unfortunately that's a style that eslint doesn't support, so to account
for it, our legacy configuration currently plainly ignores all indentation
in conditionals.
In order to drop that exception and not let messed up indentation slip
through, change all ternary operators to the non-legacy style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/725
Some more places where the indentation doesn't comply with either
the old or new style. They slipped through because the legacy eslint
configuration accounts for some patterns by plainly ignoring certain
nodes. We'll address that later, first fix up the indentation errors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/725
We currently use no less than three different ways of indenting
object literals:
let obj1 = {
foo: 42,
bar: 23,
};
let obj2 = { foo: 42,
bar: 23 };
let obj3 = { foo: 42,
bar: 23
};
The first is the one we want to use everywhere eventually, while the
second is the most commonly used "legacy" style.
It is the third one that is most problematic, as it throws off eslint
fairly badly: It violates both the rule to have consistent line breaks
in braces as well as the indentation style of both regular and legacy
configurations.
Fortunately the third style was mostly used for tween parameters, so
is quite rare after the Tweener purge. Get rid of the remaining ones
to cut down on pre-existing eslint errors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
Add a new popover with a regular entry + button to rename
folders. The layout is similar to other GNOME applications.
The popup is implemented as a PopupMenu subclass, leaving
the grab management to PopupMenuManager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/675
Create a new folder when dropping an icon over another
icon. Try and find a good folder name by looking into
the categories of the applications.
Delete the folder when removing the last icon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/671
Because the Dash icons are not drop targets themselves,
add a tiny DashIcon class, which is an AppDisplay.AppIcon
subclass, and disable all DND drop code from it.
Show a folder preview when dragging an app icon over another
app icon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/671
As per design direction, scale and fade the app icon
when starting dragging it, and show it again if the
drop is accepted. Clutter takes care of animating the
rest of icon positions through implicit animations.
Scale and fade the dragged icon while it's being dragged.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/671
Just as we animate the apps launch using the zoom out animation if the
'new-window' action provided by the app is launched, we should also show
this animation if the 'activate-discrete-gpu' action provided by the app
via its AppInfo is launched.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/673
For the "New Window" entry we add to the AppIcons popup menu we should
always animate the app icon if the menu entry is activated as it was
intended by commit 62786c09a8.
For the "Launch using Dedicated Graphics Card" entry we can also always
show the animation if the entry is activated since the entry should only
be visible if the app is stopped.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/673
We add our own "New Window" menu entry if the app doesn't already
provide a 'new-window' action. For this menu entry, we show the zoom out
animation on the app icon when the user clicks the entry.
To be consistent in case the app already provides its own 'new-window'
action via its AppInfo, also show the zoom out animation when this
action is activated.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/662
App icons inside folders are already animated when the folder is
opened, but moving an app icon from a folder doesn't, making the
transition abrupt.
Fortunately, it's easy to detect icons that were previously hidden
but are not anymore.
Add an animation to these icons when showing.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/664
This is necessary for being able to drag application icons
to folders in different pages.
Add a drag motion handler to AllView and handle overshoots
when dragging. Only handle it when dragging from AllView.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/664
After dropping an application into the folder icon, the
list of applications is updated but the folder icon itself
is not.
Introduce BaseIcon.update() and call it from FolderIcon
when redisplaying.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/664
The event blocker is an actor that is added in between the
icon grid and the app folder popup in order to guarantee
that clicking outside the app folder will collapse it.
However, the next patch will require allowing dragging events
to be passed to folder icons, and the event blocker gets in
our way here, preventing drag n' drop to work properly.
Add an API to inhibit the event blocker. This API will be
used by the app folders while an item is dragged.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/664
Commit 0f178c3b3d added a shortcirtuit to avoid running
an animation on an invisible actor. However, it introduced
a bug where the current page is not properly updated. That
leads to the wrong set of icons being animated under some
circumstances.
Update the current page even if we bail out early.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/667
We now have everything in place to replace Tweener for all animatable
properties with implicit animations, which has the following benefits:
- they run entirely in C, while Tweener requires context switches
to JS each frame
- they are more reliable, as Tweener only detects when an animation
is overwritten with another Tween, while Clutter considers any
property change
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
Now that redisplaying is a lightweight operation that only
adds and removes what changed, we can not be concerned about
redisplaying on folder changes.
Redisplaying will be necessary when custom order in the app
grid is implemented, in order to update not only which icons
are hidden, but also their position.
Call _redisplay() in AllView when folders change.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
FolderView and AllView currently check if the item is
present in the BaseAppView._items map, in order to avoid
adding the same icon multiple times.
Now that BaseAppView._loadApps() has a different role --
it returns a list with all app icons, and BaseAppView
diffs with the current list of app icons -- checking the
BaseAppView._items map is wrong.
Make sure there are no duplicated items in the temporary
array returned by all _loadApps() implementations. Remove
the now unused BaseAppView.hasItem() method.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
BaseAppView currently removes all icons, and readds them, every
time the list of app icons needs to be redisplayed. In order to
allow animating app icon positions in the future, however, we
cannot destroy the actors of the app icons.
Previous commits paved the way for us to do differential loading,
i.e. add only the icons that were added, and remove only what was
removed.
Make the BaseAppView effectively implement differential loading.
The BaseAppView.removeAll() method is removed, since we do not
remove all icons anymore. BaseAppView._loadApps() now returns an
array with the new apps, instead of putting them directly at the
BaseAppView lists.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
Next commit will introduce differential loading of
app icons, and will reorganize this part of the
codebase.
When doing that, the ideal symmetry of the new code
would be:
* Update BaseAppView._allItems array
* Update BaseAppView._items map
* Update BaseAppView._grid actor
Move the code in _loadGrid() into _redisplay() so that
we can check in-place which new icons need to be added.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
Now that the three views follow the exact same loading routine
(remove all + load apps + load grid), we don't need each view
call loadGrid() directly anymore.
This is an important step in order to animate adding and removing
icons, since now we can diff old and new app icons properly.
Move all calls to BaseAppView.loadGrid() to a single one after
BaseAppView._loadApps(). Also add the underscore prefix, since
this is now considered a protected function.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
FrequentView is another view that is slightly not unified with how
BaseAppView expects subclasses to load app icons. Instead of using
BaseAppView.addItem() and then calling BaseAppview.loadGrid(), it
adds the app icons directly to the icon grid.
Make FrequentView add icons using BaseAppview.addItem(), and load
the icons using BaseAppView.loadGrid().
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
Future patches will diff the old and new icons of views, in order to
animate them when necessary (e.g. adding an app icon to a folder, or
from a folder back to the app grid). In order to do that, all views
must be streamlined in how they load app icons.
Currently, FrequentView and AllView are already following the behavior
expected by BaseAppView, but FolderView isn't. Its icons are loaded by
FolderIcon, and FolderView doesn't implement BaseView._loadApps(),
which makes it impossible to diff old and new apps.
Move the app icon loading routine from FolderIcon to FolderView, by
implementing the _loadApps() method.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/645
The different units - seconds for Tweener and milliseconds for
timeouts - are not a big issue currently, as there is little
overlap. However this will change when we start using Clutter's
own animation framework (which uses milliseconds as well), in
particular where constants are shared between modules.
In order to prepare for the transition, define all animation times
as milliseconds and adjust them when passing them to Tweener.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/663
AppIcon makes itself draggable, and handles the various DnD
routines such as 'drag-begin' and 'drag-end' by making the
Overview emit the appropriate signals.
However, when destroyed, the AppIcon does not try to finish
any drag operations that started. That causes the event
blocker in AllView not to be updated correctly when dragging
icons to outside folders.
Make AppIcon emit 'item-drag-end' when a drag operation
started and it's destroyed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/643
While we aren't using those destructured variables, they are still useful
to document the meaning of those elements. We don't want eslint to keep
warning about them though, so mark them accordingly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
Those unused arguments aren't bugs - unbeknownst to eslint, they all
correspond to valid signal parameters - but they don't contribute
anything to clarity, so just remove them anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
