| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Pass new uncrustify criteria. No logic changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The libadwaita pkg-config adds `-I/usr/include/libadwaita-1`
(or similar) to the compiler flags, which means that
#include <adwaita.h>
is sufficient, and the currently used
#include <libadwaita-1/adwaita.h>
is not necessary.
Not only is it not necessary, but it prevents nautilus from being
built with an uninstalled libadwaita build (either meson subproject
or otherwise). To fix that, remove the `libadwaita-1/` prefix.
The libadwaita test programs also only `#include <adwaita.h>`, and
according to Debian Code Search, that is the more popular version.
https://codesearch.debian.net/search?q=%23include+%3Cadwaita.h%3E&literal=1
https://codesearch.debian.net/search?q=%23include+%3Clibadwaita-1%2Fadwaita.h%3E&literal=1
|
| |
|
|
|
|
|
| |
Replace with gtk_widget_set_visible() or gtk_window_present()
In some cases we use gtk_widget_show() unnecessarily because
widgets are visible by default
|
| |
|
|
|
|
| |
AdwComboRow:selected has value type 'uint', but I forgot to update
it from HdyComboRow, which broke the settings.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2131
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new major version of the toolkit is a requirement to fix old issues and enable future enhancements.
Update symbols and adapt logic to API changes.
Update and simplify UI definitions.
Update local copy of places sidebar and places view.
Replace dependencies with their GTK4-compatible successors.
Make a minimum changes required to build and run, with known
regressions to be fixed in future commits.
For a detailed breakup of the changes, see the 36 commits-deep
log leading to d5763facb1e5045251171ed1273dca0859f3542f.
This is the main part of https://gitlab.gnome.org/GNOME/nautilus/-/issues/276
|
| |
|
|
|
|
| |
Currently, gtk_builder_add_from_resource silently fails with old libhandy
version which leads to weird crashes. Let's print the returned error to
be obvious what is going on.
|
| |
|
|
|
|
|
|
|
|
| |
The Preferences have been recently cleaned up, which now enables us to
reorganize them in a single page using modern design patterns.
Use HdyPreferencesWindow for convenience of implementation, as well
as for the rounded bottom corners and adaptivity to small sizes.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1258
|
| |
|
|
|
|
| |
We have a few includes, defines and tree models which we no longer use.
They used to be need for widgets and options which are long gone.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike most preferences, changing this may have no effect on open
windows, which is unexpected.
This affects only new folders without any per-folder override, which
has diminute value.
Remove this from the Preferences window. The gsettings key is preserved.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1312
First part of https://gitlab.gnome.org/GNOME/nautilus/-/issues/1703
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When preparing to drop the Application Menu, this was added to the
Preferences window.[1]
Later when actually dropping the Application Menu, the action was
added to the primary window menu.[2]
So, it ended up in 2 places, which it not necessary.
The sidebar is essential for navigation, so hiding is only tempoary,
not a long-lasting preference. So, it doesn't make sense to have here.
[1] commit f2061e94093a33072e792181433b0618bf68d1b2
[2] commit 99324771868ca7fad75889418ecd08765d8b4629
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It applies only to image files, which is unexpected. The drawbacks of
setting a higher value are not explained either. How much is too much?
The last commit has raised the default value to a hopefully high
enough value making this UI control even less useful.
The gsettings key is preserved for now.
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1309
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whe the ASK option gone, the only alternative to the default is RUN.
This option is not safe: it's too easy to accidentally run programs.
Now we have a "Run as a Program" action in the context menu, which is
available by default (no configuration required) and safe (clearly
labeled, intentionally chosen).
So, remove the RUN option is no longer necessary, and with it we can
remove the preference from both the UI and GSettings schemas.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1700
Discussed in https://gitlab.gnome.org/GNOME/nautilus/-/issues/443
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is an option in Preferences which enables a dialog asking users
what they intend to do when they double-click an executable text file:
open as a text file or run as a program?
The dialog asking that question has known design problems, but they
remain unaddressed, which is not surprising because it's non-default.
Now, with the new menu item added in the last commit, the two options
("Open" and "Run as a Program") are both available by default in the
context menu, so there is no need to ask the question in a dialog.
Remove the option, the dialog, and the related code.
Closes https://bugzilla.gnome.org/show_bug.cgi?id=598671
Part of https://gitlab.gnome.org/GNOME/nautilus/-/issues/1700
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A gsettings-based option "confirm-trash" existed to determine if a
confirmation dialog should be shown when emptying the trash. This
setting, enabled by default, was misappropriated for the unrelated
"delete directly" operation of files outside Trash. This latter use of
this setting was misleading and unexpected (more discussion on the
linked issue page.)
Remove option "confirm-trash" entirely because neither of the above
mentioned operations are reversible, so they should always require
confirmation.
Add ellipsis to labels for the "empty trash" and "delete permanently"
actions since they now always invoke a confirmation dialog.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1699
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Glade has been used to change the .ui definition of the Preference
dialog in commit f2061e94093a33072e792181433b0618bf68d1b2
It has removed the "border-width" property, resulting in a 2px
padding being added around the notebook widget, which wasn not
intended and looks bad.
This issue will be gone in GTK+4, but we need to explicitly set
this style property to 0px in the meantime.
Do it in the code instead, where Glade cannot erase it.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/563
|
| |
|
|
|
|
|
| |
It went worse than I expected, it's a "break me please" setting, which
we are generally against.
It can still be enabled through dconf.
|
| |
|
|
| |
Since we want to replicate inside Nautilus what's in the app menu.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recently we removed the ability to launch binaries and scripts in
commit 3a22ed5b8e3bb.
A few cases appeared that we need to support, specially for enterprise
and content creators. Specifically, cases similar to https://gitlab.gnome.org/GNOME/nautilus/issues/434
This also shows that is hard to predict cases like these, as some
complex setups might be needed for specific workflows.
This commits allow to run binaries and scripts as before, and further
investigation in these cases need to be done if we ever want to tweak
the workflow of running binaries.
More discussion about improving binaries/script handling is being
proposed and discussed in https://gitlab.gnome.org/GNOME/nautilus/issues/443
|
| |
|
|
|
|
| |
Since the settings schemas no longer contain the required settings,
opening the preferences window causes an error and a call to abort().
This can be reverted if the ability to launch scripts is reintroduced.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When hacking on Nautilus, it is very inconvenient to have to close any
running instance before running the built version. This commit enables
running three different instances by changing the application ID.
Beside the default “profile” is one crafted for stable flatpak
releases and one for development. The stable flatpak profile adds an
identifying mark to the about dialog to aid collecting information in
bug reports. The development profile is that plus additional styling to
help visually identify the development instance. It also will be used
when generating Flatpak bundles with the help of CI.
Generally, the implementation is slightly hacky to allow all the
different workflows, spanning from regular installations to GNOME
Builder flatpak builds, as each comes with its own quirks.
|
| |\
| |
| |
| |
| | |
Thumbnail limit tweaks
See merge request GNOME/nautilus!126
|
| | |
| |
| |
| |
| |
| | |
611f381d561024b0a590237c31fc0612e6698530 added a spin button for
thumbnailable file size limit. The units are displayed in the text, but
the string is not translatable.
|
| |/
|
|
| |
Fix a misaligned '\' in the macro definitions.
|
| |
|
|
|
|
|
| |
Shadowing variables is error-prone, since one might mean to refer to a
variable that was declared earlier, but has the same name. Additionally,
being more strict about variable scoping can help make the code more
readable.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes include:
* adding a single-include header and deprecating
nautilus-extension-types.h and direct inclusions of individual
headers;
* type definition simplifications - this causes some breakages in
nautilus-file, because NautilusFile used to be typedefed to
NautilusFileInfo, and that is no longer possible, so the interface
implementation was moved to static functions and the public
NautilusFile API provides thin wrappers for them to maintain
compatibility;
* documentation cleanups and reorganization;
* general build rule and code cleanups: mostly g_auto* sprinkled
around and style changes (sorry)
|
| |
|
|
|
|
|
|
| |
Instead of setting whether the search should be full text search or
not from the preference dialog, make the permanent setting from the
search popover.
https://gitlab.gnome.org/GNOME/nautilus/issues/65
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
File sizes (especially compressed images) are arbitrary values that are
highly dependant on the camera resolution, and contents of the image.
Therefore it does not make sense to have this be a drop-down with preset
hard-coded values: A 21MP camera often produces 12MB images... but the
only option is 10MB, or 100MB.
This commit changes the combobox in the preferences to a spinbutton and
changes the signal handler for thumbnail-limit.
The value is in MB, with a maximum of 4096 and a minimum of 1.
https://bugzilla.gnome.org/show_bug.cgi?id=779165
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now archives were managed only if activated from Nautilus itself
and if a setting was set.
There are two main problems with this.
1- Archives opened in other apps cannot be handled by Nautilus
2- Users cannot use the regular mime type handling for setting Nautilus
as the app handling archives, or unsetting it.
This patch add support for archives mime types handled by gnome-autoar
and removes the UI and setting used in the previous version.
https://bugzilla.gnome.org/show_bug.cgi?id=771424
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The search text can now also match the contents of a file, besides
the file name.
This is done with the help of a Tracker query, using fts:match, which
matces both the contents of a file and the filename.
The user also has the option to choose whether to use or not the
Full Text Search. This can be done with a preference, which represents
the default option when opening a new tab/window or from the search
popover.
https://bugzilla.gnome.org/show_bug.cgi?id=775961
|
| |
|
|
|
|
| |
For next release I hope they are good enough to be able to enable them
by user preference, and also makes easier for us to switch between them
in order to test everything is fine in both.
|
| |
|
|
|
|
|
|
| |
Since adwaita-icon-theme no longer ships the system-file-manager icon,
we must our own. 7a9eacc0afa53520eef12542c4d330bf66142200 was to include
this change, as part of Flatpak integration.
https://bugzilla.gnome.org/show_bug.cgi?id=777011
|
| |
|
|
|
|
|
| |
The sort-directories-first gsetting should be consistent
system-wise.
https://bugzilla.gnome.org/show_bug.cgi?id=750996
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Make extraction the default action for activating selected archives and add an
option to open them instead of extracting.
https://bugzilla.gnome.org/show_bug.cgi?id=768646
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
Having so many deprecation warnings obscure the real warnings... :/
Should run more frequently with those disabled.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
It was inverting the UI.
|
| | |
|
|
|
With designers guidance, rework the preferences window to a better state.
Also, do few improvement on the way, like converting it to a GtkWindow.
|
