2016年12月16日金曜日

Vim x C言語で書くプロジェクトの良さと(私的)つらみについて

この記事は Vim Advent Calendar 2016 の16日目の記事です。
15日目の前日は shinespark氏の「Vimでtreeっぽくディレクトリ構成を書きたい、そんなアナタの為のVim Plugin、できてます。」でした。


この前の新Mac騒動でCtrl+]を初めて知った@MNukazawaです。
しかし相変わらずESCを連打しています。


追記 > 投稿してから文字サイズがおかしいことに気づいたのですが、ざっくり対処しておきますので、多少おかしくても勘弁いただければと思います。

まえがき


家でも仕事でも、C言語を書くときは(C言語を書くときに限らず)Vimを使っています。
ライトVimmerにとって、Vimは最高ですが、完璧ではないです。
C言語での開発とVimとの相性は最高ですが、光のあるところには影もあり、以下に書いてあるアレコレのつらみに、私は今も苦しんでいます。

今回挙げた中には、受け入れていかなければならないものや、いかにも井の中の蛙っぽい悩みも含まれており、解決策やベストプラクティスが無いはずがないと思えるものもあります。
「プラグイン忌避を克服しろ」「Vimの基本コマンドくらい覚えろ」等々、厳しくツッコミを入れて頂けると、正直とても嬉しいです。


私は現在、Vecterion(べくてりおん)という名前のベクターグラフィック・エディタを書いています。
今回のVim記事も、VecterionをVimで書いているときの話をするので、Vecterionのスペックをざっくり挙げておきます。
* GUIアプリケーション(ベクターグラフィック・エディタ)
* C言語/GTK3で書いている。
* googletest使用
* GNUMake(生Makefile)でビルド
* 中規模アプリケーション(1人で開発。アプリケーション本体のヘッダとソースが50個ずつ有る)

リリースはまだしていませんが、昨日もリリースブロッカを一つ潰したので、来年のどこかでは...。
Vecterionについては、Vimに関わらない C言語 Advent Calendar 2016 の12日目の記事「Cで書く中規模GUIアプリケーションから得た知見(初稿) 」でざっくり書いたので、よければどうぞ。





つらみ達

# ディレクトリ構成

中規模アプリケーションは、ヘッダとソースが別パスになる。
=== Vecterionのヘッダ一覧 ==
:~/etaion_vge$ ls include/
et_canvas.h             et_error.h             et_snap.h          pv_bezier.h           pv_io.h
et_canvas_collection.h  et_etaion.h            et_snap_panel.h    pv_cairo.h            pv_render_context.h
et_color_panel.h        et_key_action.h        et_state.h         pv_color.h            pv_render_option.h
et_define.h             et_layer_view.h        et_stroke_panel.h  pv_element.h          pv_renderer.h
et_doc.h                et_mouse_action.h      et_thumbnail.h     pv_element_general.h  pv_rotate.h
et_doc_history.h        et_mouse_cursor.h      et_tool_id.h       pv_element_info.h     pv_stroke.h
et_doc_history_hive.h   et_mouse_util.h        et_tool_info.h     pv_error.h            pv_svg_info.h
et_doc_id.h             et_pointing_manager.h  et_tool_panel.h    pv_file_format.h      pv_type.h
et_doc_manager.h        et_position_panel.h    pv_anchor_point.h  pv_focus.h            pv_vg.h
et_doc_relation.h       et_renderer.h          pv_appearance.h    pv_general.h

===


ソースは source/ 以下にある。

* ヘッダとソースを別パスにすると、Vimでソースヘッダ間の移動が面倒になる

imでソースヘッダ間の移動で有名な 
`:sp %<.h`
 が効かなくなるため、移動が面倒。
仕方なしにヘッダからソースへの移動は、目に付いた適当な関数を叩いて飛んでいる。
というか、ソースへのアクセスもとりあえずヘッダを開いてctagsでソースへ飛び、いつでもctagsのスタックでヘッダへ飛べるようにしておく、という運用をしている。

 * Vimに必須なctagsが絡むと、ディレクトリが深くなりタイプ量が増える

 ctagsは、tagsファイル生成と利用のために、vimのカレントディレクトリを、常にプロジェクトのソース先頭にしておかないと都合が悪い。
そうでなくても、ソースとヘッダの間を行き来することを考えると、Tab補完はあるものの、ディレクトリの分だけタイプ数が増えることを受け入れなければならない。

# 今どきな長めの名前で、インテリセンス無しで書く

 今どきの関数・変数名は、省略を避けるなど、なんとなく長い名前になりがち。
 長い名前をインテリセンス無しで書くのはつらい。
 (名前が長いこと自体は、自分が悪い気がしないでもないが。)
 Vimは最高のテキストエディタだが、最高のIDEであるとは限らない。

 ex. `>-------pv_anchor_point_set_handle(&dst_aps[2], PvAnchorPointIndex_HandlePrev, p1_handle_prev_dst);`

 インテリセンスのプラグインに決定打がない。ついでにVimプラグインはインストールがつらい。


# リファクタリング的な置換ができる命名

「リファクタリング」というほど格好良くなくても、開発していて名前を変えたくなることは多い。

 * Vimのリネームは1ファイル内のみ

プロジェクト内でファイルを跨いだ命名変更がしたいとき、Vimは無力。
 ヘッダ・ソース合わせて100ファイルを超えているので手作業は嫌。
 なので、
`sed -i 's/AA/BB/g' */*.[hc]`
を使っている。

 * sedでリネームしやすい名前を付けている(付けなければならない)

 つまり`sed`しやすい名前を付けなければならない。
 EtElement構造体のオブジェクトの変数は"element", "layer_element"などと名付ける。
リネームしずらいので、"elem"とか"e"とは付けない。
 (というか初期に一部のコードでそういった変数名を付けてしまったので、後で直さないと...)
 関数の引数を変更したいとき、引数に折り返しがあるとsedできなくてつらい。(これはIDEでも難しいだろうけれど)

ファイルの"path"(filepath)と被るのが怖くて、アンカーポイントで構成される線分"path"(ahchorpath)と名づけるのを避けて、変な名前を付けたりしていた。

# ctagsでstatic関数定義へ飛ぶとき

中規模以上のC言語プロジェクトでは、ファイルローカルなstatic関数を定義する。
そしてコーディングルールによったり、その他の都合で、ソースの先頭近くでファイルローカルstatic関数の定義をすることになる。
そしてVimを使うならば、ctagsで関数間をジャンプする。

 * ctagsは最初の候補としてstatic関数の宣言へ飛ぶが、私は定義を見たい

いつもCtrl+]とCtrl+Tを使っている。Vimのタグジャンプ自体はとても便利で多用するので、いつも常に:tsと打って候補一覧を見てから数字キーで飛び先を指定する、なんてことはしたくない。

 * そもそも開発中に関数を追加しながら毎度`:!ctags -R`するのがつらい。

コミット前のコードは、書きかけの関数が消えたり、名前が変わったりが頻繁に起こる。
`ctags -R`を何度か打つことになる。が、ディレクトリに複数のソースファイルを抱えたプロジェクトで、再帰的にソースを探索させるとctagsも2~3秒かかることもある。(いま以上に大きくなったらどうなるか不安)

# インデント整形(gg=G)にコーディング規約を合わせる

 * Vimはデフォルトでインデント整形できる機能が用意されているのがすばらしい

 しかし完璧ではないので、以下のような考慮すべき点がある。

## switch case{}とLinuxコーディング規約の衝突

Linuxコーディング規約よりインデントが1段深い。
8tabを使っていると8文字分の横幅を使われる。
他の開発者に触ってもらうなどを考えると、Vimのデフォルトから.vimrcで変えたくなかった。
一人で開発しているだけなら、そのうち慣れたので大きな問題でもない。

## extern C{} (c++対応)

* extern C{}がVimの自動インデントで引っかかる。ヘッダ全体にインデントが一段かかってしまう。

 googletestでテストを書こうとするとこれに悩む。
 googletest側でextern C{}することで解決。
 CヘッダがC++に考慮するのが間違いと思うことにする。
 せいぜいC++テストコード内のinclude行だけの問題になる。




以上です。



あとがき

今更ですが、「つらみ」ってこういう使い方で良かったのでしょうかね?

もうそろそろ「ライトVimmerの世界 - 驚きのプラグイン無し生活 -」みたいな記事を書いたほうが良い気がしています。
それよりVimコマンドを覚えたほうが有意義そうですが。

水の中の魚は水のことを意識することがありません。Vimを使ってC言語でコードを書いていると、ctagsの有り難みをつい忘れてしまいがちです(Windows上のAtomでソースを開いたときに思い出す)。
それは必ずしも悪いことではないのだと思います。が、快適なVimコーディングも、使い続けていると細かいところでつらみが意識されるようになるのも、自然なことで、だからこそ先達たちは多用なVimプラグインを生み出してきたのかもしれません。


この記事は Vim Advent Calendar 2016 の16日目の記事でした。
17日目の明日はanekos氏の「Vim の下着の話」です。

2016年12月12日月曜日

Cで書く中規模GUIアプリケーションから得た知見(初稿)

この記事は C言語 Advent Calendar 2016 の12日目の記事です。
11日目の前日はegtra氏の「配列でないオブジェクトに対するポインタ演算」でした。


@MNukazawaといいます。今、ベクターグラフィック・エディタをC言語で書いています。
Vecterion(べくてりおん)という名前です。
VecterionはGtk3/C言語で書いています。
現在進行形ですが、今日はVecterion開発の知見というか、Vecterionで使っているちょっと大きめのイディオムを、いくつか紹介したいと思います。

なおこの記事で言っている「中規模」ですが、
* ワンソース(ほぼmain.cだけ)に収まるアプリケーションを小規模
* 多人数で開発しなきゃ作れないアプリケーションを大規模
として、コマンドラインスクリプトよりは高度なことをしているけれど、コード量としては一人で収まる。
小規模と大規模の間くらい、程度の意味です。

小規模は、(語弊があるが)catやechoのような、ワンパスのコマンドラインスクリプト程度の機能。
大規模は、GIMP, LibreOfficeのようなGUIエディタや、Linuxカーネルなど。



なんというか、中規模コードの良い例を見つけることができなかったので書きました。
どなたかオススメのプロジェクトをご存知の方は教えてください。


開発中プロジェクトでまだ悩み中(本当は良くない)なので、まとまりきらない内容になっていますが、あなたが中規模プロジェクトを書く際に、一部でも参考になれば幸いです。

# ソース構成

## ソース構成

struct型の定義と一緒に、メンバ関数・構造体を操作するUtility関数を同じヘッダに置いている。
CヘッダとCソースは原則的に一対一対応させている。

これらのソース構成は、ビルド速度的には最善ではないが、関数の置き場所がわかりやすく、プロジェクト全体の読みやすさに繋がる。

"#define"でない方法で定数 を定義している。
===
 static const PvPoint PvPoint_Default = {0, 0};¬
===
static const は入れ子に宣言定義(?)できないので、その時は諦めて#defineを使う。


Gtk的な関数名の付け方を、そのままソースの名前にしている。
===
:~/etaion_vge$ ls include/
et_canvas.h             et_error.h             et_snap.h          pv_bezier.h           pv_io.h
et_canvas_collection.h  et_etaion.h            et_snap_panel.h    pv_cairo.h            pv_render_context.h
et_color_panel.h        et_key_action.h        et_state.h         pv_color.h            pv_render_option.h
et_define.h             et_layer_view.h        et_stroke_panel.h  pv_element.h          pv_renderer.h
et_doc.h                et_mouse_action.h      et_thumbnail.h     pv_element_general.h  pv_rotate.h
et_doc_history.h        et_mouse_cursor.h      et_tool_id.h       pv_element_info.h     pv_stroke.h
et_doc_history_hive.h   et_mouse_util.h        et_tool_info.h     pv_error.h            pv_svg_info.h
et_doc_id.h             et_pointing_manager.h  et_tool_panel.h    pv_file_format.h      pv_type.h
et_doc_manager.h        et_position_panel.h    pv_anchor_point.h  pv_focus.h            pv_vg.h
et_doc_relation.h       et_renderer.h          pv_appearance.h    pv_general.h

===



# コーディング

## ソース(関数・変数etc)のネーミング

sed, grep, vim, ctags, が効く名前を付けるべき。今はGtk3ライクな名前を付けている。
 vim上で一意性のある名前にするかは悩ましい(悩んでる)
 ctags対応には一意な名前を付ける。変に同名(static関数とか?)を付けなければ大丈夫。

特に開発中のプロジェクトは、実装により適切な名前が別にあることがわかったりするので、関数ローカルの一時変数名まで、置き換えを意識して付けるようにしている。
つまり、同名を避けることで、
 sed -i s/AA/BB/g */*.[hc]
 grep -r AA */*.[hc]

が効くように名前を付ける。
例えば、"Doc"を"Document"に直すときに、「ほぼ一括置換」くらいの手間で置き換えられる状態を目指している。
===
 11 struct EtDoc;¬
 12 typedef struct EtDoc EtDoc;¬
 13 ¬
 14 typedef int EtCallbackId;¬
 15 typedef void (*EtDocSlotChange)(EtDoc *doc, gpointer data);¬
 16 ¬
 17 ¬
 18 ¬
 19 EtDoc *et_doc_new();¬
 20 EtDoc *et_doc_new_from_vg(const PvVg *vg);¬
 21 void et_doc_delete(EtDoc *);¬
 22 EtDocId et_doc_get_id(EtDoc *self);¬
 23 char *et_doc_get_new_filename_from_id(EtDocId doc_id);¬

===



## C99(C11)を使う

変数の宣言、ただしgotoエラー処理と相性が悪い...
stdbool.hのbool型
const使う
安全な文字列操作 snprintf, strlcpy, g_strdup_printf
 strlcpy, g_strdup_printfは、それが無い環境では互換関数を書いたりしている。

# 未定義動作を避ける

最近は浸透してきた?
未定義動作の存在の認知度ってどのくらいなのだろう。
clang、本の虫、JPCERT CC、
 http://blog-ja.intransient.info/2011/05/c-13.html
 https://cpplover.blogspot.jp/2014/06/old-new-thing.html
 https://www.jpcert.or.jp/sc-rules/c-pre00-c.html

## ヘッダはシステム、自分ソースの順

ヘッダを書き間違えた時にとんでもないエラーメッセージが出ることがあるので、ヘッダはシステムヘッダを上に書く。
// と言いつつ、.h:.c一対一対応のコードはCソースの一番上に対応ヘッダファイルを書いているが。
===
  6 ¬
  7 #include <gtk/gtk.h>¬
  8 #include <gdk/gdk.h>¬
  9 #include <stdbool.h>¬
 10 #include "pv_element_general.h"¬
 11 #include "pv_color.h"¬
 12 #include "pv_stroke.h"¬
 13 #include "pv_appearance.h"¬
 14 ¬
===


## typedef enum定数

例えばアイコンをIDで管理して実体を引く関数を書くなら、get_icon_from_id(int icon_id)よりは(IconId icon_id)のほうが良いかと。
内部的にはint的なモノなのであくまで読みやすくするだけの糖衣。
コンパイラチェックが得られるとは期待しない。
===
 62 // ** ElementKind定数¬
 63 ¬
 64 typedef enum _PvElementKind{¬
 65 >-------PvElementKind_NotDefined,¬
 66 >-------/* special element document root */¬
 67 >-------PvElementKind_Root,¬
 68 >-------/* complex element kinds (group) */¬
 69 >-------PvElementKind_Layer,¬
 70 >-------PvElementKind_Group,¬
 71 >-------/* simple element kinds */¬
 72 >-------PvElementKind_Curve,¬
 73 >-------PvElementKind_Raster, /* Raster image */¬
 74 ¬
 75 >-------/* 番兵 */¬
 76 >-------PvElementKind_EndOfKind,¬
 77 }PvElementKind;¬
 78 ¬
===


## class的C記法 typedef struct & classメンバ的Utility関数

Gtkベースな、C++ classメンバなんて、C関数self引数の糖衣構文に過ぎない的思想。
最初はthisと名づけていたら、googletest側でC++予約語と衝突して、selfにリネームしなければならなくなった。
===
168 PvElement *pv_element_new(const PvElementKind kind)¬
169 {¬
170 >-------PvElement *self = (PvElement *)malloc(sizeof(PvElement));¬
171 >-------pv_assert(self);¬
172 ¬
173 >-------self->parent = NULL;¬
174 >-------self->childs = NULL;¬
175 ¬
176 >-------const PvElementInfo *info = pv_element_get_info_from_kind(kind);¬
177 >-------pv_assertf(info, "%d", kind);¬
178 >-------pv_assertf(info->func_new_data, "%d", kind);¬
179 ¬
180 >-------self->data = info->func_new_data();¬
181 >-------pv_assertf(self->data, "%d", kind);¬
182 ¬
183 >-------self->color_pair = PvColorPair_Default;¬
184 >-------self->stroke = PvStroke_Default;¬
185 ¬
186 >-------self->kind = kind;¬
187 ¬
188 >-------self->etaion_work_appearances = pv_appearance_parray_new_from_num(NUM_WORK_APPEARANCE + 1);¬
189 >-------pv_assert(self->etaion_work_appearances);¬
190 ¬
191 >-------return self;¬
192 }¬
193 ¬
===


## 分岐の方法

switch構文が読みやすくて好き > VimのデフォルトとLinuxでインデントルール衝突しているがまあそれはそれ。
switch文は縦横サイズを食うので、サンプルコードは略す。

## Info型とget_info_from_kind()関数

不満はあるが、Info型をKind,Id,Indexのいずれかで引く方式を使っている。
記事参照 「Cに欲しい機能 インデックス番号付き構造体配列」
===
1739 ¬
1740 const PvElementInfo _pv_element_infos[] = {¬
1741 >-------{PvElementKind_Root, "Root",¬
1742 >------->-------.func_new_data>->------->------->-------= _func_group_new_data,¬
1743 >------->-------.func_free_data>>------->------->-------= _func_group_free_data,¬
1744 >------->-------.func_copy_new_data>---->------->-------= _func_group_copy_new_data,¬
1745 >------->-------.func_write_svg>>------->------->-------= _func_group_write_svg,¬

1757 >------->-------.func_get_rect_by_anchor_points>>-------= _func_notimpl_get_rect_by_anchor_points,¬
1758 >------->-------.func_set_rect_by_anchor_points>>-------= _func_notimpl_set_rect_by_anchor_points,¬
1759 >------->-------.func_get_rect_by_draw>->------->-------= _func_notimpl_get_rect_by_draw,¬
1760 >------->-------.func_apply_appearances>>------->-------= _func_nop_apply_appearances,¬
1761 >-------},¬
1762 >-------{PvElementKind_Layer, "Layer",¬

===

## データ構造の生成というか確保というか

malloc,freeで生成・削除し、ポインタで保持する。
構造体の中身を見せたくなければ、Cのimplイディオムのように、ヘッダに宣言のみ書く方法で定義を隠す。

可変長配列は、ポインタ配列をポインタポインタで確保して使うことで実現している。
Cを使っているので、可変長配列が使いたければmalloc,freeと仲良くするしかない(mallocの速度については必要になるまでは忘れる)。

 size_t *_get_parray_num()トリックで個数を取るとイテレートがやりやすい。
 for(int i = 0; i < (int)num; i++) が定型文になりつつある。
===
 170 >-------int num = pv_general_get_parray_num((void **)elements);¬
 171 >-------for(int i = 0; i < num; i++){¬
 172 >------->-------const PvElement *element = elements[i];¬
 173 >------->-------const PvElementInfo *info = pv_element_get_info_from_kind(element->kind);¬
 174 >------->-------et_assertf(info, "%d", element->kind);¬
 175 ¬
 176 >------->-------PvRect rect = info->func_get_rect_by_anchor_points(element);¬
 177 ¬
 178 >------->-------if(0 == i){¬
 179 >------->------->-------rect_extent = rect;¬
 180 >------->-------}else{¬
 181 >------->------->-------rect_extent = pv_rect_expand(rect_extent, rect);¬
 182 >------->-------}¬
 183 >-------}¬
 184 ¬
 185 ¬
 

===

## エラー返り値

NULLまたはbool falseに統一。
それ以外が必要なら最終引数に "~bool *is_error)"
引数が不正な場合、Vecterionはabort()するが、PhotonVectorはエラーを返す方針。
===

  8 #define et_assert(hr) \¬
  9 >-------do{ \¬
 10 >------->-------if(!(hr)){ \¬
 11 >------->------->-------fprintf(stderr, "et_assert: %s()[%d]:'%s'\n", __func__, __LINE__, #hr); \¬
 12 >------->------->-------assert(hr); \¬
 13 >------->-------} \¬
 14 >-------}while(0);¬
 15 ¬
 16 #define et_assertf(hr, fmt, ...) \¬
 17 >-------do{ \¬
 18 >------->-------if(!(hr)){ \¬
 19 >------->------->-------fprintf(stderr, "et_assertf: %s()[%d]: "fmt"\n", \¬
 20 >------->------->------->------->-------__func__, __LINE__, ## __VA_ARGS__); \¬
 21 >------->------->-------assert(hr); \¬
 22 >------->-------} \¬
 23 >-------}while(0);¬
 24 ¬
 25 // Caution: depend gcc¬ 33 #define et_error(fmt, ...)  \¬
 34 >-------fprintf(stderr, "error: %s()[%d]: "fmt"\n", __func__, __LINE__, ## __VA_ARGS__)¬ 37 #define et_debug(fmt, ...)  \¬
 38 >-------fprintf(stdout, "debug: %s()[%d]: "fmt"\n", __func__, __LINE__, ## __VA_ARGS__)¬
 

===


...という感じです。
本当はもっといろいろありますし、どうしてこれが良さそうか、という理由も、いずれ書こうと思っています。
また、ここに書いたのとは別に Vim (その2) Advent Calendar 2016 にVimでCアプリケーションを開発する話を書く予定です。そちらもよろしくお願いします。

この記事は C言語 Advent Calendar 2016 の12日目の記事でした。
13日目の明日はyashi氏の「The Meson Build System」です。楽しみですね。

2016年10月28日金曜日

GdkPixbufを高速にリサイズ(cairo)


GdkPixbufのサイズ変更を、元画像500x500px から 出力画像100x100~10x10pxで行うと、どうやらとても遅くなるようです。



GDK_POINTER_MOTION_HINT_MASK を使わずに motion-notify-eventをそのまま再描画に投げている私も悪いのですが。
とはいえ GDK_POINTER_MOTION_HINT_MASK はGtk3で思った通りにならず、アプリケーションがフリーズするようになっていました。

将来的には描画前のレンダリングをマルチスレッド化するつもりではいます。しかしシングルスレッドだと競合などを考えずに済み楽であるため、どうにもならなくなるまではシングルスレッドで行くつもりです。

というわけで、単純にリサイズ機能を高速化して対応。このあたりも、cairo任せにするといろいろオブジェクトを確保するコストを考えてもずっと早いのではないかというカンが当たった感じです。


なお、 gdk_pixbuf_scale_simple()をそのまま、画質を GDK_INTERP_HYPER からバイリニア指定に変えるのは試してみましたが、ほとんど効果なしでした。

なお画質は不明。見た目にわからないですし悪くないですが、アプリケーションが将来的に画質を指定するようになったら、リサイズ機能を見直そうと思います。

呼び出し例は以下。
====
/*

 
GdkPixbuf *pb = gdk_pixbuf_scale_simple(

 

 

 
pixbuf,

 
 
 
(int)w, (int)h,
 
 
 
GDK_INTERP_HYPER);
*/

 
GdkPixbuf *pb = _pv_copy_new_pixbuf_scale(
 
 
 
pixbuf,
 
 
 
(int)w, (int)h);
====

実装は以下。
====
static GdkPixbuf *_pv_copy_new_pixbuf_scale(GdkPixbuf *pb_src, double w_dst, double h_dst)
{
 
cairo_surface_t *surface = cairo_image_surface_create (CAIRO_FORMAT_ARGB32, w_dst, h_dst);
 
pv_assert(surface);
 
cairo_t *cr = cairo_create (surface);
 
pv_assert(cr);

 
double w_src = gdk_pixbuf_get_width(pb_src);
 
double h_src = gdk_pixbuf_get_height(pb_src);

 
cairo_matrix_t m = {
 
 
w_dst/w_src, 0,
 
 
0, h_dst/h_src,
 
 
0, 0,
 
};
 
cairo_set_matrix(cr, &m);

 
gdk_cairo_set_source_pixbuf (cr, pb_src, 0, 0);
 
cairo_paint (cr);

 
GdkPixbuf *pb = gdk_pixbuf_get_from_surface(surface, 0, 0, w_dst, h_dst);
 
pv_assert(pb);

 
cairo_surface_destroy (surface);
 
cairo_destroy (cr);

 
return pb;
}
====

作ったPixbufは呼び出し元で開放しましょう。
以上です。

2016年10月15日土曜日

BLADE v7 liteについて(スマホ買いました)

BLADE v7 liteを買って、半年使ったので、本日レビューを書き散らします。
半分くらいAndroid6.0レビューみたいになるかも。
 
NTT-Xで2万円弱で買った。

BLADE v7 Liteと付属物

BLADE v7 Liteを選んだ理由は、Android6.0が使える端末で他に手頃なものが無かったから。
同価格のASUSのZenPhoneのほうがCPUが少し良いので、そちらでも良いかと思った。ノートPCはASUSなので揃えてみたかったし。
だが最終的に、ZenPhoneにはGPSに問題があるという話と、やはりAndroid5.xではなく6.0にしたいということでBLADE v7 liteにした。


開いてすぐBLADE v7 lite端末


多言語でオモテウラ有りのペライチ、マニュアルはこれっきり。


この端末、届いてから3週間近くSIMを待っていた。SIM契約のアテが外れたから。
初期設定でSIM設定をスキップすると、後が面倒そうだったので、WiFi運用などもせずバッグに放り込んでいた。この間ほぼ無充電だったが、2週間くらい放っておいてもBLADE v7 liteは普通に起動した。電波を掴んでいなかったからかもしれないが。

鎮座するBLADE v7 lite


途中で一度、Y!MobileのSIMが差し込まれた。
(店頭での動作確認。きちんとブラウザでWebサイトが見れることを確認した。通話は未確認)
Y!Mobileはパケット繰越しないと言われたためSIMを買わなかった。
UQMobileのSIMは試していない。店頭で契約しようとしたら、店員に「未対応端末では壊れるかもしれないからやめたほうがいいです」と静止されたから。これについては感謝している。次があればまたUQMobileを検討しよう、と思ったくらい。

閑話休題。

その後、MineoのSIMを契約して家で刺して、動いた。
Mineoの設定はあらかじめ登録されている。ユーザ名とパスワードも共通のものだったようで、デフォルトのままで動いた。SIMのMNP切替中に、何度か"モバイルデータの有効化"だったかを無駄にON/OFFしていたが、ともかく1時間も置いておいたらインターネットも通話もできるようになった。

なお、microSDは、秋葉原で1000円程度で買った32GBのTOSHIBA製を新規購入して入れた。

前の端末は3.5年前のAndroid4.2端末だった。電池がヘタっていたのと、ブラウザ(chromeその他問わず)が3タブほど開くと、タブ切り替えの度にページ再読み込みするのが不満だった。

BLADE v7 liteにして、ブラウザ再読み込みはかなり減った。chromeは前の端末でも最新版だったと思うし、CPU/memoryも前の端末とあまり違わないので、Android6.0の性能なのだろうと思う。

chromeの表示が豆腐になる問題も、システムアップデートを実行したら消えた。システムアップデートのサイズは忘れてしまったが、500MBも無かったと思う。

買ったばかりの端末だからか、電池の減りも少ない。前の端末は、行きにブラウザを開きつつ音楽を聞いていただけでも、会社で充電しないと帰宅中に電池切れでシャットダウンしていた。BLADE v7 liteにしてからはそれがない。試していないが、1日充電しなくても持つと思う。

以下、気にしていなかったのだけれど、新端末になってよかった点がふたつ。

前の端末ではほとんど読んでいなかった『通知』をよく見るようになった。前の端末で通知は不要なものが入り混じって読みづらかったし、整理する方法もわからなかった。今はSMSもGMailもSkypeメッセージも通知から知るし、ダブルクリックで飛んで読む。
前の端末は通知と思わしきLEDが常に点滅していて、未読のためか消えずに不愉快ですらあった。今はそういうことはない。新端末のLEDが光るとき、その色が何を示すのかは未だに知らないままだが。特に困ってはいない。

標準キーボードがよくなっていた。Simejiなどは入れたことがない。誤入力を起こさない工夫か
フリックなどの入力で指を動かす距離が少し増えたと思う。私が買ったBLADE v7 liteを触った友達も同じことを言っていたので、感覚としては間違いないと思う。
唯一残念なのは、Qwertyキーボードで日本語が打てないこと。これは設定変更でできるようになるのか、後で調べるつもり。今はチャットなどはQwertyキーボードでアルファベットだけ入力し、エセ英語で返事している。元から携帯であまり文字入力しないし。

テザリングの手間は変わっていない。あまり使われない機能なのだろう。あるいは、UIの位置を浅くすると、誤認識でテザリングが起動しそうとかあるのだろうか。
テザリングON/OFFボタンのアプリを探そうかとも思った。が、一部にAndroid6.0対応できているアプリがあるようなので、もう少し経って、必要になってからその時に探そうかと思う。

Android6.0からアプリケーションの権限が詳細に設定できるようになったが、こちらの恩恵はまだ受けていない。一部のアプリで細かく聞かれるようになっただけとも言える。現在はとりあえず、LINEに連絡先を読ませる許可を与えていない。はず。

BLADE v7 liteに付属するメールアプリケーションに登録アカウントを解除できない問題があるとのことだが、使っていない。GmailなのでGmailのアプリケーションを使っている。Mineoのメールアドレスは使っていないし、スマホに紐付けしているメインのメールアドレス以外は、すべてPCで扱うので。

この前実家に帰った際に歩きまわったが、ZenPhoneは知らないが、BLADE v7 liteはGPSは問題なかったと思う。
ポケモンGOはダウンロードして少しだけ動かしたが、まだ最初のポケモンをゲットしていないので動作確認としてはよくわからない。少し歩くとピカチュウ出るって本当ですか。


この1週間くらい、運用してきたレビューとしては以上の通り。

気になった現象は以下。

このレビューを書いている今日、帰りに音楽プレイヤーの音楽が止まった。
(再生表示のまま。再度再生すると続きが鳴った)
また、今日はじめて、Skypeクライアントがタップに反応しなくなったことが気になる。

音楽プレイヤーはアプリケーション側の問題かもしれないので、後でプレイヤーを変えてみる。Skypeクライアントの問題は、剥がれかけの保護フィルムのせいかもしれない。

保護フィルムは、買った時のものをまだ剥がしていないだけ。操作はできるが、剥がす前提なので一週間と持たず剥げてくる。
昨日、ヨドバシ.comでBLADE v7 lite専用の保護フィルムを注文したので、明日あたり届くと思う。

マイナAndroid端末は、保護フィルムもすぐに在庫されなくなるはず。前の端末もそうだった。といっても、前の端末と同じように、後半はフィルム無しで運用するつもりでいる。

安いAndroid端末の気楽さは、iPhoneなどと違って、壊れたらすぐに新しい端末に買い換えてしまえることだと思う。画面の割れたiPhoneを使い続けるよりは良いと思っている。
ケースには入れないつもり。保護する必要はないし、厚くしたくない。
ギリギリポケットに入るサイズなので、ポケットに入れて運用するつもり。
Android、特にマイナなAndroid端末は、ケースも汎用品などで限られてくる。iPhoneのようにたくさん有るケースを選びたい向きには向かない。



というわけで、今のところ BLADE v7 lite を気に入っている。
思えば、これまで携帯は仕方なく嫌々で買っていた。携帯電話を積極的に自分で選んだのは初めてである気がする。

2016年10月8日土曜日

Windows環境でMakeする際に起こるエラーと対処


Make オルタネイティヴは数あれど、小さな実験プロジェクトを始めるときに、簡単に使えるMakeは未だにビルドツールとして有力な選択肢だと思います。

MakefileはUNIX環境、というかCLIツール群があることを前提にしているところがあります。Windows環境ではUNIXコマンドがそもそも無かったりするため、Makefileが可搬ではないです。



GitHubに公開しているmkwin_mnでは、mkdir -p と rm -f を解決しました。
以下には ls find が無いことにより発生する問題もあり、wildcard関数による解決は満点とは言いがたいので、誰か対処してくれないかなと思っています。
Cygwin入れろと言われると返す言葉がないです。(MinGWといろいろ共存面倒そう、という言い訳がある。きちんと調べて対処すべきなのだろうけれど。)


 # ls, findが無いことにより起こるエラー


====
 process_begin: CreateProcess(NULL, sh C:\Users\nuka\Documents\etaion_20160920_22
h17m\etaion\library\gtk+-bundle_3.6.4-20130921_win32\bin\xml2-config --cflags --
libs, ...) failed.
cc1.exe: error: ./: No such file or directory [-Werror=missing-include-dirs]
source/pv_color.c:130:1: fatal error: opening dependency file object/pv_color.d:
 No such file or directory
 }
 ^
cc1.exe: all warnings being treated as errors
compilation terminated.
Makefile:40: recipe for target 'object/pv_color.o' failed
mingw32-make: *** [object/pv_color.o] Error 1
 process_begin: CreateProcess(NULL, ls source/*.c, ...) failed.

====

ルールによるビルドのために、ソースディレクトリ以下の *.c ファイルを探させます。Makefileを書くなら、大抵はこれをやらせます。
このとき、Make組み込みの wildcard 関数でなく、 shell lsshell find のように外部コマンドを呼び出していると、コマンドの無い環境でエラーが起こります。

wildcard()は子ディレクトリを再帰的に探索してはくれません。なので、以下のようなサブディレクトリのあるソースディレクトリ構成に対応できない問題が有ります。
src/
         + engine/
         + enemy/
サブディレクトリがそうそう増えないもので、階層も深く掘らないならば、サブディレクトリごとにwildcardを書いて、結果を加算していく



$(wildcard **.c) などとやると、子ディレクトリ内以下へ再帰的にマッチできるよ』
というStackOverflowに書いてあった小技。これの投稿の下に付いているコメント欄でも出来ない報告が書き込まれていましたが、わたしの環境ではUbuntu LinuxのGNU Make4.1でも使えなかったです。いったい何処由来のネタなのだろう。

閑話休題。



 # 出力先ディレクトリの生成に失敗したことにより起こるエラー


====
process_begin: CreateProcess(NULL, object, ...) failed.
make (e=2): wウスt@CェゥツゥワケB
Makefile:41: recipe for target 'object/pv_color.o' failed
mingw32-make: [object/pv_color.o] Error 2 (ignored)
 source/pv_color.c:130:1: fatal error: opening dependency file object/pv_color.d:
 No such file or directory
 }
 ^
compilation terminated.
Makefile:41: recipe for target 'object/pv_color.o' failed
mingw32-make: *** [object/pv_color.o] Error 1
====


出力先として想定ているobjectディレクトリが作れず、書き出し先が存在しないため、ファイルを作れなくて起こるエラーです。
mkdir -pが無いことが原因です。
GitHubに公開しているmkwin_mnでは、mkdir -p相当の機能を用意することで対処しています。
他に、objectなど、必要なディレクトリがあらかじめわかっているなら、object/.gitkeepなどを置いておいて、書き出し先ディレクトリを予めプロジェクトリポジトリに含めておくという手もあります。
その場合は誤って削除してしまわないよう注意。

以上です。

Gtk3でコンボボックス(ドロップダウン) Widgetを作る

Gtk3で、ComboBox(DropDown)を作るサンプルコードです。

これまでGtk3では公式ドキュメントを反面教師として、単体動作するコードをサンプルとして提示してきたつもりなのですが、今回は諦めました。すいません。なんというか、実用を目指すプロジェクトからコードを一部だけ、動く状態に抜き出すって無理ですね。



====
        // self->combo_linejoin = gtk_combo_box_new();
    //    GtkListStore *liststore = gtk_list_store_new(2, G_TYPE_STRING, G_TYPE_INT);
        GtkListStore *liststore = gtk_list_store_new(1, G_TYPE_STRING);
        int num = get_num_stroke_linejoin_infos();
        for(int i = 0; i < num; i++){
            const PvStrokeLinejoinInfo *info = get_stroke_linejoin_info_from_id(i);
            gtk_list_store_insert_with_values(liststore, NULL, -1,
                            0, info->name,
    //                        1, info->linejoin,
                            -1);
        }
        self->combo_linejoin = gtk_combo_box_new_with_model(GTK_TREE_MODEL(liststore));
        g_object_unref(liststore);
        GtkCellRenderer *column = gtk_cell_renderer_text_new();
        gtk_cell_layout_pack_start(GTK_CELL_LAYOUT(self->combo_linejoin), column, TRUE);
        gtk_cell_layout_set_attributes(GTK_CELL_LAYOUT(self->combo_linejoin), column,
                    "text", 0, NULL);
        gtk_combo_box_set_active(GTK_COMBO_BOX(self->combo_linejoin), 0);
        gtk_box_pack_start(GTK_BOX(self->box_linejoin), self->combo_linejoin, false, true, 3);
    }


====

ついでに使っている独自型などは以下。

====
 /*! @brief StrokeLinejoin */
typedef enum{
    PvStrokeLinejoin_Miter,
    PvStrokeLinejoin_Round,
    PvStrokeLinejoin_Bevel,
}PvStrokeLinejoin;

typedef struct{
    PvStrokeLinejoin linejoin;
    const char *name;
    int cairo_value;
}PvStrokeLinejoinInfo;

int get_num_stroke_linejoin_infos();
const PvStrokeLinejoinInfo *get_stroke_linejoin_info_from_id(PvStrokeLinejoin linejoin);


====

ドロップダウンリストの内容をGtkListStoreで作ります。それをGTK_TREE_MODEL形式でcombo_box_new_*()関数に流しこめば完了です。
一番重要なのはGtkListStoreがGtkTreeModelに変換できること、そしてそれがComboBoxに流し込めることです。

Python版コードなどを見てみると、GTK_TREE_MODELのところはタプルとか作ってそのまま流し込んでいて、確かに動的言語なら辞書配列が簡単に作れるし、それがコンボボックスの材料になるのも納得ですが、C言語だとこのなんだかしっくり来ない謎型変換をするコードになっています。

参考にしたのはこちら。
http://stackoverflow.com/questions/16630528/trying-to-populate-a-gtkcombobox-with-model-in-c
参考コードのほうが綺麗で完結していて読みやすいですね。
参考コードはコンボボックスの選択肢に色を付けるという愉快なサンプルコードになっていますが、これもしかしてここからオブジェクト取り出して選択した要素を一意に特定してコールバック処理の際に処理を分岐するとかの用途を想定しているんじゃないかな、私はコールバックの中でアクティブな選択肢の昇順を取ってきて、キャストなどもせず乱暴に元データのIndexに置き換えています。いずれはgpointer *data に選択肢のポインタそのまま投げ込んで判定するつもりだけれど、といった感じです。

====
g_signal_connect(self->combo_linecap, "changed",
            G_CALLBACK(_cb_changed_linecap_with_combo), NULL);


static void _cb_changed_linecap_with_combo(GtkComboBox *widget, gpointer user_data)
{
    EtStrokePanel *self = stroke_panel;
    assert(self);

    self->stroke.linecap = gtk_combo_box_get_active(GTK_COMBO_BOX(self->combo_linecap));

    _update_focus_elements_from_local();
}

====

以上です。

Gtk3アプリケーションをWindows環境でビルドした際に出たエラーと対処

ここでは、私の環境とビルド内容で出たGtk3固有のエラーとその対処について。Windows7 x64 と MinGWにて。

最初はビルド環境の構築その他を扱おうかと思ったのですが、他サイトでも少しづつ情報があるのでやめました。なんとなくできると思います。
Gtk2 Windows開発環境キットをGitHubにて公開しているので参考にどうぞ。
https://github.com/MichinariNukazawa?tab=repositories



今回は、gtk+-bundle_3.6.4-20130921_win32を使いましたが、見返してみると、
gtk+-bundle_3.10.4-20131202_win32.zip
とか、それなりに新しいのがありました。が、それでも2013年...。
その他バージョンなどダウンロードはこちらから。
http://win32builder.gnome.org/
この公式Gtk3パッケージ、バージョンを見ればわかるとおり、すでに非常に古いものとなっています。


 #  Gtk3バージョンが古いからか、未実装関数的なものがある?

====
 source/et_layer_view.c: In function 'et_layer_view_init':
source/et_layer_view.c:146:2: error: implicit declaration of function 'gtk_text_
view_set_monospace' [-Werror=implicit-function-declaration]
  gtk_text_view_set_monospace (GTK_TEXT_VIEW(self->text), TRUE);
  ^
cc1.exe: all warnings being treated as errors
Makefile:42: recipe for target 'object/et_layer_view.o' failed
mingw32-make: *** [object/et_layer_view.o] Error 1
====

対処:この関数だけWindows環境を判定してCソースにて #IFDEF 切って無効化しました。


 # SVG画像ファイルを読もうとすると失敗する。

実行時、それもSVG画像を読もうとしてはじめて発生するので、ちょっと厄介。
文字化けはGtk3の出力で別問題、今回は無視しています。
====
C:\Users\nuka\Documents\etaion_20160920_22h17m\etaion>make run
./build/etaion_vector.exe
debug: et_tool_init()[59]: 4
error: et_tool_init()[71]: 'サュシサ「ク・シォェュソセシセ: Z:/srv/win32builder/fixed_364/build
/win32/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.dll: `Z:/srv/win32b
uilder/fixed_364/build/win32/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-s
vg.dll': ョ「ク・シォヲ、セ€'
BUG: main()[81]:
Makefile:50: recipe for target 'run' failed
mingw32-make: *** [run] Error -1

C:\Users\nuka\Documents\etaion_20160920_22h17m\etaion>
 、
 'Unable to load image-loading module:
 ./build/etaion_vector.exe
debug: et_tool_init()[59]: 4
error: et_tool_init()[71]: 'Unable to load image-loading module: Z:/srv/win32bui
lder/fixed_364/build/win32/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg
.dll: `Z:/srv/win32builder/fixed_364/build/win32/lib/gdk-pixbuf-2.0/2.10.0/loade
rs/libpixbufloader-svg.dll': 指定されたモジãƒÂ
¥Ã£Æ’¼ãƒ«ãŒè¦‹ã¤ã‹ã‚Šã¾ã›ã‚“。'
BUG: main()[81]:
Makefile:50: recipe for target 'run' failed
mingw32-make: *** [run] Error -1
====

libpixbufloader-svg.dll が見つからないことが原因、とのことです。

gtk+-bundle_3.6.4-20130921_win32\lib\gdk-pixbuf-2.0\2.10.0\loaders.cacheを見ると、
====
 "Z:/srv/win32builder/fixed_364/build/win32/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.dll"
====
などと書いてあるので、相対パスなどで *svg.dll のロードをするよう書き換え。

====
C:\Users\nuka\Documents\etaion_20160920_22h17m\etaion>
 "library/gtk+-bundle_3.6.4-20130921_win32/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.dll"
====

以上です。