Hatena::ブログ(Diary)

shouhの日記

2016-01-08

Windows 7 でウィンドウのフォーカスが奪われるのを防ぐ試み(結論:出来ないことはない)

結論

  • Windows の仕組みとして防ぐのは不可能
  • ツールを自分で作れば、出来ないことはない
    • 例: 指定ウィンドウを強制的にアクティブにし続けるツール
    • このようなツールはどこにも存在していない模様(欲しいなら作るしかない)

以下、各結論の詳細を書く。

フォーカスが奪われるのを Windows の仕組みとして防ぐのは不可能

Windows Vista 以前であれば、レジストリ

HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout

の値をいじることで防ぐことができたが、Windows 7 ではこのレジストリキーが使われなくなったため、もう使えない。

「じゃあ代わりに別の仕組みがあるんでしょ?」と思いたくなるけど、無い。

参考

Windows 的に不可能ならツールで対処するしかない!

となれば、まずはツールを探すのだが……残念でした。そんなツールはありません。

そもそも「どんな検索キーワードで探せば見つかるのか」もわからないです。「フォーカス 奪う 防止 ツール」? それとも「stop a window from stealing focus」? ……私も色々試しましたが見つかりませんでした。

ツールが無いなら作るしかない!

ツールが無いなら、最終手段。作るしかない。

ではどんなツールを作ればいいのでしょうか。私の貧弱な頭で思い浮かんだのは「指定したウィンドウを強制的にアクティブにし続けるツール」でした。要するに、他のウィンドウがアクティブになってフォーカスを奪ったところで、無理矢理アクティブの対象を切り替えてやれば実質フォーカスが奪われない状態と同等でしょ? というアイデア。

以下、このツールの製作に関する詳細を書く。プログラミングの専門的な話題が続きます。

最初に結論。

  • そのようなツールが作れそうってところまでは実験して、作れそうとわかった
  • でも作ったところで、そのツールはあまり万能じゃない
    • たとえば一秒に十数打以上打ち込んでいる場合は、フォーカスを奪ったウィンドウに1,2打くらい流れてしまいます
  • そのツールには視覚的にうざい性質がついてくる。
    • アクティブにし続けるという処理の都合上、ウィンドウ切替操作が入り、視覚的にちかちかする
  • だからツールを作るのは断念しました。

1. 成果物

まずは成果物。自分用メモ&HSPで書いたクソースなので読みづらいだろうけど。

2. ツールの実装案

作りたいツールは「指定したウィンドウを強制的にアクティブにし続けるツール」。

これに必要な処理は以下。

  • 強制アクティブ: 指定したウィンドウを強制的にアクティブにする処理
  • ターゲット指定: アクティブにし続けたいウィンドウを選択する処理
  • アクティブウィンドウ監視: ターゲット以外のウィンドウがアクティブになったかどうかを監視

これらを組み合わせれば、以下のように組み合わせることで

  • 適当に「ターゲット指定」を行った後、「アクティブウィンドウ監視」を行う。ターゲットと異なるウィンドウがアクティブになったら、ターゲットを強制アクティブにする

ツールを実現できる。

3. ツールの実装詳細

実装には WindowsAPI を利用する。一つずつ見ていく。

ターゲット指定:
GetForegroundWindow() などでターゲットにしたいウィンドウのウィンドウハンドルを保持しておく。

アクティブウィンドウ監視:
無限ループの中で定期的に GetForegroundWindow() を行い、ターゲットウィンドウハンドルと異なるウィンドウハンドルが返ってきたら、ターゲットウィンドウを強制アクティブにする。

強制アクティブ:
これがややこしい。

まず、ウィンドウを確実にアクティブする処理として、

How to bring window to top with SetForegroundWindow() - CodeProject: http://www.codeproject.com/Tips/76427/How-to-bring-window-to-top-with-SetForegroundWindo

これの二番目のアルゴリズムを実装する(ActiveteWindow関数としよう)。このアルゴリズムについて簡単に説明しておくと、SystemParametersInfo やら AttachThreadInput やら AllowSetForegroundWindow やらで小細工して SetForegroundWindow を確実に通すという処理。

ただ、これだけだと実はウィンドウを確実にアクティブにできないパターンがあって不十分。このパターンをカバーするために、実際は以下の様にして ActiveteWindow 関数を使う。

# self_hwnd   は強制アクティブ処理を行うウィンドウ(自身)のハンドル
# target_hwnd はターゲットのウィンドウハンドル
ActiveteWindow(self_hwnd)
ActiveteWindow(target_hwnd)

つまり、いったん自身ウィンドウをアクティブにしてから、続いてターゲットをアクティブにする。

……以上。これで肝となる処理は書ける。あとは適当に UI とか整えれば、ツールの完成。

4. 使い心地を試してみた

さて、使い心地はどうであろうか。

理想は、20打/秒 くらいの高速なタイピングでも一切フォーカスが奪われない(入力した文字が漏れ無く現在利用中のエディタに反映される)ことだが……試してみると、そうはいかなかった。以下の問題があった。

  • 強制アクティブが走る度にアクティブウィンドウ切替(alt + tab で切り替えるみたいなイメージ)が走るため、画面がちらついてうざい
  • 20打/秒 レベルの打鍵全てを漏らさないのは無理で、数打が漏れるくらいは一時的に奪われてしまう(秒で言えば0.0x秒レベルなのだが)

つまり、アクティブウィンドウ切替という高級な処理自体の限界があるというわけだ。

5. 見解

一応所望のツールは作れることがわかった。しかし、完全にフォーカスを奪われないようにするのは無理で、どうしても一瞬は漏れてしまう(ので高速なタイピングをしてると一時的に数文字くらい打ち漏れる)。しかもウィンドウがちらつく問題もある。

私には、これらの問題は耐えられるものではない。だからこのツールを作るのは諦めた。

おわりに

こういうことで悩まないといけないから Windows は面倒くさいですね。まあ、そういうのをプログラミングツールや設定で対処していくところがまた面白いところでもあるのですが。

ちなみに Mac だとフォーカスが奪われることはないみたいです。羨ましい。

Hugo 初心者だけど Hugo の主な概念、仕組み、仕様、エラーなどをまとめた

はじめに

本記事は、Hugo でブログっぽいものを公開するところまで出来た私の備忘録である。わざわざまとめずとも公式ドキュメント http://gohugo.io/overview/introduction/ を読めば済むのだが、私は英語があまり読めないので自分で調べたり試行錯誤した。

なお、環境等は以下のとおり。

試行錯誤の結果は上記ソースを見ればわかるが、いちいちソースを見るのもアレなので、改めてまとめることにした次第である。本記事では、手順よりも考え方の説明に重点を置くことにした。

以下、一つの中見出しに一つの TIPS を書く、というスタンスでひたすら書き並べることとする。

Theme はどうやって設定する?

http://themes.gohugo.io/ あたりから探す。ググるなり Github で探すこともできる。入手したテーマ一式をこのように配置する。例では hugo-zen というテーマ。

hugotest
│
└─themes
    └─hugo-zen
        │  .gitignore
        │  LICENSE.md
        │  ...
        │
        ├─archetypes
        │      default.md
        ...

要するに themes フォルダの下にまるっと置けばいい。その後、config.toml にテーマ名を設定する。

...
theme = "hugo-zen"
...
[params]
  logo      = "/images/profile.jpg"
  copyright = "shouh All rights reserved."
  github    = "https://github.com/shouh/"

ここで params って何だよ?と思うだろうが、これはテーマの仕様である。テーマによっては、このように色々パラメータを指定させる場合がある。その辺は各テーマの README を読む。

Theme が動作しない(ビルド時にエラーが出る)

Theme の多くは Hugo 最新版である v0.15 に最適化されているので、本記事で試した v0.14 には対応していないことが多い。

ビルドした生成物をローカルでプレビュー表示したい

hugo server コマンドを使う。

$ hugo server -D -w -t hugo-zen --baseUrl=http://127.0.0.1/
0 draft content
0 future content
13 pages created
0 paginator pages created
7 tags created
2 categories created
in 128 ms
Watching for changes in C:\work\github\shouh\hugotest/{content,layouts,static,themes\hugo-zen}
Serving pages from C:\work\github\shouh\hugotest\public
Web Server is available at http://127.0.0.1:1313/
Press Ctrl+C to stop

ポイントは -t (テーマ名) でテーマを指定することと、--baseUrl を上述のようにローカルにすること。

ちなみに -D は下書き(下書きについてはここでは割愛)も表示するの意で、-w でリアルタイムプレビュー(記事に変更があれば自動的にビルドしなおして反映してくれる)の意。

静的ファイル(画像など)をアップしたい

静的ファイルの置き場所は static フォルダ配下。

で、置いたファイルにアクセスしたい場合、たとえば記事中から画像を貼りたい場合は、以下のようにする。

+ hugotest
 + static
  + images
   - profile.jpg  <= これを記事中から表示したい場合は...

こんな風に書く。

![profile_image](/images/profile.jpg)

つまり、正しいパスは「static という名前を省いた相対ディレクトリ」である。

Hugo の Markdown でサブリストのインデントはスペースは4つ

Github Markdown でリストを書く時はスペース2つだが、Hugo の Markdown では4つである。2つだとサブリストやサブサブリストが反映されないため注意。

以下は正しくない。

- リスト
  - サブリスト
    - サブサブリスト

以下が正しい。

- リスト
    - サブリスト
        - サブサブリスト

Github pages に自動でデプロイするにはどうすればいいか

一般的な手順は、Git rebase やら何やらを使うらしいが、その辺はよくわからなかったので私はこうした。

まず Github に Hugo 用のリポジトリ(ここでは hugotest とする)を作り、チェックアウトして、ガシガシ作業する。

+ 作業ディレクトリ
 + hugotest

問題は、Github pages にデプロイするとき。手順を書くなら、Hugo でビルドして出来上がった public フォルダを hugotest リポジトリの gh-pages ブランチに push する、となる。この手順をいかに自動化するかが争点であり、みんな悩んでて、一般的には Git rebase とか使うらしい。

私はこうした。

+ 作業ディレクトリ
 + hugotest
 + hugotest-ghpages <= もう一つ hugotest を clone し、gh-pages をチェックアウトする

んで、こうする。

+ 作業ディレクトリ
 + hugotest
  - deploy.bat        <= Hugo ビルド、publicフォルダのhugotest-ghpagesへのコピー等を行う
 + hugotest-ghpages

要するにgh-pagesブランチ用のディレクトリを別途作りビルドして出来たブツをそこにコピーして、あとはそいつを push するというアイデア。

ディレクトリを別途作るのはださいけど、わかりやすいと思う。少なくとも Git rebase やら何やらという意味不明なやり方よりはずっといい。

Github pages 上で相対リンクが上手く動作しない

config.toml の設定が肝。

baseurl = "http://shouh.github.io/hugotest/"
canonifyurls = true

baseurl にて Github pages の URL を指定することと、相対パス指定を有効にする canonifyurls も有効にしておくのがポイント。

Github pages 上でリンク先が全部 127.0.0.1 になってるのはなぜ?

hugo server コマンドでローカルでのプレビューを行った成果物をアップするとそうなる。

$ hugo server -D -w -t hugo-zen --baseUrl=http://127.0.0.1/
この時、成果物のリンク先は全て http://127.0.0.1/ になっている。
このまま Github pages にアップすると、当然リンク先は http://127.0.0.1/ のまま。

アップする際は hugo コマンドでビルドしてからにしよう。

$ hugo server -D -w -t hugo-zen --baseUrl=http://127.0.0.1/
...
$ hugo  <= ビルドしてから
...
$ Github pages にアップする

Taxonomy って何?

情報源: https://gohugo.io/taxonomies/overview/

Taxonomy とは、Hugo がサポートしてる各記事のラベリングの仕組み。用語として Taxonomy、Term、Value が登場するけど、カーディナリティはこんな感じ。

taxonomy ----- term ----- value
        1     n    1     n

Hugo のデフォルトの Taxonomy としてタグとカテゴリが用意されている。タグを例にすると、上記のカーディナリティはこうなる。

タグとして windows, linux, python の三つを指定したとする。

taxonomy ----- tag ----- windows
               | |
               | +------ linux
               +-------- python

要するに Term はタグやらカテゴリといった「分類の名前」であり、Value はその分類に属する各値、みたいな感じ。

タグとカテゴリはどうやって作る?

まず記事ファイルにはこう書く。これは タグ tag1, tag2 とカテゴリ category1, category2 を指定した例である。

+++
tags = [ "tag1", "tag2" ]
categories = [ "category1", "category2" ]
+++

ビルドすると、成果物 public ディレクトリ配下はこんな感じになる。

$ tree public /f
C:\WORK\GITHUB\SHOUH\HUGOTEST\PUBLIC
│  index.html
.
.
.
│
├─categories
│  ├─category1
│  │      index.html
│  │      
│  └─category2
│          index.html
│
├─tags
│  ├─tag1
│  │      index.html
│  │      
│  └─tag2
│          index.html

つまりカテゴリは categories/(カテゴリ名) という階層でアクセスでき、タグは tags/(タグ名) という階層でアクセスできる。アクセスすると、その分類に該当する記事の一覧ページが表示される。たとえば categories/category1 にアクセスすると、カテゴリ category1 に属する記事の一覧ページが表示される。

ちなみに、カテゴリの一覧やタグの一覧は categories/ あるいは tags/ にアクセスすると表示される。

ちなみに、これら一覧ページのデザインは terms.html というテンプレートを作ることで行う。例: hugotest\layouts\_default\terms.html

あとは、トップページのテンプレートあたりを改造して、これらへのリンクでも書いてやればOK。タグ一覧やカテゴリ一覧を備えたブログが出来上がる。

FrontMatterって何?

Hugo の記事は下記のようになっているが、このうち '+++' で囲まれたところが FrontMatter。

+++
date = "2015-12-21T14:32:50+09:00"
title = "taxonomy_test2"
categories = [ "運用" ]
+++

# 本文
hoge
...

FrontMatter は記事のメタ情報を書くところ。Hugo はビルド時、ここを見て、記事の表示順序やその他表示整形処理を決めたりするので、ここをいじることでビルド生成物を制御できる。たとえば後から date をいじって投稿日時を変えるとか、カテゴリを設定し直すとか。

記事は hugo new コマンドで作るが、この時デフォルトでセットされる FrontMatter を設定する方法がある。それは

  • archetypes\default.md

に、セットしたい FrontMatter を書いておくこと。よく使う Matter についてはここに書いておくと楽。

ちなみに date と title については勝手に付加されるので不要。

なお、どんな FrontMatter があるかについては https://gohugo.io/content/front-matter/ を。英語ですがね。

特定の記事を常に最新記事として表示させたい

FrontMatter の weight を使う。これは記事の表示順序を制御するものである。

書き方としてはこう。

+++
weight = 1
+++

値の挙動については以下のとおり。

  • 値が大きいほど先(日付が古いのと同じ扱い)に来る
  • weight 値の指定が無い記事は、weight 指定がある記事よりも後に来る

つまり weight を使うことで、常に最新として表示したい記事などを作ることができる。

コメントを付けたい

DISQUSを使う。設定手順は http://gohugo.io/extras/comments/ に書いてあるが英語。こっちで改めてまとめた。

まずは DISQUS 側の設定。

  1. DISQUS https://disqus.com/アカウントを作る
    • 強制チュートリアルで三つほどフォローしないと先に進めないので、テキトーにフォローする
  2. Site を作る
    • shortname は後々使うのでメモしておく
  3. (必要なら)Site の設定を開き、匿名コメントを許可する
    • Settings > General > Allow guests to comment にチェック

続いて Hugo 側の設定。

  1. config.toml を開き、disqusShortname = "先ほどメモしたshortname" を書く
  2. 自分が使用している Theme の single.html に以下を記載する
    • 例: hugotest/themes/hugo-zen/layouts/_default/single.html

{{ partial "header.html" . }}

    ...

    {{ template "_internal/disqus.html" . }}   <== この行を加える

{{ partial "footer.html" . }}

あとは記事をビルドし、ビルドした成果物の記事ページを開けば、DISQUS のコメントフォームが表示されるはず。

おまけ: DISQUS のコメントフォームは使いづらい

どうも TwitterFacebook といった SNS から投稿することを前提としているようで、匿名コメントには優しくない仕様である。

具体的に言えば、匿名コメントを書く場合は以下をしないといけない。

  1. Name 欄をクリック
  2. 入力欄が複数個出てくるので、I’d rather post as a guest にチェックを入れる
  3. Name 欄と Email 欄の二つのみになるので、二つとも埋める(どちらも必須。emailは適当でもOK)

面倒くさい。

……なるほど、どおりで国内の Hugo 製ブログはコメント数が少ないわけだ。

静的サイトジェネレータ Hugo (+ Github Pages にデプロイ)を試したので使い心地とかまとめる

Hugo とは何か、何が嬉しいのか、どんな人に向いているか、大変なことは何かなどをまとめた。

前提

以下を前提とする。以下を満たさない場合は、本記事の内容はしっくり来ないかもしれない。

  • Windows 使いです
  • CUIは嫌いですが、まあコマンドプロンプトは普通に使います
  • 英語はあまり読めません(ググって英語ページが出るとたまに読める程度)
  • シンプルなブログレベルのコンテンツを公開するところまでを試したいです

Hugoとは?

Hugo とは静的サイトジェネレータの一種Wiki みたいな簡単な記法で記事(テキスト)を書き、ビルドをすると、Web サイト用の HTML が生成されるので、あとはこれを Web サーバとかにアップすれば、Web サイトとして公開できちゃうよ……というもの。

特徴は以下。

  • Go言語製
    • 込み入ったカスタマイズになると Go 言語の知識が要る
  • セットアップが楽ちん(Hugo.exe を PATH に通すだけ)
  • 記事は Markdown で書く
  • 記事やら設定まで plain text なのでバージョン管理ができる
  • ビルドが速い(1000記事でも十数秒くらい)
  • ビルドしたコンテンツを Web サーバにアップするだけで公開できる
    • DBサーバサイド言語(PHP, Ruby, Python等)を使ってないのでその辺の設定や煩わしさも無い
  • 操作はコマンド(Hugo コマンド)ベースなので自動化が容易
  • 日本語情報が少ない
  • デザインテーマが少ない
    • ブログから移行した人は概ねテーマを自製するor既存テーマを大幅にカスタマイズするのに労力を使っているらしい

Hugoを使うと何が嬉しい? 向いている人は?

  • 記事を Markdown で書けるから楽チン
  • CUI やらスクリプトやらを当たり前に使うので、そういう人は自然に使える
  • デザインテーマや Hugo の挙動などをカスタマイズするのが楽しい
  • 連携先(デプロイ先をどこにするか)を考えたりいじくったりするのが楽しい

要するにエンジニアらしくクールに使えることの満足感や、あれこれカスタマイズして自分色に染めることの楽しさといったものがある。もっと言うと、そういったことの手間を惜しまず、むしろ楽しめるくらいの人が向いている。

逆に、そういう過程なんで煩わしい以外の何者でもないんだよいいから早く楽にブログ公開までさせろ! という人には向いてない。

(あまり上手くないたとえだが)Hugo はプラモデルみたいなものだろう。作る過程こそ楽しむものであり、完成品のみを求めるものではない。作る過程なんて要らねえよという人にプラモデルは向いてない。

Hugoで大変なところその1 日本語情報が少ない

特に Hugo 内部の仕組みや細かいカスタマイズ方法についての日本語情報が少ないです。というのも、公式ドキュメントが充実しているからそこを見ればいいだろ(わざわざ解説記事書く必要はない)って話だからです。もちろん公式ドキュメントは英語。

Hugo - Introduction to Hugo
http://gohugo.io/overview/introduction/

英語が読めないとツラい。私の英語力(ググって出てきた Stackoverflow の回答をたまに読み解ける程度)では歯が立たない。

しかし幸運なことに、Hugo 内部の仕組みを据えた親切なチュートリアル記事がある。ありがたい。

Hugoサイト構築
http://wdkk.co.jp/lab/hugo/

Hugoで大変なところその2 独自概念が多く学ぶのが大変

Template(デザインと記事内容を分離する仕組み)、Taxonomy(タグやカテゴリなどグルーピングの仕組み)、FrontMatter(各記事にある '+++' で囲まれたメタ情報)など Hugo 独自の仕組みや概念がたくさん出てくる。これらに慣れれば、円滑にあれこれできるようになるが、慣れるまでが大変。

その1と被るが、まずこれらを解説した日本語情報が無いので詰まる。公式ドキュメントは英語がっつりで読めない。じゃあ試行錯誤してみようかって話になるけど、Hugo はコマンドベースであり GUI ではないため、画面をテキトーにいじって何とかなる、なんてこともない。

先に進みたいなら、仕組みや概念をきちんと勉強するしかない。英語が読めないか、さもなくばよほどエンジニア的な勘(ここをこうすればこうなりそうってのがわかる直感や要領)を持ってないかしないと、進めないのである。

まとめ

以下のような人には向いているし、楽しめるだろう。

  • 英語読めます
  • CUI好きです
  • あれこれいじったり連携させたりするの好きです

逆に、以下のような人には向いてない。

  • シンプルなブログを手間なく作れればそれでいいんだよ
  • 英語読めない
  • CUI嫌い
  • 設定とかカスタマイズとか要らないからさっさと完了させろよ

Windows の Window Shade(ウィンドウシェード)に関する覚え書き

本記事はウィンドウシェードについての雑多なメモである。概要説明からプログラミング的な実装の話まで、内容は多岐。

ウィンドウシェードとは

ウィンドウをタイトルバーサイズに折りたたむ機能のこと。元々は Mac OS の機能だが、これが便利ということで、Windows 上で実現するフリーソフトが登場した。

Windows Shade ではなく Window Blinds(ブラインド) と書く場合もある。が、日本語でウィンドウブラインドと書いてる人は見たことがない。

ウィンドウシェードなフリーソフト

たとえば以下がある。

他にも探せば色々あると思う。

ウィンドウシェードを実装するには

WindowsAPI の以下を組み合わせる。

  • GetWindowRect() でウィンドウのウィンドウサイズを取得
  • GetSystemMetrics() でウィンドウのタイトルバーの高さを取得
  • MoveWindow() や SetWindowPos() でウィンドウのウィンドウサイズを、Xサイズは「元々のXサイズ」、Yサイズは「タイトルバーの高さ」に変更する

あとはシェードしたウィンドウの元のYサイズを覚えておいてもう一度シェードしたら元に戻すとか、タイトルバーをほげほげしたらシェードを実行するとか、その辺 UI を整備してやればよい。

ウィンドウシェードを行う契機となる操作、の選択肢

タイトルバーに対して何らかの操作を行わせるケースが多い。

右と左については、既に Windows に割り当てられてる働きを無効にしないといけないので面倒くさい(フックという処理が必要らしい。詳しいことは知らない)。中クリックについては、Windows 規定の働きはないため比較的楽。

あ、そうそう、Shiftキーを押しながら左クリック、といった修飾キーと組み合わせるやり方もある。

ウィンドウシェードについて検索したい時に

Windows」という言葉を付けること。でないと、現実世界の窓がたくさんヒットして邪魔。

シェードできないウィンドウがある

たとえば Windows7エクスプローラ(フォルダ)ウィンドウ。なぜか知らないが、こいつはウィンドウ最小サイズが 161 x 243 になっている。MoveWindow() 等を使ってもこれ以上小さくはできない。

……このように、なぜかウィンドウサイズ制限のあるウィンドウがあり、シェードできないことがある。

対処方法は不明。

蛇足: エクスプローラウィンドウをシェードできない件

エクスプローラウィンドウについては、かざぐるマウスや Winroll ではきちんとシェードできる。私が自作したシェードツール(MoveWindow()を使っている) ではシェードできない。

原因は不明。

ググっても何も出てこないので、Stackoverflow で質問してみた。

winapi - Why the lower-limit window size of an explorer(folder) window is 161 x 243 in Windows7? - Stack Overflow
http://stackoverflow.com/questions/34632064/why-the-lower-limit-window-size-of-an-explorerfolder-window-is-161-x-243-in-wi

英語力も表現力もクソなので vote down(お前の質問マジうんこ) されてるけど。

それから WinRoll のソースも見てみた。asmファイル(アセンブラ)なのでちょっと読みづらいが、WindowsAPI の関数名はそのまま書いてあるので何とか読める。

winroll-2.0\winrolldll.asm の WR_Rollup 関数っぽい。使ってるのは…… MoveWindow() と SetWindowPlacement() くらい。SetWindowPlacement() は表示状態(最小化最大化等)の制御なんで関係無いわけで、私と同じく MoveWindow() ってことになるんだよな。

なのになぜ WinRoll ではシェードできて、私のでは出来ないのだろう。解せぬ。

TortoiseGit でオーバーレイアイコンがおかしい(表示されない、更新されない)場合の対処方法

原因

要するに、超えちゃった分がアイコンが表示されなかったり更新されなかったりという現象になって現れる。

対処方法

オーバーレイアイコンの設定を 15 個以内に減らす。

対処方法 詳しく

オーバーレイアイコンの設定はレジストリにある。つまりレジストリを編集することになる。怖いならここでさようなら。それでもやりたいなら、バックアップした上で自己責任でファイト

設定は HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers 配下に、一設定一キーという形で設定がぶら下がっている。

+ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
 + Explorer
  + ShellIconOverlayIdentifiers
   + 1TortoiseNormal
   + 2TortoiseModified
   ...
   + Offline Files
   + SharingPrivate

つまり、ここの個数が15個以下(厳密に言えばキー名昇順で最初の15個)でなくてはいけない。

15個を超えている場合、要らないものを消すなり、キー名を変えて昇順の下の方に追いやったりする必要がある。

以降では、ここを整理するために役立ちそうな情報を雑多に列挙する。

TIPS: 使っていないアプリアンインストールする

たとえば Dropbox はオーバーレイアイコンをたくさん使うが、もし Dropbox を使っていないならこれをアンインストールすることで、オーバーレイアイコンも消すことができる。

TIPS: Tortoiseシリーズのオーバーレイアイコンを減らす

Settings > Icon Overlays > Overlay Handlers を開く。この中から、使わないアイコンのチェックを外す。

デフォルトでは7個全部にチェックが入っているが、使ってないアイコンをたとえば2個チェック外すと、アイコン数は5個になる(2個分減らせる)。

ちなみに本設定は Tortoise シリーズで共通なので、TortoiseGit で外したら TortoiseSVN 側でも外されている。

TIPS: 各キー名と対応するアプリ

使ってないアプリなら、対応するキーを消しちゃってもいいだろう。キーを消したところでオーバーレイアイコンが表示されなくだけである(たぶん。確証は無い)。

以下、各キー名と対応するアプリをまとめる。

Groove Explorer Icon Overlay 系

Dropbox

  • Dropbox のオーバーレイアイコン
  • 私は Dropbox を使うし回線も遅い(ので同期状況を示すオーバーレイアイコンは結構重要)のでキー削除は控えた。

SharingPrivate、Offline Files、EnhancedStorageShell

  • Windows が使ってるオーバーレイアイコン
  • 怖いので私は手を付けていない
    • まあ所詮はオーバーレイアイコンなので大丈夫だと思うけど。気が向いたら試す

その他のキー名

  • まあ何かのアプリが使ってるんでしょうよ
  • よくあるのは会社で使ってる暗号ソフトウェアとか
  • わからない場合は「ShellIconOverlayIdentifiers (キー名)」でググってみてもいい

TIPS: レジストリを変えたがオーバーレイアイコンが表示されないぜ?

以下を試す。

TIPS: オーバーレイアイコンについてもっと詳しく知りたい

英語だが TortoiseSVN のサイトが詳しい。

tortoisesvn: TortoiseSVN FAQ
http://tortoisesvn.tigris.org/faq.html#ovlnotshowing

秀丸エディタでコメント表記, 引用表記, コードハイライト表記内のカラー表示とアウトライン表示を無効にする

問題

例として Markdown の見出し表記をカラー表示&アウトライン化するファイルタイプ別設定を適用しているとする。

これで見出し表記を書くと、

# 大見出し1        <= 大見出し用のカラー表示とアウトライン表示がされる
hogehoge

## 中見出し1-1     <= 中見出し用のカラー表示とアウトライン表示がされる
fuga

## 中見出し1-2     <= 中見出し用のカラー表示とアウトライン表示がされる
piyo

このように認識されるが、常にそう認識させたいとは限らない。具体的には、コメント表記、引用表記、コードハイライト表記の中に見出し表記を書いた場合。この時、見出しはあくまでコメントや引用やハイライト用コードとして認識されるべきであり、従って見出し用のカラー表示もアウトライン表示もされるべきではない。

が、普通ならされてしまう(以下例ではハイライト表記 ' ``` ' 囲みを使っている)。

# 大見出し1        <= 大見出し用のカラー表示とアウトライン表示がされる
hogehoge

```
## 中見出し1-1     <= 中見出し用のカラー表示とアウトライン表示がされる(これは表示されたくない!)
fuga

## 中見出し1-2     <= 中見出し用のカラー表示とアウトライン表示がされる(これも表示されたくない!)
piyo
```

理想を言えば以下のようにしたい。

# 大見出し1        <= 大見出し用のカラー表示とアウトライン表示がされる
hogehoge

```
## 中見出し1-1     <= (ハイライト表記内なので)表示されない
fuga

## 中見出し1-2     <= これも表示されない
piyo
```

解決方法

コメント表記, 引用表記, コードハイライト表記を複数行コメントして扱ってやればよい。

  1. コメント表記, 引用表記, コードハイライト表記を「複数行コメント」の設定に追加する
    • ファイルタイプ別の設定 > 複数行コメント > ユーザ定義 を選択後、設定を追加していく
  2. アウトラインの設定にて、コメントについてはアウトラインと認識させないようにする

こうすることで、コメント表記, 引用表記, コードハイライト表記内の見出しは見出しとして扱われなくなり、カラー表示もアウトライン表示もされなくなる。

ただし、複数行コメント用のカラー表示はされるので、表記内の文字色は一色になってしまう。