| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This allows applying custom file icons and move handling of icon rendering
to compositor. However, this feature is only used in X11, so its
usefulness right now is questionable.
|
|
This was removed a while ago in 3a22ed5b8e3bbc1c59ff3069ee79755168754916
|
|
AdwDialogs can be attached to any GtkWidget. Make use of this by
generalizing the parent parameter type. Allows to simplify some
calls by dropping gtk_widget_get_root gymnastics.
|
|
The GtkMessageType parameter is unused since [1] ported show_dialog() to
AdwMessageDialog. The return type is unused since the previous commit.
[1] https://gitlab.gnome.org/GNOME/nautilus/-/commit/0f85a7d8f77afe85e1e6ccaae8c786001b1c29a4
|
|
|
|
Remove indirect inclusions by replacing includes with forward
declarations where possible. This should provide a minor speed
up in compilation times.
|
|
In many cases we only care if a list is NULL or a single item but
we use g_list_length which iterates over the whole list.
|
|
|
|
To avoid needless string copies, make nautilus_file_get_mime_type return
a const char* rather then a string copy that has to be freed. Adjust
usage accordingly, especially keep copy for extensions interface.
|
|
And other adjacent unused eel*.h includes too.
|
|
Also update scheme.h header to use a space, not tab, after #define
|
|
Use g_uri_peek_scheme and compare with predefined schemes.
|
|
While sandboxed, we should use a portal to open files with another app.
But the portal is not getting used for archive file types or any of
their subtypes. Instead, nautilus itself tries to handle them. Such is
the case for Open Document file types, which are subtypes of ZIP.
This happens because GAppInfo uses the portal only as a fallback for
when it doesn't find any handler in the sandbox. But it finds nautilus
itself inside of the sandbox, which claims to handle archives, so it
picks it.
Instead of using GAppInfo, use the new GtkFileInfo API which uses the
portal directly. Also, remove the now unused hack, because GtkFileInfo
does everything we need while running as a flatpak.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2841
|
|
This is part of an initiative to use the "app" term instead:
https://gitlab.gnome.org/Teams/Design/initiatives/-/issues/123
|
|
They are assumed to have a 1-to-1 correspondence these days.
|
|
There are some style issue since the last run. Let's run it again
before enabling style-check CI job.
|
|
We want to reuse this code for the previewer window under Wayland,
so move it to a common place.
|
|
Until now we left applications to add the files to recent if they did
modify them. This usually works, specially for gtk applications, but it
doesn't work for applications using other toolkits.
Recently, as we move towards a more containerized Nautilus with Flatpak
the recent files set by other apps are not accessible, so we need to
add them ourselves when opening in Nautilus.
This work adds every file activated by other app from Nautilus be added
as recent.
|
|
The custom handling is used only in one place, and it's simply creating
some wrapper around GtkRecentManager.
In a future commit we would need to provide some API for the simple case
of a adding an URI, which is what GtkRecentManager does by default,
so it's even more useless.
This commits removes the recent file.
|
|
We need to move away from using eel and port most functionalities
inside nautilus.
Replaced the usage of eel_show_warning_dialog() with the show_dialog()
alternative.
https://gitlab.gnome.org/GNOME/nautilus/issues/331
|
|
Changed show_error_dialog() to show_dialog() so that multiple dialog
types can be used.
|
|
This reverts commit 1f4bd55d1b9d5f701f2df8d1be7466df85a8669a
|
|
We need to move away from using eel and port most functionalities
inside nautilus.
Replaced the usage of eel_show_warning_dialog() with the show_dialog()
alternative.
https://gitlab.gnome.org/GNOME/nautilus/issues/331
|
|
Changed show_error_dialog() to show_dialog() so that multiple dialog
types can be used.
|
|
Instead of using eel_show_error_dialog, use the show_error_dialog
function from nautilus-ui-utilities.h header.
https://gitlab.gnome.org/GNOME/nautilus/issues/331
|
|
Non-static functions without any previous declaration cause warnings and
are usually indicative of incorrectly marked static functions.
|
|
|
|
Terminal applications are launched via eel, and, since this file is the
only consumer of that API, the code from eel can be moved over.
|
|
Fixes for https://bugzilla.gnome.org/show_bug.cgi?id=782109 introduced a
regression in that the Wayland window handle export data is now being
freed twice. This commit backports the fix for the regression.
https://bugzilla.gnome.org/show_bug.cgi?id=786040
|
|
Currently, Nautilus tries to find the default applications for files
itself, which does not work well in a sandbox. This commit makes
Nautilus blindly launch the default applications, which makes use of the
documents portal indirectly.
https://bugzilla.gnome.org/show_bug.cgi?id=781132
|
|
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
|
|
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
|
