last modified on [2003-04-08 09.08 (JST: GMT+0900) @047]
1st appeared on 20th January, 2002 (1st edn.: 20th May, 2000; 2nd edn.: 4th April, 2001);
Revised on [10th February, 2002], [7th-14th April, 2002], [19th-20th February, 2003], [8th April, 2003].
Acknowledgement: thanks to ayamame, Fizz.oO, Fuji, hideh, Toshiyuki Itakura, Naoto Kanzaki, ken, Ks, ManiMani, Yusuke Mizukoshi, N&R, Hirohisa Teramoto, Taro "O_SAKANA" Todoroki, and especially to the LiteStep Documentation Effort Team.
References:
ayamame, "Glossary", [ls mod doc dog] (2002-01-11).
Hirohisa Teramoto (aka Tecchi), "LiteStep Dictionary, [LiteStep @ Blue Topaz] (1999?).
necro, LSFAQ (for taking a word statistics).
the LiteStep Documentation Effort Team, "Glossary", [lsdocs.shellfront.org] (August 2000).
Copyright©2000-2003 by Takayuki KAWAMOTO.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
A copy of the license is included in the section entitled "GNU Free Documentation License" [translation in ja].
LiteStep に関連するドキュメントやウェブページにも、他の話題と同じく専門用語から隠語までたくさんの独特な言葉が使われています。いまは開発の母体が英語圏であり、またプログラミング言語のモデルとしてきた自然言語が英語であったため、用語と隠語の数多くは英語に起源をもっています。
このチュートリアルでは二つの方針で LiteStep 関連の用語をご紹介したいと思います。一つは、既に英語のまま受け入れられている用語とか日本のコミュニティーでよく使われる用語を解説すること。そしてもう一つは、使われ方が微妙に混乱している用語の意味をきちんと決めて、その定義を新しく提案することです。もちろん、僕が一人で言い張っているだけの提案を現に受け入れられている用語とごちゃごちゃにして解説するといけませんから、僕がこのチュートリアルで提案して使っていく語句には、「語句[IW]」という印をつけています。
用語の選定は、上記の各サイトで取り上げられている単語と、懐かしき LiteStep の日本語化チームで参照するために作成した語彙リストから取り上げています。後者の語彙リストは、necro さんの LSFAQ というサイトの(全てのページの)テキストを Ctrl + A でテキストファイルに貼り付け、幾つかのエディタがもっている、頻出語句の簡単な統計解析(statistics)機能で、使われた頻度の高い単語を拾い出しています。
日本のコミュニティーだけで通用している語句は英語の綴りをつけずにエントリーしています。英語の綴りで始まっている語句は殆どが海外のコミュニティーで使われている語句なので、コンピュータ業界の定訳をなるべく対訳としてつけています。[...] の中には参考程度に品詞を表示しました。 あ、それから他のページで一度も使ってない言葉がかなり混入してますので、ご注意を(笑。
なお、このページは他のページをご覧になっていて参照されることが多いと思います。というわけで、元のページへ戻る [back] というポインタを追加しています。
プログラムの版数や作者の連絡先などを表示するダイアログ・ボックスのこと。"version info" と言ったりもします。たいていのソフトウェアではメニューバーの「ヘルプ(Help)」という項目からたどって「~について」というメニュー項目で表示できます。LiteStep の場合 !about という bang コマンドで表示し、開発チームのメンバーや読み込んでいるモジュール、あるいはシステム情報を確認できたりします。が、一度でも表示するだけでメモリを余分に消費しますから、必要なければ表示しないのが吉です。更に、changes.txt という更新履歴ファイルが $LiteStepDir$ (LiteStep をインストールしたディレクトリ)にあると、それも読み込んで表示しようとします。無駄にメモリを使いたくない人は changes.txt を置かないようにしましょう。
step.rc で設定する項目の一種。モジュールが実行されているときの見栄えや動作を step.rc で設定するとき、例えばショートカットの場合は使う画像や表示する位置などと一緒に「ショートカットの画像をクリックしたときに実行する動作」を記述しますが、この動作を総称して「アクション」と言います。何かプログラムを起動したいなら実行可能ファイルへのフルパスを記述したり、LiteStep の bang コマンドを実行したいならコマンド名を書くわけです。
Windows にもマウスポインタの位置に応じて自動で「アクティブなウインドウ」を切り替える X mouse 機能があります。ユーザーの混乱を招くためか、デフォルトでは無効になっていますが、この機能を使えば「非アクティブなウインドウを最前面に表示してテキストを参照しながら、後ろのアクティブなウインドウで何かを入力する」という作業がやりやすくなります。
LiteStep では、幾つかのモジュールが X mouse のような機能をサポートしており、他のウインドウがアクティブになっても、指定したウインドウはずっと最前面へ表示しておけます。この「ずっと最前面へ表示しておく」ことを "always on top" と呼び、LiteStep の幾つかのモジュールは ".... AlwaysOnTop" というコマンドでその機能を実現しています。
この反対に、アクティブになってもずっと後ろへ隠したいウインドウを指定する機能が "always on bottom" です。
"bang" とはエクスクラメーション・マーク、つまり "!" のことです(UNIX ユーザー、 あるいは Windows ユーザーでも Perl をご存知の方にはお馴染みでしょう)。bang コマンドは step.rc の中でアクションを指定するときに記述したり、あるいはコマンド入力用のモジュールを使って好きなときに実行できる処理のことです。"bang ..." で「bang コマンドで~する」という他動詞にもなるので、しばしばその形容詞的用法である "banned" (「bang コマンドで実行された~」)も使われます。もともと "bang" は MIT やスタンフォード大学にいたハッカーの間では "excl" と綴られていたらしいのですが、カーネギー・メロン大学の連中が更に縮めて "!" を使い出したのが発祥らしいです。まったくもって、役に立たないうんちくだ。
元は斜面とか、出っ張ったものを意味します。LiteStep ではポップアップ・メニューの縁取りという意味に使われています。恐らくポップアップ・メニューを横から見ると、
/------------------\
ってな具合に見えるからでしょうね(最後の文字が円マーク(¥)に表示されている場合は、バックスラッシュだと思って下さい)。モジュールの中には同じような縁取りを "border" と呼んでいるものもありますから、注意して下さい。
"recycle bin"(ゴミ箱)といった使われ方をします。
「二つの」とか「二進法の」という意味があります。単なるテキスト形式のソースコードをコンピュータが理解できる二進法の機械語に変換したもの(つまりコンパイルして出来上がった実行可能ファイルなど)、あるいは圧縮ファイルや画像ファイルといった独自のデータ構造をもつファイルのことをバイナリーファイルと言います。LiteStep の開発チームが配布しているプログラムや、LiteStep 用の拡張モジュールを作成している開発者の多くは、ビルドされた実行可能ファイルとソースコードの両方をフリーで公開しています(GPL というライセンスに準拠しているなら、そうする義務があります)。ですから、ソースコードと対比するために、ビルドされたファイルの方をバイナリーファイルと呼んでいるわけです。他のソフトウェア(例えばブラウザの Mozilla みたいにソースコードと実行可能ファイルの両方を公開している場合)についても、"Win32 binary" などと書かれているものはインストールしてすぐに使える実行可能ファイルを指しています。
LiteStep に限らずオープンソースのコミュニティーでは、ソースコードを配布するときに圧縮ファイルのファイル名へ "src"(source) という言葉を挿入し、ビルドして生成した実行可能ファイルを配布するときには "bin"(binary) という言葉を挿入する習慣があります。なお、この言葉にも学校英語で言う「形容詞の名詞的用法」なるものがあり、バイナリーファイルを集合名詞として "binaries" と言うことがあるので注意して下さい。
Windows でウインドウなどを描画するのに使われるデフォルトの画像形式。拡張子は .bmp です。IBM の OS/2 Warp 用にも bitmap 形式の画像はありますが、ファイルの構造が違うので変換しなければなりません。フルカラー(24bit), 256 色, 16 色, 2 色などといった色数に制限できますが、ふつうはフルカラーでしか扱いませんし、減色しても .gif や .png のように圧縮しているわけではないので、極めてファイル容量が大きくネットワーク上で使うのは推奨されません。いまでは、ほおむぺえじ作成ソフトが勝手に .bmp 形式から .jpg, .gif 形式へ変換してアップロードするので、招待されたサイトへ行ってみたら 600dpi でスキャンした A4 くらいの画像を .bmp のまま 190x260 ピクセルに width, height 属性だけで縮小して表示している、という愉快なほおむぺえじは見かけなくなりました。つ~か、そんなもんはもともと表示できんわ!
LiteStep では画像ファイルを長らく bmp 形式で扱ってきましたが、2001 年の末に PNG 形式の画像もサポートしました(個別のモジュールでは、Fuji さんの bkgound.dll [sic] みたいに他の画像形式を壁紙として扱えるモジュールはありました)。正確には、現行の LiteStep は libpng などの PNG 形式を扱うライブラリと共にコンパイルされています。デフォルトで PNG 形式をサポートするようになったので、もし PNG 形式のサポートが必要ないという方は、ソースコードのワークスペース・ファイルを編集して自力でビルドして下さい。
ほぼ「二値の」と訳してもよい言葉です。step.rc に記述するコマンドが取りうる値のうち、"true/false", "yes/no", "1/0" のどれかでコマンドの有効あるいは無効を指定します。モジュールによってデフォルトの動作が異なるため、
[パターン A]
NoModuleCommand True -> ModuleCommand が無効になる
コマンドを宣言しない -> ModuleCommand が有効になる
[パターン B]
NoModuleCommand True -> ModuleCommand が無効になる
コマンドを宣言しない -> ModuleCommand が無効になる
となる場合に、パターン B だと "NoModuleCommand True" を宣言しようとしまいと同じですが、パターン A だと明示的に宣言しなければなりません。なお、"boolean" という言葉は数学者・論理学者の George Boole (1815-1864) からきています。
名詞なら靴の「ブーツ」という意味ですが、この単語を単独で使うと「蹴り上げる」とか「会社を首になる」とか、ろくな意味はありません。恐らくコンピュータの世界では「蹴り上げる」というアメフト用語の意味から派生して「起動する」という意味になったのかもしれません。単独で使うと良い意味がないので、"reboot"(リブート, 再起動), "boot up"(起動する)のように合成語や成句としてよく使われます。
プログラムの素材つまり「ソースコード (source code)」は、単純なテキスト形式のファイルです。ソースコードは、「コンパイラ(compiler)」および「リンカ(linker)」と呼ばれるソフトウェアを使って、はじめて .exe, .dll といった実行可能ファイルに仕上がります。LiteStep は、2000年から Microsoft Visual C++ 6.0 TM という統合開発環境(IDE: Integrated Development Environment)ソフトを使って作られており、このソフトを使えば「ビルド(build)」という手続きでコンパイラとリンカを連続して使えます(「コンパイルする」と言うときは、多くの場合にリンカが行う処理も含めて言われています)。
LiteStep を使っているユーザーの間では、ビルドされて出来上がったファイルの一式、あるいはそれらをまとめて圧縮ファイルにしたものも「ビルド」と呼んでいます。ファイルの一式は .zip などの圧縮形式でまとめられて配布されており、(最初の意味で)ビルドされた日付が ls-bin-20010315.zip などとファイル名に付けられます。そこで、或る日付のビルド(これは後の意味)を「~月~日版のビルド」と呼ぶこともあります。
コンパイラによる「コンパイル」とリンカによる「リンク」は、プログラムを作成するときの重要な作業です。ソースコードは単なるテキスト形式のファイルですから、そこに書かれたプログラムをコンピュータに命令しようとすればコンピュータが理解できる機械語に翻訳する作業が必要となります。コンパイラはソースコードをコンピュータが理解可能な二進法の表現に置き換える作業を担当し、リンカはそのプログラムで必要とされる他のファイルが実際にコンピュータの中にあって利用できるかどうかをチェックしたりします。
圧縮ファイルは「アーカイブ(archive)」とか「書庫」と言われています。後に説明した意味での「ビルド」は、この圧縮ファイルまたはその中に含まれるファイルの一式を表しますから、実行可能ファイルだけを指しているわけではありません。更新履歴を記録した changes.txt や、あるいは英語版のマニュアルなどもビルドに含まれています。
このようなわけで、「2001-01-02 のビルド」と言うときは "ls-dev-20010102.zip" という圧縮ファイルで配布された LiteStep を指しています。なお、こうしたビルドはソースコードと IDE があれば誰でも作れますし、LiteStep のライセンスでは誰でも自由に公開・配布できます。ですから、shellfront.org などのように自前のビルドを公開しているところもあり、「開発チームのビルド」とか「shellfront のビルド」と言って区別します。
普通の英語では「指令する」という動詞にもなりますが、ここではソフトウェアに与える命令のこと。LiteStep では step.rc などに記述してモジュールの動作や見栄えを設定する「RC コマンド」と、コマンド用のモジュールにユーザーが入力したりコマンドを実行するように設定された他のオブジェクトから即座に実行される「bang コマンド」の二つがあります。但し「マクロ」や「スクリプト」とは違って再帰的な処理などはできません。
step.rc に限らず、プログラムやスクリプトのソース内で実際には無視される部分のことです。他の開発者がソースコードを理解し易くなるように関数などの説明を書くわけですが、ソースコードからコンパイルされる段階で削除されますから、たくさんコメントを書いたせいでプログラムのファイルサイズが増えるということはありません。HTML や XML では <!-- ... -->, CSS や JavaScript では /* ... */, Perl では # など、マークアップ言語やプログラミング言語の種類によってコメントを表す記号は違っています。
step.rc にコメントを書く場合は、モジュールのコマンドについて説明したり、どこを変更すれば他の環境でうまく使えるかなどをテーマの作者が追記したりします。また ayamame さんも指摘されていますが、特定の設定やモジュールを無効にするため、LoadModule 行などをコメント扱いにして LiteStep システムに無視させるといったことにも使います。
コメントとして扱う部分を、それぞれの言語などで決められた表記法に従って指定すること。コメント扱いになった部分は、上で説明したようにプログラムの実行に影響を与えません。LiteStep では step.rc の中で ";"(セミコロン)がコメント開始の記号となっています。
step.rc では、Perl などと同じく「コメントを開始する記号からその行の終わりまでをコメント扱いにする」という行単位の表記法しかありません。したがって、複数の行にわたって書いた文字をコメントアウトするには、一行ずつ行の先頭に
; この文章は、
; コメントなのね。
とセミコロンを打つしかありません。
メーラなどで step.rc を表示しているときに、ウインドウの幅や決められた文字数といった単位でテキストを勝手に折り返して表示する「ワードラップ」機能を使ったままテキストをコピーするときは、注意が必要です。場合によっては表示されていた幅の単位で勝手に改行されてしまい、本来はコメントになっている筈の部分が途中で改行されてしまいます。当然、そのまま LiteStep に読み込ませるとエラーになります。
LiteStep システムを構成するファイルのうち、LiteStep を起動するのに必要最低限の機能を提供するファイル[IW] を「コア・ファイル」と呼んでおきます。まずその前に、LiteStep の公式マニュアルなど英語圏では、「ビルドに含まれている標準的な実行可能ファイル」をコア・ファイルと呼んでおり、2002 年 1 月の時点では以下のファイルが含まれます。
bangmgr.dll, command.dll, desktop.dll, desktop2.dll, dllmgr.dll, hook.dll, hookmgr.dll, hotkey.dll, litestep.exe, lsapi.dll, lstime2.dll, lsvwm.dll, msgmgr.dll, popup2.dll, stepsets.dll, systray2.dll, sysvwm.dll, taskbar.dll, tray.dll, vwm2.dll, wharf.dll, winlist.dll
しかし僕は、LiteStep を起動させるのに必須というわけではなく、しかも他のサードパーティー製モジュールによる置き換えが可能なものを「コア」と呼ぶのは不適当だと考えています。したがってこのチュートリアルでは、
bangmgr.dll, dllmgr.dll, hook.dll, hookmgr.dll, litestep.exe, lsapi.dll, msgmgr.dll, stepsets.dll, winlist.dll
だけを「コア・ファイル」と呼んでおき、前者のグループは「標準ファイル(standard files)」と呼びます。なお、第 2 版のチュートリアルまでは desktop2.dll を「事実上の必須モジュール」としてコア・ファイルの中に入れていましたが、これは不適当でした(他のデスクトップ用モジュールで置き換えが可能であるため)。恐らく混乱を招いたかもしれませんので、お詫びしておきます。
「(マウス・)ポインタ」とも言います。マウスを操作する時に目印となる、標準では矢印の形をした図形のこと。テキストを入力するときは「アイ・ビーム」と呼ばれるアルファベットの "I" に似た形状となったりします。
ソフトウェアを開発するときによく利用される、ソースコードなどのヴァージョン管理システムです。とりわけ複数の開発者が同時にソースコードをいじくる場合に威力を発揮し、異なる箇所を修正したり書き換えているなら、開発者全員が一斉にソースコードをアップデートしてもきちんと一つにまとめてくれます。但し、それぞれの修正が論理的もしくはプログラム上でつじつまが合っているかどうかをチェックするといった夢のような機能はもたないので(笑、プログラマーどうしはきちんとお互いに意思疎通を図っていなければなりません。
CVS についての簡単な説明は、このセクションで他のページにまとめてあります。LiteStep の開発チームはこれまで CVS サーバ(CVS のシステムが組まれているマシンのこと。特にソースコードのオリジナルもしくは本体である「リポジトリ」があるマシンへリモート・アクセスするときにこう呼びます)を非公開、もしくは一部の開発者に IRC などでサーバ名を教えるだけにしてきましたが、2001 年に入ってソースコードの管理場所を sourceforge.net に移したので、一般のユーザーも CVS サーバへアクセスできるようになりました。CVS サーバへアクセスしてソースコードをもらったりする手順も、他のページにまとめておきました。
「ディフォールト」と発音しなければ通じません(笑。「怠慢」とか「契約の不履行」という意味なので、コンピュータの世界では要するに初期設定のまま何もカスタマイズしないことを指します。
プログラムの中であらかじめ定義されているような定数とか記号を指して、"defined ..." と言ったりします。"defined variable" は「定義された変数」ということですが、これはたとえ値があらかじめ決まっていても「定数」とは別のものですから注意しましょう。定数は、重力加速度やアボガドロ数(笑、あるいはプログラムのヴァージョンといったように「勝手に定義して使えない値」のことを指しており、"defined variable" は別に定義をオーバーライドして(定義しなおして)使っても構いません。したがって、"defined variable" をもっと正確に言うと「あらかじめデフォルトの値が決まっている変数」ということになります。
LiteStep にもシステムがあらかじめ定義している環境変数が幾つかあります。自分で定義し直してオーバーライドもできますが、
LitestepDir C:\LiteStep\
などとわざわざ同じ値で定義しても無駄ですし、他のテーマを導入するときにハマる原因ともなりますから、あらかじめシステムが定義しているものはそのまま使いましょう。まあ、きちんと動かなくて定義しなおさなきゃいけない場合もありますが(笑。
まず、スクリーン上に構築される「デスクトップ環境」のことを指します。ショートカットやトレイに限らず、壁紙やマウス・ポインタまで含む広い意味があり、殆ど「GUI 環境」と同じ意味で使われることもあります。
他には「デスクトップ・コンピュータ」の簡略した言い方で "laptop" の対語として使われることもあります。ときおり「ディスクトップ」と書く人もいますが、これは 2 ちゃんねるでの「がいしゅつ(既出の発音を書き間違えたことに始まる隠語みたいなもの)」と同じようなノリで書いているのでしょう。相手が同じノリで読んでくれるとは限らないところで「ディスクトップ」と書くと、相手にあほだと思われるので注意しましょう。"Disktop" という商標の製品はありますが、まず普通の英米人には通じません。
「デスクトップ」として利用できる領域のことを指します。「スクリーン領域(screen area)」は画面に表示されている範囲だけを指していますが、「デスクトップ領域」は LiteStep の VWM とか Linux の Pager といったソフトウェアが確保する仮想デスクトップ全体を指しますから、画面に見えていない領域も含みます。
LiteStep の開発者向けベータ版を "dev build" と言ったりします。正確には、この "dev" が「開発者向け(developmental)」なのか、「開発チームのリリースした(development team's)」なのかは分かりませんが、使い道は同じことです。
LiteStep の開発チームのこと。"thanks the dev team!" と書くときは、LiteStep の考案者である Francis Gastellu(aka Lone Runner)さんから現在のメンバーに至る全ての貢献者を含みます :) メンバーの一覧は開発チームのサイトにありましたが、いまはありません。0.24.6 公式マニュアルの "development" というページを参照して下さい。
ファイル・システム上の場所を表す区画みたいなものです。これに対して Windows の「フォルダ(folder)」にはもっと広い意味があり、「名前空間(name space)」という仮想の構造でどのような位置にあるかを表しますから、「コントロール パネル」や「マイ コンピュータ」のような実体がない場所も含みます。
LiteStep を配布するには幾つかのやり方があり、まず一つめは開発チームのビルド(daily build, dev build)と同じく標準ファイルだけを一つの圧縮ファイルにまとめて配布する方法があります。shellfront.org で配布している shellfront のビルドなどが一例です。
次に、いまでは推奨されていませんが「テーマ」を配布するときに標準ファイルを一緒に同梱するというやり方もあります。テーマの制作者は全てのビルドで動作をテストしているわけではありませんから、うまく動くビルドを一緒に配布すれば、予想しない標準ファイルと一緒に使われてテーマが誤動作する心配もなくなるというわけです。
これらに加えて、2000 年の後半から広まってきた配布の仕方に「ディストリビューション」があります。これは標準ファイルを同梱しているので、容量が大きくなってテーマを集めているサイトには負担がかかってしまいますから置けません。ですからディストリビューションは「テーマ」としては提供されず、それぞれ自前のウェブサイトからダウンロードするようになっています。オリジナルのテーマを標準ファイルに同梱するだけではなく、特にはじめて LiteStep を使うユーザーの便宜を考えてインストーラをつけたり、あるいは複数のテーマを同梱してテーマを切り替えるユーティリティーが付属していたりします。
しかしこういったディストリビューションは、独自色が強くなればなるほど他のサイトで公開されているテーマとの折り合いがつかず、またオリジナルのテーマを制作しにくくなるため、the Open Theme Standard という共通の仕様を提案するグループが作られています。
.exe, .dll といった実行可能ファイルのうち、単独では動作せず他のファイルと一緒に動作するものを「ライブラリ」と呼びます。ライブラリには、本体のプログラムが何か拡張機能(独自に定義した関数などの集まり)を必要とするときに、いつでもメモリへ読み込んで利用したりメモリから解放して関連を打ち切ることができる動的(ダイナミック)なライブラリと、プログラム本体が動作するのに必須で、リンクすると本体が終了するまで関連や依存関係が継続する静的(スタティック)なライブラリがあります。
ライブラリの拡張子は、.exe, .dll, .drv, .fon などがあります。特によく使われるのは .dll ですが、ライブラリが静的にリンクする場合でも拡張子は多くの場合に .dll となっています。LiteStep では litestep.exe を本体と考えた場合に、lsapi.dll といったコア・ファイルだけでなく、shell32.dll のような(本来は Explorer.exe が使う)ファイルもライブラリとして利用します。これにより、!run といったコマンドでお馴染みの「ファイル名を指定して実行」ダイアログが利用できるわけです。したがって、「LiteStep がエクスプローラよりも軽い」とか「必要なファイルの容量が少ない」といった比較は LiteStep の標準ファイルやタスクマネージャのメモリ使用量だけでは正確に判断できず、LiteStep が起動しているときにどのようなライブラリへリンクしているかを process viewer のようなシステムツールで確認しなくてはなりません。
いまのところ正確に対応する日本語はありませんが、文書を収集して記録に留め(後世の人を含む)多くの人に利用してもらえるよう公開するといった一連の業務を "documentation" と言います。また「収集」といった意味はなくても、ソフトウェアの使い方についてオンラインのマニュアルを作成して公開することも "documentation" と言い、この場合は「文書化」という堅い言い回しが該当します。"internationalization" を "i18n" と表記することはありますが、"documentation" を "doc6n" と表記するページは殆どありません。が、URI は短い方がよい(昔の Macintosh は 256 文字以上の URI を認識しないらしい)ので、ディレクトリ名にはときおり使われているようです。つ~か、こんな名前のディレクトリを作る方も作る方ですが。
LiteStep 0.24.6 について最も多いクレームの一つが「トレイにネットワーク接続のアイコンが表示されない」というものです。これは Windows 2000 以降のシステム・トレイ(LiteStep のモジュールではなく Windows が提供している機能のこと)に変更があったためです。しかしうまく対応させるのが難しく、数多くの互換シェルが問題を抱えていました。"DUN icon" というのは、ネットワークへ接続したときにトレイへ表示されるアイコンのことです。データが流れているときに表示が変わるといった特殊なタイプのアイコンなので、これをうまく表示するのは事の他たいへんとのこと。ああ、あとは二年くらい前に使ってた ReGet のアイコンとか、いま会社で使ってる Becky! のアイコンもそうだったな。
"e-variable" などと書かれたりもします。それぞれの環境に特有のデータ内容を、共通の書式で表現したものです。Windows ではシステムのプロパティ(sysdm.cpl, あるいはコントロールパネルから開いたり、マイコンピュータのアイコンを右クリックしてプロパティを選択する)で環境変数を確認できます。
プログラムをインストールするときなど、Windows のヴァージョンによって Windows のシステム・フォルダが C:\WINDOWS, C:\WINNT など異なりますし、NT 系の OS ではスタートメニューもユーザーアカウント毎に違っていますから、Windows の方であらかじめそうした「環境に依存するパスやデータ内容」を一つの名前に決めておけば便利でしょう。例えば、「Windows フォルダを windir という名前で呼ぶ」ことにしておけば、Windows 98 を使っている人(Windows はふつう C:\WINDOWS にインストールされる)や Windows 2000 を使っている人(Windows はふつう C:\WINNT にインストールされる)が或るソフトウェアをインストールするときに、ソフトウェアの側は windir という言葉を使って Windows フォルダを定義しておけばどちらのユーザーにも対応できます。
LiteStep でも、ユーザーの環境に特有な情報を LiteStep があらかじめ幾つか取得していますので、テーマを公開するときにその人が LiteStep を E:\LS というフォルダにインストールして使っていても、litestep.exe のあるフォルダを $LitestepDir$ と呼んでおけば、他のユーザーが C:\Litestep というフォルダにテーマを入れても起動した litestep.exe は自分の場所を知っていてうまく立ち回ってくれるというわけです。例えば、
LoadModule $LiteStepDir$themes\funnyname\modules\
と書けば、どこに litestep.exe があろうと、起動した litestep.exe は $LiteStepDir$ を自分の置かれているディレクトリと解釈します。あんまり詳しく書くと本文の意味がなくなるので、このへんでさいなら(笑。
特に注意すべきところがない限り、.exe もしくは .dll という拡張子がついたファイルのことを「実行可能ファイル」と呼びます。前者と後者の違いは、単独で動くかどうかくらいだと考えておけばよいでしょう(単独で動かしても「正しく」動くという保証はありませんが)。
"advanced" という言葉も使いますが、こちらは自分でモジュールのソースをコーディングしている(あるいはできる)人も含むような意味です。英語には日本の PC 雑誌によく出てくるような「中級ユーザー」という言葉はありません。「できるか、できないか」だけで区別するみたい。シビアね(笑。
しかしまあ、いちおうの目安としては「自分でテーマを一から制作できる」くらいの知識がある人までを日本で言う「中級」と呼んでいいと思います。"experienced" かどうかは話題によって違いますから、それほど明確な意味があるとも思えません。但し、自分の使っていないモジュールの話についても readme を読めばひととおり分かるなら "experienced" と言っていいのでしょう。もちろん、Windows そのものについても知識が要求されます。
"advanced" はそういった知識だけでなく、開発者としての知識が要求されるレベルだと考えておけばよいでしょう。したがって、MCP (マイクロソフト認定技術者ライセンス)をもっていても C++ が分からない人を "advanced" ユーザーとは呼ばないわけです。
いづれにせよ、あまりこういった区別に固執するのは馬鹿げています。初心者 -> experienced -> advanced という流れを考えているのは業界人だけで、一般のユーザーがこの流れを必要もなく追うのは絶対に間違っています。コンピュータはそれで「何か自分の趣味や仕事を」やりとげるためのものであって、コンピュータの使い方をどれだけ知っていてもいい論文や絵は書けません。もちろん、コンピュータを使う仕事の多くについてすら同じことが言えます。
Internet Explorer でブックマークした、ウェブサイトへのショートカットを保存しておくフォルダ。9x/Me 系では Windows フォルダにあり、NT/2K/XP 系では Documents and Settings 以下の各ユーザー名で作られたフォルダにあります(日本語版 Windows のエクスプローラでは「お気に入り」と表示されますが、実際には favorites という名前のフォルダです)。
なお、英語(米語じゃなくて)では favourites と綴ります。注意はしていますが、個人的ないきさつからこのサイトでは綴りを(Windows で使う綴りとしては)間違えている場合がありますから、コピペするときは確認してからにしましょう。
"look and feel" という言い方でよく目にします。"look and feel" を「目で見た(look)印象(feel)」としか訳していない場合もありますが、"feel" にはユーザーインターフェイスの操作性も含まれますから、「使い勝手[IW]」というもっと広い言葉を当てておく方がよいでしょう。
ふつうの英語としては「~を見つける」とか「~が分かる」という他動詞ですが、LiteStep では find.exe, find.dll でファイルを検索する機能を指します。
LiteStep では多くのテーマに find.exe や find.dll が付属しています。これはシェルを取り替えるとエクスプローラの検索機能が使えなくなるためです。-.exe の方は単体でも使えますから、LiteStep 以外の互換シェルでも使えて便利ですね。ただ、誰が開発したものなのか不明です(笑。というか、同じ名前の検索用ソフトを色んな人が出しているので、テーマによって使われている find.exe が違っているだけですが。僕は Mijenix Corporation が 1998 年に公開した find.exe (file finder)を使っています。-.dll は mirul さんが開発した LiteStep 専用のモジュールです。どちらも古くからありますが、XP でもちゃんと使えます。
デスクトップ上では、ユーザーがマウスやキーボードで操作できるウインドウが複数あるときに「アクティブな」ウインドウと「非アクティブな」ウインドウが区別されます。アクティブなウインドウはキーボードやマウスでメニューバーから項目を選べたり、テキストの入力部分にインジケータ(マウスのカーソルではない)が表示されて、入力待ちの状態になったりします。ふつう、Windows ではアクティブと非アクティブに応じてウインドウの配色が区別できるようになっていますから、この区別は経験的に誰もが知っていることでしょう。
"focus" を当てるというのは、文字どおり或るウインドウから他のウインドウへ「アクティブ」という状態を切り替えて、他のウインドウに焦点を当てる(動詞としての "focus")ことを意味しています。Windows 用語では「タスクの切り替え」とも言います。
デスクトップそのものも一つのウインドウです。何もないデスクトップの部分をクリックすると他のウインドウが全て非アクティブになるのは、デスクトップというウインドウがアクティブになるからです。本来、Windows には GNU/Linux と同じくマウスの位置に応じてアクティブなウインドウを自動で切り替える X mouse 機能が搭載されていますが、これを導入すると「アクティブ / 非アクティブ」の対比に加えて「ウインドウどうしの前後関係」も操作しなくてはならず、デフォルトでは無効になっています。
この言葉は Windows と UNIX で意味が違っています。Windows ではウインドウの中で仕切られた個々の表示区画を指しており、「フレーム・バー」と呼ばれる仕切りをドラッグして広さを調節します。UNIX などではいま述べたフレームを "window" と呼んでおり、元のウインドウの方を「フレーム」と言うようです。
ややこしいので、IW ではしばしばウインドウの中にある区切られた表示領域(エクスプローラで表示するフォルダツリーの部分など)を「ペイン(pane)」と呼んでいます。
特に LiteStep では、VWM 機能であちらこちらのデスクトップに散らばったウインドウを一つのデスクトップへ集めることを指します。VWM モジュールにはときどき「デスクトップを切り替えているうちにウインドウがどこかへ消えてしまう」とういトラブルがあります。殆どの場合、これは仮想デスクトップの割り当て番号やウインドウの座標がプログラムの内部ルーチンで間違って計算されることに起因しているわけですが、ウインドウを gather すれば見失ったウインドウも戻ってきます。
言わずと知れた、Free Software Foundation, Inc. の壮大なプロジェクトです。正式な綴りは "GNU's Not Unix" という再帰的(定義の中に定義されるべき言葉が使われる)な表現ですが、僕は UNIX と GNU の関係については知りませんから直に GNU.org をご覧下さい。日本語のページも幾つかあります。
GNU プロジェクトのフリーソフトウェアが従っているライセンスで、LiteStep もこのライセンスに従って公開されています。要点は、誰もが自由に使ってソースコードを参照し、改変して公開するということにあり、ソフトウェア自体は有料でも無料でも構いません。これも詳しくやりだすときりがないので、GNU.org をご覧下さい。
略記の読み方としては、「ジー・ユー・アイ」と「グーイ」の二通りがあります。一個ずつアルファベットを発音する方が改まった略し方・・・というのも変ですが、「グーイ」よりはフォーマルな言い方になります。Graphical ... と元々の綴りを全て書いたり発音するのはかなりフォーマルな言い方、もしくは書き言葉です。
ああ、意味を書くのを忘れてた(笑。キーボードから文字を打ち込んでコンピュータに命令を伝える方式(「キャラクター/コマンドライン・ユーザーインターフェイス Character/Command line User Interface, CUI」とも呼ばれますが、あまり普及した言い方ではありません)とは異なり、モニターに表示されたアイコンなどの図形をクリックするなどしてコンピュータに命令を伝える方式のこと、というのが当たり障りない定義になるでしょうか。三国志でおなじみ光栄から出ていた『ウィンドウズ・マジック! GUIのすべてがわかる本』(大塚正男/監修,吉田広行・高原利之/編著,1992)という本には、CUI は一次元で GUI は二次元のユーザーインターフェイスだと書いてあったりするのですが、これらの対比については別のページで色々と書きたいのでおあずけ。
[2003-04-08 09.24 (JST: GMT+0900) @058]
おおよその感覚では、システムの挙動をちょっとしたアイディアでうまく調整するといったことを指すと思われます。山形浩生さんのサイトに詳しく解説されていますから、そちらを参照される方がよいでしょう(だから殆ど UNIX しかなかった頃のことは知らんってば)。
"width" を参照して下さい。
hexa (6 の)+ decimal (10 の)ということですね。ボードゲームのシミュレーションでマス目を「ヘクス」と言うのも、六角形をしているからです。ウェブでは色を指定するときに #ff0066 などと 16 進数を使ったりします。LiteStep では、ポップアップなどで画像を使わずに表示するときの配色に 16 進数が使われます。MS ペイントなどで使われている RGB 指定(0 - 255 の十進数)とは異なり、0 - 9, A, B, C, D, E, F で 16 を単位に繰り上がります。
"vertical" を参照して下さい。
-4, -108, 0, 45, 998 といった数ですね。特に断らない限り、正の整数と負の整数を区別せずに使います。LiteStep の画像などはモニターの画面上に表示される光点と同じくピクセルを単位にして位置を指定しますから、何かの中間処理で有理数を使う以外に精度の高い数値を使う必要はありません(し、意味もなく精度を上げるのはメモリの無駄遣いです)。
発射するといった意味があります。なお、正しい発音は「ローンチ」なので「ラウンチ」では通じません。また、自立して起動するプログラムには使われず、ユーザーインターフェイスを介して起動することを意味するようです。従って Apache とか Windows を lauch するとは言わず、Photoshop や notepad を launch するといった使い方をします。
本来は積み重なっている層のことなので、ウェブデザインで絶対座標を使い並べて配置しただけの <div> 要素を「レイヤー」と呼ぶのは間違っています。もしアメリカ人がそう言っているなら、そのアメリカ人が英語を知らないというだけの話です。
そういえば、Layer13.com は何で 13 なんだろう? 聖書に出典があるとか?
"look and feel" という成句で登場することが多いので、既にご存知の方も多いでしょう。言葉そのものは随分昔からあるようです。"feel" という言葉に引きずられて「見た目の印象」としか訳していない場合もありますが、操作性という目に見えない点も含みます。
下の "magic pink" を参照して下さい。
色としては RGB で 255, 0, 255、16 進数で #ff00ff となり、「マゼンタ」とも呼びます。LiteStep では(というか透過 GIF でもそうですが)デフォルトの透過色として設定されており、この色を使った部分はデスクトップに表示されなくなります。
あまり知られていないことですが、「ピンク(pink)」という色の名前は Owens Corning という会社の商標として登録されています。豊栖康司さんの解説によると(かなり独特な書き方のソースだったので、マークアップは編集させていただきました)、
オーウェン・コーニング・ファイバーグラス社事件
In re Owens-Corning Fiberglas Corporation., 774 F.2d 1116, 227 USPQ 417 (Fed. Cir. 10/8/1985).
合議体:ニューマン、ビッセル(反対意見)、コーウェン判事
判決文:ニューマン判事
1946年商標法が成立する以前は、色自体では商標として登録できなかった。...Prior to passage of the Trademark Act of 1946, 15 U.S.C.§1051 et seq. (the Lanham Act), color alone could not be registered as a trademark. In 1906 the Supreme Court wrote:
Whether mere color can constitute a valid trade-mark may admit of doubt. Doubtless it may, if it be impressed in a particular design, as a circle, square, triangle, a cross, or a star. But the authorities do not go farther than this.
A. Leschen & Sons Rope Co. v. Broderick & Bascom Rope Co., 201 U.S. 166, 171 (1906).
オーウェン・コーニング・ファイバーグラス社は、同社の繊維ガラス製住宅断熱材(fibrous glass residential insulation)について、ピンク色を商標として出願。商標審判部は、色は商標として機能し得ると認めたものの、ピンク色がオーウェン・コーニング・ファイバーグラス社の商品であるという識別力を有すると同社が立証できていないとして拒絶査定を維持。控訴審においてCAFCは審決を破棄し、ピンク色を商標として認めた。
...An overall color is akin to an over-all surface design, for which trademark registration has been held to be available when the statutory requirements are met. See, e.g., In re Todd Co., 290 F.2d 597, 600, 129 USPQ 408, 410 (CCPA 1961) (registration on the Supplemental Register of a pattern of green parallel lines for safety paper products); Vuitton et Fils S.A. v. J. Young Enterprises, Inc., 644 F.2d 769, 775, 212 USPQ 85, 89 (9th Cir. 1981) (protection granted to a mark consisting of an overall pattern of florets and letters). Cf. In re Soccer Sport Supply Co.,Inc., 507 F.2d 1400, 1403, 184 USPQ 345, 347 (CCPA 1975) (registration refused for an overall design covering a soccer ball, for lack of distinctiveness).
・・・となっています。恐らく、"magic pink" はこれをからかっているのでしょう。つまり、「ピンクはピンクだけど、実際には色が出ないからカンケねぇ~よ、村田製作所」ということで。
geOShell のイントロでも述べていますが、この言葉は LiteStep で少ないモジュールと画像を使ってすっきりしたデスクトップをデザインするという発想からきています。では、参考までに MINIMALISM というサイトの説明を引用してみましょう。
Basically, it's the same idea. Simple design, repeated forms. However, the reasoning behind it is different. Minimalism with LiteStep allows you to make more use of your desktop, and not have to worry about flashy designs or other crap that would normally get in the way.
基本的には英語で使っている元の意味と同じです。簡潔なデザインを心がけて、同じ機能には同じ見栄えを適用するということになります。しかし LiteStep 用に制作するテーマの「ミニマリズム」にはもう少し違った意味合いもあります。LiteStep の世界で言うミニマリズムは、デスクトップから不必要なものを出来る限り取り除くことを目的としていて、けばけばしいデザインや見栄えだけの糞ったれな効果を邪魔に思っている人でも安心して使えるデスクトップを目指しています。
こういったわけで、海外のサイトでは特に機能(モジュールの数)を抑えるとまでは言ってないようです。
「さまざまな種類の」,「多岐に渡る」といった意味があり、LiteStep では LiteStep のシステムやモジュールと直接の関係がないファイルを同梱するときにしばしば "misc" という名前のフォルダを作ります。WindowBlinds の Personality とか、壁紙とか、一緒に使ってほしいフォントとかを入れることが多いようです。
LiteStep システムで使う実行可能ファイルのうち、.dll という拡張子がついているファイル[IW]を(このチュートリアルでは)全て「モジュール」と呼びます。
分けようと思えば、モジュールを lsapi.dll のような「コア・モジュール」と shortcut2.dll のような「アプリケーション・モジュール」に大別できるでしょう。特に後者の意味では、互換シェルごとに「プラグイン」とか「コンポーネント」のような別名があります。
LiteStep のモジュールが使う設定ファイルの一つ。LSXCommand.dll のコマンド入力欄にタイプしたコマンドなどの履歴を保存したり、ウォーフの初期位置などを記録しておくために使われます。LiteStep ではレジストリを使っていないので、こういった一時的なデータは modules.ini を使います。
とは書いてますが、MRU (most-recently-used)リストなどを記録するのにレジストリを使っているようです。またモノによってはトレイ用のキーも出来ていたりします。
Microsoft の略称。マイクロソフト自身や、特に敵意がない人は "MS" と書き、敵意がある人や「ハッカー」気取りの人は "M$" と書きます(「ハッカー」気取りねぇ・・・)。しかし、特に敵意がなくても "M$" と書くことはあるので、実際にはどっちでもよかったりする(笑。
LiteStep の設定では整数しか使わないので、事実上は負の整数と言ってもよいでしょう。画像の表示などで原点をスクリーンの左上端としている場合に、-1, -1 と指定すると、多くのモジュールでは対角の右下を指すことになります。これを利用して、モニターの解像度が異なるさまざまなユーザーの環境に対応するテーマを作成できます。
全てのモジュールが対応しているとは限らないので、readme などで使える値の説明をよく確認して下さい。対応していないモジュールで負の値を使うと、左上端よりも更に左上へ設定されるか(笑・・・実はセキュリティの問題があるから笑い事ではないが)、モジュールがエラーを起こします。
「右へ」とか「下へ」といった向きのことです。"direction" よりも弱い意味合いなので、「右へ行け」というよりは「右へ行こう」くらいのものです(笑。
座標を指定するときなどの原点です。モジュールの中には、chronos.dll のように原点そのものを任意の座標に指定できるものがあります。原点をスクリーンの中央とした場合は、もちろんモジュールの座標もその原点から位置取りをしなくてはなりません。解像度依存を減らす一つの方法ですが、混乱の要因にもなるでしょう。
或る機能を実行するときや設定するときに必要な値のこと。一度設定すればいい値というよりは、状況によって(刻々と)変化するような値のことを指すようです。
LiteStep では、ドラッグして動かせるショートカットの座標とか、時刻表示のモジュールでロケールに応じた時刻の計算を補正するために使われる値などを「パラメータ」と言います。
なお演算するときに使われる値は、特に(演算子つまりオペレータから見た)「オペランド」と呼ばれます。
Windows の名前空間やファイルシステムが管理している対象には幾つか種類があって、最もよく知られているのはファイルとフォルダでしょう。多くのフォルダは「ディレクトリ(directory)」と呼ぶこともあります。これらは決まったところに配置されていて(ハードディスクの中では無茶苦茶な場所に散らばっていますが)、そのありかを「パス」と言います。また、ドライブレターから目的のファイルやフォルダまでを省略せずに書いたパスは「フルパス」と呼びます(エクスプローラはドライブを「マイ コンピュータ」の下に表示しますが、これは名前空間内での見せかけです)。例えば、
C:\WINNT\SYSTEM32\MSVCP60.DLL
と書いた場合、MSVCP60.DLL というファイルのフルパスを書いたことになります。そして、パスを書く場合に「プログラムがどこのディレクトリを検索すればいいかが定義されている」ときに限り、
myimage\myimage.bmp
という相対的な位置関係だけを表すパスが書けます。LiteStep では、画像ファイルを置くデフォルトの置き場所を LSImageFolder という命令(コマンド)で定義できますから、設定ファイルに image.bmp と書けば LiteStep があらかじめ定義されたフォルダの中でそのファイルを探してくれます。
LSImageFolder で画像ファイルの場所を定義すると、後は設定ファイルの中で画像ファイルのファイル名だけを使って画像を指定できます。しかし画像ファイル名だけを記述していても、それはパスを省略して書いているにすぎません。
ちなみに、いまこのページを見ている方のブラウザでは、ディレクトリを区切る記号にバックスラッシュ(\)が表示されているかもしれません。もちろんこれは円マーク(¥)と同じ働きをしますから、気にしないで下さい。
「実行速度」という意味合いで使われることが多いようです。一般の英語では、「任務や業務といった継続的で規則的な作業の遂行」とか、「芸当」といった意味があります。
スクリーンの解像度を表す単位として使われています。実際に紙などへ出力される単位とは違っていますから、よく似た言葉の「ドット」とは区別します。
例えば、Windows のスクリーン解像度はふつう 72 ピクセル/inch ですが、同じ大きさ(例えば 15 インチ)のスクリーンでも解像度が(XGA, UXGA などに)上がると、一定の面積あたりに表示できる光点の数は多くなります。これとは別に、紙へ出力するときの dpi (dot per inch) という単位はモニター上の解像度をそのまま使っても混乱を招きますから注意しましょう。
昨年あたりから一般のウェブサイトでもよく使われるようになった画像形式です。Internet Explorer 5.x ではキャッシングにバグがあったのでうまく表示できないこともありましたが、IE 6.0 や Mozilla、Opera といった主要なブラウザがサポートしているため、これから使う人が増えてくるでしょう。GIF と同じく可逆圧縮の形式ですが、true color やアルファ・ブレンディングをサポートしています。実は IW の PNG 画像は全て 128 色以下にしてありますし透過は使っていないので GIF でもいいのですが、GIF が使っている LZW という圧縮アルゴリズムは UNISYS という会社が権利をもっているので、念のために IW では PNG を採用しています。実際、金に困ってきたらネット企業なんてどういう手段で金を取り出すか分かったもんじゃありません(笑。ただ、UNISYS のもっている権利は保護されなければなりません。よって GIF をサポートするソフトウェアの開発者が UNISYS に対価を支払うのは(どういう経緯があれ法的には)当然です。
PNG 形式の画像は最近のビルドでは lsapi.dll によって処理されるので、ユーザー側では画像の形式を考慮する以外にやることはありませんからご安心下さい。ちなみに、1999 年頃に murphy さんという開発チームのメンバーだった人が個人サイトで PNG や JPEG をサポートする「イメージローダー」を公開していましたが、これはどういうわけか当時のビルドには採用されなかったようです。
geek 言葉(ヲタク用語)で "proggie" とも言います。良く似た言葉に "software" (ソフトウェア), "application" (アプリケーション), "source code" (ソースコード)があるので、まとめて解説しておきましょう。
まず「ソースコード」はテキスト形式で書かれた「プログラム」のことです。「プログラム」という言葉の方がもっと広くて抽象的なものも指しており、紙の上に書かれたアルゴリズムも「プログラム」と言えます。バイナリー形式にコンパイルされたプログラムは「ソフトウェア」と呼び、これは「ハードウェア」と対比してよく使われる言葉です。「アプリケーション」は英語で「応用」という意味があるように、OS やサーバ・プログラムを「アプリケーション」とは呼びません。Photoshop やワードといったような各ユーザーの用途に沿って使われるソフトウェアを指しています。
かといって、LiteStep のようなプログラムを「アプリケーション」と呼ぶのは適切ではないでしょう。だいたい、これらの中では「アプリケーション」という言葉がもっとも曖昧で特に使う必要もありませんから、僕はこの言葉を多用してはいません(殆どの場合に「ソフトウェア」と言っても済みます)。
"kill" とは違って、プログラム自身の機能として終了させるときに使います。これに対して、"kill" はタスクマネージャやターミナル・ウインドウから実行中のプログラムを強制的に終了させることを意味します。したがって、quit する場合とは異なりプログラムの終了動作も何もなしにプログラムのプロセスへ割り込むので、"kill" ではそのプログラムが扱っていたデータを破壊する可能性があります。まあフリーズしてたらどうしようもありませんが。
bang command と並んで、LiteStep の挙動や初期設定を定義するためのコマンドです。"*" (アステリスク)を付けて記述するタイプと付けずに記述タイプがあります。別にサードパーティ製のモジュールと開発チームの標準モジュールとで表記が違っているわけでもありません。
コマンドの命名法に一貫していない点も多いので、最近では「有効/無効(有効の場合は特に明示せず、後の機能を無効にする "No" だけが入る」-「モジュール名」-「機能」という組み合わせで書くようにコンセンサスができつつあるようです。例えばこれまでポップアップのベベル(縁採り)を表示しないよう宣言する RC コマンドは、
PopupNoBevel
となっていましたが、現行の 0.24.6 では、
NoPopupBevel True
というのが正式な記述方法となっています。
LiteStep を再起動することで、Windows のリブートとは関係がありません。ただ、再起動とは言っても LiteStep のプロセス自身が終了するわけではありませんから、メモリの解放といった処理がうまくいかないと recycle するたびにメモリを多く消費するといった現象が起きてしまいます。
新しく追加したモジュールを読み込ませるとか、再編集した step.rc ファイルの内容を適用するといった目的で使われ、!recycle という bang コマンドとして実行できます。Windows 9x/Me 系では recycle したときに LiteStep が落ちてしまうと「シェルなし」の状態となり、Windows そのものを再起動させられるはめになります。step.rc の記述に致命的な間違いがあると、何度 Windows を再起動してもシェルなし状態から抜け出せなくなり、エントリーユーザーがハマる原因となります(笑。
テーマを制作するときの理想とされているスタンスの一つが「モニターの解像度に依存しない見栄えのテーマを作る」ということです。例えば、画像の幅が 100 ピクセルあるモジュールの表示位置を 1024 x 768 ピクセルのモニターで x = 924, y = 0 と設定して自分用に使っているテーマは、そのままの値だと 800 x 600 ピクセルのモニターを使っているユーザーさんを困らせてしまいます(LiteStep を起動すると、モジュールはスクリーンの右手へ隠れてしまう)。
このような場合には、モジュールの表示位置を負の整数で -100, 0 などと指定しておくと、水平方向が 800 ピクセルのモニターで表示するときに LiteStep は解像度を取得してから 700, 0 という位置へ表示してくれます。「右端へ表示する」というテーマ作者の意図が異なる解像度のモニターでも反映されるわけですね。ただ、こういったやり方にも限界はあります。例えば 1600 x 1200 ピクセルのモニターで横幅一杯に画像をあれこれ並べてしまうと、それよりもピクセル数の少ないモニターではどうやっても全てのモジュールを並べて表示できなくなります。
プログラムを実行すること、というのがコンピュータ用語の定番です。LiteStep では、スタートメニューにある「ファイル名を指定して実行」のダイアログを開くことを指しており、!run という bang コマンドも用意されています。コマンド入力用のモジュールを使ってもいいわけですが、パスが分からないときにはこちらでファイルを「参照(browse)」する方がよいでしょう。
ときどき "snapshot" という言い方も目にしますが、これは個別のウインドウかアクティブなウインドウだけを「スクリーンショットにして保存する」という機能のことかと思います。スクリーンショットは、文字通りスクリーンの表示状況をクリップボードなどへ保存する機能のことです。
但し、何でも画像としてクリップボードへ送れるわけではありません。例えば、RealPlayer や Media Player で表示している動画の画面などはリフレッシュレートもしくは動画再生ソフトが意図的にやっている機能のせいでスクリーンショットに画像として映らない場合もあります(Real Player の場合は、表示を「自動サイズ」としてウインドウの縦横比をわずかに歪ませると画像に映ります<笑)。
デスクトップのスクリーンショットをウェブ上で公開したり、あるいは画像投稿用の掲示板へ送る場合は、画像の形式などに注意しましょう。スクリーンショットはキーボードの Print Screen キーでクリップボードへ送られ、それを MS ペイントなどの画像編集ソフトで開いてから保存すると、そのままは Windows の標準画像形式であるビットマップになっています。これをそのままウェブで公開したり掲示板へ送信するのは迷惑以外の何ものでもありません(笑。せめて圧縮した JPEG や GIF などに変換してからファイル容量を確認して送信したり公開して下さい。
LiteStep でもモジュール開発用にスケルトン(モジュールの雛形となるソースコード)が公開されています。こういった、ソフトウェアの開発用に配布されているユーティリティのひとまとまりを SDK と呼びます。いま述べたスケルトンや、デバッグ(プログラムのバグや挙動を追跡してソースコードを修正したり改善すること)用のソフトウェア、あるいは開発用の資料などが含まれます。
同じような言葉に "configuration" があります。"configuration" は単数形で使われることが多く、システム全般に渡る設定やハードウェアの構成を総称するときなどに使われるようです。"settings" はハード/ソフトに関係なく、また特に重要であってもなくても「設定」という言葉が当てはまる場合にいつでも使われているみたいです。まあ日本語ではどちらにせよ「設定」だからどうでもいいけど(笑。
Windows の起動時もしくは起動後でも任意に複数のシェルから選択して切り替えるためのユーティリティ。Windows 9x/Me 系では Windows フォルダの system.ini、Windows NT/2K/XP 系ではレジストリの winlogon キーにある shell エントリにあるユーザーインターフェイス設定も切り替えてくれるので、設定を替えたら次の起動時から選択したシェルでデスクトップ環境が構築されます。単にオンザフライで切り替えるだけなら、とりわけ NT 系だとシェルを終了させてタスクマネージャから他のシェルを起動すればよいのですが、9x/Me 系ではシェルを落とすとデスクトップ上で何も操作できなくなるので、こういったユーティリティで切り替えると安全です。
LiteStep では長らく katmai さんの LiteSpawn が多くのユーザーに使われてきましたから、2000 年頃までに書かれた日本語のウェブページにもシェルマネージャとして LiteSpawn を導入するよう促しているページが見られます。但し、LiteSpawn は独自のプロテクト機能をもっているようなので注意が必要です。現在は、ShellOn, carapace, すなふきん, しぇるま(9x/Me 系のみに対応)といった、安定していて機能や見栄えも優れたシェルマネージャが幾つか出ています。
「安定している」と言ってもその基準は特に決まっているわけではありません。経験からすると、
という、結果論で判断しているだけの話です。ちなみに歴代の安定版ビルドを挙げてみると、
となります。2001 年はポップアップ・メニューの(特にマルチバイト文字で名前をつけた)フォルダがうまく展開できなかったので、日本語の環境としてはお勧めできるビルドがありませんでした。いまのところ、shellfront.org で公開されている 2002-02-16 のビルドと、mzks.org で公開されている 2002-03-24 のモジュールパック(コアファイルなど日本語環境に対応するモジュールだけをアップデートするもの)が 0.24.6 としては最終のビルドとなっており、最も安定していると言ってよいでしょう。
ビルドの安定性をテストするための基準は、大まかなものが公開されていました。それによると、
という手順が説明されています。但し、LoadModule の切り替えだけでは不十分な場合があり、モジュール同士の読み込み順序がシステムの動作に関連している場合がありますから、或るモジュールを追加してシステムが落ちたときだけでなく、モジュールを追加するときに読み込み順序の組み合わせを全て試してみなければなりません。作業としてはかなり退屈なものとなりますが、これをやって問題がなければ、あとはサードパーティー製のモジュールについて同じテストを繰り返せば「そのビルドに関しての安定性テスト」はほぼ十分に行ったと言ってよいでしょう。それで他のユーザーが不具合を起こすようであれば、「仕様です」(笑・・・と言えるかどうかはともかく、不具合が起きたユーザーの環境に依存する話なので「こちらでは同じマシン環境を整えられません」(いちいち買う金なんかないし)とお断りできるでしょう。
LiteStep の初期設定ファイルの一つです。現行の 0.24.6 では外部ファイルの内容を展開する include 文がサポートされていますから、step.rc に設定を全て書く必要はなくなりました。但し、litestep.exe が起動するときに読み込むファイルは litestep.exe と同じディレクトリに置かれている step.rc ファイルだけなので、テーマを切り替えるときはテーマ毎の設定を include できるように step.rc へ書いておくのがよいでしょう。
拡張子の ".rc" は、GNU/Linux のウインドウ・マネージャなどで使われる設定ファイルと同じく、"resource (config, control, or else)" を意味しています。
よく海外の付箋ソフトを "sticky memo" と呼んだりします。デスクトップに貼りつくという感じですね。LiteStep のコミュニティでは、VWM を使っているときに或るウインドウを特定の仮想デスクトップではなく全ての仮想デスクトップで常に表示するよう設定すると、そのウインドウは "sticky" なウインドウと言います。もちろんショートカットやトレイなどの LiteStep が表示しているウインドウは最初から sticky として扱われます。
本来、テーマはそれぞれのユーザーがカスタマイズして追加したモジュールや画像などの一式を指していました。しかし、同梱しているモジュールと他のユーザーが使っているコア・ファイルの相性によってはうまく動かないことがあるため、テーマ・ファイルとして圧縮されたアーカイブの中にコア・ファイルを同梱するようにもなりました。
LiteStep を使う殆どのユーザーは、この意味での「テーマ」を「スキン(skin)」と言ったりはしません。スキンは飽くまでも個々のモジュールに使う画像のことですから、「LiteStep のスキン」は存在しないと考えて下さい。また Winamp や Sonique など、少なくともデフォルトのスキンが否応なく表示されるソフトと異なり、LiteStep はスキンを全く使わずに運用できます。実際、そういうコンセプトで作成されたテーマもあります。したがって、LiteStep のコミュニティでは「スキン」と「テーマ」は全く別のレベルのものだと覚えて下さい。
"theme switcher" とも言います。ふつうは、いわゆる「壁紙チェンジャー(壁紙切り替えソフト)」の役割ももっており、追加した新しいテーマとそれまで使っていたテーマを切り替えるために使います。
但し、LiteStep 用に公開されているテーマはそれぞれ互換性のないフォルダ構造で異なる場所に標準ファイルを入れている事が多く、解凍したフォルダを LiteStep ディレクトリにそのまま放り込んで step.rc を上書きするだけでテーマがうまく切り替わるのは、正直言って稀なことです。もちろん同じ人が公開しているテーマならうまくいく可能性は高いので、お気に入りのテーマ作家さんを見つけたら、他のテーマを導入するときにその人のフォルダ構成と同じにしてしまえばよいでしょう。もし新しいテーマが気に入らないとしても、お気に入りのテーマ作家さんが採用している構造を保っておけばすぐに戻せます。
とは言え、「step.rc とコア・ファイルの場所を除いて、他はユーザーが自由にフォルダ構造を決められる」という LiteStep の柔軟さがうまく活かされていないとも思えます。こうした柔軟さは、大袈裟に言えば「スケーラビリティ」(システムの構成が変わっても古いテーマをそのまま使える)を保つためだと考えるべきで、個々のテーマ作家さんが自由にフォルダ構造を決めるためのものではないと思います。LiteStep をはじめて導入する人の多くは、幾つかのテーマをあれこれ試してみて使い易さなどを判断しているでしょう。このとき、テーマを切り替えるたびに「モジュールがない」の「画像ファイルのパスが有効でない」のといったエラーで LiteStep が落ちていたのでは、それほど待たずに誰もが「LiteStep って不安定なんだなぁ」と落胆するか、たとえテーマごとに step.rc の書き方が違うことを知っていたとしても実際の煩わしさをはじめて経験して嫌になるかもしれません。
いまのところ、そうした不都合を避けるための手段としては、
といったことくらいしかありません。テーマチェンジャーと呼ばれているユーティリティの殆どは、いずれにせよどれか或る一定のフォルダ構造や仕様を仮定して作られていますから、テーマチャンジャーで全てのディストリビューションを交互に使い分けることはできないのです。
"party" は「政党」とか、或るまとまった集団を指す言葉です。ひとまず慣例として、「公式の開発者(developers)」と「ユーザー(users)」を考えた場合に、公式の開発者ではないが関連するソフトウェアを配布している人たちを「サードパーティーの開発者」と呼びます。同じように、Microsoft Office 製品の機能を拡張するようなソフトウェアを開発している会社も、Microsoft とユーザーに対して「サードパーティ」と言えます。
しかし、LiteStep のコミュニティでは公式の開発チームに所属している人がサードパーティーとしてモジュールを作ったりしていますから、それほど気にするような区別ではありません。もちろん、公式の開発チームに所属する人がコアファイルの新しい仕様を使ってモジュールを作る、といったことができるのは LiteStep が GPL に従っているからです。もし Microsoft の社員が本社とのライセンス契約なしに Windows の内部仕様(に関する知識)を使ってサードパーティのソフトウェアを制作・販売すれば、犯罪です。
プログラムが起動すると、OS は一つのプログラムで行われる処理を「プロセス(process)」という単位で管理します。他に幾つかのプログラムが起動しているなら、OS は個々のプロセスを細かい時間単位に割り振って「それぞれ少しずつ」処理します。この割り振られた時間単位は非常に短いので、ユーザーから見ると全てのプロセスが同時に実行されているように感じられるわけですね。
しかし、個々のプログラムでも多くの処理を継続してこなしている機能と、殆どたまにしか使われない機能があります。そこで、一つのプロセス内で更に「スレッド(thread)」という単位を作って処理を振り分けると、そのプログラム(のプロセス)が処理される順番となったときに処理してほしいスレッドを優先して処理してもらえます。
プロセスは OS が最初から認識できる単位です。アプリケーションを管理している自分自身のプロセスを認識できない OS など、危なくて使い物になりません(笑。他方、スレッドはアプリケーションの方で「スレッド単位で処理されてもいいように」プログラミングされていなければなりません。二つの処理だけを実行するプログラムがあるとき、二つの処理内容を上から下へ順番に書いただけでは二つのスレッドになりません。したがって、しばしば「マルチスレッド」という言葉を OS について聞きますが、その真価はアプリケーションの側にも問われているわけです。
LiteStep では、LoadModule 宣言でモジュールを指定した後に "threaded"(スレッドとして扱ってくれたまへ)というオプションを付けます。これにより、個々のスレッドは OS から別の処理内容として扱われるので、動作がうまく行かない(しかし LiteStep のシステム全体に影響を及ぼすほどのエラーは起こさない)モジュールがあっても、他のモジュールは特に影響を受けずに使えるというわけです。
しかし、問題なく動いているテーマでモジュールをスレッド化しても特に変化はありませんし、パフォーマンスが劇的に向上するわけでもありません。逆にスレッド化したことで LiteStep の処理に影響が出ることもありますから、単に "threaded" を書いておけばいいとうわけでもないようです。
いい訳語も定着した訳語もありませんが、要するに「そのままでいろ」ということです(笑。元の意味は、冬のコートとかで「輪っかを引っ掛けて止めるボタンに付いてる、たいては木製の棒みたいなやつ」です・・・何となく分かる? LiteStep では、モジュールの画像表示を ![...]Show, ![...]Hide といった個別の bang コマンドで切り替えるだけでなく、![...]Toggle というコマンドで「そのコマンドを実行するたびに show - hide を切り替える」ことができます。
よく、何かの制御室にあるパネルで上下に動かして On - Off を切り替えるスイッチがあるでしょう。あれを "toggle switch" とも言うそうです。
Windows で使われている透過効果には二つの種類があります。一つは Windows 2000 以前のヴァージョンにも有効な透過色の適用で、透過色を指定すると壁紙などの背景が透けるようになります。デスクトップ・アイコンに同じような処理を施すユーティリティもありますね。
もう一つの透過効果は「透明度」を設定できます。従って、その色を表示するかしないかだけでなく、何パーセントだけ透明にするかという細かい設定が可能です。また、アルファブレンディングと呼ばれる効果を使って全ての色に透明度を設定できるため、特に透過色を一つだけ設定する必要もありません。ただし、このような効果は Windows 2000 以降の Windows で使われている「拡張 API」を利用しているため、Windows 98 や Windows Me では利用できません。
LiteStep やサードパーティ・モジュールの開発は海外が中心となっているため、Windows 用のファイルを圧縮するときは殆どが ZIP フォーマットとなります。ZIP 形式で圧縮されたファイルの集まりを「アーカイブ」もしくは「書庫」と呼び、解凍には ZIP 形式へ対応している「アーカイバ」あるいは「解凍ソフト」と呼ばれるソフトウェアが必要になります。海外で最もよく使われているアーカイバは、WINZIP でしょう。日本でも PC 雑誌の付録として試用版の WINZIP が配布されています。
とは言え、フリーウェアでも ZIP 形式に対応しているものは多いので(というか、いまどき ZIP に対応していない解凍ソフトなど殆どない)、UNZIP32.dll というライブラリを Windows のシステムフォルダ(98/Me 系なら WINDOWS\SYSTEM フォルダ、NT/2K/XP 系なら WINNT\SYSTEM32 フォルダ。なお、XP では Windows フォルダが WINDOWS になっている場合もある)へ入れておくとよいでしょう。
海外では ZIP フォーマットがふつうなので "unzip" という言葉が使われます。他にも "decompress" とか "unpack" といった言葉もよく使われていますが、意味は同じで「解凍する、展開する」ということです。但し、圧縮するときにフォルダの構造を記憶させていないときはアーカイブに入っているファイルが解凍した場所にぶちまけられてしまいます(笑。ですから、圧縮するときは「ディレクトリ構造をそのまま維持する」といった内容のオプションを有効にしておきましょう。また解凍するときも「ディ