libcloudproviders provides a menu_model that we use to build a
popover menu. It's possible (and true for nextcloud) that these
menus can have sub-menus. If the sub-menus have much longer
(or shorter) item names, the entire menu will get stretched out.
Use GTK_POPOVER_MENU_NESTED when creating the popover menu, creating
a nested menu which does not exhibit this issue.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2405
Make several improvements:
1) Max filename was too long at 128 characters, half it to 64
2) Tweak min filename to 8 characters (still meaningful)
3) Stop at the first sentence rather than last sentence. A filename
should be short and concise, multiple sentences don't make sense.
4) Start at the start_sentence (i.e. eliminate leading whitespace)
Importantly this patch eliminates the potential inclusion of newlines
which is problematic in the views (it causes more than 3 lines of the
filename to appear because of the GtkLabel behavior).
When populating a GList in a loop, we should use prepend() for best
performance, then flip it around once with reverse().
The list of pending additions to files view lacks the second part.
This used to be compensated for by the old views:
* NautilusCanvasView, through NautilusCanvasContainer, would iterate
this list to populate its own list with prepend(), effectively
reversing the order, as was necessary.
* NautilusListView, through NautilusListModel, would iterate this
list to populate its own list with insert_sorted(), once again
fixing the loading order.
The new view don't do that, and have no reason to because they don't
have their own GLists (instead, they manage GListModels). But this
means that the item which should be added last actually is added first.
GtkListBase treats the first added item as the initial focus and as
scroll anchor. The end result is that the view always scrolls to the
bottom and, on keyboard focus, the last item is selected first.
The first issue (view always scrolls to the bottom) has been worked
around with a hack, but the second one persists.
Therefore, lets just reverse the list right after it is built. This
way, the first added item is the one actual first item. It gets initial
keyboard focus and anchors the view to the top (allowing to remove the
workaround).
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2353
Doing this allows us to automatically load stylesheets located in the
resource base path, so move contents of both Adwaita.css and
nautilus.css to style.css in the root of the resource directory, which
will be always automatically loaded.
Additionally, create a style-hc.css which will be used when the system
high contrast preference is enabled, and adjust it to fix issues with
NautilusPathBar.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2166
Normally we show the Sharing info bar when we are in the
XDG_PUBLICSHARE_DIR (i.e. G_USER_DIRECTORY_PUBLIC_SHARE).
gnome-user-share has a fallback to ~/Public when the PUBLIC_SHARE
folder is set to the user's home directory. Match the behavior
that g-u-s uses.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2459
We use a hack to set the focus on the item when we set the selection.
Sometimes, the item_widget isn't ready by the time we are setting
the focus, which causes a seg fault. This became even worse, when
I applied the focus hack more consistently in 2ac420316b
We should find a better solution, but in the meantime, let's stop
crashing.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2400
The properties extension no longer creates a widget, so it's no
longer a simple task of packing that widget into a window.
We never use that test program anyway; manual testing can and
should be performed in the main application.
Originally introduced by 469047a2a5
It's been disabled because it relied on gtk_main* API, which is gone
in GTK4, but even after porting to GMainLoop API, it fails to work
because operations invoke GApplication inhibition.
In other words: I'm confident this test program has been broken for
years without anyone realizing it.
We already have automatic tests for copy operations. Manual testing
can be done with the nautilus application itself with debug messages
enabled.
So, let's just drop the broken obsolete test code.
Before the GTK 4 port, we had animation theatrics which showed an
expanding "aura" for the newly revealed button, together with a
glowing CSS animation.
Under GTK4 there is currently no available copylib for implementing
similar theatrics.
So, use only the CSS animation, make it simpler, and use accent
color to compensate for otherwise reduced attention-grabbing effect.
Using g_clear_object() we release a reference which we never aquired.
This causes crashes.
So, don't do that. And going a step futher: don't even keep a pointer
nor a singal id: just use g_signal_connect_object() and enjoy peace.
The pad controller owns a reference to the window (as an action group)
and the window (as a widget) owns a reference to the pad controller.
This is a reference cycle.
Usually, reference cycles are resolved in dispose(), which can get
called multiple times. However, GTK removes the controllers during
finalize(). We end up calling finalize() recursively, which is a big
problem.
So our only option is to manually remove the controller before starting
the destruction of the window.
Toolbar holds a reference to the window, which owns the toolbar.
This reference cycle is problematic, so drop the property and just
peek the window by walking up the hierarchy.
Long term we should just dismantle NautilusToolbar completely, by
moving most logic to each their respective control and manage
everything from NautilusWindow.
The focus semantics and API changed from GTK 3 to GTK 4.
Specifically, `has-focus` is no longer TRUE for containers of the
actual focus widget. Furthermore, the location entry itself, being
a GtkEntry, never has got focus itself: that's delegated to its
internal GtkText child.
The solution in GTK4 is to use GtkEventControllerFocus, which
provides the hierarchical focus logic we need.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2463
We are setting the preferred action to 0 when the source and dest are
in the same folder. This prevents the ability to hold CTRL and perform
a copy operation (which worked in 42). It isn't clear why you can't
override a 0 preferred action with key modifiers.
In order to keep consistency, remove this check in
nautilus_dnd_get_preferred_action() and add it to
nautilus_files_view_drop_proxy_received_uris() (only if the action
is MOVE).
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2438
We use a fixed size drag icon so we need to scale the drag icon
accordingly. The hotspot doesn't make sense for listview,
and can produce very strange results, so simply set to 0,0.
Now we have another way to star files (by DnD), but unstarring is
limitted to the properties window and the listview icon. Add back
the ability to unstar from the files context menu only when in the
starred folder.
We already have the function in nautilus-files-view-dnd.
Allow dropping G_TYPE_STRING and call nautilus_files_view_handle_text_drop()
to generate the filename and create a text file.
This only worked in the main view in previous versions, so lets keep
that the same for simplicity.
It's inconsistent with the view. The motivation was making it easier
to tell each thumbnail appart. But we are going to use another
solution to that problem.
Sharp corners give an unpolished feel to thumbnail.
We've been trying to give the illusion of round corners using shadows.
But now that we already use GtkSnapshot, properly clipping round
corners is too easy not to do it.
These flags were relevant when each folder opened in its own window,
such that the open folders would have a different icon. Also, we would
ignore that icon in properties.
Spacial nautilus has been gone for maybe 15 years now.
The properties dialog provides the ability to set a custom icon.
These are not icon paintables, but rather loadable icons, just
like thumbnails are. Therefore, they need to be snapshot into
the real area too, otherwise they are going to be too large.
This brings back a feature originally introduced by commit 0d4555d76f
Back then, it used gdk_cairo_surface_create_from_pixbuf() to apply the
scaling factor, but in GTK 4 we can no longer consume cairo surfaces
directly. Instead, we are to use paintables.
For themed icons we already use GtkIconPaintable, which just works.
We've also been scaling thumbnails down in advance using GdkPixbuf API,
and keeping a cache of scaled thumbnails.
But nowadays we can push that scaling job into the render nodes,
taking advantage of GPU. This is also a lot simpler.
Thumbnails in Properties were sometimes larger than the requested size.
This is because we didn't pass the FORCE_THUMBNAIL_SIZE flag.
There were probably good reasons for this flag in the past, but there
are none now. If we request a size, that should be the size we get.
So, drop this flag entirely and default to forcing the size everywhere.
