! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
xfdesktop doesn't save the arrangement of desktop icons after a resolution ch...
Status:
RESOLVED: FIXED
Product:
Xfdesktop
Component:
General

Comments

Description amigamagic 2014-04-14 02:14:18 CEST
-------------------------
PACKAGE: xfdesktop
VERSION: 4.11.6-1ubuntu1
-------------------------

Given that the process "xfdesktop" creates a file in ~/.config/xfce4/desktop whenever the user moves or creates an icon on the desktop, I found the following anomalies:

1) I noticed that if I change the position of an icon, it will not be saved immediately in the appropriate file in ~/.config/xfce4/desktop, but only after about 8 seconds. This delay determines that if I move an icon, and right after that I log out (before 8 seconds have elapsed), after the log in I will find that icon in the position it was before the last placement.

2) Suppose you have a particular personal arrangement of icons. Now, if you set a screen resolution never used so far, bigger than the previous one, the icons will be correctly arranged as they were before the resolution change. However, now if you don't touch the desktop anymore (I mean you don't have to move/edit/create icons) and you log out, at the following log in you will find that the icons have been rearranged on the left side of the screen and reordered alphabetically. It's happened because after the resolution change, xfdesktop did not create the appropriate file in "~/.config/xfce4/desktop". This file was created only after the next login (when it was too late for xfdesktop to know the previous icons placement), so at this point xfdesktop makes an automatic standard arrangement of the icons on the left side of the screen (losing your previous arrangement). This would not have happened if xfdesktop had created the new .rc file immediately after the resolution change.

3) The files that are created in ~/.config/xfce4/desktop should include the resolution values in their names. But actually they ​​do not correspond to the actual res values. For example, if I use a resolution of 1024x768, the file created will be called "icons.screen0-1008x720.rc", instead of "icons.screen0-1024x768.rc".
Comment 1 amigamagic 2014-04-17 12:05:36 CEST
Created attachment 5435 
Proposed patch fix for icon saving problems

Ok, problem n.3 is not a real problem. It's only a cosmetic one, so I tried to solve (1) and (2) myself and created a patch that does the something:

 1) Alter the SAVE_DELAY factor from 7 seconds to 1 second, so that when you
    change/move some icon on the desktop, you don't have to wait anymore 7
    seconds before xfdesktop saves the icons and you can safely logout.

 2) When you change your screen resolution with one never used so far,
    now xfdesktop will save your icon positions even if you don't change
    the icons positions before logout.

These two modifications should solve problem 1 and 2 in the description of the bug.
For now I'm using the patch myself without problems, but I would be glad if others could try it and if the developers could take a look at the patch to confirm that it's all right with my mods. Thanks. :)
Comment 2 Eric Koegel editbugs 2014-04-17 19:43:42 CEST
Thanks for writing a patch for this! A quick note:

xfdesktop_move_all_cached_icons_to_desktop(XfdesktopIconView *
{
#ifdef ENABLE_FILE_ICONS
    GList *l, *leftovers = NULL;
    XfdesktopFileIconManager *fmanager = NULL;

    TRACE("entering");

    if(XFDESKTOP_IS_FILE_ICON_MANAGER(icon_view->priv->manager))
        fmanager = XFDESKTOP_FILE_ICON_MANAGER(icon_view->priv-

    if(fmanager == NULL)
        return;

+    xfdesktop_file_icon_save(fmanager);

If we add the save function there you won't need the if check.

I don't forsee any issues with your patch, but I won't have time
to fully test this patch until the weekend, I just wanted to provide
some quick feedback. If you're ok with my proposed change, either
you or I can turn the diff into a git formatted patch for inclusion
into xfdesktop.
http://docs.xfce.org/contribute/dev/git/start provides info and
links if you've never worked with git before and want to.
Comment 3 amigamagic 2014-04-18 01:30:03 CEST
Created attachment 5437 
Proposed patch fix for icon saving problems - Version 2 -

Thanks Erik! You are right, we can save a check placing the "xfdesktop_file_icon_save(fmanager)" function call after that if. Nice one! :)

I prepared the diff file as described in that link. It's attached to this message. ;)
Comment 4 Eric Koegel editbugs 2014-04-18 19:52:42 CEST
Created attachment 5439 
Fix icon position saving on resolution change

So I got the time to actually test the patch out and it works great, thanks. I turned it into a full git patch, so instead of doing:
git diff > ~/fix-for-bug-1234.patch

you can do:

git add -u
git commit
git format-patch -1

Those commands will 1) stage your changes, 2) commit them (and allow you to add a header and get credit for your work), and then 3) pull the patch out so it can be added to xfdesktop's code directly. This may be helpful if you write more patches for git based projects in the future.

If ypu're ok with the header I put on your patch, I'll commit it to xfdesktop. Thanks again.
Comment 5 amigamagic 2014-04-18 23:34:16 CEST
Thanks Eric, I'm glad that it works. :)
Of course you can commit it but, if it's possible, I would ask you to place my real name in the credits beside the nickname. So, instead of just:

From: amigamagic <debianmaverick@gmail.com>

I would want it to be something like:

From: Mauro Giubileo AKA amigamagic <debianmaverick@gmail.com>

Thanks! :)
Comment 6 Eric Koegel editbugs 2014-04-20 09:13:00 CEST
Do you want the AKA amigamagic part? Most people seem to
just use their name. You can also do the git add/commit
stuff to format the patch header how you like and I'll
push that to master :)
Comment 7 amigamagic 2014-04-20 12:33:25 CEST
Ok, you can take out the 'amigamagic' part and keep only my name.
I think the rest of the header is good as it is in your attachment. :)

Bug #10813

Reported by:
amigamagic
Reported on: 2014-04-14
Last modified on: 2014-04-20

People

Assignee:
Eric Koegel
CC List:
1 user

Version

Version:
4.10.0

Attachments

Additional information