GNOME Bugzilla – Bug 411757
Can't rearrange columns with drag-and-drop
Last modified: 2021-06-18 15:49:40 UTC
1. In a folder window, choose "View" > "View as List". 2. Drag the header for any column (except for "Name") to the left or right of any other column (except for "Name"). What should happen: The columns should be rearranged accordingly. What actually happens: Nothing. Problem occurs in: Nautilus 2.16.1, Ubuntu 6.10 Does not occur in: Windows 98 and later, Mac OS 8.5 and later Apologies if this hasn't been reported before; I'd be surprised if it hasn't, but I can't find it.
Thanks for the bug report. Confirming. It'd be really nice to have this fixed.
Created attachment 165622 [details] [review] Allow rearrange of columns with drag-and-drop (#411757)
Review of attachment 165622 [details] [review]: So you need to connect to "columns-changed" to store the column order after they have been moved? The code that handles this kind of changes in fm-list-view is quite hairy already, and I'm not really fond of g_object_set_data() anyway. Maybe it's possible to turn the details->columns hash table the other way round and adapt the other code that uses the table? I also inlined some more formal comments below. ::: src/file-manager/fm-list-view.c @@ +1512,2 @@ view->details->file_name_column = gtk_tree_view_column_new (); + g_object_set_data (G_OBJECT (view->details->file_name_column), "column_name", g_strdup ("name")); If we're going to use _set_data(), you should use _set_data_full(), passing g_free as a destroy notify for the duped string (here and below). @@ +1700,3 @@ } static gboolean Why gboolean? @@ +1702,2 @@ static gboolean +tree_columns_changed_callback (GtkTreeView *widget, gpointer user_data) I am a bit worried about the interaction of this callback with all the code running in apply_columns_settings(). That function is called to sync the metadata values with the actual view; correct me if I'm wrong, but we might end up doing useless work like - read metadata - apply - columns_changed signal - setting the same metadata again when something changes programmatically due to e.g. the column chooser. @@ +1730,3 @@ + NAUTILUS_METADATA_KEY_LIST_VIEW_VISIBLE_COLUMNS, + list); + g_list_free (list); What you do here is basically a no-op, since get_visible_columns() fetches the array from the metadata. @@ +1751,3 @@ + g_list_free (list); + + g_strfreev (visible_columns); You should also free column_order.
Cosimo, yeah, you're right the patch broke the selection of columns in preferences. Is there any other signal I can listen to get changes to the columns made by the user? I could probably use the hashmap.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.