Layout Window  ダウンロード






Layout Windowは特定のウィンドウを任意のタイミング、
指定した方法で位置やサイズ、ウィンドウ状態を変更します。

主に次の機能を有します。

 ・ウィンドウ情報の取得
 ・ウィンドウ情報の変更
 ・任意のタイミングで指定されたウィンドウ情報に従いレイアウトを実行
 ・指定ウィンドウを自動的に閉じる・非表示・強制終了する
 ・マウスで指定したウィンドウのみレイアウトを実行



2017.01.12
3.9.7版

・スリープ、レジュームからの復帰後にホットキーが無効化される問題を対処

2016.10.29
3.9.6版

・ターゲットウィンドウに「特殊ウィンドウ」を追加

Windows10で全画面に表示されるアップデート通知に対応した。



Windows10で自動アップデートを禁止して手動で行うようにすると
次のような有無を言わせぬ通知が表示されるようになります。
全画面かつ最前面表示、そしてトドメの選択肢が1つという驚異のデザインです。



このような通知は従来の方法で制御できなかったため
制御可能とする「特殊ウィンドウ」オプションを新たに用意しました。

上記の設定を行うことで、通知自体を自動で消すことが可能になります。

この設定情報はレイアウトウィンドウのメニューから
"設定→指定したウィンドウ情報取得"機能で通知画面を選択することで得られますが、
通知画面が最前にあるため、通常は他の操作を行うことが出来ません。
そこでマウ筋Liteの「どこでもドラック」にて次のように邪魔な画面を退かすことで
LayoutWindowを操作できるようになり、通知画面を自動で消す設定が行えます。



もしマウ筋Liteを導入していない場合は
LayoutWindowに次の情報を手動で登録しておくと良いでしょう。

項目名 設定値
アプリケーション名 windows10 アップデート通知
ファイルパス C:\Windows\System32\MusNotificationUx.exe
ウィンドウタイトル 更新プログラムを利用できます
ウィンドウクラス Shell_SystemDialog
特殊ウィンドウ 有効
状態 強制終了
実行契機 自動(常に)

アップデート通知に限らず、レイアウト対象を指定しても上手く動作しない場合は
「特殊ウィンドウ」オプションを試してみてください。

2016.05.16
3.9.5版

・ウィンドウの状態に「画面中央に表示」を追加
・子ウィンドウに対しても自動的なレイアウトを行えるようにした




前者はウィンドウを画面の中央に表示する機能です。
単に中央に表示するだけならば既存の機能を使用すれば
ほぼ同じようなことが出来るのですが、
後者と組み合わせることで絶大な威力を発揮します。

それは"子ウィンドウが表示されると自動的に画面中央に表示"されることです。
個人的にどうしても欲しかった機能なのですがようやく実現できました。

どのように便利になるのか実例を挙げましょう。


事例1 一般的な設定画面が常に見やすい位置に表示される

設定画面はメインウィドウの左上に表示されることが多いです。
そのため視線を左上に固定したまま、
多くの項目が並ぶ細かい画面を凝視することになります。

正直、目が疲れる作業です。
視線は正面に向いているときが最も負担が少ないので
画面を中央に移動しても良いのですが、
設定画面というのは意外なほど開く機会が多いため、
移動自体が面倒になり、つい視線を左上に向けることになります。

複雑な画面を操作するならば自動で画面中央に表示して欲しいものです。
しかも一部ではなく大半のアプリケーションで共通してそのようになれば理想的です。

でも、どこに表示されるかはアプリケーション次第なので通常は無理です。

しかぁし、LayoutoWindowならばその理想を叶えることが出来るようになりました!!

なにか適当な設定画面をLayoutWindowに登録し、以下のように設定します。
以下の例ではIEの設定画面を使用)

設定を反映するためには保存し、LayoutWindowを閉じてください。
(LayoutWindowが表示されたままでは実施契機の"自動"が開始されないためです)




すると、いつもはメインウィンドウの左上に表示されていた設定画面が



このように画面中央に表示されるようになりました。
(例が分かり易いよう予めメインウィンドウを画面中央に表示)




また他のアプリケーション(例えば秀丸エディタ)でも同様のことが出来ます。






この機能のお陰で精神的な疲労(目の疲れはここにきます)が大分軽減されました。
もっと早く実現しておけば良かったです。


事例2 画像ビュワーのビューウィンドウが自動的に画面中央へ表示される

私が使用してきた画像ビュワーは通常、ビューウィンドウの表示位置が
メインウィンドウの左上の方に来ます。

見やすくなるように毎回中央付近に移動するのですが、
手で移動するのが面倒なこと以外の問題として、
視線が左上から中央に移動することが繰り返されるので、眼精疲労の元になっていました。

例えば画像ビュワー「ViX」の場合、
ウィンドウクラスが可変(表示の度に変化する)であるため、
ウィンドウの判断にウィンドウクラスは使用できません。

そこで今回はウィンドウタイトルを使用することにします。

子ウィンドウのビュワーのタイトルの末尾に"- ViX"と固定で表示されるので
以下のように設定します。




すると、次のようにどこに表示されるか分からない状況が



このように中央に表示されるようになりました。
画像の選定は目を酷使するので、極力視線の移動が少ないと精神的にも負担が減ります。



この新機能、
実際に使用してみると、従来は如何に目を酷使していたかに気がつかされました。
単に便利と言うだけでは無く、精神的に非常に楽になります。
というのは視線の移動、不自然な方向への固定というだけでなく、
その前段の"どこに表示されるのかを探す"という手間も無くなるためです。

とりあえず目を中央に向けておけば目的のものが見つかるというのは
想像以上に良いものです。

2016.01.17
3.9.4版

・アプリケーションリストの並び順に前版で追加した「アプリケーション名」を指定可能にした




2015.12.19
3.9.3版

・ターゲットウィンドウ情報に「アプリケーション名」を追加

これはアプリケーションのリストに表示されるラベルになります。
従来は「ウィンドウタイトル」を表示していましたが、
任意の名称を表示できるようになりました。

新たにウィンドウ情報を取得した場合は、
デフォルトでアプリケーション名が表示されますが、任意の名称に変更できます。


・新たにウィンドウ情報を取得した場合、アプリケーションを判別する情報を
ウィンドウタイトル・クラスからファイルパスに変更

基本的にアプリケーションを判別する情報はファイルパスで済むため、
ファイルパスのみで判別するようにしました。

より詳細に絞り込む場合はウィンドウタイトルやクラスを有効にすると良いでしょう。







2015.09.17
3.9.2版



・"指定したウィンドウを取得"でウィンドウを選択時に、マウスカーソル配下のウィンドウの枠を点滅表示させて、どのウィンドウを選択しようとしてるのか明示的に分かるようにした。

マウ筋LiteやInvisibleMouseCursorで既に実装していた機能だが、
LayoutWindowにも無いと不便だったため追加した。


・"実行契機"にOS終了時に自動的に行う「自動(OS終了時)」を新たに追加

OSのシャットダウン時は素早く終了して欲しいものである。
しかしアプリケーションが終了して良いか尋ねてくる場合はそれが遅れることになる。
早く終わらせるためにはそのメッセージに対するOKボタンや、タスクリストの強制終了ボタンをその都度押す作業に追われることになる。
面倒だからと放置するとOSが自動的に強制終了を行うのだがそれが始まるまで10秒程度待たされることになる。
いずれにせよ、素早く終了しないことには変わりは無い。

更に厄介なケースはOSシャットダウン時に常駐アプリが毎回異常終了のメッセージを出す場合である。
PCの使い始めは調子よくても使い込んでくると原因不明のエラーが頻発することがあるが、その度にエラーや例外がXXXで発生しました、とメッセージが表示されOKボタンを押すことを要求してくるのである。大抵原因は不明であり、OSシャットダウン時に見せられても意味は無いにも関わらず見せられるのである。往々にしてあまり愉快な気分にはならないだろう。

OS設定用のツールを使うと、OSによる自動的な強制終了の開始時間を短くできるのである程度は緩和できるのだが、それでも遅くなる事実は変わらないし、不要なメッセージを表示しないようには出来ない。

一応、有無を言わさず全て強制的に終了させることも可能だが、そうなると今度は未保存のデータがある場合に保存を促す有用なメッセージすらも表示されなくなるデメリットが生じる。

これを解決するには、OSシャットダウン時に予め登録しておいた条件に合致するアプリケーションのみ強制的に終了されるようにすれば良い。
その機能をLayoutWindowで実現した。

LayoutWindowは柔軟な条件指定が可能であるため、
例えば次のような使い方が出来る。

 ・メモ帳の場合は無条件で強制終了

 ・秀丸エディタの場合はタイトルに「無題」が含まれる場合のみ強制終了

 ・定期的に異常終了のメッセージを出すアプリケーションを登録し、無条件で強制終了させる


設定例:





すると、従来は不要だった複数の問い合わせや意味の無いエラーが一切表示されなくなり、更にOSのシャットダウンが素早く終えるようになるため、非常に快適になる。
複数あったウィンドウが一瞬で消えるのは愉快痛快である。

OSの再起動やシャットダウンを行う契機というのは意外なほどあるため、シャットダウン時に少しでも不満を感じたことがあるならば是非試して欲しい。

2015.04.29
3.9.1版

・高DPI環境化でも画面デザインが維持されるように調整

高DPI環境ではアイコンサイズと行間が小さく表示されたため
通常DPI環境と同様のデザインとなるよう適切なサイズに変更。

調整前:


調整後:


 2015.04.12
3.9版

・フルHDを越える高解像度環境でケースによっては
 対象アプリケーションが正しく判断できない問題を修正

・フルHDを越える高解像度環境でケースによっては
 ウィンドウ取得時ができない問題を修正
2014.12.30
3.8版
・アプリケーションを追加・削除すると、リストが常に先頭へスクロールしていたが
 追加時は追加した項目、削除時は削除した位置の項目を選択状態にして
 選択項目が常に表示されるよう自動的にスクロールされるようにした

・登録項目をDeleteキーで連続削除可能にした

・コンフィグリロード後、メイン画面を閉じた後に再度表示すると、
 タイトルに「更新」が誤って表示される問題を修正

・設定画面表示時は「ウィンドウを監視する」機能を一時的に停止するように変更

・コンフィグリロード時、稀に異常終了する問題を修正

2014.12.21
3.7版
・解像度の変更で変えられたウィンドウの位置やサイズを自動で復元するようにした

ゲームの全画面表示やリモートデスクトップ等で解像度が変更されると
開いていたウィンドウも画面内に収まるように移動します。
しかし、終了後に元の解像度へ戻っても既に移動したウィンドウは戻りません。

画面サイズが戻るならば、ウィンドウも元の位置に戻ることが自然な流れであると
考えたため、元の解像度に戻るとウィンドウも元に戻るようにしました。



この機能はメニューの設定→ウィンドウを監視 が有効時(デフォルト有効)に
自動で働きます。

2014.11.25
3.6版

レイアウトを自動で行う「常に状態を維持する」機能を拡充し、
実行契機を新たに設けた。
従来は自動で実行しない、または自動で常に実行するの2択であったが
指定アプリケーションが起動したときのみ1回だけ自動でレイアウトが行われる
「自動(起動時のみ)」を新たに追加した。



アプリケーションによっては終了時のウィンドウ位置、サイズを記憶しないことがあり、
毎回手動で調整する必要に迫られることがあります。
またそれらの機能を備えていたとしても、次回起動時は毎回指定した定位置で
表示して欲しい場合はウィンドウの位置を変更せずに終了させなければなりませんが
僅かでも移動してしまうと結局は手動で調整することになります。

LayoutWindowは些細でありながら、しかし繰り返し行われ続ける労苦から解放します。
なぜなら指定したアプリケーションが起動した時のみレイアウトを自動で行うことが出来るからです。




2014.07.24
3.5.1版

・メインウィンドウが非表示時に終了すると、位置・サイズ情報が初期化される問題を修正


2014.07.23

3.5版

・メインウィンドウをリサイズ可能にした
・終了時のウィンドウサイズを記憶するようにした

従来はウィンドウサイズが固定であったため、
アイテム数の増加に伴いスクロールする必要がありましたが、
一度に表示可能な数をリサイズして調整することが可能になりました。






2014.05.31

3.4版
・メニューの「ウィンドウ監視」状態をコンフィグで保存可能にした

従来は一時的にウィンドウ状態の監視を無効化するためのメニュー項目であったが、
コンフィグで管理することにより次回起動時も反映されるようにした。

メニューの「ウィンドウ監視」は
ターゲット設定の「状態」(通常・非表示・最大化・最小化・閉じる・強制終了)の
「常に状態を維持する」機能を全て有効化または無効化する機能である。





2014.02.16

3.3版
・コンテキストメニューの「設定のリロード」が機能しない問題を修正




 2013.10.07

3.2版

・ウィンドウ状態を指定された状態へ自動的にレイアウトを行う機能は従来、非表示・閉じる・強制終了の3種類のみであったが、全ての状態で使用可能にした。
それにより、「常に状態を維持する」がどのような状態でも使用可能にした。



前回のウィンドウの表示位置を覚えてくれないウィンドウを常に同じ位置に表示できるようにしました。
この機能は次のようなウィンドウに効果を発揮します。

 ・前回の表示位置を覚えてくれない
 ・1つ以上開くことが出来ない、または1つ以上開かない

1つの例として、コントロールパネルの「コンピュータの設定」が挙げられます。
またゲームでも同様のものがあるため、そのようなウィンドウに対して役に立ちます。

拙作マウ筋Liteでもウィンドウを指定した状態に変更することは可能なのですが、毎回ウィンドウに対してジェスチャーをする必要があるため、頻繁に閉じたり開いたりするウィンドウに対して手動でレイアウトすることは手間でした。
本機能を使用することで全て自動で行われるようになったので、本来、今後何万回と行われるはずだったルーティンワークから解放され、大分快適になりました。
今まで手動で行っていたことが自動で行われるというのは、想像以上に、心身共に楽になれます。
ぜひお試し下さい。


version 3.1版リリース 13/05/19

・日本語以外のOSで日本語を表示できるようにした



version 3.0版リリース 12/12/01

Vector社のシェアレジサービスが利用可能になりました。

シェアレジ


version 3.0版、近日リリース予定 12/11/27

メジャーバージョンアップした3.0版では次の変更を行いました。



 1. フルC++化により使用メモリは約4分の1(40MBから10MB)、実行速度は
   2倍以上と大幅な性能向上とリソースの節約を果たした
 2.  登録可能なアプリケーション数を従来の20から1万に増加。
   (性能が向上したため、事実上、無制限に変更)
 3. Layout Window2から名称をLayout Windowに変更
 4. アプリケーションリストと設定画面にアプリケーションアイコンを
   表示するようにした
 5. レイアウト対象ウィンドウ条件にファイルパスを追加
 6. ウィンドウ設定に「常に状態を維持する」を有効にすると、CPU使用率が
   平均1-2%増加していたが、基本的に0%と負荷を軽減した。
 7. 任意のホットキーでウィンドウのレイアウトを実行可能にした
 8. 多言語化に対応
 9. アプリケーションリストをタイトル、クラス、ファイル名順にソート可能にした
 10. 非表示にしたウィンドウを元の位置に戻せるようにした
     
(従来は非表示にしたウィンドウは戻せません)


次版作成中 12/11/03

次版は全てVC++で書き直すため、ファイルサイズや使用メモリ量は現状より劇的に少なくなります。



開発日誌 11/10/01
自作ソフト第2弾、これも愛用していたアプリケーションがwindows7 x64で動作しなくなったため作りました。

ウィンドウをレイアウトさせるアプリがx64動作しなくなるのは想定外で、著しく作業効率が落ちました。代替手段を捜したところ、ウィンドウ操作関連ソフトはあるにはあるのですが、ショートカットが使用できない・GUI画面から指定したアプリしかレイアウトできない・登録するアプリケーションを選択できない等どうも理想とはかけ離れてしまいます。
また自動でウィンドウを閉じるアプリがx64で動作しない。

あれぇ?x64ではウィンドウ操作って意外なほど選択肢がない。
全般的にx64対応はいろいろ難しいみたいですが、時間がたてばまた優れたアプリが登場するはずなのでそれまで待ちましょうかって、、待つかーい!いつだよ、いつ出てくるの!

ということで、Ryu's Menu Version 4.00の開発で得た技術を応用し、作ってみることにしました。でも単に作るだけではつまらないので、コンセプトを決めます。(ここから専門用語がいろいろ入ってきます)

1.複数の開発言語を組み合わせて、上手に連動させることで1つのシステムしたい
  (異なる言語間の処理を連動させる実績が欲しい。
   しかもサンプル程度の品質ではなく自分が手放せないほど有用なもので。)
2.でも処理速度は落とさない(重要)
3.機能は@とAを統べて満たす(そもそもそれが目的)
4.x86、x64の両方に対応にする(環境を限定したくない)
5.他にはないオリジナルの機能があればいいね!(満足したい)
6.ショートカットキー、特にグローバルなキーは外部アプリケーションに任せる。
 外部とは特定のアプリケーションとは限定せずに、汎用的に使用できるようにする。
 (作者は当然、Ryu's Menu Version 4.00に任せています。元々rmenu4は全ての基幹となることを想定しているのです。)


さて、方向が決まったところで実現方法ですが、

1…選択に困るほど手段があるので、吟味すれば特に問題なし。
  (まあ、その吟味が難しいのですがね)

2…これは非常に悩んだのですが、検討の末excelsiorの製品にしました。
  ただ結論に至るまでにはかなり時間が掛かりました。
  excelsiorのExcelsior JETという製品に関するレビューはほとんど無く、大半は公式HPの内容をほぼそのまま紹介しているだけなので、実際に実用になるのか判断がつきませんでした。(特に日本語ではレビューすら皆無です。)
しかたないので徹底的に調査したところ、いけるという手応えが得られたため採用しました。
以下に挙げたように欠点もいくつかありますが、致命的ではないので把握さえしていれば問題ありません。

調査結果(performance/usability report):
 利点
   @処理速度の向上(1.5から2倍。流石ネイティブ化は伊達ではありません)
 欠点
   @インストーラにVM環境が丸ごと含まれるため、パッケージサイズが大きくなる
   Aネイティブ化処理に時間が掛かる
   Blog4のデバッグ文を実行した行情報が"??"となってしまう。
    (ネイティブ化によりデバッグ情報が無くなってしまうことが
    理由のようですが、気になる程度で実害は無いです。)

3.VCで実装すれば問題無し

4.x86はいいのですが、x64はいろいろ事情が特殊であり、かつ歴史が浅いので情報はx86に比べて少ないです。これはもう試行錯誤しかないのです。
でも今の内にノウハウを貯めればこれからx64が主流になるので、きっと役に立つはず!

5.自動的に指定したウィンドウを閉じる、または非表示にする機能を実現する。
  しかもx86、x64対応で。
  この機能がオリジナルなのかどうか調べてみました。完璧には無理ですが少なくとも著名なものがあればヒットするはず、と国内外を見たところ、x86/x64対応で自動的に指定したウィンドウを閉じることも、非表示にすることも存在しないようです。
 現状(11/10/01)、非表示化については明示的に手動で実行する必要があるものしか見つかりませんし、閉じることに至っては存在しないみたいです。
  (少し気になったのですが、海外のソフトはちょっとしたUtiltyでさえシェアウェアが多かったです。日本は逆にフリーウェアが多いですね。文化の違いでしょうか)

このような様々な課程を経た結果、Layout Window 2は誕生しました。
私はこのソフトウェアのおかげで作業効率が以前よりずっと向上しましたし、作成過程で得た技術力は次の開発への大きな力になりました。


あとがき 11/10/07

Layout Window 2は利点もあれば欠点もあります。というか欠点を許容しているからこそ利点が生まれると言った方が正しいです。
ダウンロードした方は気づくと思いますが、まずファイルサイズが30MBと大きいです。さらに気にする方は使用メモリも見るでしょう。大体40MB程度使用します。
おやー?、オンラインソフトってインストーラが1-10MB程度でメモリもせいぜい10MBとかじゃないの?と思うかもしれません。はい、私も思います ^^。
普通の作り方をするならばそうなりますし、そうなるようにできます。でもやりません。
なぜか?
それはアプリの大半をバイトコード化することで、次の利点が生まれるからです。

@ Linux、MAC、その他OSに比較的容易に移植可能になる 必要性があるかどうかはともかくとして
A 豊富なフリーのライブラリを使用できる 言語を固定化すると、基本的にその言語がサポートする範囲内でしか選べません
B OSの仕様変更による影響が少ない OSのバージョンが上がるたびに修正の対応を迫られるのは困ります。大体、作者を楽にするためのアプリのはずが、アプリに振り回されるのは本末転倒です(見方を変えればそれが面白いという側面もあるのですが)。
 OSに依存しない部分、依存する部分に分けていれば、後者だけ対応すればよいので対応が楽になります。
C B”とは逆のケース OSに依存する処理をしなければならなくなった場合はOSに依存しない部分だけを対応すればよい

要するに、今後のOSに対応しやすくなるので移植のモチベーションがそんなに下がらず、かつ思いついたことを特に制限無く実現できると言うことです。

とはいえ、利点の裏には当然さらに欠点もあります。それは開発が難しいということです。その根拠の1つとして、このような開発している例はまずありません。(著名なフリーソフトの中にはこの形態を取っているものはわずかではありますが確かにあります。)
いったんそれを乗り越えてしまえば結構楽です。さらに個人的には楽しいので飽きませんし。
こんな開発手法はなんて言えばいいのだろうか。異種混合開発?表現が堅いし、コンセプトがよく分からない。
Free Borderline Programmingなんて良いかも♪