[4.11.8] Desktop icons rearrange on each login

Bug #1335492 reported by Thomas Schweikle
122
This bug affects 24 people
Affects Status Importance Assigned to Milestone
Xfce4 Desktop
Fix Released
High
xfdesktop4 (Ubuntu)
Triaged
Undecided
Unassigned

Bug Description

xfce4 looses desktop icon positions from time to time. The new positions are stored. Changing them again does store them ONLY if you create an additional desktop icon. Deleting this icon WILL in all cases make xfce4 loose all icon positions again!

Two screenshots to show the situation.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: xfce4 (not installed)
Uname: Linux 3.14.9+ x86_64
NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: XFCE
Date: Sat Jun 28 23:08:02 2014
InstallationDate: Installed on 2011-10-19 (983 days ago)
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
SourcePackage: xfce4
UpgradeStatus: Upgraded to trusty on 2014-02-24 (123 days ago)

Revision history for this message
Thomas Schweikle (tps) wrote :
Revision history for this message
Thomas Schweikle (tps) wrote :
Revision history for this message
Thomas Schweikle (tps) wrote :
Revision history for this message
Thomas Schweikle (tps) wrote :

At least anoying.

affects: xfce4 (Ubuntu) → xfdesktop4 (Ubuntu)
Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

This problem may be related to bug 1190990.

11 comments hidden view all 183 comments
Revision history for this message
In , Yanpas (yanpaso) wrote :

Desktop icons order resets if there is an equal number of icons in any two or more columns.
version 4.11.8-0ubuntu0.1

Revision history for this message
In , Yanpas (yanpaso) wrote :

*** Bug 11194 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Yanpas (yanpaso) wrote :

Does this bug occurs on your desktop?

Revision history for this message
In , Eric Koegel (eric-koegel) wrote :

I've never encountered this (otherwise I'd happily fix it). Does it happen when:

- you stop and restart xfdesktop? (xfdesktop --quit; xfdesktop &)

- during a screen size change?

- during login?

Just trying to figure out when it happens for you. Thanks!

Revision history for this message
In , Yanpas (yanpaso) wrote :

Hello! Sorry for delay. I've just tried all of enlisted items, but the icons are still OK. I've noticed that after this bug occurs - number of .rc files in /home/USER/.config/xfce4/desktop/ incresing with a bit different resolutions (First time I have counted 12 rc files). And this happens on two Xubuntu machines with magic number of icons (adding or removing the icon may represent bug every reboot or fix it)
Adding another panel - made the icons to fit in one row. Deleting this panel reverted changes in icon order (I think it is standart behavior)

Revision history for this message
In , Yanpas (yanpaso) wrote :

Is there a way to make united .rc file for all resolutions?

15 comments hidden view all 183 comments
Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

Did you already test the latest version of xfdesktop4 (4.11.8)? If it does not fix your issue, please forward this bug to the upstream bug tracker and tell us the bug number or the link.

https://bugzilla.xfce.org/

Revision history for this message
Thomas Schweikle (tps) wrote :

Yes I've tested this version already. Same as before, except it sorts icons every startup, not only on occasion. I've attached what I have sorted them to, and what I have after logging off and on again.

Revision history for this message
Thomas Schweikle (tps) wrote :

Before logging off and on again

Revision history for this message
Thomas Schweikle (tps) wrote :

After logging off and on again

Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

Thanks for your quick response. Did you file a report on the Xfce bug tracker? The current developer of xfdesktop rarely checks the launchpad reports.

12 comments hidden view all 183 comments
Revision history for this message
In , Eric Koegel (eric-koegel) wrote :

Here's the rationale for the rc files:
The .rc files are how Xfdesktop sees the space left on the screen. Things like the xfce4-panel may reserve space and xfdesktop respects that. The overall idea is that if your monitor goes through a couple resolution changes when your PC starts up or if you decide to play a game then your desktop should return to its old layout when it goes back to that resolution. Same thing with multi-monitor changes; you can have different layouts when your laptop is docked. The downside is that Xfdesktop doesn’t know when an icon position change should invalidate the other saved resolutions so in that case icons may change positions but Xfdesktop tries to minimize those moves.

Is it just one icon that gets messed up or all of them do? It may be due to something changing that causes xfdesktop uses an older .rc file (different panels or something like it on the desktop).

Revision history for this message
In , Yanpas (yanpaso) wrote :

(In reply to Eric Koegel from comment #6)
> Here's the rationale for the rc files:
> The .rc files are how Xfdesktop sees the space left on the screen. Things
> like the xfce4-panel may reserve space and xfdesktop respects that. The
> overall idea is that if your monitor goes through a couple resolution
> changes when your PC starts up or if you decide to play a game then your
> desktop should return to its old layout when it goes back to that
> resolution. Same thing with multi-monitor changes; you can have different
> layouts when your laptop is docked. The downside is that Xfdesktop doesn’t
> know when an icon position change should invalidate the other saved
> resolutions so in that case icons may change positions but Xfdesktop tries
> to minimize those moves.
>
> Is it just one icon that gets messed up or all of them do? It may be due to
> something changing that causes xfdesktop uses an older .rc file (different
> panels or something like it on the desktop).

All icons change their order. The locate in top left corner.

Revision history for this message
In , Yanpas (yanpaso) wrote :

I have noticed that the order resets when I logout and login. Three times in row this happened. I will try to remove gnome settings daemon and gsettings data convert from autostart and keep watching over my problem

Revision history for this message
In , Yanpas (yanpaso) wrote :

My computer created yet another file with such config "icons.screen0-1008x584.rc"

[/home/yanpas/Рабочий стол/Лекции.doc]
row=0
col=0

[44A8-6CC0]
row=0
col=0

[Корзина]
row=0
col=0

[/]
row=0
col=0

[/home/yanpas]
row=0
col=0

Revision history for this message
In , Mati86dl (mati86dl) wrote :

Hi,
Please, inspects your file /home/USER/.cache/session-***.

It happened to me, and seeing this file, i see that there are many programs which automatically run multiple times.

I suspect that when you save the session, multipes xfdesktop try to write the same file, creating problems.

But it's just a suspicion.

Eric,
I have to admit that also suspicious of my changes in the distribution of icons. This weekend I'll try to test with this change reverted..

Regards,
Matias.

Revision history for this message
In , Mati86dl (mati86dl) wrote :

Hi,

You think this also happens to you?.
 * https://bugzilla.xfce.org/show_bug.cgi?id=11188

If yes, the problem is that the desktop is starting with some theme, this implies a font size, etc etc, resulting in a grid size, and therefore, it can change the order of icons.
After a second, xfsettingsd set your preferred theme with different fonts, spaces, etc, resulting in the final grid size.

The icons were reorganized, but as the screen size is the same, never save a copy of the pocision icons. Only replacement it by new info.

Revision history for this message
In , Yanpas (yanpaso) wrote :

YES! I've noticed that my shimmer-project theme sometimes doesn't have time to load. For example Transmission gets default GTK icon on autostart and only restarting it changes the icon to the theme icon. Maybe some elements start in default theme and lose their order. Even if it so the bug persists, but in another component maybe

PS Another example: I have Clementine and Thunderbird on autostart. If I logout and then log in - thes programs doesn't have my GTK theme. Clementine is ugly-grey and thunderbird fonts are weird

Revision history for this message
In , Mati86dl (mati86dl) wrote :

Ok,
In my tests, applying the patch to xfsettingd seems that fix the bug.

Whell, The xubuntu people should add the patch, but surely take time.
You dare to compiling xfce4-settings to test?.

Revision history for this message
In , Yanpas (yanpaso) wrote :

I will try to compile and will be watching bug

Revision history for this message
In , Yanpas (yanpaso) wrote :

Hello. I think you meant patch from bug 11188. But which of them? And how to change source code automaticly with these + and -
PS In previous comment I read it from mobile phone and misunderstood.

Revision history for this message
In , Mati86dl (mati86dl) wrote :

Hi,
The best (Easy) way is compile directly the git version.

> sudo apt-get install git
> sudo apt-get build-dep xfce4-setting
> git clone git://git.xfce.org/xfce/xfce4-settings
> cd xfce4-settings
> ./autogen.sh
NOTE: This command should be more complete, but for this test not worry so much.
> make

The next step would be: sudo make install, but recommend overwrite the executable.

> killall xfsettingsd
Note: Not worry by theme change, and maybe here you see changes in yours icons.
> sudo mv ./xfsettingsd/xfsettingsd /usr/bin/
> xfsettingsd &

And restart you desktop.. ;)

Revision history for this message
In , Yanpas (yanpaso) wrote :

And where is the patch in these steps, that small file with + and - lines. Or this patch has been already applied to the project and I need only to compile newer version from source?

Revision history for this message
In , Mati86dl (mati86dl) wrote :

> Or this patch has been already applied to the project and I need only to compile newer version from source?

Yes. ;)
The patch was added two months ago,but not enough changes to make a new release of xfce4-settings.

Revision history for this message
In , Yanpas (yanpaso) wrote :

Created attachment 5813
icon bug

(In reply to Matias De lellis from comment #18)
> > Or this patch has been already applied to the project and I need only to compile newer version from source?
>
> Yes. ;)
> The patch was added two months ago,but not enough changes to make a new
> release of xfce4-settings.

Hello! Desktop icons behave good, there were no any self-replacements. But I've found new bug with xfsettingsd, which is not fixed in github. Transmission non-theme icon. Screenshot is attached. When I start my computer - I get default ugly icon, only after restaring transmission app icon becomes normal

Revision history for this message
In , Yanpas (yanpaso) wrote :

Created attachment 5814
Bug again

Oh no! Just after a comment bug reproduced again. All I did before was plaing GTA IV in resolution 1680x1050. Then I set my creen to my native resolution 1920x1080 (everything is still OK). Then I logged out and logged in - and icons are mixed.
Also on logging in my clementine player, which is loaded automaticly didn't fully catched gtk theme, it has weird and wrong Font.

Revision history for this message
In , Mati86dl (mati86dl) wrote :

Ohh.. Ok. :(

Yesterday also happened to me. I will continue investigating.

Regards.

Revision history for this message
In , Mati86dl (mati86dl) wrote :

Hi everyone,
Nothing new. Sorry.. I Cannot isolate it :S

I reverted all my changes (I was worried about these. haha).. and the bug is still there.. :S

Perhaps it is a old bug, and only we discovered it now.

Only one detail. I discovered that it occurs when I close a session with many open applications and the "Save session" option is activated.

And noticing that is a lot easier reproduce it when restart the machine instead just close and open the session. Not know what is the difference. :S

Revision history for this message
In , Mati86dl (mati86dl) wrote :

Eric,
Not think that is related, but researching a bit found a bug:

> https://github.com/xfce-mirror/xfdesktop/commit/cfe5a0ad88b84a23a4cd6d18a25635ec84cbaf68

In this commit you introduce a big mem leak. Is not noticeable due it's just when close the session. I doubt the necessity of the commit, but surely you have your reasons. ;)

Well, the problem is that xfdesktop_application_get() increases the references and you have to add a unref after use it.

The obvious problem is the mem leak. but not the most worrying

The major problem is that you're assuming that XfdesktopApplication may be NULL. If XfdesktopApplication already NULL (understood is already closed), when you call xfdesktop_application_get(), you're starting an entirely new desktop !!!!.

..and due the missing unref basically never close it. Ends up being killed by the session. (This last is just supposition. haha. =)

Any idea how to debug this?
For now I'll add some g_print to see the sequence on shutdown.

Regards,
Matias.

28 comments hidden view all 183 comments
Revision history for this message
Thomas Schweikle (tps) wrote :

Found what is going on: Desktop-Directory and Desktop configuration files are read concurently. Since desktop icon positions are not read at first, read files in Desktop-Directory are sorted default (top-left -> down-left). At some point at least one icon position is found (reading is concurent!) and then resorted. This leads to an event writing out the "new" positions of the icons, overwriting everything with new values. Since some icon positions where read before the icons where placed, these remain intact. Other icons where read before the icon positions where known these are sorted by default.
Result: some icons keep there places, while others are sorted by default.
At least one icon may be recognized as "moved" the icon position file is overwritten with the icon positions known by now.

This is a race condition: reading config-files races against reading desktop directory. Normally, with no load reading config files wins. But if some background processes are started this isn't true any more -- directory reading is faster, than configuration file reading with the result of resorted desktop icons.

The system shall make sure not to place any icon until it has read all configuration files holding icon positions. After these are know it can continue placing icons.

Revision history for this message
In , Thomas Schweikle (tps) wrote :

Created attachment 5866
Versions of xfce-files.

While starting up icon positions are partially lost. Some icons stay where I put them, some get moved to default (top-left-down-left-sorting).

Revision history for this message
In , Thomas Schweikle (tps) wrote :
Revision history for this message
In , Mati86dl (mati86dl) wrote :

Hi,
Dup of https://bugzilla.xfce.org/show_bug.cgi?id=11266

Please, add launchpad info on these bug.

Regards.

Changed in xfdesktop:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote : Re: xfce4 looses desktop icon positions from time to time

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xfdesktop4 (Ubuntu):
status: New → Confirmed
summary: - xfce4 looses desktop icon positions from time to time
+ [4.11.8] Desktop icons rearrange on each login
Changed in xfdesktop:
importance: Medium → Unknown
status: Confirmed → Unknown
Revision history for this message
megaus (megaus) wrote :

xfdesktop 4.11.6-1ubuntu1 (trusty) do not have this issue
xfdesktop 4.11.8-0ubuntu0.1 (trusty-updates) has this issue

Changed in xfdesktop:
importance: Unknown → High
status: Unknown → Confirmed
Changed in xfdesktop:
status: Confirmed → Incomplete
Changed in xfdesktop:
status: Incomplete → In Progress
127 comments hidden view all 183 comments
Revision history for this message
In , Pavel Ponec (pponec) wrote :

Hi Jan Do.

Yes, the workaround #89 works well for me, thank you.
However I'm afraid that the bug discourages many beginners of XFCE.

Revision history for this message
In , jason.braddock.69 (jason-braddock-69) wrote :

(In reply to Ponec from comment #106)
> Hi Jan Do.
>
> Yes, the workaround #89 works well for me, thank you.
> However I'm afraid that the bug discourages many beginners of XFCE.

It discouraged me long time ago...
I left xfce with no regret

Revision history for this message
In , Mikhail Kurinnoi (viewizard) wrote :

Patch from #89 solve issue with desktop icons order reset for me.
Thanks a lot!

Revision history for this message
In , Mikhail Kurinnoi (viewizard) wrote :

Correction. Looks like I still have this issue, but more rarely with #98 patch.

Revision history for this message
In , Haenig (haenig) wrote :

problem persists here for xfdesktop 4.12.3 (OpenSuSE Tubleweed)

auditing (summary) shows the following after logon:

lots of reads from /home/thomas/.config/xfce4/desktop/icons.screen0-2544x971.rc
and then suddenly
a create icons.screen0-2544x971.rc.new.16834.tmp
a rename/move icons.screen0-2544x971.rc.new.16834.tmp to icons.screen0-2544x971.rc.new
a rename/move icons.screen0-2544x971.rc.new to icons.screen0-2544x971.rc

everything triggered/done by /usr/bin/xfdesktop (PID=16834)

inode IDs before and after logon differ and the original contents of icons.screen0-2544x971.rc are lost

meanwhile I have already 2 "solutions"

1. (the older one, from/for XFCE 4.10 (see Bug 9192))
- at every shutdown/startup of the machine I create a backup and
- there is a desktop shortcut to restore the last of those backups

2.
- systemd service looking for greeter process => removes all write permissions for .config/xfce4/desktop/ folder
- autostart script which 60 seconds after logon adds write permission for .config/xfce4/desktop/ folder
- obsoletes backup/restore

For me THE question is/remains, why at all has the positions file to be written to at logon/startup?

As it happens this seems not to be necessary, as my "solution" 2 shows.

Revision history for this message
In , Underpass-bugzilla (underpass-bugzilla) wrote :

Hello, I've never had any problem in XFCE desktop I bought a new computer some days ago and I've starting to experience this bug.
Is it solved in version 4.14?
Is it going to be solved someday? Is there anyone working on it?
Is there a "full functional" workaround? The most common "solution" (so to speak) I've read about is giving

sudo chattr -i ~/.config/xfce4/desktop/icons*

Thanks.

Revision history for this message
In , jason.braddock.69 (jason-braddock-69) wrote :

Hi underpass, the only workaround i found yet is to use gnome desktop

Revision history for this message
In , Mpsrbija (mpsrbija) wrote :

Installed xubuntu 18.04 updated and the icons moved here and then.
The rc files in $HOME/.config/xfce4/desktop/ directory are created only when the icons move.

I thought that having all those rc files must have borked something, so I made a script that launches on startup that keeps only the latest icons*rc and removes all the other rc files. https://pastebin.com/0HFjZrGi
The script requires inotify-tools package installed and notify-send (to keep track on when the icon positions are saved).

The icons do seem to stay on login/logout, except the Trash that want's to stay in the top-left corner. Sometimes even File System and Home icons move too. They are managed by xfconf, maybe that's why their position is being reset. So I turned them off. If I need them, I can make a desktop file that launches thunar with those paths can replace them.

Now the icons do move if the panel is resized and then logout is made after that.
As soon as the panel is resized, it sets the new panel strut. That triggers a change of _NET_WORKAREA of the root window property, but if the icons are not moved a new rc file will not be created. That is when the icons reset their position on login.

Revision history for this message
Colin Hemming (b-ubuntuone14) wrote :

The cause was identified long ago https://bugs.launchpad.net/ubuntu/+source/xfdesktop4/+bug/1335492/comments/41 but still no one has applied a fix. I have two scripts. One of which saves the files on logout and another which I run at login that waits 10 seconds, then restores the file and resets the desktop. That totally solves it. Without my script, many of the icons reset and the others remain because xfdesktop doesn't wait for the whole config file to be read before continuing. The reset icons reassert their new position in the files. It's a major annoyance to not be fixed for so long.

3 comments hidden view all 183 comments
Revision history for this message
In , Mpsrbija (mpsrbija) wrote :

This works for me:
The first script is set to autostart on login.
The second one is used for logout / reboot.

https://forum.xfce.org/viewtopic.php?pid=49764#p49764

The first script waits untill all the the panels are in the window stack, then sets the folder permissions of .config/xfce/desktop to 755. It also removes all but the latest rc file when a new rc is created in the folder. Requires inotify-tools to monitor when the rc files are created.

The second script opens a yad dialog and sets the folder permissions of .config/xfce/desktop to non-writable when logout / shutdown / restart is selected. Requires yad.

2 comments hidden view all 183 comments
Revision history for this message
Miloš Pavlović (mpsrv) wrote :

Colin Hemming, I also have two scripts.

The first script is set to autostart on login.
The second one is used for logout / reboot.

https://forum.xfce.org/viewtopic.php?pid=49764#p49764

The first script waits untill all the the panels are in the window stack, then sets the folder permissions of .config/xfce/desktop to 755. If all the panels are loaded, then their struts are set and the workarea is correct. It also removes all but the latest rc file when a new rc is created in the folder. Requires inotify-tools to monitor when the rc files are created and notify-send to tell when the icon position is saved. By having only one rc conf file I don't have to reset the desktop on login.

The second script opens a yad dialog and sets the folder permissions of .config/xfce/desktop to non-writable when logout / shutdown / restart is selected. Requires yad.

Revision history for this message
sami (miaousami) wrote :

OMG is this bug still open?
lol

Revision history for this message
Jose Luis Suarez (jlsuarezm) wrote :

I have this behavior loosing desktop icon positions in Xubuntu since 16.04 and now in 18.04
Esto es xfdesktop versión 4.12.3, ejecutándose en Xfce 4.12.
Compilado con GTK+ 2.24.31, Enlazado con GTK+ 2.24.32.
Opciones de compilación:
Menú del escritorio: activado
Iconos de escritorio: activado
Iconos de archivos del escritorio: activado

I usually have desktop set up to don't show icons for: Trash, Personal Folder, File System or Devices
When I change this set up to show Trash icon, desktop icons behave correctly and don't move after login.
Still waiting for a fix

1 comments hidden view all 183 comments
Revision history for this message
In , Bakhelit (bakhelit) wrote :

I just use the following workaround:

1. Move the file with desired desktop icons positions to "/etc/xdg/xfce4/desktop/icons.screen0.rc".

2. Create a new desktop file in "/etc/xdg/autostart" that deletes "/home/USERNAME/.config/xfce4/desktop" and reloads the xfdesktop - it has the following contents (use your user name instead of USERNAME and adapt the sleep interval if needed):

[Desktop Entry]
Exec=bash -c 'sleep 3 && rm -rf /home/USERNAME/.config/xfce4/desktop && xfdesktop --reload'
Name=Xfdesktop Reload
Terminal=false
Type=Application
StartupNotify=false

This restores my desired desktop icons positions on every login to XFCE. Note that when you want to rearrange your icons you need to update the "/etc/xdg/xfce4/desktop/icons.screen0.rc" file manually.

Revision history for this message
In , Alexxcons-x (alexxcons-x) wrote :

*** Bug 14031 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Alexxcons-x (alexxcons-x) wrote :

Actually this bug seems to be easy to reproduce:

1. Adjust the colum-size of the panel to something odd
2. Logout
3. Login
---> All Icon-Posotions will reset

If you already have profiles for all possible free-screen-size combinations, delete some of the configs in ".config/xfce4/desktop," to make the bug happen again.

IMO one aspect which makes thing over-complex is, that profiles are saved per free-screen-size in .config/xfce4/desktop, instead of saving them per display-configuration (monitor setup and resolution).

IMO not good to make smart decisions for the user when only free-screen-size changes ... the user can re-sort desktop items on its own on things like panel-size change.

Hope I will find some time to work on this bug soon.

Revision history for this message
In , Andreldm-2 (andreldm-2) wrote :

@alexxcons the patch proposed in Bug 14979 might help or worsen this one.

Revision history for this message
In , Underpass-bugzilla (underpass-bugzilla) wrote :

Hello, I've tested the xfdesktop 4.13.3 on Debian Testing (installed from the Experimental repository) and the problem is still there, exactly the same as in 4.12.
Any chance to have it solved in version 4.14? Sorry, I'm no coder so I can't be of much help here.

Changed in xfdesktop:
status: In Progress → Confirmed
Revision history for this message
In , Alexxcons-x (alexxcons-x) wrote :

Created attachment 8463
patch to add symlink to the latest working config, used as fallback

(In reply to Underpass from comment #119)
> Any chance to have it solved in version 4.14?

Here we go.

One concrete problem is, that opening the setting menu of the panel will add one extra pixel to the panel(some border showing the focus). That will change the size of space available for xfdesktop.
If the desktop is saved now, it will be e.g. saved as icons.screen0-1366x701.rc

After a logout + relogin the panel will not have this extra-pixel. So xfdesktop searches for icons.screen0-1366x700.rc ... possibly does not exist --> Fallback to just place all icons in a line.

The attached patch will always create a symlink "icons.screen.last.rc" on save, pointing to the current *.rc file, whenever a new .rc file is written.

This fix cures the symptoms. IMO should be fine for 4.14 .. however later on I would start to work on the actual problem, which is, that xfdesktop does not use the whole screen, but only the workarea. (Another logical error is, that the icon size is not saved in the .rc file, together with the grid, but somewhere else, independently)

Revision history for this message
In , Alexxcons-x (alexxcons-x) wrote :

Created attachment 8464
patch to add symlink to the latest working config, used as fallback

forgot to unlink existing links before adding link

Changed in xfdesktop:
status: Confirmed → In Progress
Revision history for this message
In , Christian (chgauert) wrote :

(In reply to alexxcons from comment #120)
> Created attachment 8463 [details]
> patch to add symlink to the latest working config, used as fallback
>
> (In reply to Underpass from comment #119)
> > Any chance to have it solved in version 4.14?
>
> Here we go.
>
> One concrete problem is, that opening the setting menu of the panel will add
> one extra pixel to the panel(some border showing the focus). That will
> change the size of space available for xfdesktop.
> If the desktop is saved now, it will be e.g. saved as
> icons.screen0-1366x701.rc
>
> After a logout + relogin the panel will not have this extra-pixel. So
> xfdesktop searches for icons.screen0-1366x700.rc ... possibly does not
> exist --> Fallback to just place all icons in a line.
>
> The attached patch will always create a symlink "icons.screen.last.rc" on
> save, pointing to the current *.rc file, whenever a new .rc file is written.
>
> This fix cures the symptoms. IMO should be fine for 4.14 .. however later on
> I would start to work on the actual problem, which is, that xfdesktop does
> not use the whole screen, but only the workarea. (Another logical error is,
> that the icon size is not saved in the .rc file, together with the grid, but
> somewhere else, independently)

as i said in comment #88 why using the workarea instead of the whole screen

Revision history for this message
In , Alexxcons-x (alexxcons-x) wrote :

> as i said in comment #88 why using the workarea instead of the whole screen
After some thinking on your proposal, I have to say: Its complicated.
One problem is, that xfdesktop currently has no support for multiple screens. The "screen0" in the name of the *.rc file currently is just hardcoded, whereas the workarea describes the free area among all attached screens. (So the current screen0 actually is a lie)

Just changing the filename to screen res. for most users might be sufficient. However e.g. if you have a laptop with docking station, you might actually want to use two configurations, with and without extra screen, currently resulting in two *.rc files.

Following your proposal, If you name the file like the first screen, than there will be only one file. A solution could be to put the res. of all available screens into the filename ... but that looks like an ugly workaround for me.

IMO much better would be to have one file per screen, named something like "monitor id"."screen resolution".rc
Each of these files could than consist as well background image info, icon size, etc.
However that would be a bigger change. I opened a seperate bug for that: bug #15344 . Will try to work on it when I have time.

Revision history for this message
In , Alexxcons-x (alexxcons-x) wrote :

Created attachment 8467
same patch for the xfce-4.12 branch

Attached the same patch for the xfce 4.12 branch (the original patch refuses to be applied there)

Please test it, if you can. I would like to push it soon.

Revision history for this message
In , Simon Steinbeiß (ochosi) wrote :

I think "last" is misleading in the filename, I'd personally go with "latest".
Other than that, this looks very non-intrusive.

Not sure which problems it fixes exactly because this bugreport is blown way out of proportion and it's impossible to read and understand it all (and to be sure that it's really about *one* bug). But if you have good experiences I guess/hope it won't hurt :)

1 comments hidden view all 183 comments
Revision history for this message
In , Mpsrbija (mpsrbija) wrote :

It's not only one bug. :)
The icons reposition in other cases.
The rc config file is created only after the icons are moved.
If you resize the panel just a few pixels close the panel settings
and logout the icons will move because their position isn't saved.

Another one is the Trash icon that moves to the upper left corner.
And sometimes File System and Home icon position resets.
But I think that those three icons are handled by Xfconf.

Revision history for this message
Colin Hemming (b-ubuntuone14) wrote :

I have now written a patch script to deal with this problem on my machine as it's been like this for many years with no progress. I don't understand the internals, but it occurs 100% when the desktop starts laying out icons before the underlying system has read the configuration (it occasionally gets the first couple), so starts "not knowing" where icons go, so creates a new entry, starting from the left side of the screen. I have eradicated the problem by holding a backup of the configuration, waiting for disk activity to drop to near zero after login, then restoring the backup and reloading the configuration. It takes a short while before the desktop sorts itself, but entirely fixes the problem. My job then watches the configuration file to see if it's subsequently updated, requiring a new backup. All the talk of multiple monitors and so on is a separate issue unrelated to the bug itself.

1 comments hidden view all 183 comments
Revision history for this message
In , Alexxcons-x (alexxcons-x) wrote :

I just tried to fix the most critical case, in which all icons reset to default position (since no rc config matching the current workarea is found )

(In reply to Miloš Pavlović from comment #126)
> The rc config file is created only after the icons are moved.
> If you resize the panel just a few pixels close the panel settings
> and logout the icons will move because their position isn't saved.

This case should be fixed now. Since now the symlink will be used as fallback.

> Another one is the Trash icon that moves to the upper left corner.
> And sometimes File System and Home icon position resets.
> But I think that those three icons are handled by Xfconf.

I did not look into that so far .. should be reported as separate bug, if it is still a problem. This bug is already much too long.

Revision history for this message
In , Linuxfreak-a (linuxfreak-a) wrote :

Hi Alex,

This desktop icons order resets problem is also present now at Manjaro.

regards LF

inxi -Fxzc0
System: Host: dolphin Kernel: 5.0.10-2-MANJARO x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Xfce 4.13.3git-UNKNOWN
Distro: Manjaro Linux

xfdesktop --version
Dieses ist xfdesktop Version 4.13.3git-UNKNOWN, auf Xfce 4.13.
Erstellt mit GTK+ 3.24.7, verknüpft mit GTK+ 3.24.8.
Optionen bei der Erstellung:
Schreibtischmenü: aktiviert
Schreibtischsymbole: aktiviert
Schreibtischdateisymbole: aktiviert

pacman -Si xfwm4

Repository : extra
Name : xfwm4
Version : 4.12.5-1
Description : Xfce window manager
Architecture : x86_64
URL : http://www.xfce.org/
Licenses : GPL2
Groups : xfce4
Provides : None
Depends On : libxfce4ui libwnck libdrm hicolor-icon-theme
Optional Deps : None
Conflicts With : None
Replaces : None
Download Size : 491.47 KiB
Installed Size : 2028.00 KiB
Packager : Evangelos Foutras <evangelosNOSPAMfoutrelis.com>
Build Date : Sun Jul 29 15:24:36 2018
Validated By : MD5 Sum SHA-256 Sum Signature

xfwm4 --version
This is xfwm4 version 4.13.1git.UNKNOWN (revision UNKNOWN) for Xfce 4.13
Released under the terms of the GNU General Public License.
Compiled against GTK+-3.24.5, using GTK+-3.24.8.

Build configuration and supported features:
- Startup notification support: Yes
- XSync support: Yes
- Render support: Yes
- Xrandr support: Yes
- Xpresent support: Yes
- Embedded compositor: Yes
- Epoxy support: Yes
- KDE systray proxy (deprecated): No

Revision history for this message
In , Linuxfreak-a (linuxfreak-a) wrote :

Hi Alex,

This desktop icons order resets problem is also present now at Manjaro.
(Funny is that there are different versions of xfce?)

regards LF

inxi -Fxzc0
System: Host: Kernel: 5.0.10-2-MANJARO x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Xfce 4.13.3git-UNKNOWN
Distro: Manjaro Linux

xfdesktop --version
Dieses ist xfdesktop Version 4.13.3git-UNKNOWN, auf Xfce 4.13.
Erstellt mit GTK+ 3.24.7, verknüpft mit GTK+ 3.24.8.
Optionen bei der Erstellung:
Schreibtischmenü: aktiviert
Schreibtischsymbole: aktiviert
Schreibtischdateisymbole: aktiviert

pacman -Si xfwm4

Repository : extra
Name : xfwm4
Version : 4.12.5-1
Description : Xfce window manager
Architecture : x86_64
URL : http://www.xfce.org/
Licenses : GPL2
Groups : xfce4
Provides : None
Depends On : libxfce4ui libwnck libdrm hicolor-icon-theme
Optional Deps : None
Conflicts With : None
Replaces : None
Download Size : 491.47 KiB
Installed Size : 2028.00 KiB
Packager : Evangelos Foutras <evangelosNOSPAMfoutrelis.com>
Build Date : Sun Jul 29 15:24:36 2018
Validated By : MD5 Sum SHA-256 Sum Signature

xfwm4 --version
This is xfwm4 version 4.13.1git.UNKNOWN (revision UNKNOWN) for Xfce 4.13
Released under the terms of the GNU General Public License.
Compiled against GTK+-3.24.5, using GTK+-3.24.8.

Build configuration and supported features:
- Startup notification support: Yes
- XSync support: Yes
- Render support: Yes
- Xrandr support: Yes
- Xpresent support: Yes
- Embedded compositor: Yes
- Epoxy support: Yes
- KDE systray proxy (deprecated): No

Revision history for this message
In , Linuxfreak-a (linuxfreak-a) wrote :

Can i also add the 4.12 patch to 4.13 ? I have listed different versions of xfce?? So one or more --version commands must be wrong ?

Revision history for this message
In , Alexxcons-x (alexxcons-x) wrote :

Check the attachments, there is one patch for "master", which is the one you want for 4.13:
https://bugzilla.xfce.org/attachment.cgi?id=8464
An on for the "xfce-4.12" branch:
https://bugzilla.xfce.org/attachment.cgi?id=8467

They do the same thing .. the one for master just did not apply properly for the 4.12 branch for some reason.

Revision history for this message
In , Alexxcons-x (alexxcons-x) wrote :

Created attachment 8473
patch for master (add symlink to latest)

Modified patches to use "latest" instead of "last", like proposed by Simon.

Revision history for this message
In , Alexxcons-x (alexxcons-x) wrote :

Created attachment 8474
patch for xfce-4.12 (add symlink to latest)

Revision history for this message
In , Gitbot (gitbot) wrote :

Alexander Schwinn referenced this bugreport in commit 399090b197aee2cd98e3ba5c49a56632dd388eb8

Desktop icons order resets (Bug #11266) - Added link to last used configuration as fallback

https://git.xfce.org/xfce/xfdesktop/commit?id=399090b197aee2cd98e3ba5c49a56632dd388eb8

Revision history for this message
In , Gitbot (gitbot) wrote :

Alexander Schwinn referenced this bugreport in commit e8bf69ddd4bb7099cdb389ac6715c097b50d43aa

Desktop icons order resets (Bug #11266) - Added link to last used configuration as fallback

https://git.xfce.org/xfce/xfdesktop/commit?id=e8bf69ddd4bb7099cdb389ac6715c097b50d43aa

Revision history for this message
In , Alexxcons-x (alexxcons-x) wrote :

Pushed to master and 4.12 branch, to be released in 4.13.4 and 4.12.5 soon.

Changed in xfdesktop:
status: In Progress → Fix Released
Revision history for this message
nick_s (nickstylianou) wrote :

My desktop icons are also rearranging themselves between logins, but it seems to be specifically the icons managed by xfconf (i.e. "Home", "Filesystem", "Rubbish Bin") - any other icons seem to retain their positions ok. I'm on Xubuntu 18.04 with all updates, and xfdesktop4 version 4.12.3-4ubuntu2. This wasn't happening on my previous 16.04 installation.

Revision history for this message
Sean Davis (bluesabre) wrote :

Fixed back in 2019. Marking as resolved.

Changed in xfdesktop4 (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Colin Hemming (b-ubuntuone14) wrote :

I have 4.14 installed on Xubuntu 20.04 and it has still been happening recently. I think it only happens when there are many icons to deal with. It works fine as long as the desktop starts very rapidly, but if it takes any time they get reset.

Revision history for this message
Sean Davis (bluesabre) wrote :

Thanks for the update. I'll reopen this one.

Changed in xfdesktop4 (Ubuntu):
status: Fix Released → Triaged
Displaying first 40 and last 40 comments. View all 183 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.