| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
As we have already done for the app's main window.
In this case, we must use HdyWindow.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The properties window has been subclassing GtkDialog since long ago.
GtkDialog features an action area where, historically, the properties
window added Help and Close action buttons.
These action were dropped when a headerbar was adopted.[1] Moreover, we
want to port the Properties window to a GtkBuilder UI definition, which
GtkDialog makes harder to achive.
Subclassing GtkWindow fits this use case much better.
[1] d8a8ab3b66a0a4849e2f9cd17e96f86f85541dee
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The properties window can be used from within Nautilus, and therefore a
dialog window makes sense, or from outside Nautilus, such as the
FileManager dbus free desktop standard.
In the later, used for integration with things like desktop icons
extensions, we need to keep the application alive since GApplication
would close the application if no application window is alive after a
timeout.
To fix this, this work makes the window hint a regular window if used
from those cases.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Make startup_id a param of nautilus_properties_window_present().
|
| |
|
|
|
|
|
| |
This lets us pass a startup_id string instead of a parent_widget; this will
be used from the Freedesktop DBus interface.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
|
| |
|
