GNOME Bugzilla – Bug 301615
Have ability to "lock" individual desktop icon positions
Last modified: 2018-01-02 18:48:02 UTC
I was thinking it would be nice to be able to "lock" certain desktop icons to their position so that they could not be moved, for instance, when doing a clean up or when drawing a select box and moving multiple icons. This would allow users to have their "special" icons in another portion of the desktop, for instance, if I wanted my trash icon to always stay at the bottom right, or my home icon to always stay at the top right. This would work similar to how we can lock panel applets. Just right-click and select "Lock icon position".
thanks for the bug
Created attachment 47250 [details] [review] Implements locked desktop icons I took a little time myself to hack around nautilus-2.10.1 to see how difficult it would be. I have a patch that implements the basic idea of this concept, however, I don't know how many people would actually be interested in having this feature implemented. This patch implements the following: * Ability to set the locked status of an icon or a selection of icons * When cleaning up, skip positioning on locked icons * Cannot drag, repoisition, or stretch a locked icon. Currently, auto-layout of unlocked icons occurs as if no other icons are there, so if you have a locked icon in the upper-left corner, it will overlap with another icon. I'm not aware of an easy way to have unlocked icons position themselves with regard to locked icon positions to avoid overlapping. This is my first attempt at patching something, so if it's completely messy or full of errors, you'll know why :) This patch is agains nautilus-2.10.1 (I didn't bother w/ CVS yet, if someone can verify that it patches against CVS that would be great...)
Thanks for your efforts! This looks really promising :). + for (slist = gtk_action_get_proxies (action); slist != NULL; slist = slist->next) { + proxy = slist->data; + if (GTK_IS_CHECK_MENU_ITEM (proxy)) { + lock_menu_item = GTK_CHECK_MENU_ITEM(proxy); + lock_menu_item->active = nautilus_icon_container_is_locked (icon_container); + lock_menu_item->inconsistent = nautilus_icon_container_is_locked_inconsistent (icon_container); + } + } You should rather use gtk_toggle_action_set_active. GtkCheckActions don't seem to support the inconsistent property, so feel free to use your for loop for that. Also, I think nautilus_icon_container_set_locked is a bit odd, since it seems to make all selected locked icons unlocked and vice versa. You should rather move its loop to action_lock_callback, add an additional NautilusIcon * parameter to nautilus_icon_container_set_locked and just have the signal emission as function body.
> Also, I think nautilus_icon_container_set_locked is a bit odd, since it seems to > make all selected locked icons unlocked and vice versa. You should rather move > its loop to action_lock_callback, add an additional NautilusIcon * parameter to > nautilus_icon_container_set_locked and just have the signal emission as function > body. This suggestions implies that you use gtk_toggle_action_get_active to determine the desired locking state of all selected items. nautilus_icon_container_is_locked should IMHO be called nautilus_icon_container_selection_is_locked, same for nautilus_icon_container_is_locked_inconsistent. On the other hand, you could also merge them to _selection_is_locked and have an additional gboolean * locked_inconsistent parameter.
> You should rather use gtk_toggle_action_set_active. GtkCheckActions don't seem > to support the inconsistent property, so feel free to use your for loop for that. when I use gtk_toggle_action_set_active(), I get undesired results, ie, the checkbox just keeps checking/unchecking itself. I'm guessing this is because calling gtk_toggle_action_set_active triggers something that in effect re-triggers itself (for lack of a better explanation). > Also, I think nautilus_icon_container_set_locked is a bit odd, since it seems to > make all selected locked icons unlocked and vice versa. You should rather move > its loop to action_lock_callback, add an additional NautilusIcon * parameter to > nautilus_icon_container_set_locked and just have the signal emission as function > body. The reason nautilus_icon_container_set_locked looks the way it does is bacuase I was attempting to keep consistent with the current coding style. There necessary headers aren't available in fm-icon-view to deal with NautilusIcon, ie, anything that deals with NautilusIcon is in nautilus-icon-container. But, you're right when you say the function looks confusing. I could either change "nautilus_icon_container_set_locked" to "nautilus_icon_container_toggle_locked" or I could give it a gboolean param telling it whether to lock or unlock. > This suggestions implies that you use gtk_toggle_action_get_active to determine > the desired locking state of all selected items. The way I determine the locking state of an icon is simply by checking its is_locked property. > nautilus_icon_container_is_locked should IMHO be called > nautilus_icon_container_selection_is_locked, same for > nautilus_icon_container_is_locked_inconsistent. On the other hand, you could > also merge them to _selection_is_locked and have an additional gboolean * > locked_inconsistent parameter. The reason I named the _is_locked function that way is because I was attempting to keep in line with _is_stretched, which returns true if _any_ of the icons are stretched. (You're right, however, that it makes more sense to call it _selection_is_locked).
I also thought of a couple of usability questions while making this: * Should we be able to drag locked icons to other places, such as trash, other folders, programs, etc? * Should unlocked icons "respect" the positions of locked icons when auto-laying-out, or should they just completely ignore locked icons? I might see a situation where someone wants to lock some icons in a place where auto-layout might overlap them with unlocked icons.
*** Bug 312335 has been marked as a duplicate of this bug. ***
*** Bug 327949 has been marked as a duplicate of this bug. ***
Has there been any progress on this, a year and a half after the patch was submitted? "Should we be able to drag locked icons to other places, such as trash, other folders, programs, etc?" I don't think so. If you lock something it should stay there until you unlock it. "Should unlocked icons "respect" the positions of locked icons when auto-laying-out, or should they just completely ignore locked icons?" I'm pretty sure they should respect their position, to avoid overlapping.
The Nautilus code has changed quite a bit since that patch, and I haven't had much time to take a look at it. If you're skilled and willing, you're more than welcome to write your own patch. Ideally, we need to have a patch against current development version, so that they might add it into the final release.
I'd love to, but I can't code at all. Sorry Ben.
Created attachment 95454 [details] [review] Implements locked desktop icons (nautilus-2.18.1) Here's an updated patch for 2.18.1. You'll also need the eel patch which I forgot to include last time :). There is still a bug that occurs when "Clean Up by Name" is used.. it positions icons over the locked icons, so I will still need to figure out what is going on there. Once I get that fixed, I'll try patching against cvs...
Created attachment 95455 [details] [review] eel patch (required for nautilus locked icons patch)
Created attachment 106373 [details] [review] Updated Patch Updated Patch for 2.21.93/rev13861. Can't code at all, so no code change, just updated to apply to the new version.
Thanks for the updated patch Christopher. Does this patch still has the bug Ben describes in comment #12?
Yes. Like I said I can't develop C, so there's nothing I can do about.
Hmm, I found another issue: Then an Icon is locked it can only be opened by middle-click or context-menu, left-click does not work. Can you have a look at the patch, please?
I'm working on an updated patch for this.
*** Bug 473712 has been marked as a duplicate of this bug. ***
Any news Cosimo?
Created attachment 120734 [details] [review] updated patch for nautilus-2.22.5.1 updated patch for nautilus-2.22.5.1. Make sure to also patch eel2 using the eel2 patch also attached to this bug.
could you please make a patch for current trunk? (2.25.1) - it doesn't apply here. and is the bug from comment 12 fixed?
and the one from comment 17 ?
Can't reproduce #17, and #12 is still an issue. I'm pretty new to hacking gnome, and I have no idea how to work with trunk. Right now I'm just getting the source for my current deb pkg, applying the patch, and using dpkg-buildpackage to recompile, then installing the new deb. If you can point me to a good howoto on how to develop on gnome trunk without messing up my normal envirotment, that'd be great!
That's pretty esay: grab the source: svn co http://svn.gnome.org/svn/eel/trunk eel svn co http://svn.gnome.org/svn/nautilus/trunk nautilus then use ./autogen.sh instead of ./configure the first time. other from that proceed as normal. with svn up you can update to the latest trunk
(In reply to comment #6) > I also thought of a couple of usability questions while making this: > > * Should we be able to drag locked icons to other places, such as trash, other > folders, programs, etc? > > * Should unlocked icons "respect" the positions of locked icons when > auto-laying-out, or should they just completely ignore locked icons? I might > see a situation where someone wants to lock some icons in a place where > auto-layout might overlap them with unlocked icons. On Q1: Yes. Definetly. Personally I see this as a method for avoiding having automoving icons when cleaning up the desktop -- not as a way to avoid moving them completly. On Q2: Yes. Absolutely. If not, the whole idea seems pretty useless to me. I see this as a method for making sure that important icons are in the same position, no matter what other clutter is around and when you last cleaned your desktop. On that note, I'm beginning to have a look at producing a patch myself -- I have to find out how to get around trunk first though. I see this as a pretty simple feature that only requires two types of changes -- first of all it should be possible to set and unset the locked status and second of all the auto-align code needs to change too.
Frederik, not sure if you noticed, but we already have a patch for Nautilus-2.22.5, but there is a bug with the auto-layout that causes unlocked icons to overlap locked icons. If you can help with patching this against trunk, fixing the bug, and testing, perhaps we can work on getting it in officially.
Ok, so apparently I _can_ reproduce the issue where locked icons cannot be opened. It seems that this happens when nautilus starts up with the icons already locked. If you unlock and lock again, then the icons can be opened. If I get time, I'll look into this, but anyone else is more than welcome to help debug this feature.
(In reply to comment #27) > Frederik, not sure if you noticed, but we already have a patch for > Nautilus-2.22.5, but there is a bug with the auto-layout that causes unlocked > icons to overlap locked icons. If you can help with patching this against > trunk, fixing the bug, and testing, perhaps we can work on getting it in > officially. > Nope, I hadn't noticed that there was one for 2.22.5. I'll take a look at it when time presents itself (sometime later this week). I still haven't quite found my way around trunk though.
This is obsolete as well now.
I'll see what I can do (...) Don't expect anything before 2.30/3.0
*** Bug 670305 has been marked as a duplicate of this bug. ***
Review of attachment 95455 [details] [review]: eel/eelmarshal.list was removed by commint 75a03a440ebff23ccbf8674ca4a0e9f6475ebbb8 Rejecting pending patch to tie up Bugzilla loose ends before transition to GitLab.
Starting with version 3.28, nautilus will not handle the "files on desktop background" feature. For better alternatives, read this blog post https://csorianognome.wordpress.com/2017/12/21/nautilus-desktop-plans/