ラベル Linux の投稿を表示しています。 すべての投稿を表示
ラベル Linux の投稿を表示しています。 すべての投稿を表示

ImageMagickで画像変換に失敗する場合に行うリソース上限設定

ImageMagickでPNGをJPGに変換しようとしたところ、 エラーが発生。

 


使用コマンド:

`find *.png | xargs -I{} convert "{}" "{}.jpg"` 

 エラーメッセージ:

```
convert-im6.q16: no images defined `Shinden144_Camera.FreeTop-fs8.png.jpg' @ error/convert.c/ConvertImageCommand/3229.
```


エラーメッセージは原因を指しておらず、またコマンドのファイルパスやオプションによるものではなく、原因はリソース不足でした。

PCの性能ではなく、ImageMagickの設定上のリソース上限です。

10000*10000pxを超えるようなサイズの大きい画像をImageMagickで変換するには、ImageMagickのリソース上限Upが必要となります。


Ubuntu24.04の場合のパスは次の通り。

`sudo vim /etc/ImageMagick-6/policy.xml`

次のように上限変更してリソース使用量を増やしました。

```
<policy domain="resource" name="memory" value="1024MiB"/>
<policy domain="resource" name="map" value="1024MiB"/>
<policy domain="resource" name="width" value="64KP"/>
<policy domain="resource" name="height" value="64KP"/>
<policy domain="resource" name="area" value="512MP"/>
<policy domain="resource" name="disk" value="4GiB"/>
```




参考:
http://www.imagemagick.org/discourse-server/viewtopic.php?t=34044


[クロス本草稿]ロギング


本文章は、技術書典5にて[project daisy bell]( https://twitter.com/MNukazawa )がリリースする予定の、クロスプラットホーム・デスクトップアプリケーション・GUIフレームワーク・クロスレビュー本(仮)(以下、クロス本)の一部の草稿です。
クロス本は、筆者のGTK/Qt/Electronの経験と知見について扱います。具体的な解説書というより技術エッセイです。
本文章には、校正前の文章・記憶により記述し未確認の内容・雑なmarkdown風紀法・張ってないURLリンク、などがあります。



# ロギング

本物のデスクトップアプリケーションは、バグレポートに添付して原因を解析可能な、本物のデバッグログ(動作ログ)が出力されるべきである。
デバッグログは、アプリケーションの開発中・ユーザ環境での実運用中の両方で、常に出力され続けなければならない。
本章では、デスクトップアプリケーションからのデバッグログのファイル書き出しについて扱う。
開発中のデバッグ手法は基本的には開発環境の章で扱うが、本章で扱う動作ログも無関係ではない。



GTKにはデバッグログのための機構はない。
QtにはデバッグログのためのqDebug()関数群が用意されている。
Electronではconsole.log()関数群を用いる。
筆者は、Electronでは動作ログのファイル書き出しを行っていないため、それは扱わない。
本章は、GTK,Qt,Electron固有のテクニックと言うより、C,C++での文字列操作テクニックや、筆者の方針が多い内容になっている。

デスクトップアプリケーションでのロギングは下記が参考になる。
[Joel on Software やさしいバグトラッキング]( http://local.joelonsoftware.com/wiki/やさしいバグトラッキング )
[Joel on Software ユーザからクラッシュレポートを自動的に取得する方法]( https://www.amazon.co.jp/Joel-Software-Spolsky/dp/4274066304 )
ただ、筆者は上記に書いてあるようなクラッシュレポートの収集はまだ実施できていない。

マルチプラットフォームを考えると、syslog()が使えない。

筆者は、以下の通りにしている。
- デバッグログはファイルに書き出す
- 標準出力,標準エラー出力からリダイレクトしてテキストファイルに書き出すようにする場合もある
- 基本的に、ログにASCII文字以外は使わない
- 上記を前提に、マルチプラットフォーム(Windows)で日本語出力した場合に起こるかもしれない文字化けは基本的に最初から諦める
- フォーマッティングに難があるため、"+"演算子やstreamによる文字列連結を避ける
- 必要があれば独自実装の簡易なログローテーション(削除や圧縮)を行う
- 起動時にアプリケーションのversion情報をdumpする(手動でインクリメントされるリリース番号だけでなく、gitのコミットハッシュ等をバイナリに織り込んで用いる)

streamについて。
フォーマッティングの文法が長くコードの読み書きが難しいため、極力使用を避けている。

ログローテーションについて。
ログファイル名に起動時刻を使用し、アプリケーション起動時に一週間より古い名前の付いたログファイルを検出して、それらをzipするコマンドを叩く、という実装を行った。
なお、zip圧縮はアーカイブに後からファイルを追加していくことができる。
必要なければzip圧縮でなく単に削除するようにすればよい。
Windowsでは標準コマンドが機能不足であったため、[7-Zip コマンドラインバージョン(7za.exe)]( https://sevenzip.osdn.jp/download.html )をバイナリに添付して用いた。
Linuxでは標準のzipコマンドを呼び出せば用が足りる。
MacOSXでは行っていないが、たぶんLinuxと同じ方法で行ける。

アプリケーションのversion情報について。
過去にはビルド日時も入れていたが、これはビルド毎にバイナリハッシュが変わるだけで意味はないため、最近は行っていない。
gitコミットハッシュを付与する際、未commitな変更がないか確認して存在すればその旨("-develop"など)を付与するようにしている。
[vecterion/version.sh]( https://github.com/MichinariNukazawa/vecterion_vge/blob/master/version.sh )
一部抜粋
```bash
# repository
GIT_HASH=$(git log --pretty=format:'%h' -n 1)
GIT_BRANCH=$(git branch | awk '/^\*/ { printf $2 }')
GIT_DATETIME=$(git log --date=iso --pretty=format:"%ad" -n 1)
## @todo can't check to unstaging new file.
GIT_STATUS_SHORT=$(git diff --stat | tail -1)
```
が、gitで未コミットファイルの十分な判定が未解決の問題となっている。
(未ステージングな新しいファイルが存在する場合にそれを検出する良い方法が見つかっていない。)
また、この方法はQt(QtCreator)では、qmakeファイル(.pro)に組み込むことが難しい。
(QtCreatorから外部のMakefileを呼び出すようにしたら、Makefileを呼び出すだけでヌルビルドに4秒余分にかかるようになってしまった)

## GTK

GTKには、GTKライブラリ側のデバッグオプションがあるが、筆者はこれを使ったことがない。
[Running and debugging GTK+ Applications]( https://developer.gnome.org/gtk3/stable/gtk-running.html )

内容が完全にC言語マクロテクニックになってしまうが、筆者は下記の関数マクロを使用している。
[vecterion/include/pv_error.h]( https://github.com/MichinariNukazawa/vecterion_vge/blob/master/include/pv_error.h )
一部抜粋
```c
#define pv_error(fmt, ...)  \
    fprintf(stderr, "error: %s()[%d]: "fmt"\n", __func__, __LINE__, ## __VA_ARGS__)
```
呼び出すマクロでレベルを指定する。
コード上の関数名と行番号を自動付与する。
vecterionでは、関数名があればファイル名が無くてもログの出力箇所が一意に特定できるため、ファイル名は付けていなかった。
(pc_critical()でexit()を呼んでいないのは、筆者が修行不足であったが故。ここはサパっと死ぬべきだった。)

なお、gtkにはg_strdup_new()というユーティリティ関数がある。
これはprintフォーマットで生成した文字列を必要なメモリを確保して入れて返す。確保するので開放する必要もある。

日本語出力した場合どうなっていたか覚えていないが、多分コマンドプロンプトは文字化けする。

## Qt

QtにはqDebug()関数群がある。
呼び出す関数でレベルを指定する。
環境により出力先を切り分けてくれるようなのだが、常にトラップしてファイル出力していたため、筆者は詳細を知らない。
トラップは[qInstallMessageHandler()]( http://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler )で行う。
[QDebug Class]( http://doc.qt.io/qt-5/qdebug.html )
[What's New in Qt 5.6.0: Logging to syslog and journald]( https://www.ics.com/blog/whats-new-qt-560-logging-syslog-and-journald )
ドキュメントに使用例でQRectをそのままストリームに渡しているところを見ると、QObjectを渡すだけで適切にデバッグ出力してくれるのかもしれない。

qDebug()はprintフォーマットでないため、16進数やゼロ埋めを使ったデバッグ出力が欲しい場合に苦労した。
(筆者はc++開発では一般にprintフォーマットが存在しないため苦労する。)
QStringにformatという似た機能があったため、なんとかやっていた。
下記使用例はうろ覚え。
```c++
qDebug(QString::format("%1,%2")
    .arg(hex_value, 16)
    .arg(space_fill_value, 3, 10, QChar(' ')))))
    // hex_valueは、続く第二引数が16進数表記を表す
    // space_fill_valueは、続く第二引数が桁数で第三引数が10進数表記を表す(!)、第四引数が埋めに使う文字
```

str.sprint()というメソッドがあり、筆者はこれも使っていた。
staticメンバではないため、QStringのオブジェクトを用意する必要がある。
下記使用例はうろ覚えだったため[stackoverflow]( https://stackoverflow.com/questions/4784155/how-to-format-a-qstring )より改変引用。
```c++
QString str;
qDebug(str.sprintf("%s %d", "string", 213));
```
2018年現在のQt5.11のドキュメントには無いため廃止された模様。

公式ドキュメントによると、古いversionのQtではqDebug()でprintフォーマットが使えた模様。
[Qt3.3 qDebug()]( http://doc.qt.io/archives/3.3/qapplication.html#qDebug )
2018年現在のQt5.11のドキュメントには無い使用法なので、廃止されたものと思われる。

アプリケーションversion番号のgit hasuについては、よく覚えていない。
確か最終的に.proファイルにコマンド出力をマクロ変数(?)に格納する記法があり、それを用いて「.proのマクロから、c++プリプロセッサマクロ置換」、で実装したような気がする。

Qtと関係ない、純粋なC++言語マクロテクニックの話になってしまうが、MicrosoftのMSDNマガジンで書かれたstd::stringをprintフォーマットに渡せるTempleteテクニックがあり、とても気に入っている。
[最新の C++ で Printf を使用する]( https://msdn.microsoft.com/ja-jp/magazine/dn913181.aspx )

日本語出力がどうなるかは覚えていないが、多分Qt(qDebug())側でハンドリングしているのではないかと思う。

## Electron

console.log()でする。
呼び出すメソッドでレベルを指定する。
デバッグコンソールでログレベルをverboseにしておかないとconsole.debug()が出力に表示されないので注意。

chromium由来のconsole.log()には、いくつかの拡張機能が用意されている。
(どうやら他ブラウザに無い場合があるようで、たぶん標準でない...といっても厳密にはECMAScript仕様にはconsole.log()関数は存在しないのではないかと思うが)
- オブジェクトだけを引数に入れるとコンソールでオブジェクトを展開できる
- 簡単なprintフォーマットが使える

lina_dictoではファイル出力等はしていない。
今後本格的なアプリを書いた場合の課題になっている、未解決問題。
たぶんnpmに選ぶのに困るほど多くのロギングパッケージがあるだろうと考えている。

[クロス本草稿]デプロイ







本文章は、技術書典5にて[project daisy bell]( https://twitter.com/MNukazawa )がリリースする予定の、クロスプラットホーム・デスクトップアプリケーション・GUIフレームワーク・クロスレビュー本(仮)(以下、クロス本)の一部の草稿です。
クロス本は、筆者のGTK/Qt/Electronの経験と知見について扱います。具体的な解説書というより技術エッセイです。
本文章には、校正前の文章・記憶により記述し未確認の内容・雑なmarkdown風紀法・張ってないURLリンク、などがあります。


# デプロイ

開発というコストの存在を忘れる開発者はいない。
が、空ウィンドウ表示までに環境構築という見えないハードルがあることはついわすれがちになる。
同じように、開発完了からアプリケーションをリリースするまでにも、デプロイという大きな見えないハードルが存在する。



gtk-rs(GTK/Rust)やPyQt(Qt/Python)を使用していないのは、デプロイ方法の十分な情報が期待できないことが大きい。
特に、実用的なアプリケーションは外部ライブラリを使う可能性が高く、アイコン画像などのその他のリソースを使う場合が多い。
それら必要な依存ファイルをインストーラに積載する方法が必要である。

筆者は、デプロイはバイナリと必要な依存ファイルをzipした配布パッケージを作成して行っている。
インストーラの作成はQtアプリケーションのWindows版でしかしたことがない。
また、MacOSXアプリケーションはGTK,Qtでの開発経験はなく、Electronでしかデプロイ・リリースをしたことがない。

MacOSX版でアプリケーション・アイコンを使う場合は別途アイコンの章を参照。

## GTK

GTKにはQtのような独自のインストーラ構築システムは無い。
GTKによる補助としては、インストーラ(配布パッケージ)には添付する必要のある設定ファイルがあり、その設定ファイルを構築するためのプログラムがGTKにより用意されている。

GTKアプリケーションのデプロイには、Windows版バイナリが公式から配布されていないという大きな問題がある。

GTKライブラリのビルドは、依存ライブラリ自体の数が多く、バージョン含む依存関係が複雑である。
集めるだけでも難しい。
GTKアプリケーションを作りたいだけのライト開発者(?)が挑戦すると挫折する危険性が高い。

GTK2の途中までは公式から配布されていた。
...のだが、2018年現在、確認したら`all-in-one bundle`のページがリンク切れしてる。
ただし直リンクからファイルはダウンロードできる。
GTK2ライブラリ公式配布[gtk+-bundle_2.24.10-20120208_win32.zip]( http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.24/gtk+-bundle_2.24.10-20120208_win32.zip )

筆者は、Windows版バイナリは[@niloufarjp 氏]( https://twitter.com/niloufarjp )の配布している野良ライブラリを使用している。

公式による[Download for Windows]( https://www.gtk.org/download/windows.php )
によると、他にmsysのpacmanにwindowsクロスビルドのバイナリがあるため、パッケージマネージャから取得するのが推奨の模様。
パッケージが展開された先からバイナリをコピーして集める方法でもWindows版が得られると思われる。

氏の野良ライブラリから配布パッケージを作るにあたって、
- 付属の設定ファイルを再構築する必要がある。
- フルパスになっている箇所を相対パスに置換する必要がある。
- ディレクトリ内のライブラリのバイナリから必要なものだけ抜き出す作業は基本的にトライアンドエラー。
と、わりと泥臭い。
`gschemas.compiled`,`loaders.cache`に対して、sedしたり、`bin\glib-compile-schemas.exe`,`gtk-update-icon-cache.exe`などを使ったり(詳細は忘れてしまった)。
アイコンキャッシュ周りだったと思うが、使い方の解説がなかったため、GTKのMLで質問したり、野良ライブラリを配布している[@niloufarjp 氏]( https://twitter.com/niloufarjp )に直接尋ねることになった。

Linux版は基本的にはリポジトリから取得すれば開発には足りる。
Ubuntuの場合、`sudo apt install libgtk-3-dev -y`

Windows:
GTK3アプリケーションのWindows版ビルドのデプロイは、圧縮ファイルにまとめるまではクロスコンパイラ等を用いることでWindowsを使用せずすべてLinux上で完結できる。
詳細は[vecterion_vge/deploy/packaging_win64.sh](  )を参考にするとよい。

Linux:
Linux版は作成しなかったのでやり方はわからない。
(Linux版は.debパッケージを作ろうとしていた記憶があったのだが勘違いだった模様。)

MacOSX:
MacOSX版は作成しなかったのでやり方はわからない。

## Qt

Qtには独自のインストーラ構築システムがある。
[Qt Installer Framework Manual]( http://doc.qt.io/qtinstallerframework/index.html )

筆者の経験では、これには、
- 依存ライブラリを収集するプログラム
- アプリケーションを含むディレクトリをインストーラにパッケージするプログラム
が用意されており、Windowsで使用してインストーラを構築したことがある。

Windows:
やり方は同人誌が出ている。
[理ろぐ インストーラを作ろう!]( https://booth.pm/ja/items/122098 )
日本語で貴重な情報が整理されているので必要になったら迷わず買うべき。
筆者は、この同人誌の前の版を購入した同僚が作ったインストーラ作成システムの、説明書を読みながらコマンドラインを叩いただけなので詳細は把握していない。
ただ当時のシステムは依存ライブラリを収集しきれていないようで、2つくらい手作業でコピーする必要があった。

Linux:
Windows版のQtアプリケーションではインストーラを作ったが、同じアプリケーションの、Linux版の配布パッケージをインストーラでない圧縮ファイルとして作成した。
当時のQt Installer FrameworkのLinux版がどうなっていたのかは記憶にない。筆者はlddを使って依存関係を見ながら、手作業でシステムから依存ライブラリ等を集めた。

MacOSX:
MacOSX版は作成しなかったのでやり方はわからない。

## Electron

Electron向けのパッケージングシステム、npmに4種類以上ある模様。
どれを使うのか悩むレベル。

公式ドキュメントでパッケージングを扱っているページ。
[Application Distribution]( https://electronjs.org/docs/tutorial/application-distribution )
[Application Packaging]( https://electronjs.org/docs/tutorial/application-packaging )

筆者は、
- Windows,MacOSXにelectron-packager
- Linuxにelectron-installer-debian
を使っているのだけれど、ドキュメントに記載のパッケージを見ていると[electron-builder]( https://github.com/electron-userland/electron-builder )良さそう。

Windows:
筆者は試していないが、Wineの存在もあってか、インストーラ作成まで作業をLinux上で完結できるらしい。

Linux:
debなどが作れる。
Linux以外の環境で作ったことはないけれど、Linuxのインストーラパッケージは大抵はただの圧縮フォルダなので、多分作れるのではないかと思う。

MacOSX:
きちんと案内していないパッケージシステムも多いけれど、どのパッケージシステムでも、MacOSX向けのインストーラはMacOSX以外では作成できない模様。
[electron-builder]( https://github.com/electron-userland/electron-builder/issues/3210 )もissueにそのような回答がある。
むしろ、MacOSXアプリケーションがLinux上でビルドできるのは衝撃的だった。
実際はダウンロードしてきたビルド済み実行ファイルからアプリケーション固有のファイルを読んでいるだけと思うが。

[クロス本草稿]未調査の項目


# 未調査の項目

本章は、クロスプラットホーム・デスクトップアプリケーションについて、わたしが使ったことのないテクノロジーについて書いている。
なので、他の章よりさらに現実乖離度が高いと思われる。
個人的な印象であることに留意しつつ、短く留めるよう努力する。


## その他のクロスプラットホームFW

クロスプラットホーム・アプリケーションFWはGTK/Qt/Electronだけではない。
ぱっと思いつくものとして、Java,C#,Unity,SPAがある。(これらがFWであるかはともかく)

### Java
JavaはGUIなデスクトップアプリケーションだけのものではないが。
joel氏が「宇宙人が見様見真似で作ったため味を付け忘れたUI、後に修正されたが」と語っていた奴。
<<joelonsoftware本へのリンク>>
Javaの機能は、クロスプラットホームGUIだけでない。

Javaの悪評について。
Javaが使われている環境ではプログラマの扱いが悪いという話が目につくし、Java自体も酷評されている印象がある。
特に恨みもないので擁護するようなことを書いておくことにする。
COBOLを置き換えて長期利用する安定したシステムにJavaが採用されるのは、エコシステムを含めたJava全体で見ればそのようなメリットがあるということだと思う。
Javaが持つ機能は、GC・VM・中間表現その他、当時から見たらどれも革新的な新テクノロジだったと思う。
Javaはそれらの新テクノロジを一度に商用システムに持ち込み一般化したすごいパイオニアだった。
そしてJavaは、商用化についてパイオニアになった。
同時に、パイオニアが犯すことを避けられないあらゆる失敗を抱え込んだのではないかと思う。
悪いことに、Javaは成功した本物の商用言語製品だった。後方互換性を捨てることはできないことは失敗を修正する機会がなかったことも意味する。
長生きすればするほど、Javaは10年前のよく知られた言語設計の失敗を今もそのまま抱えた言語として、悪評も固めていったのではないかと思う。

と、個人的にJava開発環境を悪く思ってはいないが、前述の通りプログラマには劣悪環境であるという話しか聞かない。
個人開発で採用する理由はないし、Java案件に関わらないで済ますためにも、Javaは使いたくない。

### C#
フォームデザイナとかあってすごく使いやすいJavaのようなものらしい。
Linuxでやるのが面倒くさそうなので採用したことはない。

### Unity
ゲーム用。
Qtと同じくモバイルアプリケーションを守備範囲に含む。
ユリアーモの文字割り当て変換(※)のWebサービスを作っていた時、競合がWebサービスをUnityでラップして、デスクトップアプリケーション版をリリースした。
[自家のWebサービス sisto_converter]( https://github.com/MichinariNukazawa/sisto_converter )
[競合のWebサービス EsperantoToJuliamoWithHTML5]( https://sugurunatsuno.github.io/EsperantoToJuliamoWithHTML5/ )
[競合のアプリケーション EsperantoToJuliamo]( https://twitter.com/fuyunosuguru/status/903929591122636800 )
モバイルやゲーム以外にも、Electronと同じ使い方で同じ範囲をカバーできるらしい。
Unityは言語として、C#とJavaScriptが使える。他にもあった気がする。

個人的には、Qtと同じくモバイルアプリケーションに傾注するであろうという予想とか、プロプライエタリであり無償版は起動時ロゴが出る、3D性能が必要なことはしない等の理由で、マルチプラットフォーム・デスクトップアプリケーションFW選択の際に真っ先に脱落する。

※
ユリアーモは「ことのはアムリラート」劇中に登場する架空の自然言語。
独自のアルファベットを用いる特徴があり、公式からフォントがリリースされている。
[『ことのはアムリラート』ユリアーモフォント配布 公式URL]( http://sukerasparo.com/sp004/font.html )
このフォントのアルファベットの割り当てが特殊であるため、一般に使われるラテン・アルファベットの割り当てを、公式の独自割り当てに変換するサービスが必要となる。

### Webアプリケーション(SPA等)
デスクトップアプリケーションから主役の座を奪い、現在はモバイルアプリケーションと覇権を争っている奴。
滅茶苦茶雑に言えば、ブラウザがあれば動くので、マルチプラットフォーム性が最強。
現実にはいろいろ面倒なところや弱点があり、決定打とはいえない。(このへん列挙は面倒だし、読者を含め私より詳しい人はいくらでもいるので書かない)

ぱっと作れてぱっと使う、家の外やモバイルで使う、軽いツールを作る場合はWebアプリとして実装することが多い。
前述の、ユリアーモの文字割り当て変換は軽いツールの例。

## 使用していないFWの機能

GTKは機能ヘルパ兼依存ライブラリの数が多く、Qtは分厚く範囲の広いクロスプラットホームレイヤであるためこちらも機能が多い。
Electronはわりと機能の少ない小さなアプリケーションを書いたつもりなので、最低限以上の機能は使わないようにしていた。
そのため、筆者が使用していない機能のほうがずっと多い。
そもそも網羅的な入門書を書くのではなく、本物のアプリケーションを書くためにGTK,Qt,Electronを使っているので、全機能を触っておく必要はない...。
(なので本書はこういう感じです。)

というわけで、使っていない機能の話はしておくべきかと思うので本章を書いた。

### Electron:自動アップデート・クラッシュレポート
githubのリリースページにインストーラを置いておくと勝手に認識して自動アップデートしてくれる、とかだと嬉しかったのだが、そういうわけでもない模様。
そもそもElectronを使って作ったlina_dictoはプラットフォーム毎にインストーラを作るのが面倒でzipでリリースしている。
現在はインストーラ形式での配布はしていないので、自動アップデートの前にインストーラ作成しなければ。

クラッシュレポートはJoel先生のブログ記事を読んでからぜひ実装したい機能で、Electronに搭載されていると聞いたときは狂喜乱舞したのだが、いかんせん作ったアプリケーションのユーザベースが少なすぎてコストに見合う気がしない...。

### Qt:QML
JSでアプリケーションを書くなら普通にブラウザアプリのほうがいいと思う...。

### Qt:Android/iOSのモバイルクロス開発
Androidアプリのリリース経験があるが、[lina_dicto for Android]( https://github.com/MichinariNukazawa/lina_dicto_for_android )はElectronで書いたlina_dictoをWebViewで移植して作ったので、QtのAndroid,iOSクロス開発機能は使用しなかった。
QtのAPIがカバーする範囲はよくわからないが、QtのAPIに無い機能については、プラットフォーム毎にネイティブコードを書くし、そういう書き方ができる、とのこと。
<取り消し線>Qtでモバイル開発していた周囲の人々は、iOS11対応で悲鳴を上げていた。</取り消し線>

### Qt:組み込み
死に体のデスクトップアプリケーションからQtが見つけ出した脱出先。
セットトップボックス等でHTMLが重いような場合を想定しているとのこと。
ターゲットによってはQt自体のクロスビルドから自前でする必要がある。
組み込みQtのサポートは販売ライセンスがデスクトップアプリケーション版と異なるという話が。

### GTK:マークアップ言語によるウィンドウ構造記述
QtはQtCreatorをフォームデザイナとしてポトペタするのが一番簡単であるためそれを使うことになるし、目diffを目patchする羽目にでも陥らない限りはQtのXMLを直接触る必要はない。
ElectronはHTMLを書くしかないので、マークアップを使う使わないという話にそもそもならない。
GTKの場合、QtCreator相当のフォームデザイナがクラッシュするような品質であり、マークアップを直接書くのはドキュメントが整備されていたとしても御免こうむるので、コードで直接UIを構築していた。
今はもう少しマシになっているといいなと思う。Windows版はバイナリ配布が無いかもしれないけれど。

### GTK/Qt:非ネイティブな言語バインディング
バインディング境界でバグが発生したら解決できなさそうだったので、生産性を犠牲にして、GTK,Qtではネイティブ言語なC言語,C++言語をそのまま使う選択をした。
また、バインディングはどうしてもネイティブ言語よりドキュメントの優先度が低く、ユーザが少ないこともあって、情報を集めることが難しい。
既にバインディングを使ってアプリケーションを書いてしまった場合や、公式が本当に一級市民扱いのサポートをしている場合以外には、おすすめしない。


[クロス本草稿]ドキュメント


本文章は、技術書典5にて[project daisy bell]( https://twitter.com/MNukazawa )がリリースする予定の、クロスプラットホーム・デスクトップアプリケーション・GUIフレームワーク・クロスレビュー本(仮)(以下、クロス本)の一部の草稿です。
クロス本は、筆者のGtk/Qt/electronの経験と知見について扱います。具体的な解説書というより技術エッセイです。
本文章には、校正前の文章・記憶により記述し未確認の内容・雑なmarkdown風紀法・張ってないURLリンク、などがあります。



# ドキュメント

公式ドキュメントのメンテナンスレベルは重要である。

最低限、APIマニュアルとクイックスタートマニュアルとサンプルコードが公式で欲しい。
サンプルコードは初心者状態で触るので、最低限の作業で完動するものであって欲しい。

公式ドキュメントとは別に、Stack OverflowのFAQ・有象無象のブログ記事(Qiita含む)・物理書籍等の、非公式な外部ドキュメントの充実度は気になるところである。
外部ドキュメントの充実度は、人気のバロメータでありフレームワークの将来性を測る指標として採用検討の際に気になるところである。
筆者は公式ドキュメントの他に、ブログ記事があればそちらも読む。

Gtk/Qt/Electronすべてにおいて、残念ながら物理書籍は母数が少なく、タイミングに恵まれないこともあり、筆者は今のところ縁がない。
書籍の内容は大抵、網羅性は高いがAPI解説が主で公式ドキュメントの日本語訳のような者が多く、実用に関するEffectiveな内容はまずない。

公式ドキュメントにおいて、「XXXについては書いてない」「XXXができない」と書いてあることはまずないので、そのへんは筆者の体感を書いた。
そういう時の筆者は、悪魔の証明になるが、APIマニュアルのページタイトルあたりを網羅して書いてないことを確認しつつ、Web上で同じ結論に到達した人が居なかったか確認している。

一応再度注意しておくと、以下に指摘している不備は、当時のもので現在は解決しているかもしれないし、そもそも十分探していないから見つかっていないだけかもしれない。
実際、開発と無関係に本書のために調べてみると、見たことのない新しい資料がわりと出てくる...。
(こんな同人誌出して大丈夫なのか筆者...本当に)

## Gtk

[GTK+ 3 Reference Manual]( https://developer.gnome.org/gtk3/ )
Gtk2とGtk3でドキュメントが分かれている。Gtk3はさらにversion毎にページが分けられている。
<<ここにスクリーンショット>> [GtkAlignment Widget]( https://developer.gnome.org/gtk3/3.22/GtkAlignment.html )


Gtk3バージョン内でのAPI変更(追加・削除ほか)はドキュメント中に記載され、必要に応じてURLリンクなどが追加される。

とても不思議なことに、何故か、Gtkのドキュメントを引くためだけのアプリケーションが存在する。
内容はWebから参照できるものと同じである。
<<ここにスクリーンショット>> [GTK-Doc, Devhelp]( https://wiki.gnome.org/Apps/Devhelp )

Devhelpという名前は名前空間汚染的(ex.Surface,Go言語)だと思う。

CSSについて十分なドキュメントは存在しない。(これについての文句はCSSの章で書くはず。)

配布パッケージの作り方については公式ドキュメントがない。
Gtk3自体がライブラリビルドだけでも依存関係の解決はユーザ側でできるという前提だが、実際にはライブラリ間のversion依存が複雑。
Gtk3ライブラリのビルドだけで挫折or満足してしまう可能性が高い...。
[参考:Gtk2-3野良ビルドをしている @niloufarjp 氏のtwitter]( https://twitter.com/niloufarjp )
以前からライブラリ以外に必要なものはあったが、Gtk3からはアイコンキャッシュ等、さらに複雑になった模様。
またGtk3以降もバージョンにより必要なものが微妙に異なるようで、野良の情報を集めてなんとかする必要がある。

### サンプルコード

アプリケーションサンプル集が、gtk-3-examplesというパッケージ名で、集約されたアプリケーションの形式で存在する。
Widgetの使用方法がメイン。
<<ここにスクリーンショット>>

問題点として、サンプルコードを単にコピペしただけでは動作するアプリケーションのコードにならない。
サンプルコードはmain部分が共通化されており、このmain部分が記載されていないため、探してきて補完しないと手元でサンプルコードをビルドしてみることができない。
(手元のGtkバージョンで同サンプルコードが有効か否か確認する等したい派の筆者は困る。)
また、サンプルコードはanjutaが生成するほど本格的でなくエラーチェックを真面目にしているわけでもないわりに、わかりやすく単純に書かれているわけでもなく、微妙に参考にしにくい。

### 外部ドキュメント

Qt,Electronと比べると、GtkについてはWeb上の情報は少ない。

非公式のドキュメントとして、
[GTK+/GNOMEによるGUIアプリケーションプログラミング (菅谷保之著)]( http://wiki.cis.iwate-u.ac.jp/~suzuki/Soft/GUI-Application-Programming-20070430.pdf )
がある。
なぜかWeb上で無償公開されている。
Gtk3になってAPIが多少変更されたが、これが扱っている範囲はGtk2,Gtk3の間であまり違いはないので十分参照できる。
筆者は一時期、USBメモリに開発環境と一緒に入れて持ち歩いていた。
今見ると、
[入門GTK+ (菅谷保之著)]( http://wiki.cis.iwate-u.ac.jp/~wiki/csd/docs/GTK-book-all.pdf )
というものがやはりWeb上に有り、こちらのほうが新しい?(といっても2012年だとのことだが)
CSS化前のドキュメントなのでCSS関連の内容はない。
Web上の断片情報が少ない一方で、これらのドキュメントに、主要なWidgetおよび基本的な機能が網羅されている。

物理書籍は、Gtk2時代の古い書籍しか存在しない。
物理書籍も販売されている「入門GTK+ (菅谷保之著)」を同人誌と言うのは無理がある。
同人誌でGtkを扱っているものを見た覚えがない。だから本書を書いたところもある。

### その他

救いとして、GtkにはMLがあり、疑問点は質問すれば大抵は数日中に回答がある。
[modal dialogに関するML上での質問]( https://mail.gnome.org/archives/gtk-app-devel-list/2017-June/msg00050.html )
さっき自分の質問タイトルでWeb検索したら引っかからなかったので、検索性に難があるのでは?

## Qt

[Qt Documentation]( http://doc.qt.io/qt-5/ )
Qtのversion毎にドキュメントが分かれているが番号が飛び飛びなので、どうやら長期サポート・メジャー変更あたりで区切っている模様。

QtもCSSの詳細なドキュメントは無いが、QtCreatorのフォームデザイナとCSS入力支援があるので多少マシである。

ARMボードへのクロスビルドに関する公式ガイドページとか無いの? (仕事でわりと面倒な目に遭った)

### サンプルコード

Qtのサンプルコード集はWebサイトに存在する。
QtCreatorからもサンプルにアクセスできる。
[List of Qt Examples]( http://doc.qt.io/qt-5/all-examples.html )
サンプル毎のスクリーンショットが用意されていることもあり、GtkのようなWidgetの使用方法というより、用途ごとのアプリケーションサンプルとしての色合いが強いように見える。
これはGUIツールキットとしてのGtkとクロスプラットホームFWとしてのQtの性質を反映しているところもあると思う。
プロジェクトのファイルが一通り揃っており、これはそのままビルドして実行できるプロジェクト一式なので、Gtkのサンプルコードよりも参考にしやすい。

### 外部ドキュメント

Gtkと比較すると、調べたときに扱っているページが多い。

Qtにはインストーラ作成の仕組みが用意されているが、これについての同人誌が出ている。
今見たらAmazonで取扱があった。
「インストーラーで配ろう! (理ろぐ) Kindle版」(URLは長くなってしまうため略)
技術書典などで見る。たぶんいつもの人が出しているのかなという気がする。

Qt4(QtC++)時代のものだが、オライリーから動物本が出ている。
また、Qt5になってからのQtQuick(QML)の物理本が出ている。

### その他

Qtには何故か専用のStack Overflowみたいなサイトがある。普通に検索に引っかかるので意識する必要はない。
筆者は幸い質問が必要になったことがないため、使ったことはない。

## Electron

[Electron Documentation]( https://electronjs.org/docs )

### サンプルコード
そんなものはない。
ドキュメント中にコード断片として存在する。
Gtk,QtよりさらにFWとしての性質が強い(テンプレートに埋め込む的な)性質が強いせい、またGUIサンプルはそのままHTMLページサンプルになってしまうからか。

### 外部ドキュメント

出たばかりなのもあり、わりと新しい情報が多い。
//ただ、良くも悪くもnodejs,npm周りのテクノロジなので、陳腐化も早いかも。

大きなアドバンテージとして、HTML/CSS/JSなのでSPAなどWebページ設計のための膨大な情報がそのままElectronで使える。
(これはよく言われていてその通り。)

物理書籍が出ている。
[Electronではじめるアプリ開発 ~JavaScript/HTML/CSSでデスクトップアプリを作ろう](URLは長くなってしまうので略)
筆者は本書を見つけた時点で、初心者向けのスタートガイドや網羅情報はすでに必要なくなっていたので購入しなかった。
自動アップデートやエラーレポートなどの踏み込んだ内容は書いてなかった。

技術書典などでちらほら見なくもない。

### その他

公式ドキュメントにプラットフォーム毎のBuild Instructionsなんてページがあるけれど、Electronはnpmでバイナリ取得できるのもあって、こういう情報はGtkの方にこそ欲しい...。

[クロス本草稿]開発環境・IDE








本文章は、技術書典5にて[project daisy bell]( https://twitter.com/MNukazawa )がリリースする予定の、クロスプラットホーム・デスクトップアプリケーション・GUIフレームワーク・クロスレビュー本(仮)(以下、クロス本)の一部の草稿です。
クロス本は、筆者のGtk/Qt/electronの経験と知見について扱います。具体的な解説書というより技術エッセイです。
本文章には、校正前の文章・記憶により記述し未確認の内容・雑なmarkdown風紀法・張ってないURLリンク、などがあります。

# 開発環境・IDE

現代的なプログラミング言語やフレームワークには、専用の開発環境が用意されていたり、開発を支援するエディタアドオンが利用されていることが多い。
前者はiOSのXcode、AndroidのAndroidStudio、PythonにはJupitorNotebookがある。後者はVSCodeのc++アドオンなど。
GtkにはAnjuta、QtにはQtCreatorというIDEが用意されており、electronには専用IDEのたぐいはない。

筆者は、Qt以外ではGUIアプリケーション以外でもほぼ全てのコーディングにVimを使っている。
またターミナルによるコマンド操作で開発作業を行うことが多い。

## Gtk

GtkのAnjutaは率直に言って使い物にならない。
Ubuntu14.x-16.xの頃、aptパッケージマネージャから導入したAnjutaが、最初のプロジェクト作成ウィザードを実行中にクラッシュしたことがある。
また、公式によるWindowsバイナリは用意されていない模様。

Anjuta自体は、PyGtk言語バインディングだけでなく、Gtkと関係ない開発も行える汎用IDEを目指しているようだ。
(Java、GnomeShellの拡張、等のプロジェクトが作成できる。eclipseのようなものか。)
Gtk向けの開発支援機能として、GUIによるフォームデザイナ(ポトペタ)機能が用意されている。

ドキュメントの章で書いていると思うが、Gtkユーザの中でもAnjuta使用者は少ないため利用するにあたって参考になる情報もあまりない。
フォームデザイナでWidgetをポトペタした後で、Widgetに求めるプロパティを設定するにはどこを編集すれば良いのかわからない。

2018年現在、今ならさすがに解決されているだろうと思ってUbuntu18.04でAnjutaの動作を確認してみたところ、一番最初のウィザードでgtkのライブラリが足りない旨のエラーが出た。
その後のビルドも `**Error**: You must have `libtool' installed.` などと出て失敗したので、色々と依存関係パッケージが足りていないようである。




デバッガも専用のものはないのでgdbを使用する。
メモリ範囲外アクセスのバグ等でクラッシュする場合など。
ビルド時に-gオプションを忘れないこと。

筆者はAnjutaは使わずに、開発はMakefileを書いてターミナルで実行し、コードはvimで書いている。
Windows向けはUbuntu上でmingwを用いてクロスビルドし、公式がGtk3ライブラリのWindows向けバイナリを提供していないため、非公式なビルドをダウンロードしてGtkアプリケーション開発をしている。
[Windows向けGtk3ライブラリ 非公式配布版]( https://drive.google.com/drive/folders/0BwkefA3JqxdIcGVuNkJfLVFyV2c )
[上記ライブラリを配布している @niloufarjp 氏のtwitter]( https://twitter.com/niloufarjp )
MacOXS版は作ったことがない。

## Qt

GtkのAnjutaが使い物にならないのに対して、QtのQtCreatorは実用的である。

Qt公式によりWindowsおよびLinux版(たしかMacOSXも)のバイナリが提供されている。
QtCreator以外に、VisualStudioでもWindows向けQtアプリケーションが開発可能であるらしい。
ありがちな話として、Ubuntuのパッケージマネージャでインストール可能なQtCreatorは大抵バージョンが古い。

QtCreatorにも汎用IDEを目指す部分はあるようなのだが、基本的には、QtおよびQML、その他のQtの言語バインディングに特化している。
もちろんWidgetのフォームデザイナ機能も用意されている。
GtkよりはWidgetのプロパティ設定も読みやすく設定しやすい。
ある程度ユーザも多いようで、Web上に参考になる情報もある。

QtCreatorのフォームデザイナは、QtCreator向けアドオンで拡張することで、独自定義Widgetを扱えるようになる。
ただし、筆者が以前試した限りでは、このアドオン導入は上手く行かなかった。原因を追求していないので、アドオン側が壊れていたか、単に筆者の手順が悪かっただけかもしれないが。

Ubuntu環境ではQtCreatorを使用してQtC++のプロジェクトをビルドする際に、依存するライブラリの不足で失敗することがあるため、追加パッケージとしてlibglをインストールする必要がある。
(Ubuntuバージョンによってパッケージ名が違うかもしれないので検索でlibgl*-devを探すとよい。)

Ubuntu17付近のIMEがfcitxを使用している環境では、QtCreatorに日本語入力するためにはfcitx-qt5アドオンをソースからビルドしてQtCreatorに導入する必要がある。

QtCreatorをVM上のUbuntuで使用する場合に、OpenGL周りの問題なのかWindowが白塗りとなって内容が表示されない場合がある。
その場合、QtCreatorをターミナルから起動し、起動時オプションでOpenGL周りのオプションを無効にすることで回避できる。

以前はビルドシステムはqmake、自動テストはQTestLibのみだったが、現在はビルドシステムにcmakeや自動テストにgoogletestが選択できるようになった模様。

gdbが組み込まれている。QVectorの範囲外アクセスによる例外などが発生した場合に重宝する。

筆者は公式からWindows向けおよびLinuxのQtCreatorをインストールしてQtアプリケーション開発をしている。
クロスビルドを構築するのは面倒なようなので、配布用バイナリは、Windows/Linuxそれぞれ環境構築してビルドしている。MacOSX版は作ったことがない。
Windows向けはVisualStudio版とMinGW版があり、MinGW版を使用していた。近年、VisualStudio版と統合された模様。

## electron

electronには専用IDEのたぐいは存在しないが、chromiumブラウザ由来の強力な実行時デバッガにより、Gtk/Qtとは段違いに高レベルが高いランタイムな開発支援が受けられる。

electronは専用のフォームデザイナは無い。
electronの画面は普通のHTMLなので、ポトペタがしたければ別途HTMLエディタ的なものを探せばよい。(使ったことがないのでどのようなものがあるかは不明)

だが、chromium由来の機能として、実行中に実行時のウィジェットツリー(DOM構造)と、Widgetプロパティを見ることができる。
DOMツリーに追加したelementが、思った箇所に追加されているか、また思い通りに表示されているかを実際の描画で確認することができる。
Windowサイズ変更した際の、Widgetサイズがどのように変化するかも確認できる。
また、CSSの値も確認することができる。
elementのCSSの値は、親elementからの継承、CSSクラス指定による上書き、style Attributeによる直接指定、jsによる書き換えによって複雑に上書き変化するため、思い通りに表示されない場合、人間が追いかけることは大変むずかしい。
思い通りの表示になっていなければ、動作中にDOMツリーやCSSを書き換えながら、思い通りの表示をする方法を探すことができる。
これらのフォームデザイン補助機能は、圧倒的に便利である。
CSSの章でも書くと思うが、electronの実行時GUIビジュアルデバッガを体験すると、GtkとQtのフォームのデバッガビリティの低さは論外であると理解できるし、特にGtkのCSS採用はあまりに愚かな判断ミスだったとしか思えなくなる。
(※このへんの内容は、もっと詳細にしてCSSの章に移動すると思う)

jsのデバッガが組み込まれている。
gdb,QtCreatorなどと同じく、ブレークポイントや関数呼び出しのトレースなどデバッグに必要な操作が行える。

Gtk,Qtとの違いとして、配布の際もchromiumの全機能が付いたままであるため、デバッガを切り離すことはできない。
ユーザからのデバッガへのアクセスを避けたい場合、デバッガの呼び出しショートカットを無効化すること等で対応する。



筆者はnodejsの最新安定版をnodejs公式からインストールして、そのnpmからelectronパッケージおよび他の依存関係パッケージをインストールしてelectronアプリケーション開発をしている。
開発時のtest等のコマンドはpackage.jsonに書くのが一般的なようなのだが、筆者はパッケージ作成まで含めたMakefileを書いている。
コードはhtml,css,jsまですべてvimで書いている。
開発はLinux上で行い、配布用のWindowsおよびMacOSX向けビルドはLinux上で作成できるためそのようにしている。

[クロス本草稿]テスト-Qt

本文章は、技術書典5にて[project daisy bell]( https://twitter.com/MNukazawa )がリリースする予定の、クロスプラットホーム・デスクトップアプリケーション・GUIフレームワーク・クロスレビュー本(仮)(以下、クロス本)の一部の草稿です。
クロス本は、筆者のGtk/Qt/electronの経験について扱った技術エッセイのようなものです。
校正前の文章・記憶により記述し未確認の内容・雑なmarkdown風紀法・張ってないURLリンク、などがあります。


# テスト

本章では各FWにおけるテストの方法について扱う。
GUIアプリケーションの主要なテストには、一般的なユニットテストと、GUIアプリケーション固有のGUIテストのテストの2つがある。
GUIテストにおいては、コールバックイベントをエミュレーションするダミーメッセージの生成と送信、画面更新および描画内容を取得して正解とdiffし結果を確認する方法、という2つの問題がある。

筆者の開発したアプリケーションは、大きなものでも筆者1人が1-2年かけて開発可能な規模のものだった。
そのため、「GUIテストが一覧にされたドキュメント仕様があり、それがすべて自動テスト化されている」というレベルの自動テスト構築は必要ではなかったため、行っていない。
経験は主にユニットテストについてのものであり、GUIテストについては少し書いている。


## Qt

Qtのテストは、なんというか、ほとんどすべてがGtkと逆である。

Qtには、専用のQtTestという名前のテストシステムが用意されている。
QtTestは、ユニットテストとGUIテストの両方をカバーしている。
[Qt Test]( http://doc.qt.io/qt-5/qttest-index.html )
名前空間とインクルードヘッダ名は`QTest`で、qmakeでの追加指定は`QT += testlib`と書く。
また、明記された箇所を見つけることはできなかったが、Qt4までは`QTestLib`と呼ばれ、Qt5以降でQtTestという名前になったのではないかと思う。
[Qt Documentation Archives QTestLib Manual]( http://doc.qt.io/archives/qt-4.8/qtestlib-manual.html )
少々名前が混乱している気がする。Qtの命名ルールに詳しくないので断言はできないが。

テスト専用ではないが、シグナルを監視できる[QSignalSpy Class]( http://doc.qt.io/qt-5/qsignalspy.html )もTestのページに記載されている。
Qtではsignal/slotという名前のメッセージングシステムでGUIを含むイベント処理を行うため、これをQSignalSpyでテストできるという意図なのだろうと想像している。

筆者は結果的に、Qtアプリケーションで自動テストを行わなかった。
そのため経験で語れることはあまりないのだが、ひとつだけ「Qtではgoogletestが使えなかった」というのがある。
当時、Qtアプリでgoogletestが使いたい場合には、Qt公式でない外部のプラグインを導入するなどの工夫が必要があった。
このあたり、Qtがc++風の独自言語により実装されている(※)ため発生した問題かと思っている。
いつからなのかはわからないが、2018年現在、[QtCreaterからgoogletestを選択して使えるようになった模様]( http://doc.qt.io/qtcreator/creator-autotest.html )。
自動テストをしなかったのは、筆者が作ったQtアプリケーションは、QtTestを学ぶかgoogletestを導入するほどの、自動テストの必要性がなかったためである。

※筆者の独自見解。前述の通り(と書いた段階ではまだ「前述」の章を書いていない。書くはず。本当に書くと良いのだが)

[クロス本草稿]テスト-Gtk

本文章は、技術書典5にて[project daisy bell]( https://twitter.com/MNukazawa )がリリースする予定の、クロスプラットホーム・デスクトップアプリケーション・GUIフレームワーク・クロスレビュー本(仮)(以下、クロス本)の一部の草稿です。
クロス本は、筆者のGtk/Qt/electronの経験について扱った技術エッセイのようなものです。
校正前の文章・記憶により記述し未確認の内容・雑なmarkdown風紀法・張ってないURLリンク、などがあります。

# テスト

本章では各FWにおけるテストの方法について扱う。
GUIアプリケーションの主要なテストには、一般的なユニットテストと、GUIアプリケーション固有のGUIテストのテストの2つがある。
GUIテストにおいては、コールバックイベントをエミュレーションするダミーメッセージの生成と送信、画面更新および描画内容を取得して正解とdiffし結果を確認する方法、という2つの問題がある。

## Gtk

Gtkには専用のGUIテスト・ユニットテストのテストフレームワークの類はない。
(無いと思う。使っているときには見あたらなかった。無いよね?)


私がGtkアプリケーションを書く際はC言語で書く。そのため、ユニットテストには[googletest]( https://github.com/google/googletest )を採用している。
C言語以外では書いたことがないのでわからないが、Gtkの各言語バインディングでも、言語ごとのデファクトなユニットテストが問題なく使えると思われる。
これは後述の、QtがC++言語を使用していながらgoogletestと衝突することのほうが、どうかしている。

コールバックイベントエミュレーションは、前述の通りフレームワークが無いので自動化していない。
コールバックテスト化のため、一応の工夫が2つある。
- コールバックエミュレーションのユニットテスト化
- 手動テスト(自動化は諦める)
である。








コールバックエミュレーションのユニットテスト化について。
Gtkコールバックループから来たマウスイベントを機能ブロックに送る前に、必要な情報のみをイベント受け渡し用に用意したstructにコピーしてから渡している。
別にGtkネイティブのstructに必要な変数を代入して使っても良いのだが、実際のイベントの取り回し等も考えて、そのような設計にしている。
実際のコード例を挙げると、vecterionの[et_tool_into機能ブロックのテスト]( https://github.com/MichinariNukazawa/vecterion_vge/blob/master/test/utest/test_et_tool_info.cpp )がある。
読んでらえれば、イベントコールバックをなんとかユニットテスト化しようとしている筆者の苦労の様子がわかる。
et_toolはツール、例えば「マウス操作によるアンカーポイント編集」などの集合である。
アプリケーションウィンドウ上でのマウス操作(EtMouseAction)と現在アクティブなツール種別( et_tool_info_util_func_*_mouse_action()関数 )を受け取り、ドキュメント上のアンカーポイントの編集操作や、ポインタの触れた位置へのフォーカス変更などを行う。

手動テスト(自動化は諦める)について。
個人によるOSSでは手動テスト・リリーステストの類のドキュメントをあまり見かけない印象があるのだが、筆者がOSSをあまり多く読んでいないだけかもしれない。
vecterionには手動による[リリーステスト]( https://github.com/MichinariNukazawa/vecterion_vge/blob/master/test/release_test.md )を用意している。
安定版をリリースする前には、リリーステストを実施することにしている。
目的はちょっとしたうっかりバグによる基本機能欠損状態でのリリースの防止。
リリーステストにより実際に、ポカミスのようなバグを何度か発見している。
リリーステスト自体の前文に書いてあるとおり、省力で済むよう心がけているのだが、それでもこんなに項目が多くなってしまうのだった。
正直、手動テスト自体が苦手なのもあり、あまりやりたくはない。

Gtkのテストについて、未調査の事項として、Gtk製の画像編集アプリケーションであるGimpをビルドした際、テストの段階でメインウィンドウと複数のダイアログが一瞬だけ立ち上がって消える。
何らかの実行テストであると思われるのだが、どのような方法で何をテストしているのかは不明。

## Qt

Qtのテストは、なんというか、ほとんどすべてがGtkと逆である。

(続く)

ubuntu18.04 alphaで日本語入力(ibus-mozc 英字配列キーボード)

ubunu18.04 alphaの試用を始めました。
新しいUbuntu、特にリリース前の試用版を使おうとすると、まず問題になるのは日本語入力です。
LTSリリースでさえ、リリース日の前後に有志の方々(足を向けて寝られない)の力でやっと日本語入力できるようになった、という場合がけっこうあって、ubuntuの日本語入力機能のリリーススケジュールは体感ではリリース日後になる場合もある、という感じです。

それで、今回のubunu18.04 alphaですが、ちょっと驚いたのですが、最初から(設定すれば?)日本語入力できる状態になっています。ちょっと問題はありますが。



結果的に、これまでの経験(?)からfcitx-mozcを使おうとしたせいで、自分から問題に迷い込んでしまった格好です。

なお、あくまでalpha版なので、明日にも状況が変わるかもしれません。参考程度に。

TL;DR

ibus(ibus-mozc)使う。fcitx使わない。 im-configをdefaultのまま変えない。
(いちど変え直して再起動するといいとかの罠は無いと思う。多分。)

# fcitxを使おうとした(失敗)

http://www2.it-ishin.com/archives/2018/02/01/1506.html
では、fcitx-mozcを使ってim-configする方法を紹介している。
これは私の環境とバージョンでは失敗した。

im-configの勧めにしたがって一度はibusをアンインストールしたが、後にインストールしなおして、念の為fcitxの方をアンインストールした。


デフォルトがibusだったので、fcitxを使う場合は、 im-configをいじる必要があった。
自分はim-config、sudoありなしで両方とも設定してしまったが、両方とも戻した。


fcitx-mozcは、日本語入力はできるが、IME切り替えをしても変換処理が止まらず、英字を直接入力することができない。
IMEアイコンが2つ表示されている。IME切り替えキー操作をしてもfcitx-mozcが止まらない問題らしい。

また、fcitx?のアイコンから出てくるメニューは、各項目の内容が、一瞬だけ表示されてすぐ消えてしまうため、まったく設定が操作できなかった。

# 英字キーボード固有の話

 入力切替のショートカットキーの設定は、右上のIMEアイコンからではなく、Gnomeの設定アプリ(Ubuntuの設定)から行う。
場所は「デバイス>キーボード 」。
入力切替ショートカットキー設定

入力切替のショートカットキーがデフォルトでsuper+spaceになっている。
(日本語入力できていないうちに設定を変えてしまったので、動作を確認していない。)
この設定をCtrl+spaceにすると、上の設定も自動で書き換わる。特に悪さはしない模様。

# TIPS

IME設定を変えたら、Ubuntuを再起動する。ログオフではIME設定変更がうまく反映されない模様?

IME切り替えUIの表示が一瞬遅い&切り替えキーを離すと即消えるので、一瞬でやると切り替えUIが表示されない。最初は、『切り替えUIが出たり出なかったりする』ようにしか見えないので、特に日本語入力がうまく行っていないとき、IME切り替えができていないのではと思って、戸惑う。
UI自体はWindows10で感心したやつに近い仕組みで良いと思う。



日本語入力するために、毎回、mozcの入力モードを「ひらがな」にする必要あり。ibus-mozcの入力モードは、再起動すると「直接入力」(英字入力)に戻ってしまう。このこと以外は概ねうまく行っている。
ibus-mozcの入力モード設定

以上です。

ubuntu18.04 alphaにcudaをinstallする

 ubuntu18.04 alphaにcudaをインストールする手順です。

 
16.04でもnvidia公式リポジトリのおかげでかなり楽になっていましたが、18.04ではcuda9.0がubuntuリポジトリに上がっており、ドライバごとaptから導入できます。
最新版 は9.1が出ているっぽいですが。
(というかUbuntu16.04でcudaインストールが大変だった問題の、諸悪の根源はバラバラな方法が検索上位にいくつも上がってくるqiitaのような。昔のように最初から公式ドキュメントを読めばよかった。とはいえ本記事もalphaのこの時点ではうまく行ったという話なので信憑性は似たりよったり...閑話休題。)

# インストール

リポジトリ追加すら必要ありませんでした。
ドライババージョン等は、まだalphaなので、最新版が登場したり取り下げられたりするかもしれませんが。

```
sudo apt install nvidia-driver-390 libcuda1-384 libcufft9.0 nvidia-cuda-toolkit
```

(※02/28時点のalphaで下記cuda導入コマンド実行後に後からnvidiaドライバを導入しようとしたらUbuntuが壊れました。report中。)
```
sudo apt install libcuda1-384 libcufft9.0 nvidia-cuda-toolkit
```

libcufft9.0はなんとなく入れただけです。今回は動作確認していません。
nvidia-cuda-toolkitはnvccが入っています。ビルドに必要です。
この時点で、libcufft9.0のバージョンを信じるならば9.0? って感じでした。

とりあえず単純なソースをビルドして実行するだけならば、ドライバライブラリへシンボリックリンクを手作業で貼り直したり、.bashrcにパスを設定したりする必要はありません。ubuntu16.04の頃を思うと、感動的に楽です。

# 確認

まずはコマンドで、次にビルドおよびバイナリの動作によりcuda環境の動作を確認。

## コマンド

```
$ nvidia-smi
Mon Feb 26 00:32:06 2018      
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.111                Driver Version: 384.111                   |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 105...  Off  | 00000000:27:00.0  On |                  N/A |
| 45%   33C    P5   ERR! /  75W |    964MiB /  4035MiB |      2%      Default |
+-------------------------------+----------------------+----------------------+
                                                                              
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      1522      G   /usr/lib/xorg/Xorg                            57MiB |
|    0      1569      G   /usr/bin/gnome-shell                          47MiB |
|    0      1938      G   /usr/lib/xorg/Xorg                           534MiB |
|    0      2086      G   /usr/bin/gnome-shell                         321MiB |
+-----------------------------------------------------------------------------+

$nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2017 NVIDIA Corporation
Built on Fri_Sep__1_21:08:03_CDT_2017
Cuda compilation tools, release 9.0, V9.0.176

$ which nvcc
/usr/bin/nvcc

$ ldconfig -p | grep cuda
    libicudata.so.60 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libicudata.so.60
    libcudart.so.9.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcudart.so.9.0
    libcudart.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcudart.so
    libcuda.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcuda.so.1
    libcuda.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcuda.so

```

## サンプルソース・アプリ動作

https://gist.github.com/dpiponi/1502434
で確認しました。ダウンロードしてビルドして実行したところ、動いているようです。
```
$ nvcc example.cu && ./a.out
```
以上です。



Install Android Studio 2.3.1 to Ubuntu16.04LTS

今回特に、エラーメッセージをメモしていないので、これは記憶で書いているメモです。







基本的には公式サイトに書いてある手順でOKです。
ただ、事前に32bitライブラリをインストールする指示がありますが、それらのパッケージはかなり前のUbuntuから廃止されているようで、かつ、無くてもInstallおよび実行できました。




インストール中、アドオンのProxyが設定されていない(だったか)旨のエラーが出ますが、Cancelすればインストールが続行します。
インストール中、わたしのマシンではブラウザのインターネット接続が切れました。インストーラがパッケージをダウンロードしてくるので、その時に帯域を使い切る等があったのかもしれません。
また、インストール中にパッケージが見つからなかった的な旨のメッセージが出ましたが、 これは2回ほどRetryを選択したところ、続行できました。ネットワークの問題かと思われます。

Android公式のチュートリアルにまあまあ従って(Android6.0ターゲットに変更。ユーザカバー率が10%を切ると表示されていてすごい。)プロジェクトを作ると、 エラーメッセージ。




http://amaebi.jp/?p=318
に従い、Proxy設定をAuto-Detectにして、いったんプロジェクトを閉じ、再度開いたところ、幾つもエラーは出るものの、進行はしました。

一覧にそれらしき端末は出るし(とはいえudev設定する前から出ていた)、ビルド成功のメッセージは出てエラーは出ないものの、そこから先、アプリケーションが実機で実行されない。

http://kntmr.hatenablog.com/entry/2015/12/02/113533
を参考にUSB接続をMTPにすると、「USBデバッグを許可しますか?」というダイアログと共に、公式ドキュメントのフィンガープリントの許可ダイアログが出ました。
わたしのLTE/Blade V7 Liteでは、「充電のみ」モードではUSBデバッグが出ませんでした。

認識されるようになると、名前が「null」ではなく、きちんとデバイス名が表示される。





一度目はAndroid23SDKが無いとかで失敗しますが、再度Runすると、これが自動でインストールされます。

で、何度か繰り返したら実機にアプリケーションが表示されました。

雑感

- 必要になった都度インストールがあって、新しことをする度に待ち時間がありそう。
- IDEからWebのドキュメントへ飛ぶリンクが多数あるので、都度インストールと合わせて、インターネット必須。
- インストール・ネットワーク関連は、再度実行すると上手く行くこと多し。ネットワーク周り、不安定すぎやしないか。

以上です。

ComfyUIでXYZ-PlotするワークフローのサンプルとTips(ComfyUI-XYZ-Stitch)

 ComfyUIでAutomatic1111的なXY-Plotをしたいのだが、ComfyUIデフォルト機能には用意されていない。     カスタムノードが必要となるのだが、Webには古いとか何故か動かないとかなXY-Plotパッケージの使ってみた系記事か、githubに上げられた...