User-Agent: Opera/9.10 (X11; Linux i686; U; en) Build Identifier: If you select a backdrop and change that file, the actual backdrop does not get updated to show the contents of the changed file. This is expected. But, if you go into Desktop Settings and browse to select the image again, THEN it should be updated. But it is only updated if you select another image in between. Reproducible: Always Steps to Reproduce: 1. Select an image to use as backdrop 2. Change the image file in GIMP 3. Select the new image (with the same filename as before) to use as backdrop Actual Results: The old image is still used as the backdrop Expected Results: The new image should be used as the backdrop
This isn't really a bug, per se. What you really want here is file monitoring.
Hi I have stopped reporting new bugs to open source project for reasons like this. Either people cannot read or they do not want to read. I do not want file monitoring. I quote: "If you select a backdrop and change that file, the actual backdrop does not get updated to show the contents of the changed file. THIS IS EXPECTED." But when use an open file dialog to browse for a file, I expect that it be read from disk. I don't need file monitoring. I can go and select the file manually. The bug is, that when I go and manually open the file again, XFCE refuses to open the file again, because it happens to have the same name as the old file. This is outrageous. XFCE shouldn't care what I name my files. This bug was reported quite a while ago. After that, the desktop settings window has been re-designed so that the bug probably isn't there any more. Now there is a list of images. When the bug was reported it wasn't like that. You had to manually select the file in a open file dialog. And then XFCE just ignored my file selection and did nothing instead of actually changing the wallpaper. Don't tell me this not a bug. Don't tell me it has anything to do with file monitoring. The new desktop settings window has another bug, that makes it very hard to see if this bug is still here! Instead of selecting an individual file there is now a list that is added to. Selecting a file again is not even possible without selecting a different file inbetween. So what is the new bug? Notice how I said that files could be added to list of wallpapers. Just think about it. Files can be added. BUT FILES CANNOT BE REMOVED (XFCE 4.6.0 on Arch). The "-" button is ALWAYS grayed out. Wait a bit, they CAN be removed. Just close the window, and all the files you added to the list for use later are gone the next time you open it... And there is another bug: The same image can be added multiple times. And if you change the file inbetween, the preview image (in the list) actually reflects the file contents. But even when selecting the new file in the list (with the new preview image) the desktop still displays the old image (which is not in the file any more). So the old bug is still there. And also, svg files, which are called scalable, because they are, well scalable, are rendered before they are scaled instead of being rendered at the correct resolution. So they don't work well as backdrops. You don't need to fix any of this, as I don't use XFCE any more.
No, I read it perfectly fine. File monitoring *would* solve your problem. A hack to re-read a file when it's re-selected would be just that, a hack. *That* bit is a gtk issue, not an Xfce one. At any rate, the re-select issue isn't really there anymore with the new settings dialog. I suggest you drop the attitude and understand that some people may know a bit more about their software than you do. Your rant is not appreciated. If your goal is to actually get things fixed, you might want to avoid being a dick. If your goal is just to vent your feelings of frustration, I sympathize, but this is not the place to do it.
Sorry for being obtuse, I've got the flu. I maintain that the behaviour in the version of XFCE that this bug was reported against, was non-standard (in the meaning: most GTK programs don't do it this way).
Yes, sorry, I was thinking of something else; it has nothing to do with gtk of course. The problem is in how both xfdesktop and the settings dialog interacts with our configuration storage system, xfconf. Xfconf doesn't allow you to "change" a setting to the same value it's already set to. Or rather, it will, of course, but it doesn't generate a "PropertyChanged" signal when the new value is the same as the old value, so xfdesktop has no idea that you re-selected the same file. This is a very useful optimization in just about all cases, and I have no intention of changing it. There are various ways of hacking around this, such as setting the property to the empty string, and then back to the correct file name, but you'll get ugly extra flicker, and it's a bit of a hack that I don't like. So really, you *do* want file monitoring. If the file that's set as the backdrop changes, wouldn't you want xfdesktop to notice and update itself?
> So really, you *do* want file monitoring. If the file that's set as the > backdrop changes, wouldn't you want xfdesktop to notice and update itself? Personally, I wouldn't want that. However, 99% of users would probably want it. A simple and working (but ugly) way around the caching in xfconf would be to set a dummy filname (not empty) that means that xfdesktop should do nothing (must be a filename that is invalid, such as a single dot). Then set the correct filename. The property will have changed, so xfdesktop will reload the image.
(In reply to comment #6) > A simple and working (but ugly) way around the caching in xfconf would be to > set a dummy filname (not empty) that means that xfdesktop should do nothing > (must be a filename that is invalid, such as a single dot). Then set the > correct filename. The property will have changed, so xfdesktop will reload the > image. Which is exactly the sort of hack I just said I won't implement.
With latest xfdesktop versions, if you select a backdrop and change that file, the actual backdrop does get updated to show the contents of the changed file. Closing.