まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:notes

こちらの続きです:
ノーツデータベースの設計変更履歴を git で管理する(1)

↑のブログエントリを書いた時点では未完成だったインポート機能が使えるようになったので、続きのエントリとして紹介します。

上述の記事内で紹介した dxl_export.vbs ツールでエクスポートした XML データを元の NSF ファイルにインポートするのがもう一つのファイルである dxl_import.vbs です。以下のようにして使います(XML ファイルはフルパス指定が必要な点に注意してください):
> c:\Windows\SysWOW64\CScript //nologo dxl_import.vbs C:\Users\username\dev_mydb.nsf\mydb.xml

成功すると指定した XML ファイルと同じフォルダ内に拡張子が .xml から .nsf になったノーツデータベースが復元されます。復元元のデータ(設計要素と文書)は XML ファイルです:
2023051601


復元されたデータベースをドミノデザイナーで開くと、設計要素も元の(dxl_exporter.vbs でエクスポートされる前の)状態で復元されているはずです:
2023051600


このツールの便利なところは XML データを git でバージョン管理できるという点にあります。つまり元のデータベースが変更される度に dxl_exporter.vbs を実行しておくことで、 git の履歴(ログ)を見て、必要に応じて過去のコミットに戻り(チェックアウトし)、過去の状態の NSF データベースに復元することもできるようになる、という点です。この dxl_importer.vbs が正しく動くようになったことでこちらの機能も動くようになりました。





(以下 2023/05/15 追記)
このブログエントリで紹介している DXL Import 機能は正しく動くようになりました。記録として残しておきますが、現状は問題なく動作します。
(以上 2023/05/15 追記)


自作ツール dxl.vbs を紹介する目的で先日こんなブログエントリを書きました:
ノーツデータベースの設計変更履歴を git で管理する

このツール(dxl_export.vbs)は HCL Notes のデータベースをテキスト(XML)化することで、本来はバイナリデータであるデータベースファイルの設計変更履歴(ちょっとカスタマイズするとデータも含めた変更履歴)を git で管理できるようにする、というものです。テキストデータになっていれば変更差分の履歴や、変更一回ごとに限らず任意の2つのタイミングでの変更差分を比較する、といったことも(git の機能として)可能になる、というものでした。

実はこの dxl.vbs にはもう1つ dxl_import.vbs というツールがあります。Export と Import ということで、なんとなく機能の想像がつくかもしれませんが「XML 化されたデータから Notes データベースを復元する」ためのものです。git で変更履歴を管理しつつ、どこかのタイミングで使っていた設計状態に git checkout して、その状態を作成した時のノーツデータベースを復元する、というためのものです。が、残念ながら現時点ではこちらは期待通りに動きません。その点に関する解説ブログエントリとして記載します。

もともとこのツールは LotusScript および Java の API として用意されている DXL Import/Export の機能を使って実装しています。ツールそのものは VBS で、いわゆる ActiveX/COM を使って NotesSession オブジェクトを生成し、そこからこれらの機能を呼び出すことで Export で XML 化し、Import で復元を実装しています。この Import 部分がどうも正しく動いていないように見えるのでした。

少し補足をすると、DXL Export を実行すると指定されたデータベースが XML 化されます。実はここにも一点問題があって、「データに日本語が含まれている場合、XML には encoding 指定のない(つまり UTF-8 )データが出力されるが、実際にはシフト JIS の日本語データが含まれる」というものです。この時点で XML データとしての不整合が生じてしまっています。そのため本ツール(dxl_export.vbs)では、この XML データを書きだす前に強制的に encoding="Shift_JIS" を追加してから出力することで不整合を回避しています。

で、改めて dxl_import.vbs ですが、現状ではこのツールを実行することでノーツデータベースファイル(.nsf ファイル)を(日本語文字列含めて)復元することまではできています(※)。が、この復元結果をノーツクライアントから開こうとするとこのようなエラーが発生してしまって正しく開くことができないのでした:
20230508

↑左のアイコンがある方が元のデータベースで、これを dxl_export してから dxl_import したものが右のアイコンがない方。アイコンは復元できていないが、(日本語の)データベースタイトルは復元できている。でも開くことはできない。

※厳密には dxl_import.vbs 実行時に以下のようなエラーが発生しています。エラーにはなるけど .nsf ファイルは出力されている、という状況です:
2023051402


なお、この復元された(?)ノーツファイルを Domino Designer で開くと、フォームなどの設計要素が空になっています。という意味ではやはり DXL Import に失敗しているとみるべきなのだと思っています:
2023051401


XML の encoding 設定を勝手に書き換えたのがよくなかったのか、、と思ってやり直してみても結果は同じ。というわけで DXL Import がおかしいのか、あるいはその前の DXL Export の時点で何か間違っているのか、その両方なのか・・・ この辺りはもう手が出せないのでこれ以上の対応が難しいのですが、ここがなんとかなればこの1対のツールとしても完成すると思っています。


ノーツのデータベース(アプリケーション)はノーツクライアントやドミノサーバーが無いと開くことができないため、内容を確認したりデータ文書を追加したり、あるいはデータベースそのものの設計を変更したりする際には、原則的にこれらがセットアップ済みの環境が必要です。

特に設計に変更を加える場合、ドミノデザイナーという専用クライアントアプリが必要になります。Eclipse RCP をベースとしたツールとして提供されていますが、データベースそのものがバイナリファイルになっていることもあり、(例えば git などを利用してソースコードの変更履歴管理をする場合と比較して)設計の変更履歴を管理することが難しいのでした。

そんな背景の中、「じゃあノーツデータベースの変更履歴を git で管理できるようにならないか」というアイデアネタを思いつき、実現可能性のありそうな方法を見つけて試しに作ってみました。まだ理想形には至っていないのですが、当初の目的であった「git による変更履歴管理」はできそうな目途が立っているので公開します:
https://github.com/dotnsf/dxl.vbs

で、↑このページ内でも(英語で)使い方の説明をしているのですが、このブログエントリでは図を含めて日本語で紹介します。


【前提条件】
上記コードは MIT ライセンスのオープンソースとして公開しますが、正しく動作させる上での前提条件がいくつかあります:
  • Windows 64bit 環境(32bit でも多分動くが未検証)
  • Windows 版 git がインストール済み
  • ノーツがセットアップ済み
  • 対象データベースに対する設計者以上の権限がある

前提条件について補足します。まずこのツール自体が VBScript で出来ています。実現可能性や使っていただく上での条件をいろいろ考慮した結果、最もハードルが低そうなものを選択しました(これはこれで文字コードが Shift-JIS になってしまう制約があって苦労しました。が、他よりはマシだったと思っています)。この VBScript を動かすため Windows 環境が必要となります。変更管理ツールとしての git も Windows 環境下で動かす必要があります※。

※ WSL を併用している場合であれば、このツールを使って出力した結果のフォルダに WSL のターミナルを移動して WSL の git を使う、ということができないわけではありません。ただこのツール自体が Windows の CLI で動くものなので、コマンドプロンプトを起動して、ツールを実行して、実行結果をそのまま git で管理する、、という使い方が便利で、その場合は(WSL の git ではなく)Windows 環境で動く git 環境が必要です。 また Windows 版で GUI を提供する git もあるようですが、今回のツールを使う場合はコミット ID を指定しての差分比較などを行えることが便利だと思っていて、そういった操作までができる GUI 版 git であればいいのですが、私が軽く調べた限りではそこまでの GUI を持ったものがなかったので、CLI 版の利用をお勧めします。

また「ノーツが不要」というわけではありません。ツールを使って設計をテキストにエクスポートした後は git だけで使えますが、ツール利用時にはノーツが必要で、かつ対象となるデータベースに対して設計者権限または管理者権限がないと設計内容にアクセスできません。設計変更履歴を管理しようとすると何回もこのツールを利用することになると思っていますが、仮に「1回だけ利用して中身をテキスト化する」という目的であったとしても、実行時にはセットアップ済みノーツ環境が必要です。


【ツールの使い方】
ツールは Github のこのリポジトリで公開しています。git clone するか、zip download で README.md ごと取得してください:
https://github.com/dotnsf/dxl.vbs


リポジトリには dxl_export.vbs と dxl_import.vbs の2つのツールが含まれています。が、dxl_import.vbs はまだ開発途中で、期待通りの挙動は実現できていないので、2023年5月の現時点では実質的に dxl_export.vbs だけがリリースされている、とご理解ください。

ツールはコマンドラインツールなので、実行する上では Windows のコマンドプロンプトを使います(管理者権限は不要です)。コマンドプロンプトを開き、dxl_export.vbs を保存したフォルダに移動します:
2023051101


ここで CScript.exe (VBScript のコマンド)を実行して del_export.vbs を動かします。パラメータの最後に設計変更履歴を管理したいノーツデータベースを相対パスで指定します(下の例だと dev/mydb.nsf というデータベースを指定しています)。注意点として CScript.exe は必ず指定のフルパス(c:\\Windows\\SysWOW64\\CScript)を指定して実行する必要があります(64bit Windows ではパスを指定せずに CScript を実行すると 32bit 版の VBScript が実行されてしまいます。64bit 版 Windows では 64bit 版 VBScript を実行するためにこのフルパスを指定して実行してください:
> c:\Windows\SysWOW64\CScript //nologo dxl_export.vbs dev/mydb.nsf

このようなダイアログが表示された場合は、表示されているノーツ ID のパスワードを入力してください(一度入力しておくと次回からしばらくパスワードなしで使えるはずです):
2023051001


dxl_export.vbs が正しく実行されると以下のような出力になります(この例だと dev_mydb.nsf/mydb.xml にエクスポート結果が出力されていることになります):
2023051001


この出力された XML がパラメータで指定したデータベースファイル(dev/mydb.nsf)の設計情報を DXL(Domino XML Language) というフォーマットで出力したファイルになっています:
2023051001


本ツールでは、このバイナリデータベースが XML でテキスト化された状態を git でコミットすることを想定しています。具体的にはこんな感じ:
> git add dev_mydb.nsf\mydb.xml

> git commit -m "first comment"

これでこの状態の設計情報が(テキスト形式で)git に格納され、コミットされました。git はコミット単位で履歴を追ったり、比較できるようになるツールなので、まずはその履歴の1つが記録された状態になりました。

その後、このノーツデータベースになんらかの設計変更が加わったとします。例えば "myForm" という名前のフォーム要素を新たに追加したとします:
2023051101


何らかの設計変更が加わった状態で、再度この dxl_export.vbs ツールを実行します(コマンド自体は最初に実行したものと全く同じです):
> c:\Windows\SysWOW64\CScript //nologo dxl_export.vbs dev/mydb.nsf

するとこの時点での設計情報が dev_mydb.nsf\\mydb.xml ファイルに記録(正確には上書き)されます。この結果をやはり同様に git でコミットします:
> git add dev_mydb.nsf\mydb.xml

> git commit -m "myForm added"

コミットの履歴は "git log" で確認することができます。↓の例では1回目の "first commit" というコメントの付いたコミットと、2回目の "myForm added" というコメントのついたコミットの2つを確認することができます:
$ git log

2023051102


2つのコミットログを並べて "git diff" を実行すると、コミット間の差分を表示することができます(以下の例では "myForm" に相当する設計要素が追加されたことがわかります:
$ git diff (変更前のコミットID) (変更後のコミットID)

2023051103


同様にしてデータベースに設計を加え、ツールを使って XML ファイルにエクスポートして、git でコミットし、git diff で比較することができます。以下の例では LotusScript プログラムの内容が表示できていることわかり、そのプログラムに後からコメントを追加している様子がコミット間比較によって視覚化されています:
2023051104


このように、
・データベースの設計を変更
・dxl_export.vbs ツールを実行
・git で差分をコミット
を繰り返すことで、バイナリデータであるノーツデータベースの設計変更履歴を git で管理することができるようになります。

(2023/05/12 追記 裏技の紹介)
dxl_export.vbs は VBScript なのでテキストファイルです。テキストエディタで開くことでカスタマイズもできます。

例えば 76 行目の
nc.SelectDocuments = selDocs           'Documents

となっている部分。これは「(データベースからエクスポートする要素として)各文書データは対象外とする」ことを指定しています。なので dxl_export.vbs をそのまま使った場合、設計要素のみが対象となって、文書データはエクスポート対象外となります。

ここを、
nc.SelectDocuments = True           'Documents

と無理やり変更して保存すると、文書データもエクスポート対象に含まれるようになります(ただし文書データも含めてエクスポートする場合はメモリ不足のエラーが発生する確率が高くなります)。テキストファイルとして読める形でアーカイブしておきたい場合などに使ってください。


(2023/05/16 追記)
続きはこちらです:
ノーツデータベースの設計変更履歴を git で管理する(2)


facebook に URL を含めて投稿すると、そこは自動的にリンクになり、クリックすると指定された URL ページを開くことができます。ここまでは当たり前の話:
2020080206


2020080207


このリンク先の URL は正確には元の URL とは少し異なります。というのは(おそらく追跡目的で)元の URL に fbclid=XXXXXXXX というパラメータが付与されたURL がリンク先になります(XXXXXXXX 部分はその時によって異なるランダムな文字列です)。このパラメータはリンク先ではほとんどのケースで無視されるので実質的には何の違いも生じずに期待通りのページが開きます:
2020080208


さて、問題はこの facebook の仕様が期待通りの結果にならないケースがあるということです。その典型がウェブ上に公開されたノーツの各種ヘルプデータベースのページです。例えば bcom.com 様が公開している Lotus Domino Designer 8.5 のデザイナーヘルプは以下の URL で開きます:
https://www.bcom.co.jp/help/help85_designer.nsf/Main?OpenFrameSet

2020080209



※勘のいい人はこの時点で気づいているかもしれませんが、↑実はこの URL は少し特殊なフォーマットになっています。"?" のあとに URL パラメータとして "OpenFrameSet" が付与されています。が、一般的には URL パラメータは "key=value" という形になっているもので、この URL は key だけが指定された形になっています。とはいえ、これで正しく動くんですけど。。


さて、問題は上記のようなおかしな URL を facebook に貼ったときのリンクの挙動です。仕様的には fbclid=XXXXXXXX というパラメータが追加され・・・るはずなんですが、元の URL が少しおかしなフォーマットになっているせいか期待通りの形(https://www.bcom.co.jp/help/help85_designer.nsf/Main?OpenFrameSet&fbclid=XXXXXXXX)になってくれません。OpenFrameSet の直前の "?" がなぜか "!" に変換されて、https://www.bcom.co.jp/help/help85_designer.nsf/Main!OpenFrameSet?fbclid=XXXXXXXX という URL が facebook からリンクされます。そしてこのリンク先を開くとエラーとなってしまうのでした:
2020080201


さて普通にヘルプのページを facebook に貼っただけではリンク先がエラーになってしまう事実がわかりました。ではそこまで理解した上で該当の URL を facebook に正しく貼るにはどのようにすればいいでしょうか?

実は単純な解決方法があります。もともとのおかしな URL は key=value の key 部分だけが指定されているものだったので、無理やり value 部分を足してフォーマットしては矛盾のない形する方法で解決できそうでした。具体的には https://www.bcom.co.jp/help/help85_designer.nsf/Main?OpenFrameset=1 という URL を指定して facebook に貼る、という方法です。

こうすると facebook からのリンク先は https://www.bcom.co.jp/help/help85_designer.nsf/Main?OpenFrameset=1&fbclid=XXXXXXXX という矛盾のないフォーマットになり、この URL であれば問題なく開くことができるようでした:
2020080202



ノーツの各種ヘルプファイル以外にこのようなフォーマットの URL を使うケースがあるのか、また facebook 以外でこのような(パラメータ自動付与による)不都合が生じるサービスがあるのかどうかもよくわかっていないのですが、おそらくここで紹介したのと同様の方法で回避できると思っています。

最近マイブームになっている「『あつまれ どうぶつの森(以下『あつ森』)』のマイデザイン」ネタです。いままではエンターテイメント色が濃い内容でしたが、ちょっとだけ業務に寄せてみました(ほんのちょっとだけ)。


『あつ森』の「マイデザイン」は 32x32 のピクセルデータになっています:
EYXVHfAUwAAz0tb


このサイズはノーツ/ドミノのデータベースアイコン(以下『DBアイコン』)と同じです:
2020061500


・・・ということは!! というわけで(?)インポートツールを作ってみました。データが流れるロジックとしてはこんな感じ:
  1. ノーツ/ドミノのデータベース(サーバーとファイルパス)を指定
  2. 指定データベースからアイコン情報を取り出す
  3. 取り出したアイコン情報を『あつ森』のマイデザイン情報に変換
  4. 変換したマイデザイン情報を QR コード化して画面に表示
  5. Nintendo Switch Online アプリで QR コードを読み取り
  6. 『あつ森』からマイデザインにダウンロード

このうち4以降の部分は過去のブログで紹介したものと同じですが、1~3部分が今回挑戦した部分です。内容が内容ということもあってググってもサンプルコードや役立ちそうな情報が見つからず、ほぼ独自実装でした。

で、この1~3部分を実現するウェブアプリケーションを作ったわけですが、そのシステム構成はこのようになります:
2020061500


ご覧のように2つのシステム(赤字部分2つでツールとして成立)から成り立っています。理想を言えば①の Domino Servlet(Java Servlet)のみで QR コードを生成できればよかったのですが、現時点では実現できていません(理由は後述)。Java Servlet のみで実現できなかった部分を補足する②のアプリケーション・サービスを別途足すことで実現しています。


作ったシステムはこちらです。ソースコード含めて MIT ライセンスで公開しています:
https://github.com/dotnsf/nsficon2qr


以下、このシステムのセットアップ方法です。ドミノサーバー環境がある方で『あつ森』ユーザーの方(加えて Nintendo Switch Online 加入済みの方)はぜひ試してみてください。ちなみに自分は CentOS 7.8 上の Domino v10.0.1 で動作確認しています。


まず上記リポジトリを git clone するか zip ダウンロード&展開して、nsficon2qr プロジェクトソースコード一式を手元に用意します。このプロジェクトフォルダには java フォルダと node フォルダが含まれており、それぞれ上述の①、②システムを構成するパーツになっています:
2020061501


では順にセットアップしていきます。まずは①ですが、こちらは Domino 環境側にも事前準備が必要です。管理者 ID で Domino サーバーに接続して Domino ディレクトリのサーバー文書を開きます。そして "Internet Protocols" タブの "Domino Web Engine" を選び、その中の "Java Servlets" カテゴリー内を以下のように設定して保存し、サーバーを再起動します:
  • Java Servlet Support : "Domino Servlet Manager" を選択
  • Servlet URL path : "/servlet" と入力※
  • Class path : "domino/servlet" と入力※

2020061502

※これらの設定をすることでデータディレクトリ(CentOS 版だと /local/notesdata)以下の domino/servlet というフォルダの中に存在しているサーブレットのクラスファイル(例えば a.class)を "/servlet/a" という URL パスで指定して実行できることになります。

加えて、Class path に指定したフォルダ(この例だと /local/notesdata/domino/servlet)はデフォルト状態では存在していないため、このフォルダを作成しておきます:
$ sudo mkdir -p /local/notesdata/domino/servlet

$ sudo chown notes.notes /local/notesdata/domino/servlet


これで Domino Servlet Engine が動くようになりました。改めて github からダウンロードした nsficon2qr プロジェクトを開き、java フォルダ内の nsficon2qr.class ファイルをサーブレットフォルダ(上述の例であれば /local/notesdata/domino/servlet/)にコピーします:
$ cp nsficon2qr.class /local/notesdata/domino/servlet

$ chmod 755 /local/notesdata/domino/servlet/nsficon2qr.class

そして、Domino サーバーコンソールから HTTP タスクを再起動します:
> tell http restart


これで①部分のセットアップは完了です。続いて②部分もセットアップします。なお ②は Domino と同じシステム上に作ってもいいですし、①の Domino サーバーに接続可能な別のシステム上に構築しても構いません。動作確認目的であれば、 localhost (つまり自分の PC )上であっても構いません。

②を構築する環境上に Node.js 環境を構築します。リンク先を参照して、各自のシステムに合わせて最新モジュールをインストールしてください(V10 以上であれば動くはず)。

次に node/settings.js ファイルをテキストエディタで編集します。実質1行だけのファイルですが、この中で定義されている exports.servlet_url の値が①で用意したサーブレットにアクセスするための URL となるように編集して(要するに IP アドレス部を変え、必要であればポート番号を追加して)保存します:
exports.servlet_url = 'http://192.168.xx.xx/servlet/nsficon2qr';

その後、ターミナル(コマンドプロンプト)を開いて node/ フォルダに移り、以下のコマンドを実行して②のアプリケーションを起動します:
$ cd node

$ npm install

$ node app

これで②も準備完了です。ウェブブラウザで②が動いているシステム(自システムであれば localhost)の 8080 番ポートにアクセスしてください。以下のような画面になればセットアップは成功です:
2020061503


実際に2つのデータベースを使って動作確認した様子を紹介します。以下ではこの2つのデータベースをマイデザイン化しています:
2020061509


まずは "Node API Demo" というタイトルのデータベースです。こちらはアプリケーションアイコンが設定されているデータベースです:
2020061504


ちなみにもう1つの "デフォルトアイコン" というタイトルのデータベースではアプリケーションアイコンは設定されておらず、クラシカルアイコンが表示されています。こちらも後で試します:
2020061505


まずは前者のデータベースをマイデザイン化してみましょう。②のアプリケーションにアクセスして、Domino サーバーから見たデータベースファイルを指定します。サーブレットが動いている Domino サーバー上のデータベースを対象とする場合であれば "Domino Server" 欄は空のままとなります。また "FilePath" 欄はデータベースファイルのパスを指定します(通常のデータベース指定方法と同じです)。なおこの機能はサーブレットが動いているサーバーの ID を使って動くため、この ID でデータベースの設計要素にアクセスできる権限が必要です。最後に "NSFICON2QR" と書かれた青いボタンをクリックします:
2020061506


データベース容量や複雑さによってパフォーマンスが変わりますが、数秒で解析が終わり、QR コードが画面内に表示されます:
2020061507


この QR コードをスマホにインストールした Nintendo Switch Online アプリケーションのタヌポータル画面から読み取ります。この QR コードを読み取る箇所から先の手順はこちらで紹介した手順と全く同じなので、必要に応じてこちら(の後半部分)も参照ください。

タヌポータルで読み取って保存した後に Nintendo Switch の『あつ森』を起動し、マイデザインからダウンロードを試みると、QR コードで読み取ったデザインが見つかります。「オッケー!」を選択することで『あつ森』ゲーム内で利用することができるようになります:
EaiWUQ6U8AAQsr2


"Node API Demo" という、データベースタイトルと同じ名前のマイデザインが、アプリケーションアイコンをインポートした形でダウンロードできました:
EaiWUROU0AI6-dL


ダウンロードしたマイデザインを地面の模様として貼り付けてみました。これ以外にアバターのトップスとして身につけたりすることもできます:
EaiWURXUEAAq_wq



同様にしてアプリケーションアイコンのない(クラシカルアイコンだけの)データベースも指定して、QR コードを生成してみました。これもスマホの Nintendo Switch Online アプリ内タヌポータルで読み取って、『あつ森』内にダウンロードできます:
2020061508


クラシカルアイコンのマイデザインも取り込むことができました:
EaiWUQ4UYAADIbh


(注 ↑よく見るとクラシカルアイコンを取り込んだ結果の左右が反転していました。現在のソースコードでは修正済みです)


あらためて元のデータベースアイコンと見比べてみます。ちゃんとエクスポートできていますね:
2020061500




以下に現時点での制限事項などをメモしておきます。

まず、上述の「本来はサーブレットのみで実現したがったができなかった」点について。最終的に表示する QR コード(の画像)をサーブレットの実行結果として返すことができるのが自然だし、理想的な挙動だと思っています。一方でこの『あつ森』マイデザイン用の QR コードは(URL などの文字列ではなく)バイナリ配列データを示す QR コードとなっていて、その意味でも少し特殊な仕様となっています。Java で利用できる QR コード生成ライブラリは有名な ZXing をはじめいくつかありますが、このバイナリ配列データを示す QR コードを生成可能な Java ライブラリを見つけることができなかったため、理想的な挙動を断念したという経緯があります(②がデータ入力部分と QR コード生成部分を担当しています)。もしどなたかバイナリ配列の QR コードを生成可能な Java ライブラリをご存知であれば改良に挑戦したいのでぜひ教えてください。

次にマイデザイン化するアイコンについて。上述のように1つのノーツデータベースには最大2つのアイコンが定義されています:
2020061504


これはノーツ v8.5.2 からの新仕様で、それ以前は特定のカラーパレットから選択した16色(+透明な背景色)だけが利用できるもの(以降「クラシカルアイコン」と呼びます)でした:
2020061500


v8.5.2 からは 32x32 のサイズであれば各種画像ファイルを指定して取り込むことができるようになりました(以降、こちらを「アプリケーションアイコン」と呼びます)。実際にワークスペースなどに表示されるアイコンは
 ・アプリケーションアイコンが設定されている場合はアプリケーションアイコン
 ・アプリケーションアイコンが設定されていない場合はクラシカルアイコン
  (クラシカルアイコンにはデフォルト画像が設定されている)
のように判断されて表示されます:
2020061509


このアプリケーションでも同様の判断基準でアイコン情報を取り出してマイデザイン化しています。ただここでマイデザイン特有のカラーパレットの問題が生じます。

簡単に説明すると、『あつ森』マイデザインに利用できる色は自由に選べるわけではなく、特定の 159 色から選択する必要があります。また1つのマイデザインの中で最大15色(+背景色)までしか選ぶことができない、という制約があります。

一方、ノーツアイコンですが、クラシカルアイコンの場合は16色から選択、アプリケーションアイコンの場合はより自由度高く利用できる、という違いがあります。

今回、このツールを作るにあたり、このカラーパレットの違いを吸収する必要がありました。以下のような仕様にしています:
・背景色は強制的に白
・アプリケーションアイコンの場合はカラーパレット内の利用頻度の高い15色に減色
・クラシカルアイコンの場合は2つの灰色を同一視する形で15色に減色
2020061500


これらの仕様の違いによって、ノーツデータベースアイコンが 100% マイデザインで再現できるわけではない、という点をご了承ください。




このページのトップヘ