Fix hard-coded paths of scripts/gnome/___.desktop

[jgvictores]

Org-wide fix hard-coded paths of scripts/gnome/___.desktop

Learn from https://github.com/roboticslab-uc3m/asibot-configuration-files

Refs:

• cmake/templates/asibot-apps.desktop.in
• CMakeLists.txt (no install step yet)

Special treatment as always for https://github.com/roboticslab-uc3m/project-generator

[PeterBowman]

TODO list (:panic:):

• amor-configuration-files
• asibot-hmi
• follow-me
• footsteps x
• force-torque-balance x
• fusion-control x
• manip-waiter x
• openrave-yarp-plugins
• speech
• teo-bimanipulation x
• teo-configuration-files
• teo-grasp x
• teo-self-presentation
• textiles
• tiago-main
• tools
• vision
• waiter x
• xgnitive
• yarp-devices
• project-generator

Note: some of these are not used at all and may be safely removed.
Note 2: repos marked with an x are low priority.

[PeterBowman]

CMakeLists.txt (no install step yet)

Let's talk about this. Where should these .desktop files land upon install? Is $HOME/Desktop a good location, and plain $HOME as a fallback in case of trouble (e.g. missing Desktop directory)? The xdg-user-dir utility could come in handy here, see:

• https://askubuntu.com/q/194124
• https://wiki.archlinux.org/index.php/XDG_user_directories
• https://packages.ubuntu.com/trusty/xdg-user-dirs
• https://packages.ubuntu.com/xenial/xdg-user-dirs
• https://github.com/lxde/lxqt-build-tools/blob/4d434ca/cmake/find-modules/FindXdgUserDirs.cmake

[jgvictores]

Is $HOME/Desktop a good location, and plain $HOME as a fallback in case of trouble (e.g. missing Desktop directory)?

Yes, that would be perfect.

[PeterBowman]

Proof of concept: roboticslab-uc3m/asibot-configuration-files@d8f9f07.

Behavior:

• configure_and_install_desktop_shortcut accepts one single parameter: a path to the desktop shortcut template to be configured and installed.
• This template file must strictly follow the <whatever>.desktop.in naming scheme.
• Upon configuration, a <whatever>.desktop will show up in build/CMakeFiles/.
• This file is copied into build/ with execute permissions. This is meant to spare users the need to run make install and let them use the shortcut straight away. This has some implications (*).
• We look for the xdg-user-dir script.
• If found, it's called and CMake retrieves the path to $HOME/Desktop Otherwise, the $HOME variable is resolved.
• At last, we install the shortcut in said location.

(*) Actually, the generated shortcut should be properly handled to work locally, i.e. from build/. I'd leave this as a TODO.

[PeterBowman]

(*) Actually, the generated shortcut should be properly handled to work locally, i.e. from build/. I'd leave this as a TODO.

Done at roboticslab-uc3m/asibot-configuration-files@825b9f7.

[PeterBowman]

As found out at asrob-uc3m/robotDevastation#126, we are having trouble in correctly displaying the shortcut icon whenever the full path points at system-located PNG files. Apart from that, @jgvictores posted the following link, which may render useful: https://developer.gnome.org/integration-guide/stable/desktop-files.html.en. I learned from it that the standard way of registering applications in a GNOME-compatible desktop (so that they show up as menu items (Debian) or as search results in the Unity launcher (Ubuntu)) is to place their .desktop shortcuts either in /usr/share/applications (all users) or ~/.local/share/applications (single user). Therefore, we'll may have up to three different copies of the same app shortcut:

• in the build tree of the project
• at ~/Desktop
• in the Main Menu of a GNOME desktop environment or showing up as search results in the Unity launcher

All or some of these might be enabled/disabled via CMake options.

[PeterBowman]

Solely regarding icon files and their standard location(s): https://askubuntu.com/a/435612. Perhaps /usr/local/share/icons? (per $XDG_DATA_DIRS/icons, test on different distros)

[PeterBowman]

Moar on standard directory layout: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY.