| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently, the tooltip says 'Toggle view', which isn't clear.
Usability testers had difficulty finding out how to change between
list and grid view.
Change tooltip to say 'Show list' or 'Show grid', depending on which
view it can change to.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/issues/893
|
| |
|
|
|
|
|
|
|
|
|
| |
The view exports the background extensions and templates menu models for
consumption by the pathbar. They are exported as GMenu.
However, the consumer is not supposed to modify the menu, which is what
the GMenu API is for. Also, it needs to cast to GMenuModel everytime.
To make this clearer and cleaner, cast to GMenuModel at the point when
the GMenu API is not going to be used anymore.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
One of the benefits of the new menu on the path bar buttons is that we
show the background menu.
This was the intended design since the start, but we didn't come to
finalize it earlier on.
Now with the 3.30 approaching, this work implements that.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/405
|
| |
|
|
|
|
| |
So they can be accessed easily from outside the view or window-slot.
This is useful for preventing layer violation, as we had in the past.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were relying on the current view to return the icon to put in the
toolbar, however that requires a view instance and also we cannot
control really what icon we want to show in which circumstances.
We want more control about that, so we need a single entry point where
we can get the icon to show depending on the known view types we
have.
So this patch converts the view property to a static method.
https://bugzilla.gnome.org/show_bug.cgi?id=771075
|
| |
|
|
|
|
|
|
| |
And make the style of Nautilus the same for all files.
Hopefully we can fix all the style issues we can find in the next days,
so expect a little of movement on this.
https://bugzilla.gnome.org/show_bug.cgi?id=770564
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we have this menu structure:
------------------------------
1. New Folder/New Tab/Bookmark
------------------------------
2. Zoom controls
------------------------------
3. Undo/Redo
------------------------------
4. Sort options
------------------------------
5. Other view related controls
------------------------------
The view creates 2-5, contained in a single GtkWidget - which is then
passed to the toolbar via the enclosing window slot. The problem is that
3 shouldn't be created or managed by the view as the controls in that
section of the menu are not related to the view. We'd like to move this
responsibility back to the toolbar, but that would mean the view must
pass multiple menu sections back to the toolbar (as 3 is in the middle
of the other view controls).
This change allows the view to pass multiple sections back to the
toolbar, using the new NautilusToolbarMenuSections structure. The files
view now passes 2 as a separate section to 3-5 (3 will be moved out of
the view in a future commit).
https://bugzilla.gnome.org/show_bug.cgi?id=764632
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior changes to merge the view and action menus essentially moved the
action menu items into the view menu. This was the path of least
resistance; the view has a lot of hooks on items in the view menu,
whereas the there are very few hooks on items in the action menu,
meaning the latter could be moved more easily.
However, previously the view menu was disabled for Other Locations and
the action menu wasn't. So the side effect of the changes is the
remaining menu is now disabled completely on Other Locations. There are
a couple of items that could be shown for Other Locations (e.g. New
Tab), so we still want to show a menu, but this involves some
refactoring so has been deferred until now.
This commit is the first part of the refactoring; the files view owns
the menu popover, meaning that the Other Locations view doesn't have
access to it. This commit moves the ownership of the menu popover to the
toolbar. Future commits will move the common items into the popover so
all views will show them.
https://bugzilla.gnome.org/show_bug.cgi?id=764632
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus is in the proccess of receiving a places view,
based on GtkFileChooser's one.
To be able to handle that, an abstraction layer is needed
between NautilusFilesView and NautilusWindowSlot, so we factor
out the common data between views.
Add the NautilusView interface, and make NautilusFilesView a
NautilusView implementation. Because of the new way we handle
search on the view side, the search logic is rewritten to match
the new expected behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=753871
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
NautilusView is the proposed name for the new
interface that will cover NautilusFilesView and
NautilusPlacesView.
The current NautilusView name, however, will crash
with the proposed interface name.
Fix that by changing the class name to NautilusFilesView.
As an easter egg, makes it match the current Nautilus
code style.
|
| | |
|
| |
|
|
|
|
| |
I removed that part of the code. Also, now that both behaviours
between renaming and new folder are closer, simplify the code
and merge the common parts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
All X11 custom keys are currently handled by NautilusWindow,
which performs a search on it's own action group as well as
the view's one to perform the corresponding action.
Since we're isolating NautilusView from other classes, the
search on the view's action group is undesired.
Fix that by making the view handle zoom-in and zoom-out actions,
instead of the window itself.
https://bugzilla.gnome.org/show_bug.cgi?id=753695
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NautilusToolbar handles the view menu, requiring
direct access to the underlying view inside the
window slot.
Since we're wiping out every access to the underlying
view, we shouldn't access it from NautilusToolbar.
To fix that, makes the view handle the view widget.
Since we're making NautilusWindowSlot a wrapper, add
the necessary properties for it to expose view data
without exposing the view itself.
https://bugzilla.gnome.org/show_bug.cgi?id=753673
|
| |
|
|
|
|
|
|
|
|
| |
Some users felt it quite disruptive to us a dialog, even
if the attention has to be on the name entry.
Also it's the way that GtkFileChooser implemented it
and it actually feels less disruptive and desigerns agreed
it works better.
So continue to use a dialog for the new folder creation, but use
a popover for renaming.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NautilusView directly access NautilusWindow to make sure
the window is shown when the view starts loading, and not
before this.
Since we're restricting communication between NautilusView
and other widgets, the view shouldn't ask the window directly.
Fixed by making NautilusWindowSlot handle the visibility of the
window on NautilusView::begin-loading signal. Also, this patch
gets rid of an old code that updates the title of supposedly
hidden slots that were present or created before showing the
window. which is something doesn't happen anyomore.
https://bugzilla.gnome.org/show_bug.cgi?id=753356
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NautilusView is an abstract class that manages
various context menus, depending on the view's
location, the clicked point and the implementation
details.
While this in theory provides a good isolation
from other classes, in practice NautilusView
manages the pathbar context menu, which is not
necessary, as it doesn't depend on the current
view anymore after the GAction rework.
Fix that by making NautilusPathBar manage the
context menu by itself instead of the view. To
cleanly implement that, add a new signal that
matches GtkPlacesSidebar::open-location signature,
and adapt NautilusWindow to reuse the existing
methods to handle pathbar's new signal.
https://bugzilla.gnome.org/show_bug.cgi?id=753158
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus classes add custom methods to grab the focus
differently according to the class.
The problem with this approach, however, is that we end
up with more code coupling, since it's necessary to include
more headers to use the custom grab methods.
To fix that, make classes override GtkWidget::grab_focus
method and remove the custom methods, so widgets can simply
call gtk_widget_grab_focus.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 2e1ac98 introduced the new behavior of persistently
storing the show-hidden setting whenever it changes.
This, however, caused an update cycle where NautilusDirectory
tracked the show-hidden change and invalidates the mime types
of the files, sending the apropriate ::file-changed signals.
When NautilusView receives the signals, it unconditionally
updates the action states, which sets the show-hidden action
again, causing another change on the setting and re-triggering
the NautilusDirectory signals, which are detected by NautilusView
and perpetuating the cycle.
Fix that by only storing the show-hidden setting when it
differs from the current one.
|
| |
|
|
|
|
|
|
|
|
|
| |
NautilusWindowSlot currently manages the floating bar,
requiring access to the underlying model of NautilusView
and making the code even more coupled and adding more
complexity to the codebase.
Fix that by delegating the management of the floating
bar to NautilusView itself, and turn NautilusView a
GtkOverlay subclass in order to facilitate the transition.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
NautilusWindowSlot is the class responsible for managing
the empty views, causing even more code coupling and
blurring the lines of functionality of each class. Also,
it requires that the slot access the underlying model
behind NautilusView, something we're avoiding in order
to get Nautilus ready for future modifications.
Fix that by delegating to NautilusView the responsability
to manage the empty views, and not NautilusWindowSlot.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now we were not stopping the search if no callbacks from clients
were present. That happened when the user canceled the search while the
search directory was waiting for its files metadata, since that async
call was not canceled.
This was actually making nautilus freeze on situations where the search
was so expensive that other threads couldn't cope with it.
To fix it, make sure we stop the search if no clients are present as
callbacks, and make sure we stop the load of the view when we cancel the
async call in the stop_loadin handler of the view.
|
| |
|
|
|
|
|
|
|
|
|
| |
We stop loading the view on destroy, and we add a check on
done_loading to not do some things if we are on destroy.
But the check was checking for the slot not having a window,
which actually has if the view is being destroyed while the slot
is not, like when switching views.
To avoid this crash, mark the model as NULL before all the checking,
and check for the model, not for a window in the slot.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Following previous decision for others preferences.
|
| |
|
|
| |
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
|
