Re: Help to solve bug 132326



Hi again,

in first place, thank you for your help. The "crash" I explained was not a crash, but a side-effect of deleting the directory I was browsing, so the nautilus window was closed automatically. If I delete another directory it doesn't happen. Maybe the right behaviour would be the same as moving to the trash: leave the tree unselected.

On the other way, I've applied all your suggestions, although the patch is not complete: I've tried to apply the same conditions than the directory view to enable the delete action, but something is not working:
 - Trying to detect if the file is a special link doesn't work, although I've tried using the same macro that the other views use (NAUTILUS_IS_DESKTOP_ICON_FILE).
 - In the same way, trying to detect if the parent file is writable doesn't work... I don't know why, but I get results like / is writable...

I attach a new version of the patch to bugzilla. Any suggestions will be appreciated.

Thanks,
Ferran




2006/1/4, Christian Neumair <chris gnome-de org>:
Am Dienstag, den 03.01.2006, 22:24 +0100 schrieb Ferran Puig:
> I'm trying to provide a patch to bug 132326, since it seems to have
> been "abandoned" for some time.

Thanks for working on this, and welcome to the developer family!

> I attach the work I've done so far (against the gnome 2.12 branch),
> based on the original patch by Nirmal kumar and the comments provided,
> although there are two parts which I'm not sure how should be done:
>
> 1. Now the "delete" command in the popup menu is always enabled (if
> the user has activated the option to show the command). Should I do
> exactly the same checks done in fm-directory-view.c before enabling it
> (file is not read only, file is not an special link and file is
> neither home nor desktop directory) ??

Yes, that would be great. This kind of consistency is really important.

> 2. When I delete a file with this patch, the file is deleted, but
> nautilus crashes... obviously I'm missing something, but I don't know
> what it is? Any idea?

I cannot reproduce this with Nautilus HEAD. Maybe you could follow the
steps described at [1] to get a backtrace.

On the patch:

                gtk_widget_set_sensitive (view->details->popup_trash,
can_move_uri_to_trash (uri));
                g_free (uri);

+               if (show_delete_command_auto_value) {
+                       gtk_widget_show (view->details->popup_delete);
+                       gtk_widget_set_sensitive
(view->details->popup_delete, TRUE);
+               } else {
+                       gtk_widget_hide (view->details->popup_delete);
+               }

I'd prefer if you did

gboolean can_move_to_trash;

...

uri = ...
can_move_to_trash = can_move_to_trash (uri);
g_free (uri);

...

gtk_widget_set_sensitive (view->details->popup_trash,
can_move_to_trash);

and pass can_move_to_trash to the sensitivity call instead of TRUE (cf.
my comments on "1."). The menu functions from the directory view all
seem to follow that "initialize once - use multiple times" pattern for
boolean variables which involve some extra computation.

+       static gboolean setup_autos = FALSE;
+
+       if (setup_autos == FALSE) {
+               eel_preferences_add_auto_boolean
(NAUTILUS_PREFERENCES_ENABLE_DELETE,
+
&show_delete_command_auto_value);
+               setup_autos = TRUE;
+       }

eel_preferences_add_auto_boolean (NAUTILUS_PREFERENCES_ENABLE_DELETE,
                                  &show_delete_command_auto_value);

should IMO be moved to fm_tree_view_class_init instead.

[1] http://live.gnome.org/GettingTraces

--
Christian Neumair <chris gnome-de org>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDvDIPWfvsaU5lO4kRAgxvAKCiX21uqyGd5YsihPQ8uR6eaZ5YigCfTPrA
6mwqRVsRSlwcdKtz6V8EBh0=
=oFD3
-----END PGP SIGNATURE-----





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]