How to save and restore a desktop icons positions in MATE?

I'm currently using Ubuntu 18.04 LTS as daily system. I have never faced the problem with misplaced desktop icons. I'm using MATE on Ubuntu since 12.04 LTS.

I did some research. Really the problem is deeper.

Every icon has its own metadata attribute. So one can:

  • read it by

    gio info -a "metadata::caja-icon-position" ~/Desktop/file1.txt

    to get something like

      metadata::caja-icon-position: 922,382
  • write it by

    gio set -t string ~/Desktop/file1.txt metadata::caja-icon-position 300,400

    and ask Caja to refresh the desktop by calling caja -q.

There is script elsewhere. But it does not work.
Also there is a script on french forum. But initially it also have issues. The adapted version of the script is below.
To use it you have to install xdotool package by sudo apt-get install xdotool and then execute single long command below to create the script programmatically:

cat << \EOF > ~/
# name and path of the script to be created (to be modified if necessary) 

echo '#!/bin/bash'>$file
    for i in ~/Desktop/*
     do echo -n gio set '"'"$i"'"';gio info --attributes=metadata::caja-icon-position "$i"|grep metadata

icons_xy >>$file
sed -i 's/n:/n/g' $file

chmod u+x $file

# focus the Desktop and simulate pressing F5 shortened to refresh the Desktop (to be adapted according to the Desktop used, here Mate) 
echo 'id=$(xdotool search --classname desktop) ; xdotool windowfocus --sync $id; xdotool key F5'>>$file

If understand things correctly, then you use the script as follows:

  1. run sh ~/ It will save current icon positions to the second script.
  2. run second script by ~/

Note that these scripts cause creation of ~/.config/caja/desktop-metadata file. Its contents may change on desktop update.

The overall problem is very interesting. I still hope to get the solution of your problem. Thank you!

I currently use 20.04.current LTS, and will upgrade to the next LTS major release when it becomes available, provided that Ubuntu will continue to support "upgrade in place". I apologize for the length of this reply, but only by explaining my situation will it be clear why I run LTS production current. Note with any major release update of Scientific Linux (an IBM Red Hat Enterprise Linux exact clone save for logo intellectual property, as Ubuntu is a "clone" of Debian), one had to do a fresh install -- upgrade in place was NOT recommended, and might "break things". I keep current on LTS (having gone from 18.04 to 20.04, in place) because of the need for better hardware support and for newer releases of applications such as TeXstudio ( For example, the TeXstudio current production release would not run on SL 7 (there never was a SL 8, only an almost-proprietary IBM RH EL 8) because the basic gcc library that is required for SL 7 could NOT be upgraded to a more current gcc and could not be run in an encapsulated environment. It only would work with a type 2 hypervisor virtual machine (e.g., Oracle VirtualBox running Ubuntu as the guest under a SL host). As my Linux workstation is not a development machine, I only run VirtualBox or VMware to be able to run MS Windows for applications that are not available for Linux. The Institute for Advanced Study has a Springdale EL 8 clone, but once I have switched to Ubuntu LTS, I decided to remain. I only use production "enterprise" Linux, not enthusiast nor development editions (e.g., nothing equivalent to IBM RH Fedora).

I faced a similar situation some time ago. In my case the reason for the unintended desktop icons chaos was not a "glitch", as such (ie a bug), but the result of a caja "feature": I had accidentally triggered the caja right-click menu option "Organize desktop by name", from which there is no escape or undo.

This prompted me to write a set of short python scripts which can "automatically" save and (if necessary) later restore the desktop state by moving the icons to their previously saved positions.

I have now succesfully tested it on several occasions by first moving icons around to random positions and then running the "restorer" script, so I feel confident that, at least for me, it will work as intended, saving the day should the desktop order happen to become totally jumbled once more.

I posted about this here: Disable "organize desktop by name" option.
The scripts are here:
The code is basically a stripped down, GUI-less version of a QT-based python scripts by RockDoctor: (as I see Norbert_x already mentioned).

1 Like

Thank you -- you have faced the same issue and have a solution. I tried the GUI version to which you allude, but for some reason, that did not seem to work. I am using 20.04 LTS and MATE, both "current" production release.

I read your Github commentary, and have tested your utility. I downloaded the .zip from the Github location, and then used unzip to extract all of the files. At the moment, I clearly am doing something wrong.

[email protected]:~/desktop-save-icon-positions/Icon-pycon-main/icon-pycon/home//Desktop/DTbkp.d/1-SAVING$ python3
Traceback (most recent call last):
File "", line 7, in
import icons_pycons
ModuleNotFoundError: No module named 'icons_pycons'
[email protected]:~/desktop-save-icon-positions/Icon-pycon-main/icon-pycon/home//Desktop/DTbkp.d/1-SAVING$

Glad you already have had time to test!

I can guess at a couple of possibly reasons for the error message.

One would be if you haven't adapted the line immediately before the critical "import icons_pycons" line, namely the one which starts:

As the file path declared here (inside parentheses and single quotes) points to the directory where is to be found, it needs to be edited to reflect your local install, probably to read something like ~/Desktop/DTbkp.d/0-defs/.

The second possible reason, judging by your post, is that you seem to attempt to run the directly from where it was extracted, "buried" as it were in the github folder structure.

I suggest that you move just the directory DTbkp.d (and its contents of course) to your machine's desktop (i.e. your ~/Desktop/), then open a terminal in the 1-SAVING directory and issue python3 as before.

In short, any file paths "softcoded" in this, or the companion RESTORE script, have to correspond to your local "reality". Otherwise the Python interpreter will soon be lost.

By the way, you can rename the script files and their directories to anything you prefer, as long as the referencing file paths given in the scripts are adapted accordingly.

I trust you should get a little further now on the path to securing your desktop layout.

Through the reading of your Python source code, I have determined that Skrivbord is Desktop in my system, etc. I may have made incorrect substitution modifications to your source code.

Traceback (most recent call last):
File "./", line 12, in
File "/home/ykarant/Desktop/DTbkp.d/0-defs/", line 71, in SAVE_current_layout
with open(dpname, 'wb') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/home/ykarant///Icons_ervator.p-2021-03-01'

before this failure output, there was a very long output line ending with:

['xournalpp_xournalpp.desktop', 651, 236], ['xsane.desktop', 1383, 123], ['xterm.desktop', 1024, 106]]

in which the values such a 651,236 are the "coordinates" of the icon on the desktop.

Without criticism, as you were writing this code for your own immediate use, portability would have been a useful feature, much as "configure" producing a system-local-specific configuration of a makefile, rather than the old method of manually editing a makefile for the local file and executables configuration.

I have deleted my previous post in this thread. When re-reading it today, I realised with great embarrassment and dismay that sifgnificant parts of it was so ambigiously written that it could easily be interpreted in a way totally opposite to what I meant to say. I apologise for this, and sincerely hope that no one has been offended by my lack of proofreading skills.

A shorter version with just the technical content of the post follows.

I fully agree with you when conclude that the code would be more portable and accessible for others if it had an easier means of configuration. Indeed, your interest in my amateurish efforts has helped inspire me to investigate a central configuration file solution.

Until I have the time to finish such an attempt, however, I can at least offer a verbatim walkthrough of the different lines in the three files which need to be edited:

For simplicity, let us assume you have opted to keep the name of the enveloping directory as DTbkp.d and also that you have put it directly in your Desktop directory, similar to my "prototype case".

  1. Then in the common definitions file /home/ykarant/Desktop/DTbkp.d/0-defs/ line 27 should read:
    desktop = home + '/Desktop/' # Provide your localized DT name here
    and line 28:
    pname = desktop + 'DTbkp.d/Icons_ervator.p' # Pickle file (dir name to suit)
    and line 39:
    gio_in_cmd = "gio info $HOME/Desktop/* | egrep 'standard::name|caja-icon-position:'"

  2. Now, just to be sure, we can manually create the (empty) file /home/ykarant/Desktop/DTbkp.d/Icons_ervator.p. This will later be overwritten by the script as a binary file.

  3. Finally, we change line 4 in both /home/ykarant/Desktop/DTbkp.d/1-SAVING/ and /home/ykarant/Desktop/DTbkp.d/2-RESTORING/ to read:

  4. When (if!) the time comes to use the RESTORE script it will be necessary to first remove the date part of the chosen pickle file's filename extension. Thus for instance Icons_ervator.p-2021-03-03 becomes simply Icons_ervator.p. The ISO formatted date tag is only there as a means of differentiating between potentially many stored Icons_ervator.p files.

Those are all the edits I expect to be critical for smooth operation. If you do try it again, please let me know the outcome.


(Unless I should use your human real name, not your "avatar")

I did not take your response badly in any way, and I appreciate your
commentary and updates. I did not criticise your software engineering as
you are supplying your workaround as a courtesy, not either as a
Canonical employee nor a MATE maintainer (I assume unlike Canonical or
IBM Red Hat, MATE entirely is a volunteer effort, but hopefully not an
"enthusiast" effort -- rather, one implemented by professionals for
professional production environment use, as I use MATE and formerly EL
and now LTS). However, given my other obligations (I could post as an
attachment some of the material I prepare for my students), I do not
have the spare time to "debug" or "port" source code. It also would be
useful if MATE maintainers/developers would incorporate this
backup-and-restore capability into either the base MATE desktop
management system or into an addon package that readily is available.
Note that I use stock LTS and then load the MATE .deb (formerly, .rpm
under SL) packages into the stock LTS distro -- I do not use MATE Ubuntu
distro. Again, thank you for understanding my situation. Your response
has been both professional and polite than that on the Ask Ubuntu list
to which I initially posted this question.

1 Like

There appears to be one small issue with the above modifications, but otherwise I now have a saved file. The small issue is that DTbkp.d ( appears repeated in the strings, but I seem to have fixed that issue (with the repetition, the directory path does not exist, and thus no file can be written). One must manually strip the "time stamp" from the save-file name. I will attempt a restore but only after I have made a screenshot of my current desktop for me manually to move things about in case the restore fails. I also do not want this utility to appear as a folder on my desktop; thus, I must move the DTbkp.d directory from ~/Desktop/ to something else, probably ~/save-Desktop-layout/ that will require changing all of the absolute (and relative ?) paths in the scripts. If I were extremely industrious, I would produce a user interface that shows the various dated backups, allow manual selection of one of these, then the interface script would copy the selected backup file to a file without the date information in the file name, and proceed with the restore.

I'm happy that you have managed to generate the saved file. It is at least promising, so far!

Also, it should not be too difficult to later move the utility to somewhere off the desktop, modifying the searchpaths accordingly.

As I mentioned earlier the original PyQT5 based script by RockDoctor (which I used as the basis for my clunky attempt) was the subject of this thread at the LinuxQuestions site: ( I'm the pseudonym "affekadaffe" there. Real name is Martin Bergman, by the way.)

For ideas on how to make the icon-saving process more userfriendly one should of course firstly have a look at his solution. His actual code is linked for download in post #6 ibid:

Mr. Bergman (Martin?),

Unless you are a MATE developer or maintainer, neither of use should
need to write a special MATE application for what should be an intrinsic
functionality. For example, in Oracle VirtualBox, one option is to
clone a machine (not the running state, but the state from which the
guest "boots" under the type 2 hypervisor). That way, if something in
the guest does go wrong, one can restore to a previous "working" state,
and much more simply than attempting to do this within the guest.
(Example: the on-line "update" from MS Win 8 to MS Win 10 for an MS Win
guest. If the update fails, one simply uses the clone of MS Win 8 to
continue with a MS Win 8 environment in the guest, and, with yet another
clone, attempt the "update" after MS, say, fixes the update "bugs".)
For the layout of a GUI desktop, something similar should be available
from the application environment, and this should be added to MATE
without us continuing to invest work and time into addressing the
necessary utility. If I get this to work, I shall publish it under the
GPL to the MATE list (and the Ask Ubuntu list as well), acknowledging
both you and the history of the work up until then. For now, I am
rather busy to get to this. The lack of such a "backup and restore" in
terms of the MATE desktop is a "failure" of software engineering behind
MATE (and presumably Gnome 2 of which MATE is the "continuation"). This
failure is not the fault of any individual, merely of the development

Take care. Stay safe. AND -- thank you for your understanding of the
issue (others have not been so indulgent), for your solution, and your
willingness to help modify your solution to be configurable for the
specific environment that you needed on your own platform and environment.

Thanks, Yasha.
It is always satisfying to be able to contribute something, in any forum.
Take care and stay safe now, you too.
// Martin