Re: [ruby-gnome2-devel-ja] vteの実装をしてみました

[Masaaki A. <mas...@gm...>]

青柳です。

>> それと、glib に GRegex を実装する必要があると思われます。
>
> うーん、Rubyの世界にもRegexpがあるので、できればGRegexは外に
> は出したくないんですよね。文字列化Regexpを渡すと中で勝手に
> GRegexに変換してあげるっていうのは難しいですよねぇ。

完全隠蔽は、難しいでしょうね。


>> * ブロック引数を受ける場合、rb_scan_args で"&"指定をする方法と rb_block_proc を使用する方法があるようですが、
>>　 ブロックを省略可能にする場合は、前者で行う必要があるということなのでしょうか？
>
> rb_block_procを使う場合もrb_block_given_p()で確認できます。
> （Rubyレベルのblock_given?と同じものです。）
>
> rb_scan_argsの"&"も中ではrb_block_given_p()とrb_block_proc()
> を使っているので、rb_scan_args()もrb_block_proc()もどちらも
> 同じです。ただ、rb_scan_args()は便利関数として提供されている
> ので、rb_scan_args()で事足りる場合はrb_scan_args()を使うのが
> よいかと思います。
>
>> * vte_terminal_fork_command_full の引数は、NULL許容のものをオプショナルとしています。
>>　 そのため、Cの引数と順番が異なってしまっていますが、どうするのが良いのでしょうか？
>
> Hashとして引数をとれるようにするのがよいかと思います。
> Ruby 1.9.3のrb_scan_args()は":"でそういうことができるように
> なった。。。のですが、あれ、なんかいま見たら思っていたより便
> 利になっていないですね。。。
>
> Hashの中身も変数に代入してくれるかと思っていたのですが、そこ
> まではやってくれないですねぇ。
>
> https://github.com/ranguba/rroonga/blob/master/ext/groonga/rb-grn-utils.c
> ここにrb_grn_scan_options()というのがあって、これを使うと
> rb_scan_args()のようにHashから各オプションの値を変数に代入し
> てくれます。あと、未知のオプションを指定したらエラーを報告し
> ます。
>
> 私が書いたものなので、持ってきてRuby-GNOME 2のライセンスに変
> 更して取り込んでも大丈夫です。
>
>
>> * vte_terminal_fork_command_full 自身の使い方がよく分からないです。
>>　 添付のサンプルファイルのようにしても、子プロセスの入出力がウィジェットに繋がらない？ような感じです。
>
> 見てみました。
> child_setupを指定する場合は、child_setup内で
> vte_pty_child_setup()を呼んであげないとダメみたいです。
>
>
> vte_terminal_fork_command()がdeprecatedで
> vte_terminal_fork_command_full()になったんですね。Rubyレベル
> ではどちらもTerminal#fork_commandになると使いやすそうな気が
> しますが、APIがかなり変わっているので難しそうですね。。。

教えて頂いたことを踏まえ、いくつか変更しましたので差分を添付します。
前回からの変更点は、
 * fork_command_full を Hash 引数に変更
 * 引数のデフォルトを fork_command に合わせる
 * ブロック引数を省略した場合は、child_setup を渡さないように
　これにより、ブロックを省略した場合は動くようになりましたが、ブロックを渡した場合は相変わらずよく分からない。。。
 * fork_command で引数を省略した際と Hash で渡した際は fork_command_full に処理を委譲する
 * vte_terminal_fork_command が使われる場合は、warning メッセージを出力する
 * search_get_wrap_around が"?"付きメソッドになっていなかったので修正
といったところです。
いかがでしょうか？


> search_{get,set}_XXXなんですが、{get,set}を先頭に持ってきて
> {get,set}_search_XXXにするのはいかがでしょうか？set_が先頭に
> ないとG_DEF_SETTERSでsearch_XXX=みたいなメソッドを自動生成す
> るやつが動かない気がするんです。
>
> でも、これもメソッド名の統一感的に難しそうですねぇ。うーん。

これは、以下の命名規則のページでも動詞の削除などをしないとされているので、個別対応となると思っています。
大して数はないので、それでいいのかなと。
http://ruby-gnome2.sourceforge.jp/hiki.cgi?Naming+and+Conversion+Rules

今回対象となるメソッドは、search_set_gregex と search_set_wrap_around ですが、
代入メソッドを定義した方が良いでしょうか？
また、見ていて気づいたのですが search_set_gregex はNULL許容のため、引数がオプショナルになっており
search_set_gregex()とコールするとNULLを渡した事になり、設定が解除されてしまいそうです。
引数を必須にしておいた方が良いでしょうか？