| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
A method to query maximum filename length has been introduced by
commit a5520fd8930910ffa686232f3fc92325fe47c64e
However, Ernestas has noticed that another implementation was already
present in nautilus-file-operations.c
This commit will replace both with a file-utilities function, which
takes ideas from both implementations.
|
| |
|
|
|
|
|
| |
This commit removes redundant header inclusions and tries to optimize
headers by using forward declarations of types in headers. Such
optimization should generally make builds speedier in that changes in
certain headers will not cause unrelated sources to be rebuilt.
|
| |
|
|
|
| |
This is to be used by a potential fix for
https://gitlab.gnome.org/GNOME/nautilus/issues/148.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The traditional include guards are not as easy to handle
and require extra thought into the names.
Pragma once is an easier, more contributor friendly approach.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/294
general: Remove include guards in favor of pragma once
The traditional include guards are not as easy to handle
and require extra thought into the names.
Pragma once is an easier, more contributor friendly approach.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/294
|
| |
|
|
|
|
|
| |
Add option to make files Favorite, by either toggling a star in the
list view, or from the context menu.
https://bugzilla.gnome.org/show_bug.cgi?id=786039
|
| |
|
|
|
|
|
| |
If any derived classes have one of their own defined, the compiler will
start spewing warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=786760
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=784941
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now Nautilus was not able to handle files where the user had
no permissions. An error was reported.
The only way for a user to handle those files were to start Nautilus
with sudo, which is something that shoudl be avoided for security
reasons.
On Wayland, is not even possible to launch an application with sudo,
so this is no longer available and therefor no way to handle files
with no permissions.
On 3.22 gvfs added an admin backend with integration with Polkit,
so a file withouth permissions can be accessed using this backend
if the user has the root password.
Add support for the admin backend in Nautilus, where a file will
be opened using it if cannot be read.
There still work to do, basically implement the operations with
this backend too and refactor the code to be able to open from
nautilus application command line also a file withouth permissions.
https://bugzilla.gnome.org/show_bug.cgi?id=773937
|
| |
|
|
|
|
|
|
|
|
|
| |
We use checks to know whether a file is local, using g_file_is_native.
However, we also need to know for some cases when a file, even if no
native, can be handled like native, using FUSE.
This will be needed for the selection of default applications on remote
locations, and will be used in a upcoming patch.
https://bugzilla.gnome.org/show_bug.cgi?id=764506
|
|
|
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
|
