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

Merge latest pot

Clean up a11y code and make sure inheritance for
EelCanvasAccessible->NautilusIconContainerAccessible and for
EelCanvasItemAccessible->NautilusIconCanvasItemAccessible work properly.
This makes the ATK state machinery in EelCanvasItemAccessible work
again, which fixes

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

eel_accessibility_create_derived_gtype() is now unused.

Instead of eel_accessibility_create_derived_type.

If the final class does not override the get_accessible method, it will
inherit it from the parent class; what we're interested in is the first
class for which get_accessible is != from our class get_accessible.

Use the previously introduced function to create a suitable
GtkAccessible implementation.

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

For EelEditableLabel, we need to create an object derived from the
accessible type of the parent class; since that will be a
GtkWidgetAccessible, which is private, we can't just subclass it using
the regular GObject mechanisms.
This functions creates a derived GType by peeking at the parent
accessible class and type.

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

rustyBSD authored May 21, 2012 and Cosimo Cecchi committed May 21, 2012

Or images with a very long description will create a label that is
bigger than the whole screen.

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

In got_file_info_for_view_selection_callback(), we unconditionally try
to fetch information for the parent directory in case the selection is a
regular file, but we should avoid doing that when the file has no
parent, such as when it's the root of a web server.

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

Instead of just packing it into the GtkInfoBar's box, since that will
put it after the buttons of the action area.

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

We already make them non-selectable - there's no point in having a menu
for headings here.

https://bugzilla.redhat.com/show_bug.cgi?id=819404

Fixes a lot of reported crashers with NFS/Samba volumes.

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

Sébastien Bacher authored Apr 27, 2012 and Cosimo Cecchi committed Apr 27, 2012

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

Don't set the ACTIVE flag if we don't have focus, it just doesn't make
sense.

Charles Kerr authored Apr 18, 2012 and Cosimo Cecchi committed Apr 18, 2012

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

Charles Kerr authored Apr 18, 2012 and Cosimo Cecchi committed Apr 18, 2012

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

When the row is selected, and we right click on it, make sure we popup
its context menu and not its parent's, since the selection is a stronger
indication of intent.

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

Since that's what GVfs sets.

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

Otherwise untitled files end up with a (possibly) corrupt part of the
name appended.

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

There were previously some tricks in nautilus to this effect:

 - when you call nautilus_file_get_volume_free_space() on a
   NautilusFile, the return result is NULL at first and later you get a
   "changed" signal on the file after the value is filled in

 - the value is being stored inside the NautilusDirectory equivalent for
   the file that is created when the call is first performed and kept
   around until after the change signal fires (so that the person
   receiving the change signal can still get the data).  This is done to
   save space by not expanding NautilusFile.

   The NautilusDirectory is then dropped after the change signal is done
   firing.

 - the nautilus properties window has a 200ms timeout after changes to
   files being reported before it re-queries the properties

The end result is that the NautilusDirectory (which holds the
information about the free space) is already freed by the time the
properties window tries to update the free space display.  This results
in the directory being recreated and the process starting over again.
The end result is that we never get the free space shown in the dialog
and instead we have an infinite loop of CPU usage (fortunately repeating
only every 200ms, so you get ~5% CPU usage instead of 100%).

We can solve the problem by just storing the free space information
directly in the NautilusFile details structure and dropping the dance
with NautilusDirectory; nothing in NautilusDirectory is actually using
that information anyway.

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