小技チョコレート

ちょっとした小技を紹介するだけのブログです。

GNOMEのデスクトップ通知音が鳴らないときに視覚的に知らせる方法

※この記事は「通知音が鳴らないときの対処法」という文脈で書かれていますが、「通知音を出さずにデスクトップ通知の存在を知る方法」として読むことも可能です。


〈目次〉


GNOMEでは、デスクトップ通知の際に音を鳴らすためには、下記の画像のように設定画面の中の「サウンド」の項目の「音響効果」のタブで「警告音の音量」をゼロより大きくしておかなければいけませんが、そのようにしても音が鳴らない場合があります。

f:id:ichbin:20180531075518p:plain

音を使わずに通知を知らせる方法として、画面の一部を点滅させるという「視覚警告」という機能がデフォルトでGNOMEに備わっていますが(設定画面の「ユニバーサルアクセス」の中にある)、それも機能しない場合があります。

f:id:ichbin:20180531075537p:plain

その場合の対処法として、下記のNtofication AlertやRecent Notificationsというソフトを使うと便利です。

対策1:Notification Alert

GNOME Shell ExtensionsのNotifications Alertを使うと、通知が来ればデスクトップの「パネル」の中央にある時計の文字が赤/白で点滅し続けるので、通知の存在を視覚的に知れるようになります。

f:id:ichbin:20180531085505p:plain

時計をクリックして通知欄を開けば、点滅が止まります。赤以外の色も選べるようです。

Notification Alertのインストール方法と設定変更

準備

端末で sudo apt-get install chrome-gnome-shell と実行して chrome-gnome-shell をインストールします。

また、GNOME Shell EXtensionsのインストールにはWebブラウザが必要なので、WebブラウザとしてFirefoxを使う場合はFirefoxGNOME Shell Integrationというアドオンをインストール。ChromiumChromeを使う場合は、ChromeウェブストアのGNOME Shell integrationという拡張機能をインストールします。

Notification Alertのインストール

上述のアドオンや拡張機能をインストールしたWebブラウザNotifications Alertのページを開き、Notification Alertというタイトルの右側にあるスライド式スイッチを動かして"ON"にします。「ダウンロードしてインストールしますか?」と訊かれたら「インストール」を選択。それで完了です。

Notification Alertの設定変更

インストール後に、Notifications Alertのページでタイトルの右側にある工具のアイコンをクリックすると設定画面が開きます。

f:id:ichbin:20180531081751p:plain
(×アイコンの左)

f:id:ichbin:20180531081221p:plain

設定項目は、上から順に

  • 点滅させる色の指定
  • チャットの通知のみを知らせるかどうか
  • 通知をオフにしている状態でも知らせるかどうか
  • 点滅の速さ
  • 通知を知らせないアプリケーションのリスト

となっているようです。

対策2:Recent Notifications

上述のNotification Alertに似たものとして、Recent Notificationsというソフトもあります。こちらの記事で解説されています。

GNOME系デスクトップ環境で画面の明るさが維持されない問題の対処法

GNOMEや、GNOMEから派生したデスクトップ環境を用いるLinuxUbuntu、Manjaro GNOME Edition、Ubntu Budgieなど)において、ログイン後に端末で

$ xrandr --output VGA1 --brightness 0.7

などと入力すると、画面の明るさ(輝度)を変えることができますが、その操作を実行した後で、別のアクション(アプリケーションのウィンドウを開いたり、テキストエディタに文字を入力したり)をすると、画面の明るさが勝手に元に戻ってしまう(100%の明るさに戻る)という不具合が起こることがあります。

筆者は、この不具合を下記の4つのOSで経験しています。いずれも、GNOMEまたはGNOMEから派生したデスクトップ環境です。*1

  • Ubuntu 18.04 LTS
  • Manjaro GNOME Edition 17.1.10
  • Ubuntu Budgie 18.04 LTS
  • Zorin OS 12.3 Core

この不具合の対処法が、AdamKane41氏によりGitHubに発表されていたので、ここに和訳しておきます。*2 Ubuntu 18.04 LTSとManjaro GNOME Edition 17.1.10とUbuntu Budgie 18.04 LTSでこの対処法を実行してみたところ、成功しました(ログイン中には、明るさが勝手に100%に戻ることはなくなった)。


(ここからは翻訳)

※原文はこちら:Sometimes when I open a window (especially chromium) brightness controller resets brightness settings to default (not on app ui) · Issue #102 · LordAmit/Brightness · GitHubにおけるAdamKane41氏の回答

この不具合は /usr/lib/gnome-settings-daemon/gsd-color (GNOME Settings Daemon's color plugin) によって起こります。これがログイン時に自動で実行されることを防ぐことにより、xrandrコマンドなどで設定した画面の明るさや色を維持することができます。

設定方法

(1) GNOME Settings Daemon's color plugin は「自動起動するアプリケーション」にデフォルトで登録されていますが、デフォルトでは「自動起動するアプリケーション」のウィンドウ内に表示されない設定になっているので、端末で下記のコマンドを実行して、同ウィンドウ内に表示させるようにします。

sudo sed -i "s/NoDisplay=true/NoDisplay=false/g" /etc/xdg/autostart/*.desktop ~/.config/autostart/*.desktop

(2) 「自動起動するアプリケーション」を開きます(端末で gnome-session-properties と実行すれば開く*3)。そのウィンドウの中で、"GNOME Settings Daemon's color plugin"というタイトルのものを見つけ、オン/オフのスイッチを動かして「オフ」にしてから、このウィンドウを閉じます。

自動起動するアプリケーション
(「自動起動するアプリケーション」ウィンドウ内の"GNOME Settings Daemon's color plugin"。画像はGithubから引用)

(3) その後でログオフして再びログインし、上述のようなxrandrコマンドやBrightness Controllerのようなソフトで明るさや色を設定すれば、ログイン中にそれが勝手に変更されることはなくなります。

(4) そのとおりになったら、 GNOME Settings Daemon's color plugin を「自動起動するアプリケーション」のウィンドウ内に表示させるようにした上述の設定(1)を元に戻すために、下記のコマンドを端末で実行しましょう。

echo NoDisplay=true | find /etc/xdg/autostart ~/.config/autostart -name \*.desktop -exec sudo tee -a {} + >/dev/null

すべてをデフォルトに戻す方法

上述の設定をすべて取り消して元に戻すには、再び上述の1〜4を実行します。ただし、2のところで"GNOME Settings Daemon's color plugin"を(オフにするのではなく)オンにします。

(翻訳終わり)


その他の設定方法

Ubuntuの場合、 /etc/xdg/autostart/ に org.gnome.SettingsDaemon.Color.desktop というファイルがあります。これが、上述の手順において自動起動をオフにする対象となっているファイルでしょう。このファイルの内容は、デフォルトでは下記のようになっていると思います。

[Desktop Entry]
Type=Application
Name=GNOME Settings Daemon's color plugin
Exec=/usr/lib/gnome-settings-daemon/gsd-color
OnlyShowIn=GNOME;
NoDisplay=true
X-GNOME-Autostart-Phase=Initialization
X-GNOME-Autostart-Notify=true
X-GNOME-AutoRestart=true
X-Ubuntu-Gettext-Domain=gnome-settings-daemon

このファイルの末尾に、

X-GNOME-Autostart-enabled=false

と付け加えるだけでも、上述の手順の実行結果と同じ状態にできると思います*4*5

なお、この org.gnome.SettingsDaemon.Color.desktop というファイルは、ホームディレクトリの下の .config/autostart/ にも存在しているかもしれないので、存在していればそちらも同様に編集すべきかもしれません。

関連記事

*1:デスクトップ環境がXfceやCinnamon、KDE、MATEであれば、この不具合は起こりませんでした。

*2:訳者による補足を適宜入れていますので、原文にない文言もあります。

*3:Manjaro GNOME Editionなどのように、「自動起動するアプリケーション(gnome-session-properties)」がデフォルトではインストールされていないディストリビューションもあります。その場合は、この記事の後半に載せている「その他の設定方法」を実行すればよいと思います。

*4:このファイルをそのように編集するには、例えばテキストエディタとしてgeditを使う場合なら、端末で sudo gedit /etc/xdg/autostart/org.gnome.SettingsDaemon.Color.desktop と実行する。

*5:NoDisplay=true のところを NoDisplay=false に変えれば、"GNOME Settings Daemon's color plugin"が、上述の画像のように「自動起動するアプリケーション」のウィンドウ内に表示されるようになると思います。

luckyBackupが意図しない時刻にも実行される場合の対処法

例えば、毎日の午前9:00に自動でバックアップをするようluckyBackupで設定してあるのに、その時刻以外にもluckyBackupが自動でバックアップを行う、という現象が起こることがあるようです。

それは、luckyBackupの"schedule"の画面で remove のボタンと cron IT!! のボタンを押して取り除いたはずのスケジュールが、crontabファイルからは正しく取り除かれずに残ってしまい、その残ったものが実行されているせいではないか、と思われます。

f:id:ichbin:20180513212413p:plain
(例えば、この画像に載っている15:00と21:00のスケジュールを remove ボタンで消してから cron IT!! を押しても、crontabファイルからはその2つのスケジュールが消えていない、というようなこと)

端末で

crontab -l

と入力すると、ログイン中のユーザーのcrontabファイルの内容が表示されます。その中で、

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ luckybackup entries ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0 9 * * *   /usr/bin/luckybackup -c --no-questions --skip-critical /home/〈ユーザー名〉/.luckyBackup/profiles/default.profile > /home/〈ユーザー名〉/.luckyBackup/logs/default-LastCronLog.log 2>&1
0 15 * * *  /usr/bin/luckybackup -c --no-questions --skip-critical /home/〈ユーザー名〉/.luckyBackup/profiles/default.profile > /home/〈ユーザー名〉/.luckyBackup/logs/default-LastCronLog.log 2>&1
0 21 * * *  /usr/bin/luckybackup -c --no-questions --skip-critical /home/〈ユーザー名〉/.luckyBackup/profiles/default.profile > /home/〈ユーザー名〉/.luckyBackup/logs/default-LastCronLog.log 2>&1
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ end of luckybackup entries ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

というように、"luckybackup entries"と"end of luckybackup entries"で挟まれた領域(行)が、luckyBackupのスケジュールを示しています。行頭が"0 9 * * *"などとなっているのが、個々のスケジュールに相当します。上述の例では3つのスケジュールが存在しています。

luckyBackupの画面で消したはずのスケジュールが、この挟まれた領域の中で消えずに残っていれば、それを消すことで、luckyBackupの不要な実行を止めることができます。*1

その手順を紹介します。

まず、crontabファイルを編集するエディタを指定します。ここでは例としてgeditを指定することにします。

端末を起動し、

$ EDITOR=gedit
$ export EDITOR

と入力。

次に、同じく端末で

crontab -e

と入力。

すると、geditが起動し、下記のようなテキストが表示されます。

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ luckybackup entries ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0 9 * * *    /usr/bin/luckybackup -c --no-questions --skip-critical /home/〈ユーザー名〉/.luckyBackup/profiles/default.profile > /home/〈ユーザー名〉/.luckyBackup/logs/default-LastCronLog.log 2>&1
0 15 * * *    /usr/bin/luckybackup -c --no-questions --skip-critical /home/〈ユーザー名〉/.luckyBackup/profiles/default.profile > /home/〈ユーザー名〉/.luckyBackup/logs/default-LastCronLog.log 2>&1
0 21 * * *    /usr/bin/luckybackup -c --no-questions --skip-critical /home/〈ユーザー名〉/.luckyBackup/profiles/default.profile > /home/〈ユーザー名〉/.luckyBackup/logs/default-LastCronLog.log 2>&1
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ end of luckybackup entries ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

消したい行があれば削除します。"luckybackup entries"と"end of luckybackup entries"で挟まれた領域以外は、編集しません。

編集し終わったら、geditで「保存」を実行。そしてgeditを閉じます。その時点で、端末にcrontab: installing new crontabというメッセージが表示されれば、これで完了です。*2

関連記事

*1:この挟まれた領域が、crontabファイルの中に、同一の内容で複数存在していることもあるかもしれません。その場合も、1つだけ残して他は消せます。

*2:その時点で端末に"crontab: no changes made to crontab"というメッセージが出ていたら、何らかの理由でcrontabファイルの変更ができていません。使用するエディタをviに変えるなどして再度実行するとよいかもしれません。

luckyBackupで自動バックアップができないときのチェックポイント

Linux用のバックアップソフト「luckyBackup」で自動バックアップができないときに、チェックするとよいと思われるところを紹介します。

(1) Task propertiesの画面で、SourceやDestinationの欄に半角英数字以外の文字が入っていないか(入れるべきではないみたい。フォルダ名に日本語が含まれていると、これに該当する)。

f:id:ichbin:20180511182742p:plain

(2) スケジュールを編集する画面で、

  • skip criticalの欄にチェックが入っていないか(チェックを入れると、"critical"というカテゴリに当てはまる処理は、スキップ=不実行となる)。
  • Console Modeの欄にチェックを入れたか(チェックを入れないといけない、という情報がある(参照12)。

f:id:ichbin:20180511182803p:plain

(3) scheduleの画面で、 cronIT!! のボタンを押し忘れていないか。

f:id:ichbin:20180513171922p:plain

(4)crondが起動していないのではないか。

Luckybackupに、バックアップを自動で実行させるためには、crondが起動していなければなりませんが、Linuxの起動時にcrondを自動で起動する状態になっていない場合もあるようです。

Linuxの起動時にcrondを自動で起動させるように設定する仕方はいくつかあるようで、たとえばArch Linux系であればこちらのようにするとできます。

関連記事