| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of checking whether the URI of every item we add is a candidate
for selection, cycle through all the added items after inserting.
This also fixes a bug where the GtkTreeIter we used for keeping track of
the last added item was not up-to-date with the actual cell, since the
sort function we apply to the items will modify the position of the item
in the tree itself, making the iter invalid.
https://bugzilla.gnome.org/show_bug.cgi?id=668212
|
|
|
|
|
| |
We were using it just for GtkTreeDragSourceIface, which we can implement
ourselves.
|
|
|
|
|
|
|
|
| |
We were hitting an assertion when middle clicking a desktop icon, since
we were trying to open it in a tab (same window), and we don't really
want to do that on the desktop.
https://bugzilla.gnome.org/show_bug.cgi?id=655576
|
|
|
|
|
|
|
|
| |
Don't export nautilus_window_update_split_view_actions_sensitivity(),
but alwauys call it from nautilus_window_update_show_hide_menu_items(),
since that's what the code always does.
https://bugzilla.gnome.org/show_bug.cgi?id=669189
|
|
|
|
|
|
|
| |
In case a slot close is requested, we should still update the split view
actions sensitivity/state.
https://bugzilla.gnome.org/show_bug.cgi?id=669189
|
|
|
|
|
|
|
|
| |
Internally, GnomeBGCrossfade depends on the GdkWindow we pass on to
gnome_bg_crossfade_start() to be available during the whole crossfade.
If our widget is destroyed, we have to immediately stop the crossfade,
without waiting our finalization step, which happens after the widget
is already gone.
|
|
|
|
|
| |
This also prevents signals being emitted from it after our destruction,
as in https://bugzilla.gnome.org/show_bug.cgi?id=665796
|
|
|
|
|
|
| |
slot->pane is already cleared in nautilus_window_slot_dispose(), which
will get called while the slot is destroyed; setting it here can cause
an invalid memory access.
|
| |
|
|
|
|
| |
This caused some actions not to be scheduled for redo.
|
|
|
|
|
| |
We were allocating the wrong size for the NautilusApplication private
structure.
|
|
|
|
|
|
| |
When we redo a trash operation, we should make sure our trashed files
hash table stores the updated timestamp when we trashed the file again,
or we won't be able to trash them again.
|
|
|
|
|
| |
Don't stack allocate the struct for the file operations return value,
and make sure we don't return success for a failed operation.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
We can just store GFiles directly in the hash table and use
g_file_hash() and g_file_equal() instead of parsing the URIs ourselves.
|
|
|
|
| |
No need to call g_free() anymore.
|
|
|
|
|
|
|
|
| |
The rubberband fade-out effect should observe the gtk animation
setting, intened to make life easier for people running
resource contrained setups (like X11 over a network.)
Signed-off-by: Arthur Taylor <theycallhimart@gmail.com>
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Also, make the mtime checks actually useful; we need to check the
trash::deletion-date attribute and match it with the time we trashed the
file (which we can easily know using g_get_current_time()).
|
|
|
|
|
| |
We were querying the mtime of the trashed file after it was already
trashed, and we were also overflowing the guint64 assigning -1 to it.
|
|
|
|
| |
The action might be synchronous.
|
| |
|
| |
|
| |
|
|
|
|
| |
Get the info object from the manager and use that to build menus.
|
|
|
|
| |
And fix some typos.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rework NautilusFileUndoManager to use the new NautilusFileUndoInfo
objects.
At the same time, make it use a single item instead of a queue, turning
it into a state machine. This has various reasons; from a code
perspective, if we keep a stack of operations, we should also keep track
and invalidate items in there when something changes on the filesystem,
but this can be very expensive.
On the other hand in the UI we probably don't want to expose more than
one item anyway.
|
|
|
|
|
|
|
| |
Make it a GObject with subclasses for each type of operations.
This allows for easy sharing of the base class object with the view as
well, for menu information, and provides an async API to the undo
manager for the file operation.
|
|
|
|
|
| |
We want to know if a file operation failed for some reason, so that we
don't add it in the redo queue.
|
|
|
|
|
| |
So that dialogs triggered by the file operations can correctly be
parented.
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=667853
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Not queueing resizes may play oddly with the size request caches in
GTK+, resulting in gtk_widget_get_preferred_width/height returning
0 even after the canvas was populated.
https://bugzilla.gnome.org/show_bug.cgi?id=667831
|
|
|
|
| |
Fix distcheck.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Before checking if the GModule pulls in ORBit, we should make sure
g_module_open() returned a non-NULL GModule.
|