One of the benefits of the new menu on the path bar buttons is that we
show the background menu.
This was the intended design since the start, but we didn't come to
finalize it earlier on.
Now with the 3.30 approaching, this work implements that.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/405
Builder keeps trying to format the JSON automatically for any change,
which is quite cumbersome since it appears as a changed file on git and
also it's a mess if an actual change happens.
Just accept the defeat and go with whatever Builder wants.
Instead of checking explicitly for some options, we allow any value as
profile and assume is a development snapshot.
This will help with having Flatpak bundles/refs of different branches
with different purposes.
With the new search bar design, the search information displayed under
they query editor was not working properly.
Instead, the new design says that the information should be displayed
in the view itself, as a top banner.
This work implements the new design and fixes several issues of sizing
due to the wrong position of the search information label.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/403
canvas_set_scroll_region_include_visible_area() was added in
ec054c8098 to fix
https://bugzilla.gnome.org/show_bug.cgi?id=42068 ("Dragging icons
adjusts scroll area in a way that causes immediate scrolling"). This is
no longer the case, because now icons remain in place when being dragged
and are not allowed to be rearranged.
ec054c8098 causes issues relating to extra
scrolling space (#340), hence the removal.
Fixes#340.
With the new design the tags weren't fitting into the box anymore,
probably due to a style somewhere. Not sure where the issue is, but all
margins from within the tagged entry were 0 pixels.
This commit restores the margins to make the tags fit. This will
eventually go away with the new tagged entry that goes with gtk4, so it
doesn't worth to dig much deeper.
Invoking `apt` triggers a warning about its interface being not stable enough for use in headless setups. That, and I messed up the last commit, so here we are.
Every time we call apply_emblem_to_icon(), we need to declare a second
GIcon beforehand to store the return value, and we need to unref the
original GIcon afterwards.
If the file has got no emblems, the second GIcon is just another
reference to the first one.
Let's simplify this by lending ownership of the GIcon.
Emblems whose names are in metadata::emblems are added to icons, but
this is not happening if the file also has metadata::custom-icon-name.
This may have been a regression from the last refactoring of the icon
loading code (commits a6b88ebde1 to c123b6056b).
Make sure to apply emblems on custom icons as well.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=748736
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.
Open properties from pathbar popup show properties of view.
We want it to show the properties of current location of pathbar.
Added an action to files-view to handle the properties of pathbar,
because we just want the properties of current directory of files-view
Closes: https://gitlab.gnome.org/GNOME/nautilus/issues/475
The YAML files already use the gitlab URLs, while the json doesn't.
The gnome-apps-nightly build script reads the json file, and the
builds have been failing because of this.
Update the json file accordingly.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/485
_GNU_SOURCE is required to be able to use POSIX functions that are not
available on non-Linux system. Specifically, we use sys/types for
requesting user accounts with getpwent and similars.
Usually systems seems to compile with this set, however some systems
like RHEL doesn't assume it so.
Since this is more correct to set it explicitly, this commit does that
by passing an argument to meson project.
setpwent is used but we didn't include the necessary headers.
It was building in Fedora because some other header included it,
but that's not the case in RHEL.
