Andrea Azzarone authored Jul 30, 2016 and Iain Lane committed Aug 01, 2016

The problem is that in the function canvas_container_set_workarea the screen width
and height are in "application pixels" while the workarea ones are in "device
pixels" so when the scaling is > 1, the margins are not properly setted.

We need to scale-down the workarea geometries to "application pixels".

https://bugzilla.gnome.org/show_bug.cgi?id=769302

When thumbnailing a directory with jp2 some times nautilus
was crashing.
However tests on gdk_pixbuf were successful and gnome-desktop-thumbnails
generation tests were also working.

Also, nautilus is using raw pthreads in the thumbnail generation
code, and seems the crash was actually only happening when inside the
pthread and when using gdk-pixbuf, not only the gnome-desktop-thumbnail.

Looking at the implementation of glib in threads and nautilus, one of
the differences is that nautilus sets a stack size.
The crash is happening because, unluckely, libjasper with some big
images is using more stack size than the one nautilus is setting, which
leads to a crash in libjasper.

To fix it, remove the stack size set by nautilus, similarly to what glib
does, not setting an actual stack size.

Obviously the right thing to do is rewrite nautilus code to use the
glib threads, but I want to let that as a newcomer bug to do.

This was a wrong fix and it's only needed on 3.14

This reverts commit 4c56f31c.

If the name is the empty string then nautilus_file_set_display_name
won't actually set the display name. In this case we were returning
NULL from nautilus_file_peek_display_name, which some of our callers
weren't prepared to handle. This led to crashes.

https://bugzilla.gnome.org/show_bug.cgi?id=700507

We were using the internal list of the application to
iterate through the windows and closing them.
Problem is that when closing one window, the list is modified,
so next time accessing the list we are accessing the "old"
list, which is invalid and makes nautilus crash.

To fix it make a copy of the list to preserve the consistency.

https://bugzilla.gnome.org/show_bug.cgi?id=755803

We changed to only show access time for sorting in the sort menu
in 3.16 to avoid having both sorting options always present.
But for folders like Downloads, the most useful sorting criteria is
actually modified time, since it orders the files in downloading order.
Actually modified time is more useful than access time is all cases
except in "Recent", which what we actually want is the most recent
accessed or modified file.

For that, show only Modified Time sorting menu item in all places
except in "Recent", where we will show only Access Time.

https://bugzilla.gnome.org/show_bug.cgi?id=748185

Sometimes the file can be gone without even noticing when
changing the location (and therefore creating the attached bookmark
to that new location).
In bookmark_changed we just disconnected the file if that happened,
so we where failing graciously. But that was not the case when just
changing the location, where we were asserting that the file is not gone
and therefore crashing in such case.

Instead of that, do something similar as bookmark_changed and just
clean up some of the bookmark objects and hope for the best.

After back and forward on this, users used both, and most of them
didn't know about the other shortcut, which makes trying to use
only one shortcut for this action too controversial for what it worth.

So allow both shortcuts for this specific case.

The style tag needs to be inside the <object> scope

So the user can open a folder in a different app.
This is useful in cases like IDEs or text editors
for entire projects.

https://bugzilla.gnome.org/show_bug.cgi?id=691479

António Fernandes authored Mar 15, 2015 and Carlos Soriano Sánchez committed May 13, 2015

We are setting the sidebar as visible in the ui definition and binding
this visibility to the disabled-chrome property (inversely) to prevent
the sidebar from being visible in the desktop. But this also makes
the sidebar visible in all new windows, ignoring both the state of the
"Sidebar" toggle in the app menu and the start-with-sidebar setting.

Fix this by setting the sidebar as not visible in the ui definition and
removing the binding. The sidebar will be made visible if appropriate
in the nautilus-window-initialize-actions function.

Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=746217

As we allow to open them with the default app, but in this
case we have to ensure all selected files can be opened by
a single app.

Seems people were used to it instead of the ctr+r shortcut.