| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=747773
|
| |
|
|
| |
Found with cppcheck.
|
| | |
|
| |
|
|
| |
This code is not used anymore.
|
| |
|
|
|
|
|
|
|
|
| |
We removed it accidentally in the port to GAction due to the
bad naming of the functions.
Add a TODO for implement a better named functions to not be confused
again.
https://bugzilla.gnome.org/show_bug.cgi?id=746392
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We removed the menu item to delete permanently and instead always
allow the shortcut <shift>Delete to do so, thinking that move
to trash will be always available.
The problem is that trash is not supported on some systems, and the user
can be confused if there is no way to delete the item on the menu.
To fix that, still allow always to delete permanently with the shortcut
and show the menu item only when trash is not available.
https://bugzilla.gnome.org/show_bug.cgi?id=748692
|
| |
|
|
|
|
|
|
| |
So the user can open a folder in a different app.
This is useful in cases like IDEs or text editors
for entire projects.
https://bugzilla.gnome.org/show_bug.cgi?id=691479
|
| |
|
|
|
|
| |
Until patch on bug 748805 is accepted or we figure a different recommended way,
we have to select the entry after showing the dialog, since the entry selects
all the text on focus, withouth taking into account previous selection.
|
| |
|
|
| |
As per mockups
|
| |
|
|
|
|
| |
As we allow to open them with the default app, but in this
case we have to ensure all selected files can be opened by
a single app.
|
| |
|
|
|
| |
Now that we use a dialog, we can remove lot of hacks we had
for in place renaming.
|
| |
|
|
|
|
|
|
|
| |
So we do something similar than for the new folder dialog.
Also we were using gtk_dialog_run, but that implies the main
thread is blocked, so it's not a good option for applications
with multiple windows.
Instead connect to the response signal of the dialogs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces the "New Folder"
dialog, which asks the folder name before
actually creating it.
With the introduced changes, the folder
is created with the given name instead
of creating it first with the generic
"Unamed folder" and then renaming it.
The dialog has a "delayed message" logic,
where typos are immediatly recognized, but
coincident folder names appear ~2s later.
This dialog is part of the ongoing effort
to modernize Nautilus to better fit GNOME
standards, and the latest mockups can
be found at [1].
[1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/nautilus/nautilus-next/create-folder-wires.png
https://bugzilla.gnome.org/show_bug.cgi?id=747381
|
| |
|
|
| |
This reverts commit 6f4fc647917364e0b86e6f485efca9d70bbe21f2.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces the "New Folder"
dialog, which asks the folder name before
actually creating it.
With the introduced changes, the folder
is created with the given name instead
of creating it first with the generic
"Unamed folder" and then renaming it.
This dialog is part of the ongoing effort
to modernize Nautilus to better fit GNOME
standards, and the latest mockups can
be found at [1].
[1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/nautilus/nautilus-next/new-folder.png
https://bugzilla.gnome.org/show_bug.cgi?id=747381
|
| |
|
|
|
|
|
|
|
|
| |
In 3.15.90, selecting two (or more) files and right-click > “Open with another
application” silently fails to open the application-chooser dialog. So what we
want here is hide that menu item when the selection is bigger than 1 item.
https://bugzilla.gnome.org/show_bug.cgi?id=745898
Signed-off-by: acgtyrant <acgtyrant@gmail.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before 3.15 we had a setting for adding a menu item for permanent
deletion of files. But the shortcut was always enabled no matter the
state of the setting, which seems inconsistent.
Then with the GAction port we changed that behavior to be consistent,
but people that were unaware of the setting were complaining that
the shortcut for permanent deletion was not working.
Given that we show a dialog if we hit that shortcut, and the setting
itself is confusing, just enable always the shortcut but remove the
setting and the menu item for it.
https://bugzilla.gnome.org/show_bug.cgi?id=745321
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now the "move-to-trash action" was disabled while in the trash,
and only the "delete" action was enabled. This had the problem that
that action was used for the "delete permanently" menu item, which its
visibility relies on a setting and uses a different shortcut than
move-to-trash.
To allow the user to use the delete shortcut in the trash as well
create a new action so we can control the visibility and the shortcut
differently than the Delete Permanently and rename the actions to make
it more clear.
This is a fallout of the menus rework, from the clean up of the
actions.
|
| |
|
|
|
|
| |
This commit is a simple clean up of a harmless code
that adds twice the Shift + Delete shortcut for the
same action.
|
| |
|
|
|
| |
This commit fixes the regression introduced with commit bb884cb61 where
the new folder shorcut was mistakenly removed.
|
| |
|
|
| |
They have runtime type checking.
|
| | |
|
| |
|
|
|
|
|
| |
Now that we changed the shorcut for move to trash to Delete, we need
to inform the user when he tries to use the old shorcut.
We allow to disable the dialog for next times with a checkbutton in
the dialog.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Store the entire state in the action. The toolbar will be called to
update the state anyway...
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
No need to have subclasses override this.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Make this simpler to follow. Also handle the case where a submenu
defines an item with the same name as one of the above menus.
|
| |
|
|
|
|
| |
Make sure that, although extensions can use the same action name,
they are unique appending the index of the extension to the action
name plus the menu name.
|
