| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the toolbar menu reorganisation work, the code to create and
manage the undo/redo items on the menu ended up in files-view.c. This
isn't the correct place as they don't have much to do with the files
view. Some refactoring was needed before the code for these items could
be moved back into the toolbar, which has now been done in a previous
commit.
This commit moves the undo/redo creation and management code into the
toolbar.
https://bugzilla.gnome.org/show_bug.cgi?id=764632
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And fix make distcheck.
Although libnautilus-private seem self contained, it was actually
depending on the files on src/ for dnd.
Not only that, but files in libnautilus-private also were depending on
dnd files, which you can guess it's wrong.
Before the desktop split, this was working because the files were
distributed, but now was a problem since we reestructured the code, and
now nautilus being a library make distcheck stop working.
First solution was try to fix this inter dependency of files, but at
some point I realized that there was no real point on splitting some of
those files, because for example, is perfectly fine for dnd to need to
access the window functions, and it's perfectly fine for the widgets
in the private library to need to access to all dnd functions.
So seems to me the private library of nautilus is somehow an artificial
split, which provides more problems than solutions.
We needed libnautilus-private to have a private library that we could
isolate from extensions, but I don't think it worth given the problems
it provides, and also, this not so good logical split.
Right now, since with the desktop split we created a libnautilus to be
used by the desktop part of nautilus, extensions have access to all
the API of nautilus. We will think in future how this can be handled if
we want.
So for now, merge the libnautilus-private into src, and let's rethink
a better logic to split the code and the private parts of nautilus than
what we had.
Thanks a lot to Rafael Fonseca for helping in get this done.
https://bugzilla.gnome.org/show_bug.cgi?id=765543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
NautilusView is the abstract class that
concrete views such as icon or list view
inherit.
In its header, there was a method that was
used nowhere throughout the code.
Remove this unused method.
|
|
|
|
| |
Found with cppcheck.
|
|
|
|
| |
This code is not used anymore.
|
|
|
|
|
| |
Now that we use a dialog, we can remove lot of hacks we had
for in place renaming.
|
|
|
|
|
| |
Store the entire state in the action. The toolbar will be called to
update the state anyway...
|
|
|
|
| |
No need to have subclasses override this.
|
|
|
|
|
| |
Instead of putting it in the superclass, have the subclasses implement
it individually.
|
|
|
|
|
|
|
|
|
| |
Refresh the nautilus menus in the view (context menus) and the menus in
the toolbar, changin as well in the path the UI of the toolbar to match
mockups.
In the way, port to GAction and GMenu every action and menu of nautilus
and some clean ups thanks to this port.
|
|
|
|
|
| |
Nane the pathbar actions "location" is confusing. Instead rename it to
pathbar.
|
|
|
|
|
| |
With the upcomming UI rework the user won't need to reset to defaults,
since the UI will be straighforward and not need to this item.
|
|
|
|
|
|
|
|
|
|
| |
Following a design request and preparing to the port to popovers of
nautilus, we want to use only 3 zoom levels for each kind of view, so
the slider makes sense.
Also, following design guidelines, the new zoom levels sizes for icon
view are 64, 96, 128, with default to 96 and 16, 32, 48 for list view,
32 being the default
|
| |
|
|
|
|
|
|
| |
We stopped having pluggable views a long time ago; remove the factory
code completely in favor of a simple nautilus_view_new() that looks at
the specified view ID among the list of views we support.
|
|
|
|
|
| |
Since the error is always reported by the base class, there's no need
for this signal - just report the error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the window of the slot can change, we don't want to connect
signals from the view to the window.
We only connect to NautilusWindow signals for two reasons:
- updating the shadow type of the content view when the number of tabs
in the notebook changes
- following the hidden-files-changed signal
Since the first is really a hack, it can live in NautilusWindow itself
To implement the second, move the Show Hidden Files action to the view
action group, and handle hidden files action changes completely in the
view.
|
|
|
|
|
|
|
|
|
| |
Instead, use nautilus_view_get_ui_manager() and
nautilus_view_get_window(), and turn the checks on window != NULL to
slot != NULL.
This is needed in preparation for detachable tabs; since the window for
a given slot might change underway then, avoid staying out of sync by
not storing a pointer to the window.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch does three things:
- It adds API to the floating bar to have primary and details labels
instead of a single label. The primary label is ellipsized separately
from the details, so it makes a good fit for a filename.
- Modifies the code setting status messages in NautilusView to split
them into two separate strings
- Removes obsolete code in NautilusView and NautilusWindowSlot that was
setting long statuses for the old non-floating statusbar
https://bugzilla.gnome.org/show_bug.cgi?id=660695
|
| |
|
|
|
|
|
|
|
| |
This will allow us to retain canvas view for the desktop directory
but implement a new icon view for other folders.
https://bugzilla.gnome.org/show_bug.cgi?id=681370
|
|
|
|
|
| |
Consolidate identical code that builds a list of emblems to ignore
inside nautilus_file_get_emblem_icons()
|
|
|
|
|
|
| |
Set a "nautilus-inactive-pane" style class on the inactive
NautilusWindowPane; this allows us to theme the inactive pane state way
more easily and removes a bunch of setup code.
|
|
|
|
|
| |
And keep it in sync with the renaming widget. This will be useful to
forward events to the view if it's renaming.
|
|
|
|
|
|
|
|
|
| |
"Create launcher" entry from nautilus seems weird as nautilus doesn't draw the
desktop for GNOME Shell, and this rely on a gnome-panel binary. This brings
inconsistency between the two sessions.
https://bugzilla.gnome.org/show_bug.cgi?id=654848
https://bugs.launchpad.net/bugs/723861
|
| |
|
|
|
|
|
|
|
| |
Don't always choose the tree root as parent when creating a new folder,
but look at the current selection's directory.
https://bugzilla.gnome.org/show_bug.cgi?id=330644
|
|
|
|
| |
Having a function just to call a cast seems a bit weird...
|
| |
|
|
|
|
| |
The mode is now always decided by the GSettings preference.
|
| |
|
| |
|
|
|
|
| |
Big code rename/indent fix, no actual code change here.
|
| |
|
|
|
|
| |
Instead of using virtual methods
|
|
|
|
|
|
|
| |
This hack should not be required anymore now that we don't have user
emblems.
Other emblems should be taken care of by the normal NautilusFile's
changed signal.
|
|
|
|
|
|
| |
No need for some internal methods to be virtual if they're never
overridden.
Also, some of this code does nothing.
|
| |
|
|
|
|
|
| |
The property is only used by the icon view, so it's better to move the
check there.
|
| |
|