GNOME Bugzilla – Bug 688812
UX: Setting a wallpaper is awkward.
Last modified: 2021-01-11 12:35:21 UTC
Created attachment 229579 [details] video Setting a wallpaper through 'Files' is working fine, but it's producing some unnecessary side effects. (I'll split this into multiple reports if you want). 1- It creates a useless ~/Pictures/Wallpapers: I have my wallpaper collections at a different partition, setting something as my background copies that file to ~/Pictures/Wallpapers which is: a) Unnecessary. In terms of copying and creating a new directory without my approval. You could've used a .local or .cache directory. b) Useless. Even if the creation of the new directory could be considered a new collection of my most-used backgrounds, the 'Backgrounds' section in GCC isn't picking up files from that directory. Which makes it completely useless. 2- Setting the same wallpaper will show a confirmation dialog that this file exists. Which can be extremely confusing since the user did NOT press 'copy/paste'. 3- Trying to use the directory to set a fav. wallpaper again will automatically create a duplicate. Lastly, video attached.
*** Bug 689534 has been marked as a duplicate of this bug. ***
*** Bug 692962 has been marked as a duplicate of this bug. ***
*** Bug 701852 has been marked as a duplicate of this bug. ***
This also affects 3.8.x I have a suggestion: Can we put wallpapers in ~/.local/share/nautilus, or ~/.local/share/wallpapers? With the latter, assuming we just automatically overwrite instead of asking for confirmation (which seems reasonable since people shouldn't be storing files they want in ~/.local/share/nautilus) the behavior is consistent with that of color profiles, which put .icc profiles in ~/.local/share/icc and does not worry about overwriting.
Created attachment 246374 [details] [review] Changes directory of saved wallpapers in nautilus
nautilus shouldn't need to copy the file itself, it should just pass the URI to gnome-control-center's background panel (which would copy the file if necessary). eog's way of setting the background is awkward at best as well. Designers, should we show a UI when setting the wallpaper, or should we just set it and ask the user if they want to change it (as eog does)?
(In reply to comment #6) ... > Designers, should we show a UI when setting the wallpaper, or should we just > set it and ask the user if they want to change it (as eog does)? I think we should just set the image as the wallpaper, and not copy the file in a way that is visible to the user (ie. it's fine to copy it to a hidden location, but I wouldn't copy it to ~/Pictures/Wallpapers).
I agree, since Gnome doesn't really have any configuration options for wallpapers. If there was a choice to set the fitting method (i.e., scale, stretch) or other options then the most intuitive option would be to feed the picture into the Background section of Settings. Another inconsistency is that the Background section of Settings doesn't even show the pictures in ~/Pictures/Wallpapers! If you select the Pictures tab, it shows the pictures in ~/Pictures only, without the contents of the sub-directories. So, we're deciding to copy to a hidden location. Does anyone know of a better place to put them than '~/.local/share/wallpapers'? Also, what is the best way for Settings to show these wallpapers? I think all previous custom background choices should be shown, and it should offer the ability to delete them. It would effectively be a glorified file browser for ~/.local/share/wallpapers, but I think that makes sense from a user perspective. Thoughts?
(In reply to comment #7) > (In reply to comment #6) > ... > > Designers, should we show a UI when setting the wallpaper, or should we just > > set it and ask the user if they want to change it (as eog does)? > > I think we should just set the image as the wallpaper, and not copy the file in > a way that is visible to the user (ie. it's fine to copy it to a hidden > location, but I wouldn't copy it to ~/Pictures/Wallpapers). I'm asking whether or not we should show the background panel UI or not. We already copy files that aren't from the user's pictures dir, or from the stock backgrounds to a hidden directory.
*** Bug 702667 has been marked as a duplicate of this bug. ***
*** Bug 720454 has been marked as a duplicate of this bug. ***
*** Bug 721471 has been marked as a duplicate of this bug. ***
*** Bug 724722 has been marked as a duplicate of this bug. ***
I think this is now doubly awkward, because the "Set as wallpaper" option in nautilus does not set the lock wallpaper, making it very difficult to set them to the same picture.
(In reply to comment #9) > (In reply to comment #7) > > (In reply to comment #6) > > ... > > > Designers, should we show a UI when setting the wallpaper, or should we just > > > set it and ask the user if they want to change it (as eog does)? ... > I'm asking whether or not we should show the background panel UI or not. We > already copy files that aren't from the user's pictures dir, or from the stock > backgrounds to a hidden directory. Right, yes, I think we should just change it and not show the additional UI (although I have to say that I'm not entirely sure what that would look like). Unless you can say why this extra UI would be much better.
Keep it simple, devs ! Set as wallpaper > change link to file, don't copy anything!
*** Bug 723042 has been marked as a duplicate of this bug. ***
From a comment in duplicate bug 723042: > gnome-control-center copies files to the cache if they're not in ~/Pictures (or in a sub-folder) or they're remote files (Flickr source). I think it would make sense for nautilus to do the same thing.
Review of attachment 246374 [details] [review]: Rejecting as what we want is to copy them in the cache.
*** Bug 752554 has been marked as a duplicate of this bug. ***
Bastien, is there a way to pass to gnome-control-center an uri to set as background so it manages all the cache copy etc? I cannot find anything on dbus or in the code. If not, we probably will need something similar if we want to make the pictures set as background in nautilus to be visible in gcc.
*** Bug 747591 has been marked as a duplicate of this bug. ***
*** Bug 765004 has been marked as a duplicate of this bug. ***
*** Bug 748114 has been marked as a duplicate of this bug. ***
Hey Bastien, ping on comment 21?
(In reply to Carlos Soriano from comment #21) > Bastien, is there a way to pass to gnome-control-center an uri to set as > background so it manages all the cache copy etc? > > I cannot find anything on dbus or in the code. > > If not, we probably will need something similar if we want to make the > pictures set as background in nautilus to be visible in gcc. Your office neighbour Debarshi is the maintainer of the background panel, best ask him.
Created attachment 332125 [details] It explains the behavior I originally posted a bug explaining this situation but they marked as duplicate, however, I decided to attached the video and the original comment because I believe it's important: As the attached video shows, if I want to set a particular image located in any folder as a wallpaper, gnome doesn't set it directly from that folder but copies that file into a folder named "wallpapers", if I copy another image or try to use the same file I used before, gnome is creating a copy of the same file to set it as the background image. Gnome should set the wallpaper directly where the file is located.
*** Bug 769748 has been marked as a duplicate of this bug. ***
(In reply to Ricardo Ramos from comment #27) > Gnome should set the wallpaper directly where the file is located. I don't think that this is a good idea in case the file is moved, corrupted, or deleted. I think storing them in a separate place is a good idea, just how it's done should be changed. Each time a file is moved to Wallpapers it should be given a new name such as "Wallpaper-1" and the number should be increment each time. This avoids the problem with files with duplicate names being set. Then to make things not just clog up with duplicate images it could also check if you are trying to set a file which, despite probably having a different name, is the same. And just set the file in the Wallpapers folder instead of creating a duplicate file in there with a different name.
(In reply to cooks.go.hungry from comment #29) > (In reply to Ricardo Ramos from comment #27) > > Gnome should set the wallpaper directly where the file is located. > > I don't think that this is a good idea in case the file is moved, corrupted, > or deleted. I think storing them in a separate place is a good idea, just > how it's done should be changed. That's ok but at least it should have the option to set that folder in a different location, like in a hidden .wallpaper folder located on home folder
(In reply to Ricardo Ramos from comment #30) > That's ok but at least it should have the option to set that folder in a > different location, like in a hidden .wallpaper folder located on home folder Exactly what I suggested in my bug which was marked as a duplicate of this one. All this should be done and stored more internally. Having them in a hidden folder in the user's home folder would be good.
It would be great to first hear the information alluded to in comment 21. If that comes to a dead end, I feel like emulating the behavior G-C-C exhibits is the way to go.
(In reply to cooks.go.hungry from comment #31) > (In reply to Ricardo Ramos from comment #30) > > That's ok but at least it should have the option to set that folder in a > > different location, like in a hidden .wallpaper folder located on home folder > > Exactly what I suggested in my bug which was marked as a duplicate of this > one. All this should be done and stored more internally. Having them in a > hidden folder in the user's home folder would be good. That's actually what gnome-control-center does (except it uses .cache/ instead of littering homedirs). The problem with g-c-c though is that the wallpapers accumulate in .cache with no obvious way to delete them... OTOH, keeping just the *current* wallpaper, at a fixed location, might be better. (That's what Windows does, as well as various other apps. The path should IMO be DE-specific but not app-specific (like .cache/gnome/wallpaper.png), so that you could set a wallpaper via eog and later another via Nautilus, and .cache won't accumulate old junk.)
(In reply to Mantas Mikulėnas from comment #33) > OTOH, keeping just the *current* wallpaper, at a fixed location, might be > better. (That's what Windows does, as well as various other apps. The path > should IMO be DE-specific but not app-specific (like > .cache/gnome/wallpaper.png), so that you could set a wallpaper via eog and > later another via Nautilus, and .cache won't accumulate old junk.) Sounds even better, but don’t you think that ~/.local/share would fit better? The user might just decide to nuke ~/.cache in hopes of freeing up some space and that would result in a blank background.
I agree, I wouldn't think of wallpapers as 'cached' content. And most users probably won't either, so they may just delete the .cache folder and get a shock. Deleting a cache should never cause such a noticeable problem as this would.
Yeah, .local/share/gnome/ sounds better. (I guess I was already afraid of *other* apps breaking when .cache is deleted, so I didn't think of users doing that freely, heh.) But in that case it definitely should avoid hoarding all past wallpapers. (There was a separate bug report for g-c-c, IIRC?)
I'm Using Arch with GNOME Shell 3.20.4 and Nautilus 3.20.3. The problem still exists. When you right click on an image and choose 'set as wallpaper' it copies the image to ~/Pictures/Wallpapers. It's fine if it has to copy the file in a cache somewhere but when you are in the ~/Pictures/Wallpapers directory and you set an image as a wallpaper it creates a copy called 'original-file-name (copy).jpg' which is very annoying. I would like to see two things done: 1) If the wallpaper being set is already in ~/Pictures/Wallpapers then do not make a copy. just set that image URI as wallpaper. 2) Would be nice if GDM (lock screen) adopted the wallpaper from the user's desktop so both were the same. (same as the functionality of Ubuntu's LightDM setup where it shows the wallpaper of the currently selected user at the lock screen.
*** Bug 779190 has been marked as a duplicate of this bug. ***
Created attachment 352114 [details] [review] improve UX when setting a wallpaper
Review of attachment 352114 [details] [review]: Hey! Thanks for this patch. However, this raises the concern that we were dealing with. How the user deletes a wallpaper with this solution? (From the point of UI/UX) ::: src/nautilus-files-view.c @@ +6663,3 @@ g_object_unref (parent); + + g_file_copy_async (nautilus_file_info_get_location (file), why this change?
(In reply to Carlos Soriano from comment #40) > Review of attachment 352114 [details] [review] [review]: > > Hey! > > Thanks for this patch. However, this raises the concern that we were dealing > with. How the user deletes a wallpaper with this solution? (From the point > of UI/UX) Hello, Thanks for having reviewed the patch. I'm sorry but I fail to understand the concern. The patch does what as been discussed in the most recent comments : - It keeps a copy of the picture in the file ~/.local/share/gnome/wallpaper - If another picture is chosen, the file is silently overwritten. It is basically what Windows and other apps do. Which wallpapers have to be deleted ? > > ::: src/nautilus-files-view.c > @@ +6663,3 @@ > g_object_unref (parent); > + > + g_file_copy_async (nautilus_file_info_get_location (file), > > why this change? By looking at all the bug reports (and my personal experience) the main issues people have come from the use of nautilus_file_operations_copy_move : the current implementation is basically a macro that can trigger dialog boxes or create duplicates automatically. I haven't found a public function in nautilus that can overwrite silently, so I have used g_file_copy.
Oh sorry, I didn't follow the last comments. See comment 21 and before, we still need a make the wallpaper available to gnome-control-center, otherwise we will have an inconsistency. Also, my point with "how do you delete the wallpaper" is, currently we put it in a user's folder because that's the way the user can delete the wallpaper if necesary. In the case we put it in ~/.local/share/gnome/wallpaper, how the user would delete it? What if the user wants to delete it, and for that, the user deletes the file from where it set the wallpaper but since we put a copy into a hidden folder the user doesn't know what's going on? You could argue the user would understand changing the wallpaper would be enough. So this point is not so important. Still the patch needs to make the wallpaper available to gnome-control-center somehow.
(In reply to Carlos Soriano from comment #42) > Oh sorry, I didn't follow the last comments. > > See comment 21 and before, we still need a make the wallpaper available to > gnome-control-center, otherwise we will have an inconsistency. The discussion has been going on for years, so I didn't know if comment 21 was a dead end or not. I made the patch, just in case. You can reject it if you want. It wasn't hard to do. > Still the patch needs to make the > wallpaper available to gnome-control-center somehow. The g-c-c looks into ~/Pictures and ~/.cache/gnome-control-center/backgrounds. I'll think about it, but each choice would raise a problem, wouldn't it ? Ah. I wish I could help, unfortunately the situation seems to be stuck. I don't see how to fix g-c-c's design problems in nautilus. Would you accept a patch that only fixes the "overwrite dialog" and "duplicates" issues (points 2 and 3 of comment 1) ? It won't be a perfect solution, but still an improvement.
Just a user's opinion: If I do 'gsettings set org.gnome.desktop.background picture-uri file:///home/hussam/Desktop/back', g-c-c will show the preview of this background even though it is not in a folder it recognizes. But if I change it, g-c-c cannot set it again which is ok. This however maintains compatibility with g-c-c. This can apply to nautilus. You can simply have nautilus do 'gsettings set org.gnome.desktop.background picture-uri file:///home/hussam/downloads/newpic.png' and not break anything. You don't necessarily need to make copies.
(In reply to slatchurie from comment #43) > (In reply to Carlos Soriano from comment #42) > > Oh sorry, I didn't follow the last comments. > > > > See comment 21 and before, we still need a make the wallpaper available to > > gnome-control-center, otherwise we will have an inconsistency. > > The discussion has been going on for years, so I didn't know if comment 21 > was a dead end or not. Yeah, the problem is more about finding a solution, rather than just code. > > I made the patch, just in case. > You can reject it if you want. It wasn't hard to do. Not at all! Just need a little more work to find the proper solution :) > > > Still the patch needs to make the > > wallpaper available to gnome-control-center somehow. > > The g-c-c looks into ~/Pictures and > ~/.cache/gnome-control-center/backgrounds. > I'll think about it, but each choice would raise a problem, wouldn't it ? Indeed, the solution I discussed with some of us is to have in gcc a DBUS API that allows to set the wallpaper, and then gcc needs to take it and put it in the cache. In this way, Nautilus is no longer controlling the wallpapers and other apps can set backgrounds properly (like GNOME Photos). What do you think? > > Ah. I wish I could help, unfortunately the situation seems to be stuck. I > don't see how to fix g-c-c's design problems in nautilus. Nah, it's about finding the best solution that fit both parts, I think with what I mention before we can do it. > > Would you accept a patch that only fixes the "overwrite dialog" and > "duplicates" issues (points 2 and 3 of comment 1) ? It won't be a perfect > solution, but still an improvement. Let's try to do the proper solution, and if we see nothing can be done then we can do a workaround like this, since as you mention it will be an improvement.
(In reply to Carlos Soriano from comment #45) > Indeed, the solution I discussed with some of us is to have in gcc a DBUS > API that allows to set the wallpaper, and then gcc needs to take it and put > it in the cache. > In this way, Nautilus is no longer controlling the wallpapers and other apps > can set backgrounds properly (like GNOME Photos). > > What do you think? I totally agree, a centralized and/or middleman way to handle all this would be a great solution. It would also be easier to handle the lockscreen. But a year later, there doesn't seem to be any progress. In the meantime, the users are still stuck with the current implementation in nautilus and its bugs for 5 years now ("duplicates" being the most reported bug, and actually the most easily fixable). > Let's try to do the proper solution, and if we see nothing can be done then > we can do a workaround like this, since as you mention it will be an > improvement. I understand. The proper solution would be the best of course. But are the g-c-c devs open to the idea ? How many more years will it take ? Imho, it would have been better to keep the things simple in the apps (just set a wallpaper, which is actually the current "API") and add the proper solution when it's done, instead of keeping the current nautilus' implementation. It would have been more consistent, and all those bug reports would have been sent to g-c-c, not to nautilus.
Yes, gcc devs are fine with the idea, I discussed with them. I think now it's just a matter of someone writting the code, and make the appropiate details correct. So it's a good time for someone to try to finally tackle this!
(In reply to Carlos Soriano from comment #47) > Yes, gcc devs are fine with the idea, I discussed with them. I think now > it's just a matter of someone writting the code, and make the appropiate > details correct. > > So it's a good time for someone to try to finally tackle this! Sorry for the spam, but that's really great news!
*** Bug 783727 has been marked as a duplicate of this bug. ***
*** Bug 786313 has been marked as a duplicate of this bug. ***
(In reply to Carlos Soriano from comment #47) > Yes, gcc devs are fine with the idea, I discussed with them. I think now > it's just a matter of someone writting the code, and make the appropiate > details correct. > > So it's a good time for someone to try to finally tackle this! What is the current state of this bug? It's been 2 years now and still no apparent progress has been made.
(In reply to Matic Bojan from comment #51) > (In reply to Carlos Soriano from comment #47) > > Yes, gcc devs are fine with the idea, I discussed with them. I think now > > it's just a matter of someone writting the code, and make the appropiate > > details correct. > > > > So it's a good time for someone to try to finally tackle this! > > What is the current state of this bug? It's been 2 years now and still no > apparent progress has been made. What you see is how it is. No one worked on it.
Hello, Matic. If you want to work on this issue, the starting point is creating an API in gnome-settings-deamon for setting a wallpaper. See discussion here: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/122
Fixed by https://gitlab.gnome.org/GNOME/nautilus/-/commit/ece6b8257047bfec13877a61d71d02bfa7384af0