The last time I tried it, GNOME-Shell (i.e., Metacity is important here, I suppose) was controllable with wmctrl
just fine. So you can add shortcuts calling wmctrl
to switch the workspace.
Be aware that it only knows about workspace 1
, 2
, ... -- so there might be some work involved before it behaves as you'd like it to.
(You could be better off with diving into GNOME-Shell's sources; the relevant parts here are written in Javascript and it could be fairly easy to get your keys the way you'd like them. I tried something similar with the keybindings of the window switcher Alt+Tab
thingy, I'm not actually sure if the workspace switching is accessible in a similar way; still it might be worth a look.)
No idea about Unity, though.
Some Gnome applications are launched by systemd --user
, in which case umask is set by systemd to 0022
regardless of the configured value for pam_umask. I am not aware of any workarounds, but I opened an issue on systemd github issue tracker. This issue is also reported on Gnome bugzilla.
Umask set using pam_umask
is working as expected for applications which are not launched by systemd --user
.
One workaround is suggested on Ubuntu bugzilla to place systemd service overrides to all affected applications.
Update: pam_umask should work as expected for systemd version 246 and newer. Newer distribution releases should ship with a version where the bug is fixed.
To investigate this yourself
You can list the processes running on your system in a tree format (parent/child processes) using:
pstree -Tapu
Find PIDs for: (1) your session's instance of systemd --user; (2) an application launched by it, such as gedit, which will show as child process to systemd --user; and (3) a process in your session not launched by systemd --user.
Compare umasks reported in procfs:
grep Umask /proc/<pid>/status
systemd --user itself (1) and processes not launched by it (3) should have the correct umask which was set by pam_umask. Processes launched by systemd --user (2) will have umask of 0022
.
Best Answer
In GNOME and other freedesktop.org-compliant desktop environments, such as KDE and Unity, applications are added to the desktop's menus or desktop shell via desktop entries, defined in text files with the
.desktop
extension (referred to as desktop files). The desktop environments construct menus for a user from the combined information extracted from available desktop entries.Desktop files may be created in either of two places:
/usr/share/applications/
for desktop entries available to every user in the system~/.local/share/applications/
for desktop entries available to a single userYou might need to restart GNOME for the new added applications to work.
Per convention, desktop files should not include spaces or international characters in their name.
Each desktop file is split into groups, each starting with the group header in square brackets (
[]
). Each section contains a number of key, value pairs, separated by an equal sign (=
).Below is a sample of desktop file:
Explanation
[Desktop Entry]
theDesktop Entry
group header identifies the file as a desktop entryType
the type of the entry, valid values areApplication
,Link
andDirectory
Encoding
the character encoding of the desktop fileName
the application name visible in menus or launchersComment
a description of the application used in tooltipsIcon
the icon shown for the application in menus or launchersExec
the command that is used to start the application from a shell.Terminal
whether the application should be run in a terminal, valid values aretrue
orfalse
Categories
semi-colon (;
) separated list of menu categories in which the entry should be shownCommand line arguments in the
Exec
key can be signified with the following variables:%f
a single filename.%F
multiple filenames.%u
a single URL.%U
multiple URLs.%d
a single directory. Used in conjunction with%f
to locate a file.%D
multiple directories. Used in conjunction with%F
to locate files.%n
a single filename without a path.%N
multiple filenames without paths.%k
a URI or local filename of the location of the desktop file.%v
the name of the Device entry.Note that
~
or environmental variables like$HOME
are not expanded within desktop files, so any executables referenced must either be in the$PATH
or referenced via their absolute path.A full Desktop Entry Specification is available at the GNOME Dev Center.
Launch Scripts
If the application to be launched requires certain steps to be done prior to be invoked, you can create a shell script which launches the application, and point the desktop entry to the shell script. Suppose that an application requires to be run from a certain current working directory. Create a launch script in a suitable to location (
~/bin/
for instance). The script might look something like the following:Set the executable bit for the script:
Then point the
Exec
key in the desktop entry to the launch script: