| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, the operations button doesn't get removed from every
Nautilus window. And if clicked, an empty popover will appear. One case
is when the user starts a long operation, and then closes the popovers
in all windows once the operations have completed (and before the
buttons are due to be removed).
All windows get notified that the operations have finished. But if
there's a popover open in any window at that point, the windows don't
schedule removal of the button - as the logic is to keep the buttons
visible while there are popovers open. When the user then closes the
popover in the last window, that window knows there are no popovers in
the other windows, so it removes the button from it's toolbar. But
there's nothing to notify the other windows to remove their buttons.
The fix is to implement a more robust solution; instead of the windows
checking the other windows for popovers (windows shouldn't know about
the other windows anyway), the progress info manager maintains a list of
viewers. When an popover is open or closed, the window tells the manager
to update it's list of viewers. When there are no entries in the list,
the info manager notifies all listeners (the windows), so they all know
when to schedule removal of their buttons.
https://bugzilla.gnome.org/show_bug.cgi?id=765019
|
|
|
|
|
|
|
|
|
| |
Some GdkDisplay operations have been deprecated in GDK 3.20.
This commit replaces the deprecated code with new GdkSeat
operations.
https://bugzilla.gnome.org/show_bug.cgi?id=762235
|
|
|
|
|
|
|
|
|
| |
Some GdkDisplay operations have been deprecated in GDK 3.20.
This commit replaces the deprecated code with new GdkSeat
operations.
https://bugzilla.gnome.org/show_bug.cgi?id=762235
|
|
|
|
|
|
|
|
|
| |
Some GdkDisplay operations have been deprecated in GDK 3.20.
This commit replaces the deprecated code with new GdkSeat
operations.
https://bugzilla.gnome.org/show_bug.cgi?id=762235
|
|
|
|
|
|
|
|
|
| |
The deletion rate shown to the user is wrong, it's coming out as a
massive number. An earlier fix corrected the deletion rate used to
determine if the message should use the plural. This fix is to make the
same change to the value shown to the user.
https://bugzilla.gnome.org/show_bug.cgi?id=759986
|
|
|
|
|
|
|
|
|
|
| |
A simple operator precedence mishap prevented the deletion rate during
long deletion operations from being displayed properly. Also, the
formatting of the message is subtly different from the others of this
kind because we don't have a predefined formatting token for a file
count, and it ended up missing a space character.
https://bugzilla.gnome.org/show_bug.cgi?id=759986
|
|
|
|
|
| |
Having so many deprecation warnings obscure the real warnings... :/
Should run more frequently with those disabled.
|
|
|
|
|
| |
Having so many deprecation warnings obscure the real warnings... :/
Should run more frequently with those disabled.
|
|
|
|
|
|
| |
For a better structured hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
| |
This reverts commit c9dcccae611e40f48024bdfeccbb081fa10b7b15.
|
|
|
|
| |
For a better structured hierarchy.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A simple operator precedence mishap prevented the deletion rate during
long deletion operations from being displayed properly. Also, the
formatting of the message is subtly different from the others of this
kind because we don't have a predefined formatting token for a file
count, and it ended up missing a space character.
https://bugzilla.gnome.org/show_bug.cgi?id=759986
|
|
|
|
|
|
|
| |
We moved the code to nautilus-file, but forgot to remove the files.
Remove them.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We needed to do some hackish code in order to allow types that are
not included in nautilus-directory to dispatch the correct subclass.
Instead of that, we can just create a "plugabble" system that allows
directory types to be registered in the system, and implement a class
vfunc that queries if the class handles a specific type of uri, falling
back if none can handle it to the usual nautilus-directory.
We can do this for the desktop directory and the search directory.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
| |
In case we don't meet the conditions the parent function can still
deal with it.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
| |
Just to make it cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
| |
This feels like belonging to the file itself rather than the view.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
| |
So we don't double free it.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And allow overriding of subclasses.
Nautilus mime actions file currently uses the file as parameter, as if
it was part of the nautilus file class.
However it's hosted in a different file, even though we need to special
case some subclasses of nautilus file for its management.
imho, this code design is wrong, since it defeats the purpose of OOP.
So move it to the nautilus file, allow overriding, and override this
vfunc in the subclasses that need it, like the desktop-icon.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
| |
Since the desktop files needs to do nothing at all.
This removes the last desktop dependency from nautilus file (yay).
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
|
| |
We are special casing some cases where we want to do something different
in subclasses.
Allow to override this function so subclasses can use it.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
| |
Now that we can use inheritance for dnd handling, use it in the subclass
instead of special casing on the parent.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
| |
Subclasses may want to override some dnd handling.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are requiring file handling like special casing subclasses in the
dnd handling.
We are currently doing it outside of nautilus class... which makes
overriding on subclasses impossible.
This design goes against inheritance design, so there is no point on
making it that way if it defeats this purpose.
So merge the handling of file dnd inside the file class itself, and in
upcoming patches we will override that handling in order to use
inheritance instead of special casing in the parent.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
| |
Now that we can do it in subclasses, use inheritance instead of special
casing in the parent.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This get target uri is used for those which we have special handling on
the activation uri, instead of the usual glib attribute
G_FILE_ATTRIBUTE_STANDARD_TARGET_URI. So it behaves like a supergroup
of those which have G_FILE_ATTRIBUTE_STANDARD_TARGET_URI, but we use
it in the same way.
We use for handling special files like desktop links on drag and drop,
etc.
However, this is useful for other parts of nautilus, and we will use it
in a upcoming patch, so we can rename it in order to communicate the
wide nature of the function.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
| |
So subclasses like desktop icon can make its own handling, instead
of special casing in the parent.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
| |
Now that we can override the vfuncs needed for special casing the
desktop icon files, move all that handling to the subclass.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
| |
We will need it for using inheritance instead of special casing.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now we were creating the desktop directory in a lazy way, like
any other cached directory.
However, we have the problem that at some point we have to dispatch
between different types of files, when creating them for the cache.
We cannot know when we will need to create the desktop directory for
first time in order to discern between that type of directory, or the
regular one.
What we can do is ensure that we created the desktop directory before
any other part of nautilus request it. In this way, we can create it
on our subclasses of the desktop, and after that, nautilus will request
the cache as a regular use, without the need to special case the
desktop.
For that, create the desktop directory when the desktop application
starts, holding the reference so the cache doesn't release it, and then
let nautilus work as expected.
For that, in previous commits we moved the file dispatching to be inside
the directory, so now any file creation happens inside the directory,
and therefore we can control, when creating the desktop directory, what
subclass will be called.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
| |
So we use inheritance instead of special casing, making possible
to remove the desktop dependency for the creation of the desktop
files.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
| |
So subclasses like the desktop directory can do their own.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's the directory who owns the files, and we were actually creating
new files from nautilus directories in nautilus-file.
We can move that code to nautilus directory.
In this way, we will able to handle files of a specific scheme better,
like the desktop, in future patches.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were assuming we had in cache the files used for dnd, but with
the desktop split that's not longer the case.
What can happens is that we cannot discern whether the drop action
should be a copy or a move, since Nautilus always performs a move if
the file system is the same as the dragged files.
To fix it, in a best effort mode, we will request to update the files
information if it's not available. In future times it will be requested,
and if the files are not freed, we will have the file system information
available in order to decide a more appropriate drop action.
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Nautilus, the trash is monitored for state changes - going from empty to
non-empty and the other way round. Monitoring is done by handling change signals
from a regular file monitor. On each signal, an enumeration of the trash
contents is started in order to see if it is empty or not. This causes issues
when many files are trashed, because the gvfs trash backend is flooded with
enumeration requests, resulting in CPU usage spikes. In order to fix this, the
"item-count" attribute of the trash should be queried instead.
Replace asynchronous enumeration with asynchronous information query and update
the trash state based on the "item-count" attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=763218
|
|
|
|
|
|
|
|
| |
The label of a mounted location is displayed differently in the pathbar and in
an open tab, due to different means of obtaining the location title. In order to
fix this, use the mount name when computing the mount title for an open tab.
https://bugzilla.gnome.org/show_bug.cgi?id=764573
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Vim and emacs modelines are used to specify some of the code style in the code.
However, this is misleading and poorly supported since nautilus had a mix of
code style for some time.
Also, the mode lines doesn't specify the whole code style, so we will need to
use a different tool as well to specify the whole code style.
For that, we can just use a different tool for everything.
So remove the mode lines, and in a short future we will reestyle the nautilus
code to have a single code style, and use a tool like editorconfig to specify
the whole code style.
|
|
|
|
|
|
|
|
| |
With the latest redesign of the search, there is not much point to
bookmark a search, and instead, make the search again.
Anyway, maybe it makes sense if we create a more complex search engine,
but we can add support for it in the future, when it's needed.
|
| |
|
|
|
|
|
|
|
|
| |
In Nautilus, undo operations are performed as asynchronous tasks, using the
GSimpleAsyncRequest API. Because this API is now deprecated, replace it with the
GTask API.
https://bugzilla.gnome.org/show_bug.cgi?id=763445
|
|
|
|
|
|
|
|
| |
Modularization was done in preparation for another commit supposed to fix a
trash issue. Since this issue is probably not from nautilus, this is no longer
needed.
This reverts commit 39798e28c9566656c248d3462195e0f9ae188bd9.
|
|
|
|
| |
This fixes warnings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Untitled"
When a new document is created using a template, the word "Untitled"
is displayed in front of the template name. For example,
creating a new document with a template called "document.doc"
will create new file named "Untitled document.doc".
This is obviusly a non-practical use of templates and this patch
aims to fix this miss-behavior.
The fix is simple, the word "Untitled" has been removed from the
code when a user creates a new document from a template.
https://bugzilla.gnome.org/show_bug.cgi?id=762774
|
|
|
|
|
|
|
|
|
| |
In Nautilus, when the Trash is emptied, trash undo / redo operations are
invalidated by the undo manager. However, only the undo operations should be
invalidated, because a redo is not affected by the state of the Trash. In order
to fix this, change the invalidation condition to only target undo.
https://bugzilla.gnome.org/show_bug.cgi?id=763134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the zoom level is too small, thumbnails become useless, as they are
so small that they don't give any information.
The solution to this problem is to use mimetype icons when the zoom
level is too small
In order to achieve this, there was added a function that returns
true if the zoom is too small, nautilus_thumbnail_is_limited_by_zoom,
meaning that the corresponding mimetype icon should be used instead
of the thumbnail
https://bugzilla.gnome.org/show_bug.cgi?id=752805
|