Pretty much, RSA is your only reasonable, reliable & compatible option in OpenSSH


  • DSA is deprecated in OpenSSH 7.0
  • ECDSA is not supported by GNOME Keyring.
  • Ed25519 is not supported by GNOME Keyring.


Via SSH Keys, in Arch Linux Wiki



  • As of July 10, 2015, GNOME Keyring does not handle ECDSA[4] and Ed25519[5] keys. Users will have to turn to other SSH agents or stick to RSA keys.
  • These keys are used only to authenticate you; choosing stronger keys will not increase CPU load when transferring data over SSH.


Via How to save an SSH key passphrase in gnome-keyring? in Stack Exchange for Unix & Linux

cd $HOME/.ssh
/usr/lib/seahorse/seahorse-ssh-askpass my_key


In Arch Linux Wiki


SOLVED: Diagnosis & remediation for gnome-terminal failure to start with Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error spawning command line ‘dbus-launch…’


** (gnome-terminal:28588): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-jXttvb928F: Connection refused
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error spawning command line 'dbus-launch --autolaunch=2f24fcda41304c13ac6826ea32e20941 --binary-syntax --close-stderr': Child process exited with code 1


There are too many connections to he X11 server.


Have fewer connections to your X11 server.


The limit is only have ~255 (or maybe it’s 127, unclear). The error messaging when connections to the graphics server fail are … murky and misdirecting at best.


Restarting the GNOME keyring daemon after (it) crashes


setsid /usr/bin/gnome-keyring-daemon > ~/tmp/o.gnome-keyring-daemon.out 2>&1 &
$ cd /run/user/500
$ sudo mount --bind keyring-$NEW keyring-$OLD


  • Restart the daemon by hand
  • Modify /run/user/$UID to contain the appropriate directory
    • Both the old and the new keyring directories (names) need to “work”
    • Do not use a symlink to get the defunct name to point to the operational one.
      The keyring daemon will observe this after a time and will shut down on its own.
    • Use a bind mount to mount the directory of the operating daemon onto the name of the inoperative one


  • For various reasons gnome-keyring daemon can die
  • You cannot (conveniently) establish a new GNOME session (logout, login again)
  • Many sessions depend upon access to the existing security apparatus
    • ssh-agent
    • gpg-agent
    • etc.

Error Messages

The keyring daemon dies spontaneously:

Dec 28 12:56:08 vast kernel: [2230783.652433] traps: gnome-keyring-d[2679] trap int3 ip:3fd704ed9d sp:7fff617dc420 error:0

If the keyring directory itself is not actually a directory or does not have the correct permissions, then the keyring daemon exits without further recourse:

** Message: Replacing daemon, using directory: /run/user/500/keyring-IIUwlw
** Message: The gnome-keyring control directory has invalid permissions. It must be only be accessible by its owner (ie: 0700): /run/user/500/keyring-IIUwlw


  • Fedora 19
  • GNOME 3.8
  • gnome-keyring-3.8.2-1.fc19.x86_64



  • How to start the keyring daemon after a gnome-shell crash?; Some droid using the self-asserted identity token l0b0; In Stack Exchange; 2012-02-25.
    tl;dr → refers to GNOME circa 2012 (what was that?), but the concepts are valid.
  • GNOME Keyring; In Some Document Landfill; undated.
    tl;dr → seems to have good & current information; sortof, is involved in the GNOME2 & Mate dissent etc.


There are too many (user) processes running. In the gnome-keyring-daemon spontaneously exits.

-bash: fork: retry: No child processes
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: retry: No child processes
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: retry: No child processes
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable

You have to resolve this resource issue before moving in. Perhaps there are to many ssh clients reaching out into the network. Perhaps

$ setsid /usr/bin/gnome-keyring-daemon) > ~/tmp/o.gnome-keyring-daemon.out 2>&1 &
[1] 15202

Restarting the gnome-keyring-daemon results in names on the standard output, which would normally become environment variables for descendants.

$ cd /run/user/500
$ rm keyring-1Vplme
$ mkdir keyring-1Vplme
$ sudo mount --bind keyring-J2oEff keyring-1Vplme

Diagnosing Gnome Terminal failure to start over ssh from merely the cryptic message: Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Could not connect: Connection refused


The contents of /etc/machine-id was the same on both machines


uuidgen | sed -e 's/-//g' | sudo tee /etc/machine-id


  • Some machine ‘s gnome-terminal “just works”
  • Some machine’s gnome-terminal “fails silently”
  • They are “the same”
    • Same package set
    • Same Fedora 22
    • Same VM
    • Same hosting service
    • VMs created within hours of each other
    • etc.

say that again

Same hosting service, same OS, the VMs created within hours of each other,


localhost $ ssh -Y
remotehost $ gnome-terminal
** (gnome-terminal:4508): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8BIJ2Pi6pY: Connection refused
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Could not connect: Connection refused


  • The user-level dbus-daemon has not started. Fix that.
  • Someone or some thing is not creating ~/.dbus/session-bus.
  • Someone or some thing is not allowing dbus-launch to do anything at all



Recall, that one VM “just works” and one VM exhibits the problem. Of course, both are “the same” being Fedora 22, the same kernel 4.1.5, created within hours of each other, etc. The differences in packages between the two

$ diff o.broken-vm-package.list o.working-vm-package.list
broken> elfutils-default-yama-scope
working> python2-firewall
broken> python-firewall
broken> python-pip
broken> python-setuptools

This not indicative of anything.

Machine ID

The Machine IDs of the two machines are “the same” becaues they were created from the same VM cloud image; the Machine ID wasn’t regenerated when the instance was activated. $ ls -lZ /etc/machine*
-r--r--r-- 1 root root ? 33 May 26 09:28 /etc/machine-id $ cat /etc/machine-id 
8aed69c9cc314c318b2af5672573b109 $ ls -lZ /etc/machine*
-r--r--r-- 1 root root ? 33 May 26 09:28 /etc/machine-id$ cat /etc/machine-id.orig

Same contents in the files, same (very old) date in on the files; the date pertains to when the cloud VM image was created.

uuidgen | sed -e 's/-//g' | sudo tee /etc/machine-id


  • Did you reboot?
    No, rebooting, whatever that might mean, doesn’t help.
  • You need to start dbus-daemon --session.
    No, that is supposed to be started by dbus-launch, automatically.


Free Desktop Documentation



  • 834347gnome-terminal through ssh session fails because of stale X server property; In Red Hat Bugzilla; 2013-08-06-21 → 2013-08-01.
    tl;dr → filed against Fedora 17, yet was helpful for Fedora 22.
    Suggests: dbus-launch --exit-with-session gnome-terminal
  • dbus-launch – Utility to start a message bus from a shell script; In Free Desktop Documentation
  • DBUS_SESSION_BUS_ADDRESS environment variable
  • The --autolaunch behavior
  • Default behavior is as if DBUS_SESSION_BUS_ADDRESS=autolaunch: was set
  • Unclear
    • The behavior when ssh’ing to a remote machine; is vague about what does or should happen.
    • How the ~/.dbus/session-bus/machine-id files get created
    • <quote>If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use D-Bus, by default the process will attempt to invoke dbus-launch with the --autolaunch option to start up a new session bus or find the existing bus address on the X display or in a file in ~/.dbus/session-bus/</quote>


Apparently there are problems with gnome-terminal and locales. This is not that problem.
This is a different issue, not described here.

Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Terminal exited with status 8



You should see two dbus instances

  • dbus-daemon --system
  • dbus-daemon --session
$ ps -ef | grep dbus
dbus      2559     1  0 12:08 ?        00:00:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
wbaker    4749     1  0 13:05 ?        00:00:00 /usr/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
wbaker    5107  4780  0 13:19 pts/5    00:00:00 grep --color=auto dbus

To be placed in & around the ~/.bash_profile; interesting but unnecessary in modern Fedora.

# set dbus for remote SSH connections
if [ -n "$SSH_CLIENT" -a -n "$DISPLAY" ]; then
    machine_id=$(LANGUAGE=C hostnamectl|grep 'Machine ID:'| sed 's/^.*: //')
    x_display=$(echo $DISPLAY|sed 's/^.*:\([0-9]\+\)\(\.[0-9]\+\)*$/\1/')
    if [ -r "$dbus_session_file" ]; then
            export $(grep '^DBUS.*=' "$dbus_session_file")
            # check if PID still running, if not launch dbus
            ps $DBUS_SESSION_BUS_PID | tail -1 | grep dbus-daemon >& /dev/null
            [ "$?" != "0" ] && export $(dbus-launch) >& /dev/null
            export $(dbus-launch) >& /dev/null

UNSOLVED: Emacs prior use of C-M-f is occluded by Clipit’s search_key=F

  • emacs uses C-M-f as the natural binding for forward-sexp
  • clipit declares search_key=<Ctrl><Alt>F in ~/.config/clipit/clipitrc

This is super-inconvenient because “clipit always wins” … there is no way for clipit to delegate handling of C-M-f off to emacs within the geometric confines of emacs’ windows.

How can it be disabled?


  • Create ~/.config/autostart/clipit.desktop
    with Hidden=true
  • Not configurable in Settings
  • Not configurable in Startup Applications of gnome-tweak-tool.

From bash:

  • Remove the desktop file /etc/xdg/autostart/clipit-startup.desktop
  • Erase the package
    yum erase clipit

How is it stopped?

From GNOME: unknown, probably there is no way to stop it.
From bash: Kill the process.

How is clipit started?


Perhaps from /etc/xdg/autostart

$ ls -ld /etc/xdg/autostart/clipit-startup.desktop
-rw-r--r--. 1 root root 872 Dec 15 2014 /etc/xdg/autostart/clipit-startup.desktop

$ cat /etc/xdg/autostart/clipit-startup.desktop
[Desktop Entry]
Comment=Clipboard Manager



  • Desktop Application Autostart Specification, Version v0.5; John Palmieri, Kévin Ottens, Renato Caldas, Rodrigo Moya, Waldo Bastian; Free Desktop Standards; 2006-02-13.
    • $XDG_CONFIG_DIRS/autostart
    • $XDG_CONFIG_HOME defaults to ~/.config/autostart/
    • $XDG_CONFIG_DIRS defaults to /etc/xdg/autostart/
    • <quote>If an application autostarts by having a .desktop file installed in the system wide autostart directory, an individual user can disable the autotomatic start of this application by placing a .desktop file of the same name in its personal autostart directory which contains the key Hidden=true. </quote>
  • Manage the startup applications; In The GNOME Shell; 2011-08-26.
    tl;dr → out of date; offers gnome-session-propertiesas a solution

    • Yet gnome-session-properties no longer exists in Fedora 21.
    • <quote>System-wide shortcuts can be found in /etc/xdg/autostart and in /usr/share/gnome/autostart but the preferences dialog will create local copies in your user profile when you edit a shortcut by disabling it or editing its name, command or description. You generally don’t need to edit the system-wide shortcuts but you can make modifications at your private copies.</quote>
  • Autostarting; In Arch Linux Wiki; 2015-05-31.
    tl;dr → not helpful.


Somewhat SOLVED: Bringing up Fedora 21 on the Dell M3800 with a 4K2K Display

Just Works … (almost)completely

  • Installation of Fedora via wireline ethernet (network install) is not possible
  • Installation of Fedora via wireless network not offered.
  • Installation of Fedora via (legacy BIOS boot) USB media … just works.
  • Wireless networking does not work under Fedora [NOT SOLVEDSOLVED]

Once Fedora (Fedora 21) is installed, the network works as it should.


Wireless Network

Does not work.  No wireless networking capability is recognized by Fedora. It worked under the native Ubuntu from Dell.  TODO.

Wireline Network

There s no win or workaround here.  Dell does not provide a wireline NIC on the M3800.  The USB dongle is not supported in BIOS during the network install scenario.  You lose.  You must use a USB stick.

Some dude explored all the options in Dell laptops, including the M3800 to assess which of the BIOS and USB-to-Ethernet dongles would “work.”  Windows-centric (there is some sort of Windows7-vs-Windows8 issue going on for that culture).  The net of the issue is that while the in-ROM PXE will operate the USB-to-Ethernet dongles for long enough to bring over a kernel, once the kernel itself attempts to assert control over the devices from PXE, then the USB controller drops back into HCI mode only, the network-capable hardware “disappears” off the USB bus.  There is no workaround, it is a (legacy) BIOS thing; UEFI does not support network booting in this scenario at all.


  • That blog post.

HiDPI Display

The whole point of this machine was the 4K2K display.  Wiithout intervention, it render similarly to an HDMI display, that is comfortable to read at 15″; to get it to use the full native resolution, which can be uncomfortable to read at 15″ you will need some settings.

To avail yourself of the “High DPI” screen you will need to establish that in GNOME, else you’ll have what amounts to a HDMI-scale screen.  At runtime, within a GNOME session, declare:

gsettings set org.gnome.desktop.interface scaling-factor 1

This wasn’t necessary when using a 31″ display (on Fedora 19 & Fedora 20), but is absolutely necessary using a 15″ display (on Fedora 21).


<quote> cite=”ref”>HiDPI (High Dots Per Inch) displays, also known by Apple’s “Retina Display” marketing name, are screens with a high resolution in a relatively small format. They are mostly found in Apple products or high-end “ultrabooks”, as well as in 4K (Ultra HD) or even 5K monitors.</quote>

<quote cite=”ref“>Hi-dpi support means that applications render at half the available screen resolution to avoid content that is defined in terms of pixels from becoming tiny. Effectively, this means treating 2×2 blocks as device pixels as application pixels, with the extra twist that data that is available in high resolution (e.g. svgs or fonts) can be rendered at the full resolution. </quote>


  • HiDPI; Some Dude; In Arch Linux Wiki; 2015-07-05.
    tl;dr → declares for GNOME as the first solution recipe.
  • Hi-DPI; MatthiasClasen‘; In GNOME Wiki; 2014-12-21
    tl;dr → discursive, not very helpful avoids any mention of gsettings or org.desktop.interface.scaling-factor, mentions gnome-tweak-tool but not what to do with it, discusses detailed application-specific workarounds (avoid these, GNOME works just fine with scaling-factor)
  • How to debug Xorg problems; In Fedora Documentation; 2015.
    tl;dr → this is not a “problem” in Xorg, rather it is a feature of HiDPI displays

    • /var/log/Xorg.0.logno longer exists in Fedora; each release has a different way of recovering the logfile, perhaps the changes have stabilized
      • Fedora 22 → journalctl -b _COMM=gdm-x-session
      • Fedora 21 → journalctl -b _COMM=Xorg.bin
      • Fedora 20 → journalctl -b _COMM=Xorg
      • Fedora 19 (& prior) still used /var/log/Xorg.0.log


  • Use scaling-factor 2 to get something approximating an HDMI (HD-type) resolution.
  • Use scaling-factor 1 to get the native resolution
  • Use scaling-factor 0 to get (what?)
  • Use gsettings reset to recover the default
  • Use gsettings get to recover the current setting.
  • Of course, gnome-settings-daemon must be running.


Printing with CUPS & GNOME & LibreOffice under Fedora 20

Previously: LibreOffice printing Does.Not.Work. Not with GNOME, not with manual config, not at all. And maybe never has.; 2014-12-02
Frustration: very high

Success Recipe


  • GNOME applications have their own print dialog; it works with CUPS.
  • GNOME print dilog can listen to IPP broadcasts
  • GNOME applications “just work.”

Verdict: GNOME printing “just works.”  Full Stop.


  • LibreOffice applications have their own print dialog that might not work with CUPS.
  • LibreOffice print dialog cannot listen to IPP broadcasts
  • LibreOffice printing must be configured on a per-machine basis with spadmin
    • This can be done on a site-wide basis by superuser
    • This can be done on a per-user basis by the consumer.
  • Absent appropriate configuration, “Generic Printer” is the LibreOffice method
    This seems to just call lpr (/usr/bin/lpr) without any further arguments
    Of course, if printing is not manually configured (see above), this will fail silently.

Verdict: LibreOffice does not “just work”; you have to know a lot to get it configured correctly.


  • /usr/lib64/libreoffice/program/spadmin
  • Configuration Files
    • /usr/lib64/libreoffice/share/psprint/psprint.conf
    • ~/.config/libreoffice/4/user/psprint/psprint.conf


  • Two proud & storied developer groups: GNOME & LibreOffice.
  • Both implement a print dialog for their applications & suitable for their culture.
  • Neither dialog system works with the other.
  • Neither is willing to work with the other and change anything.
  • The consumer is left with: “does not work.”


  • Internet Printing Protocol (IPP)
    • port 631
    • tcp/631 for client out connecting to cupsd (server)
    • udp/631 for server broadcasting availability of printers on the subnet
  • FirewallD of Fedora
    • May or may not allow anything but ssh (port 22) by default; tThis has varied across the releases.
    • Default in Fedora 20+ is to run firewalld with aggressive blocking (it’s a nasty world out there).


  • firewall-config
    sudo firewall-config
  • system-config-printer
    sudo system-config-printer
  • /usr/lib64/libreoffice/program/spadmin
    sudo /usr/lib64/libreoffice/program/spadmin


$ cat /etc/fedora-release
Fedora release 20 (Heisenbug)
$ rpm -q -f /usr/bin/libreoffice
$ rpm -q cups
$ rpm -q -a | grep system-config-print
$ rpm -q -a | grep firewall-config

To ensure that the local print server is broadcasting…

$ sudo tcpdump -i em1 'port 631'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes
12:15:56.433174 IP loolie.sanguine.local.ipp > broadcast.sanguine.local.ipp: UDP, length 257
12:15:56.433199 IP loolie.freerange.local.ipp > broadcast.wireline.freerange.local.ipp: UDP, length 256
12:15:56.433203 IP loolie.wireline.foreign.local.ipp > broadcast.wireline.foreign.local.ipp: UDP, length 256
12:15:56.436333 IP joubijou.sanguine.local.ipp > broadcast.sanguine.local.ipp: UDP, length 260
12:15:56.436341 IP joubijou.freerange.local.ipp > broadcast.wireline.freerange.local.ipp: UDP, length 259
12:15:56.436388 IP joubijou.wireline.foreign.local.ipp > broadcast.wireline.foreign.local.ipp: UDP, length 259


Configure the host’s firewall to allow IPP announcements to be received.


  • GNOME print dialog “just works” with GNOME apps & CUPS.
    Exhibit with gedit.


  • Host requires configuration via system-config-printer
  • Host requires configuration via spadmin

Establish a manually-defined printer which pulls from the IPP-available printer on the print server.  You have to do this because LibreOffice’s print dialog cannot understand the IPP broadcast messages that are flying about.  LibreOffice can only shoot at an existing IPP printer (via cupsd) that you have defined manually.

spadmin of LibreOffice

Now you have to manually configure LibreOffice to use the manually-configured printer that you just manually configured.  This is a manual step that you must manually repeat for each host and consumer that you manage.  Manually.


Bluetooth File Sharing no longer works in Fedora 20 with GNOME 3.10, but returns with gnome-user-share-3.10.1

Pafff!!  Gone.  But they don’t just come out and say that.  It used to work in Fedora 19 (GNOME 3.8) and Fedora 18 (GNOME 3.6) … it worked … it “just worked”  Now it’s just gone. You can send files outbound, but you can’t receive files on Fedora 20 (GNOME 3.10).


; Bluetooth file sharing (ObexPush) in GNOME 3.10; In His Blog; 2013-11-12.
tl;dr → support was dropped

  • ObexPush server support is fixed in gnome-user-share 3.10.1,
  • ObexFTP server support is gone.

Yet … on Fedora 20, with updates applied

$ rpm -q -a | grep gnome-user

Prior to gnome-user-share-3.10.1, this dialog in Preferences->File Sharing simply doesn’t work.  It does nothing and files sent from bluetooth devices (e.g. phones) are always refused.

The current GNOME documentation is irrelevant, out-of-date and wrong



GNOME v3.8, Configuring to [not] set folders before files

Problem Statement

  • Fedora 19
  • GNOME v3.8
  • The directories appear before the files in the list mode.
  • Make that stop => [make files and directories be treated equally


  • Find the Files Menu of nautilus
  • Recall that the Files Menu now appears outside of the nautilus window
    [on an 8K4K display, you might forget that it exists]
  • Check [uncheck] the option.

But …

  • For nautilus windows browsing truly remote file systems [e.g. via made available by sftp] the ordering cannot be changed at all.  [wow! that's weird, and frustrating] You will have your directories-before-files and you will like it.  Move along.




<snark>Since GNOME 3.0, the GNOME UX/UI crew have been radically altering the desktop behaviors; and not always for the better.  It’s not clear what overarching theory they are following other than: remove as much functionality as possible.  It’s impossible to predict where features are moving or why they are being removed or truncated.  This is supremely disorienting.  It’s even unclear where to read to receive warnings about these changes or participate or even listen to the debate as it occurs.  One’s best bet is to “read the net” and try to find someone who has had the same Q&A, and then try to read their prose to understand how they rediscovered the setting or mitigated the problem. And hence this tutorial series, with the pictures and arrows..</snark>

Lowering Mouse Sensitivity in Fedora 18 for the Kensington 72123CAA Mouse-in-a-Box Optical Mouse

Not yet SOLVED …

Problem Statement

  • The mouse moves too fast
  • There ought to be a setting to slow it down


  • The setting does not “stick”
  • After the dialog is settings dialog is closed, the mouse speed reverts.
  • Mouse speed setting from the GNOME GUI level does not work.


  • Fedora 18
  • Kensington 72123CAA Mouse-in-a-Box Optical USB Mouse


  • The Kensington 72123CAA what you will receive from Amazon nowadays, even though you order 72123
  • The Kensington 72123 (no the CAA suffix), works just fine and has appropriate desktop speed & acceleration with the default settings.


Untested …


  • xinput --list --short
  • xinput --list --long
  • xinput --set-prop $NAME $PROPERTY $VALUE
  • xinput --list-props $NAME
  • xinput --set-prop $NAME $PROPERTY $VALUE

where $PROPERTY is among

  • "Device Accel Constant Deceleration"
  • "Device Accel Velocity Scaling"

which are enumerated in [WHERE?]


  • device can be the device name as a string or the XID of the device.
  • slave can be the device name as a string or the XID of a slave device.
  • master can be the device name as a string or the XID of a master device.
  • property can be the property as a string or the Atom value.


$ xinput --list --short
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ PIXART USB OPTICAL MOUSE                	id=13	[slave  pointer  (2)]
⎜   ↳ PIXART USB OPTICAL MOUSE                	id=8	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳ Logitech USB Keyboard                   	id=11	[slave  keyboard (3)]
    ↳ Logitech USB Keyboard                   	id=12	[slave  keyboard (3)]
    ↳ Logitech USB Keyboard                   	id=14	[slave  keyboard (3)]
    ↳ Logitech USB Keyboard                   	id=15	[slave  keyboard (3)]
    ↳ GASIA USB Keyboard                      	id=9	[slave  keyboard (3)]

Recall … the GNOME settings “do not work” because they do not stick after the settings dialog is dismissed.

GNOME3 Shell Cheat Sheet

William Jon McCann; GNOME3 Shell Cheat Sheet; updated 2013-11-22

System Settings -> Keyboard -> Shortcuts


  • System (Windows) key: Switch between overview and desktop
  • Alt+F1: Switch between overview and desktop
  • Alt+F2: Pop up command dialog
  • Alt+Tab: Pop up application switcher
  • Alt+Shift+Tab: Cycle in reverse direction in the application switcher
  • Alt+[key above Tab]: Switch between windows of the same application in Alt+Tab
  • Ctrl+Alt+Tab: Pop up accessibility switcher
  • Ctrl+Shift+Alt+R: Start and end screencast recording
  • Ctrl+Alt+Up/Down arrow: Switch between workspaces
  • Ctrl+Alt+Shift+Up/Down arrow: Move the current window to a different workspace


Simplified instructions for the configuration of Firefox to support Yahoo! Messenger’s ymsgr:SendIM URLs


Step 1

In the file ~/.local/share/applications/mimeapps.list, add the following

# ymsgr

Step 2

Within the directory ~/.local/share/applications add a file ymsgr.desktop containing the following:

[Desktop Entry]
Name=Yahoo! Messenger
Comment=Yahoo! Messenger
Exec=purple-url-handler %u

Step 3

Configure the MIME types handler to use the new MIME type and purple-url-handler.



$ rpm -q -a | grep purple

Previously noted

Preventing Western Digital SmartWare Virtual CD from automounting in your desktop

Why do this?  When the CD-ROM function is burned into the very firmware of the disk unit …  That’s when.  Very pesky. You crack the case on one of those things and it’s not really a sata disk inside, the pins are all different.  Which means it does different things than a disk.  <spooky>Different things.</spooky>

Preventing Western Digital SmartWare Virtual CD from automounting in your desktop; in /etc/fstab

/dev/sr1 none udf rw,noauto 0 0

Via: Linux Living: Enjoy your WD My Book 1TB Drive: No more WD SmartWare icon in Ubuntu! » circa 2010-01-14.

<quote>As I mentioned in my last post, I recently picked up a Western Digital My Book Essential 1 TB external hard drive. Although it doesn’t as yet display the same problems that my Simpletech hard drive wa….</quote>

Via: backfill


Enter Special Characters in GNOME by Defining a COMPOSE Key


You want enter characters with diacritical marks as are found in European languages … English, French, German, etc.   For example: Nôtre naïve élève reçois quelque chose de bizarre et outré. Instead of: Unsere naive Schüler bekommen etwas seltsam und extravagant.


  1. Open the Activities overview and start typing Keyboard.
  2. Click on Keyboard to open the panel.
  3. Select the Shortcuts tab and click Typing.
  4. Click on Compose Key in the right pane.
  5. Click on Disabled and select the key you would like to behave as a compose key from the drop-down menu. You can choose either of the Ctrl keys, the right Alt key, the right Win or Super key if you have one, the Menu key or Caps Lock. Any key you select will then only work as a compose key, and will no longer work for its original purpose.


Let LEFT-MENU be the compose key that you’ve defined:

  • Press compose then ' then a letter to place an acute accent over that letter, such as é.
  • Press compose then ` (back tick) then a letter to place a grave accent over that letter, such as è.
  • Press compose then " then a letter to place an umlaut over that letter, such as ë.
  • Press compose then - then a letter to place a macron over that letter, such as ē.



Operating a Fedora 17 (Beefy Miracle) laptop with an outboard monitor and the lid closed; e.g. on a dock

Problem Statement

You want to operate your laptop “a dock” or “in a drawer”

  • with the lid closed
  • with an outboard monitor, perhaps at a larger resolution (e.g. connected to the HDMI output)
  • with an outboard keyboard
  • with an outboard mouse


The default settings for Fedora 17 (Beefy Miracle) do not support this:

  • The laptop suspends when the lid is closed
  • If configured to not suspend when the lid is closed, the outboard monitor darkens is inoperable when the lid is closed


You need: GNOME Tweak Tool (e.g. gnome-tweak-tool-


Lots of references; lots of mentions of the problem; lots of alleged HOWTO and SOLVED tags out there.


A critical piece of folklore is that the external display will wake up if the mouse is moved a few seconds after the laptop lid is closed cite

Procedure [cite]:

  • Configure actions on lid close as Nothing and Nothing
  • Remove Lock on screen blank (apparently after a time delay is OK)
  • Close the laptop lid
  • Wait ten seconds
  • Move the mouse around until the external monitor awakens
  • You may now leave the monitor; depending upon your settings
    • it may lock after a time delay
    • it may not lock at all


Described and perhaps relevant but untested; answer in dated 2011-11-22.

  1. sudo yum install -y dconf-editor
  2. Edit org/gnome/settings-daemon/plugins/power

Or from the command line:

gsettings set org.gnome.settings-daemon.plugins.power lid-close-battery-action blank
gsettings set org.gnome.settings-daemon.plugins.power lid-close-battery-action nothing