We were enabling Selinux support by default, which is just to show the
Selinux labels in the properties dialog.
However, this gives problem when trying to create a release since
Flatpak Sdk doesn't have Selinux I guess to be able to work in most
distros.
So with the purpose of having a proper default that works in different
distributions, let set it off by default.
This is not used anymore.
We only need one bounding box, which is provided by the new
nautilus_canvas_container_get_icon_bounding_box().
So remove unused API. We can always revert this if we need it.
We are casting (cost GdkEvent *) to (GdkEvent *)
back and forth, all because some files-view functions
don't take a pointer to const GdkEvent as argument.
But those functions don't actually change the event,
so, make them take a pointer to const GdkEvent instead
and drop unnecessary casting.
An important portion of file management functionality
is exclusively available through context menus.
Currently, when using a touchscreen, there is no way
to open a context menu.
Fix this adding a longpress gesture to popup context
menus on canvas view and list view.
Closes: https://gitlab.gnome.org/GNOME/nautilus/issues/178
Make internal function for both _reveal_rectangle_for_context_menu()
and _compute_rename_popover_pointing_to() to deduplicate the code for
rectangle computation.
Also, make internal function for both _reveal_selection() and
_reveal_rectangle_context_menu() to deduplicate the code for revealing.
Also, make internal function for both _reveal_selection() and
_compute_rename_popover_pointing_to() to deduplicate the code for
getting the first selected item_ui.
Context menus pop up where the pointer is, which is at the
selection if the pointing device is used to open the menu.
However, if the <Menu> key or <Shift>+<F10> keyboard shortcut
are used, context menus still shows up wherever the pointer is,
which may not be near the selected item at all.
Instead, when the context menu is activated from the keyboard,
show it next to the selected item. If multiple items are selected,
show it next to the focused item. If the focus is not on a selected
item, show it next to the selected item which is sorted the lowest.
In all cases, scroll as necessary to make sure the whole item is
visible.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=102666
Background context menu pops up from the pointer's position, which
is good when using a poiting device to open it.
When using keyboard shortcuts to open the background context menu,
the pointer may be outside the view, so the background context menu
will pop up out of context.
Instead, when triggered from the keyboard, pop up from the center
of the view.
When the user presses the <Menu> key or the <Shift>+<F10> combo, we
need to pop up a selection context menu or background context menu,
respectively if something is selected or not.
Currently, this logic is duplicated in list and canvas views, in
different ways, and not implemented in the new icon view at all.
Instead, handle the "popup-menu" signal in files-view. This way,
the new views get the feature for free.
nautilus_pop_up_context_menu() was implemented in bb884cb6 when it was
a wrapper for gtk_menu_popup(). But gtk_menu_popup() has since
deprecated, so it was ported to gtk_menu_popup_at_pointer() in 1f57c5b1.
However, _popup_at_pointer() is not enough for our context menu needs.
We will use _popup_at_rect() and _popup_at_widget in future commits.
Rename to nautilus_pop_up_context_menu_at_pointer() to reflect this
specific use. Also, simplify the code, as GtkMenu's API already
interprets event=NULL as the current event.
This was used when creating new folders with manual layout,
to position them where the user had clicked.
Manual layout was removed along with nautilus-desktop, so
this cache has no use anymore. Remove it.
Currently we always scroll the item to reveal to the top.
This will scroll the item even if it is already visible
but not in the first row.
Instead, scroll as little as necessary to reveal the whole
item, matching the behavior of list view and canvas view.
When renaming, if the item is out of view, the popover may pop up
outside of the window or even outside of the screen.
It is conveninent to see the whole item to be renamed and provide
a visible target for the popover.
So, reveal selection before popping up a rename popover.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/issues/5
We force a rectangle with width=40 to avoid pointy popover
arrows, then we center it to the file name column.
This will not work well when reusing this for context menus.
Instead, use the file name cell's area as rectangle. It should
have enough width anyway.
This reverts commit e874ae7060.
That commit has an incomplete commit message and didn't actually
add the gesture to view-icon-controller.
A reworked version of that commit will be reaplied at the end of
this patch set.
The current way poses problems when dragging the window on one of the
navigation buttons, i.e. the long-press menu gets shown while dragging
the window around. Also, those signals are gone in gtk4.
We are having an issue where "sort" was used in more than one context, so we require different translations.
The solution is to split the strings and provide context to the translators
Closes#151
When requesting the thumbnail icon of a file, if the requested size is
more than 25% larger than what the gnome-desktop thumbnail factory gives
us, the code tries to thumbnail the file using GdkPixbuf to avoid
possible quality degradation.
After 860f748ab2, that code path should
never be executed (but is, because of a missing change to the logic) and
is safe to remove.
Doing that when transitions are deactivated destroys the popover in the
middle of gtk_popover_popdown, causing gtk_popover_hide_internal to
operate on a finalized popover.
Fixes#216.
Currently, Nautilus is able to save the last window position when it’s
closed. That is broken in certain cases (#197 and multi-monitor setups
in general) and therefore window placement is best left to the window
manager.
Nautilus as a file manager needs access to the whole file system, for
that there is a value called "host" which allows direct access to it.
Use it instead of just access to home.
Closes#201
Due to the absence of an obvious way to close location entry
a close button is added to the location entry container which
can be used to close it.
Fixes : https://gitlab.gnome.org/GNOME/nautilus/issues/63
Trash monitor queries info from gvfsd-trash after each file monitor
change which can be problematic when too many changes happen in
a short time. Let's rate limit the number of queries...
