| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
A code clean up that will make things easier for the next patch
where we will use a template for the window
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 91bb18fe23dd12f31bb63d702c6b5cb31670649f.
It needs to be sensitive so it's focusable and selectable for users and
for A11y.
gtk+ selects automatically the label on focusing the tab, so for fixing
it we will need to do some tricks that would probably better be
fixed/discussed inside gtk+.
|
| | |
|
| | |
|
| |
|
|
| |
Don't create a delete notification if the user cancelled the operation.
|
| |
|
|
| |
Currently it gets selected, but it should be insensitive.
|
| |
|
|
|
| |
Seems this is a silly change I did while doing the port to test things
and I forgot to change it again to the original behaviour.
|
| |
|
|
|
|
|
| |
The query editor is hidden if the size of the window is less than
a certain value because it has not enough space for it.
So make sure all widgets are visible setting a minimum width.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were grabbing the focus on view mode change, so if the user changed
the view mode with keyboard he could continue using it.
But it makes the problem that with the new popover menu in the toolbar
where you can choose between different views while the menu is open,
grabbing the focus to another widget dismiss the menu, which is
against the behavior of the GtkMenuPopover.
To fix that, don't grab focus on view changes.
In the tests I have done, you can still focus the view just using the
arrows after the view changes, so I don't think it will be a problem for
keyboard users.
https://bugzilla.gnome.org/show_bug.cgi?id=743591
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=743630
|
| |
|
|
|
|
|
|
|
|
| |
Now that we have an in app notification, the user has a feedback if
they push Delete key as an accident. So we no longer need to make
the move to trash action difficult to do.
So change the accelerator of move to trash from <shift>Delete to
just Delete
https://bugzilla.gnome.org/show_bug.cgi?id=743630
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to make sure the user has feedback when moving files to trash,
so add an in app notification when some file has been moved to trash.
Currently the notification manager only supports one notification at
once, since the undo machinery only support to undo the last operation,
not a specific operation.
Even if we add support to it I'm not sure if multiple notifications of
deleted files would be good, so instead of that just show one at once.
To achieve that, connect to the undo state and delete all notification
when the undo state changes and create the new notification if the undo
operation is "move to trash" and if the undo manager state is "undo".
https://bugzilla.gnome.org/show_bug.cgi?id=743630
|
| |
|
|
|
|
| |
We will use it for in app notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=743630
|
| | |
|
| | |
|
| |
|
|
|
| |
Even if the singular form is never used, we have to put the
sentence in singular for the singular form for ngettext
|
| | |
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=743557
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
It's useful to differentiate files from different folders with
the same name. That's a common problem that we hit in the normal
nautilus search.
But it's easily fixable for the shell provider search, adding the path
as a description.
https://bugzilla.gnome.org/show_bug.cgi?id=743715
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
For context menus we update menus on a timeout. For the cases of
the toolbar afaik that's not needed so we update directly.
The schedulers for the context menu has a protection against updating
if the view is destroyed or not active.
Apply that protection to the update of the toolbar so we don't crash
if we call it while destroying.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Currently the main GtkBox of the view menu has spacing for its sections,
but we actually want only spacing for each separator, so there is not
separation between radio items, but there is space between each section.
So just replace the box spacing for margin in each separator.
|
| |
|
|
|
|
|
| |
Commit 1968379a2e2dc7e601a0379856c05da5ed04d01d changed the code here to
use the new names for icon sizes, but not consistently.
https://bugzilla.gnome.org/show_bug.cgi?id=743651
|
| | |
|
| | |
|
| |
|
|
| |
To match mockups.
|
| |
|
|
| |
To match mockups.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously when using GtkMenuItem, setting NULL to a label of a menu
item was not a problem, although it was a bug anyway since the
label was present as empty.
We were doing that with the Undo and Redo labels on the toolbar.
Now with GMenuItem it was crashing when deleting more than a file since
the label was NULL and the menu item couldn't be created.
To fix it, make sure we always set a label for the trash delete job.
|
| | |
|
| |
|
|
|
| |
Store the entire state in the action. The toolbar will be called to
update the state anyway...
|
| | |
|
| |
|
|
| |
This way we can avoid directly poking at the toolbar.
|
| |
|
|
|
| |
They are shared between different views - and windows actually. So it
makes more sense for them to live here for now.
|
| |
|
|
|
| |
Currently we always reload the menu from scratch and reset the menu
button; the intent of the code here is to modify the menu in-place.
|
| |
|
|
| |
We were not freeing the strings coming from the undo manager.
|
| | |
|
| | |
|
