ruby-gnome2-devel-ja — Ruby-GNOME2 developer's Mailing list. in Japanese.

Re: [ruby-gnome2-devel-ja] 命名規則などの提案

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

青柳です。

> 関数の方もマクロの方もprefixは揃えた方がよいと思うので、
> rg_/RG_でいかがでしょうか！？

では、rg_poll のあたりの関数はいずれ変更するということで。
マクロの方は、RG_DEF_CONVERSION というのだけありますが、そのままでもいいでしょうか？

今までの内容をまとめると、

 * 1ファイル＝1名前空間（クラスまたはモジュール）とする
 * ファイル名は rb<名前空間>.c とし、名前空間のネストは - で繋ぐ
　例）Vte::Terminal → rbvte-terminal.c
 * 名前空間の変数名（RG_TARGET_NAMESPACE）は、m<モジュール名> または c<クラス名> とする
　（グローバルスコープの場合は、prefixとして rg_ を付ける）
　例）Vte::Terminal → cTerminal
 * rubyからのIFになっている関数名は、rg_<メソッド名> とする
　（シングルトンメソッドの場合は、rg_s_<メソッド名>、モジュール関数の場合は、rg_m_<メソッド名>）
　使用マクロ：RG_DEF_METHOD、RG_DEF_SMETHOD、RG_DEF_MODFUNC
 * ? 付きメソッドの関数名は、末尾に ? の代わりに _p を付ける
　使用マクロ：RG_DEF_METHOD_P、RG_DEF_SMETHOD_P、RG_DEF_MODFUNC_P
 * ! 付きメソッドの関数名は、末尾に ! の代わりに _bang を付ける
　使用マクロ：RG_DEF_METHOD_BANG
 * 演算子メソッドの関数名は、rg_(|s_|m_)operator_<任意> とする
　使用マクロ：RG_DEF_METHOD_OPERATOR、RG_DEF_SMETHOD_OPERATOR、RG_DEF_MODFUNC_OPERATOR

こんな感じで、よろしいでしょうか？

Re: [ruby-gnome2-devel-ja] 命名規則などの提案

[Kouhei S. <ko...@co...>]

須藤です。

In <CAM...@ma...>
  "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 16:33:33 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

>>> 他のprefixを考えた方がいいのかなと思ったのですけど、いかがでしょうか？
>>
>> 例えば、どんなのがよさそうでしょうか？
> 
> 単純に、rbif_ または rif_ というのは、いかがでしょうか？
> いずれも使われていませんでした。

ifですか。。。
他では見たことがない字面なのが気になりました。

うーん、そうですねぇ。
とすると、現在あまり使われていないrg_を使うのがよい気がして
きました。

> マクロの方のprefixは、使われていますが RBG_ でよろしいでしょうか？

↑もせっかくなのでキレイなところからスタートしたいですよね？
RG_なら1から決めていけるのでそっちの方がやりやすい気がします。


関数の方もマクロの方もprefixは揃えた方がよいと思うので、
rg_/RG_でいかがでしょうか！？

Re: [ruby-gnome2-devel-ja] 命名規則などの提案

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

青柳です。

>> 他のprefixを考えた方がいいのかなと思ったのですけど、いかがでしょうか？
>
> 例えば、どんなのがよさそうでしょうか？

単純に、rbif_ または rif_ というのは、いかがでしょうか？
いずれも使われていませんでした。
マクロの方のprefixは、使われていますが RBG_ でよろしいでしょうか？

Re: [ruby-gnome2-devel-ja] 命名規則などの提案

[Kouhei S. <ko...@co...>]

須藤です。

In <CAM...@ma...>
  "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 01:30:12 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

> 説明不足でしたが、「あるprefixを持った関数＝rubyからのIF」と言えるようにしたいと思っています。

なるほど。

> rbg_を使うとすると、例えば rbg_cstr2rval のようなIFになっていない関数は名前を変えたいですが
> グローバルスコープですし、それは難しいですよね？

そうですね。
やるなら、まずは、rbg_cstr2rval()を使ったらrb_warn()で警告が
でるようにして、しばらくしたら削除、という感じだと思います。

> rb_の方は、関数として使われているのは static の rg_poll のあたりなので名前の変更は出来るでしょうか。

こっちはすぐにできますね。

> 他のprefixを考えた方がいいのかなと思ったのですけど、いかがでしょうか？

例えば、どんなのがよさそうでしょうか？

Re: [ruby-gnome2-devel-ja] 命名規則などの提案

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

青柳です。

>> すみません、今調べたらrg_もrgb_も使っている箇所がありましたが、どうしましょう？
>> マクロのprefixも新たにしてマクロの整理も行う方向に持っていけたらベストでしょうか。
>
> そうですね。
> ざっと見てみたら、rg_よりもrbg_の方が多いので、rbg_に統一す
> る方向でいきましょう

説明不足でしたが、「あるprefixを持った関数＝rubyからのIF」と言えるようにしたいと思っています。
rbg_を使うとすると、例えば rbg_cstr2rval のようなIFになっていない関数は名前を変えたいですが
グローバルスコープですし、それは難しいですよね？
rb_の方は、関数として使われているのは static の rg_poll のあたりなので名前の変更は出来るでしょうか。
他のprefixを考えた方がいいのかなと思ったのですけど、いかがでしょうか？

Re: [ruby-gnome2-devel-ja] 命名規則などの提案

[Kouhei S. <ko...@co...>]

須藤です。

In <CAM...@ma...>
  "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 00:11:19 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

>> うーん、でも、ドキュメント化されていれば杞憂になるのかなぁと
>> いう気もします。今はここに書いてありますが、これから書くなら
>> Hikiじゃないところの方がいいですよねぇ。
>>  http://ruby-gnome2.sourceforge.jp/#For+Developers
>>  http://ruby-gnome2.sourceforge.jp/hiki.cgi?How+to+Implement+Ruby-GNOME2
> 
> yardドキュメントを埋め込む方向で今やっているので、ソースに書くのがいいのでしょうか？

YARDであれば、ソース以外にテキストファイルもドキュメントに加
えられるので、テキストファイルに書く方がよいと思います。たと
えば、これもソースとは別のファイルに書かれていると思います。
  http://rubydoc.info/docs/yard/0.7.1/file/docs/GettingStarted.md

> TARGET_NAMESPACEを隠蔽しようとしているのは、1ファイル＝1名前空間を強制させる意味が大きく
> ちょっとやりすぎ感は確かにあるのですが、この方式にしたいです。

わかりました。
では、そうしましょう。

>> LispとかRuby本体ではpredicateな関数・メソッド（述語。真偽値
>> を返す関数・メソッド）に?をつけるので、_qではなく_pの方がい
>> いかなぁと思いました。
> 
> predicateと言うのですか。
> では、_pでいいですかね。

では、_pにしましょう。

>>>  * ! 付きメソッドの関数名は、末尾に ! の代わりに _e を付ける
>>>　 使用マクロ：G_DEF_METHOD_E
>>
>> eはexclamationの略ですよね。
>> Ruby本体ではbangを使っているのでそっちにあわせる方がいいかなぁ
>> と思いましたが、_bだとなんだかわからないんですよねぇ。_bang
>> でもいい気がしますが、1文字がいいんですよね。うーん。
> 
> ! 付きメソッドは、それほど多くないはずなので、_bangでいいですかね。

では、こちらは_bangで。

> すみません、今調べたらrg_もrgb_も使っている箇所がありましたが、どうしましょう？
> マクロのprefixも新たにしてマクロの整理も行う方向に持っていけたらベストでしょうか。

そうですね。
ざっと見てみたら、rg_よりもrbg_の方が多いので、rbg_に統一す
る方向でいきましょう

>> やり過ぎ感をもう少し書いておくと、一回リポジトリからremoveす
>> る前のRuby/GIO2みたいな方向になっていくのを危惧しています。
>> ソースコードを見てもらえばわかると思うのですが、「たしかに
>> Rubyの拡張ライブラリを作っているCなんだけど、違う言語に見え
>> る」、という感じになっています。
>>
>> r3724で削除したので、これで見れると思います。
>>  http://ruby-gnome2.svn.sourceforge.net/viewvc/ruby-gnome2/ruby-gnome2/trunk/gio/?pathrev=3723
> 
> なるほど、似たようなことをやってらっしゃいますね。。。
> ただ、自分が考えているのは実装やドキュメントの不足チェックとテンプレート生成を自動化することが主な目的なので、
> 関数定義の部分まで手を突っ込むことはないと思います。

わかりました！
では、この方向でいきましょう！

Re: [ruby-gnome2-devel-ja] 命名規則などの提案

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

青柳です。

>> 自動化しやすくすることや冗長性を排除していくことを目的に、以下の規則を提案します。
>
> 目的は理解できます。
> が、少しやり過ぎかなぁという気がしました。

やっぱり、そう思われますか。


> うーん、でも、ドキュメント化されていれば杞憂になるのかなぁと
> いう気もします。今はここに書いてありますが、これから書くなら
> Hikiじゃないところの方がいいですよねぇ。
>  http://ruby-gnome2.sourceforge.jp/#For+Developers
>  http://ruby-gnome2.sourceforge.jp/hiki.cgi?How+to+Implement+Ruby-GNOME2

yardドキュメントを埋め込む方向で今やっているので、ソースに書くのがいいのでしょうか？


>>  * 1ファイル＝1名前空間（クラスまたはモジュール）とする
>
> よいと思います。
>
>>  * ファイル名は rb<名前空間>.c とし、名前空間のネストは - で繋ぐ
>>　 例）Vte::Terminal → rbvte-terminal.c
>
> よいと思います。
>
>>  * 名前空間の変数名（TARGET_NAMESPACE）は、m<モジュール名> とする
>>　 （クラスの場合は、c<クラス名>）
>>　 例）Vte::Terminal → cTerminal
>
> TARGET_NAMESPACEは↓のマクロとかでいろいろ暗黙的に使われるの
> で、やり過ぎかもなぁという気がしました。
> （でも、ドキュメント化で解決するかもとは思っています。）

TARGET_NAMESPACEを隠蔽しようとしているのは、1ファイル＝1名前空間を強制させる意味が大きく
ちょっとやりすぎ感は確かにあるのですが、この方式にしたいです。


> あと、名前が一般的なのでprefixをつけた方がいい気がしました。
> 個人的にはprefixは「RBG_」に統一したいなぁと思っていましたが、
> 「RG_」でもいいと思います。
>
> 変数名ですが、staticなやつはm<モジュール名>やc<クラス名>でよ
> いと思います。ただ、staticじゃないやつはprefixをつけた方がい
> いと思っています。今は、mGLibとかそのまま出ちゃっていますが、
> rbg_mGLibとかrg_mGLibにした方がいいと思っています。

確かに、そうですね。


>>  * rubyからのIFになっている関数名は、rg_<メソッド名> とする
>>　 （シングルトンメソッドの場合は、rg_s_<メソッド名>、モジュール関数の場合は、rg_m_<メソッド名>）
>
> いいと思います。
>
>>　 使用マクロ：G_DEF_METHOD、G_DEF_SMETHOD、G_DEF_MODFUNC
>
> 既存のマクロがG_DEF_はじまりなので揃えてくれたんですよね。
> でも、これをチャンスにG_ではないprefixにしてもいいかなぁと思っ
> ています。G_はGLibでも使っているので、同じのは使わないほうが
> いいかなぁと思っています。
>
> ↓のマクロ名も同じように思っています。
>
>>  * ? 付きメソッドの関数名は、末尾に ? の代わりに _q を付ける
>>　 使用マクロ：G_DEF_METHOD_Q、G_DEF_SMETHOD_Q、G_DEF_MODFUNC_Q
>
> qはquestionの略ですよね。
> LispとかRuby本体ではpredicateな関数・メソッド（述語。真偽値
> を返す関数・メソッド）に?をつけるので、_qではなく_pの方がい
> いかなぁと思いました。

predicateと言うのですか。
では、_pでいいですかね。


>>  * ! 付きメソッドの関数名は、末尾に ! の代わりに _e を付ける
>>　 使用マクロ：G_DEF_METHOD_E
>
> eはexclamationの略ですよね。
> Ruby本体ではbangを使っているのでそっちにあわせる方がいいかなぁ
> と思いましたが、_bだとなんだかわからないんですよねぇ。_bang
> でもいい気がしますが、1文字がいいんですよね。うーん。

! 付きメソッドは、それほど多くないはずなので、_bangでいいですかね。


>>  * 演算子メソッドの関数名は、rg_(|s_|m_)operator_<任意> とする
>>　 使用マクロ：G_DEF_METHOD_OPERATOR、G_DEF_SMETHOD_OPERATOR、G_DEF_MODFUNC_OPERATOR
>
> いいと思います。
>
>> 上記規則を適用した vte の変更したソース自体と差分を添付しますので、ご確認ください。
>> 現時点では、マクロを rbvte.h に定義していますが、全体に適用できることになったら glib2 に移動したいと考えています。
>> なお、コミットする際はいくつかの段階に分けて行う予定です。
>
> 個人的にはprefix関連は必ず解決したいことで、それ以外は青柳さ
> んの意見を尊重する方向でいいかなぁと思っています。

ありがとうございます！
すみません、今調べたらrg_もrgb_も使っている箇所がありましたが、どうしましょう？
マクロのprefixも新たにしてマクロの整理も行う方向に持っていけたらベストでしょうか。


> やり過ぎ感をもう少し書いておくと、一回リポジトリからremoveす
> る前のRuby/GIO2みたいな方向になっていくのを危惧しています。
> ソースコードを見てもらえばわかると思うのですが、「たしかに
> Rubyの拡張ライブラリを作っているCなんだけど、違う言語に見え
> る」、という感じになっています。
>
> r3724で削除したので、これで見れると思います。
>  http://ruby-gnome2.svn.sourceforge.net/viewvc/ruby-gnome2/ruby-gnome2/trunk/gio/?pathrev=3723

なるほど、似たようなことをやってらっしゃいますね。。。
ただ、自分が考えているのは実装やドキュメントの不足チェックとテンプレート生成を自動化することが主な目的なので、
関数定義の部分まで手を突っ込むことはないと思います。

Re: [ruby-gnome2-devel-ja] 命名規則などの提案

[Kouhei S. <ko...@co...>]

須藤です。

In <CAM...@ma...>
  "[ruby-gnome2-devel-ja] 命名規則などの提案" on Sat, 23 Jul 2011 19:37:58 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

> 自動化しやすくすることや冗長性を排除していくことを目的に、以下の規則を提案します。

目的は理解できます。
が、少しやり過ぎかなぁという気がしました。

うーん、でも、ドキュメント化されていれば杞憂になるのかなぁと
いう気もします。今はここに書いてありますが、これから書くなら
Hikiじゃないところの方がいいですよねぇ。
  http://ruby-gnome2.sourceforge.jp/#For+Developers
  http://ruby-gnome2.sourceforge.jp/hiki.cgi?How+to+Implement+Ruby-GNOME2

>  * 1ファイル＝1名前空間（クラスまたはモジュール）とする

よいと思います。

>  * ファイル名は rb<名前空間>.c とし、名前空間のネストは - で繋ぐ
> 　例）Vte::Terminal → rbvte-terminal.c

よいと思います。

>  * 名前空間の変数名（TARGET_NAMESPACE）は、m<モジュール名> とする
> 　（クラスの場合は、c<クラス名>）
> 　例）Vte::Terminal → cTerminal

TARGET_NAMESPACEは↓のマクロとかでいろいろ暗黙的に使われるの
で、やり過ぎかもなぁという気がしました。
（でも、ドキュメント化で解決するかもとは思っています。）

あと、名前が一般的なのでprefixをつけた方がいい気がしました。
個人的にはprefixは「RBG_」に統一したいなぁと思っていましたが、
「RG_」でもいいと思います。

変数名ですが、staticなやつはm<モジュール名>やc<クラス名>でよ
いと思います。ただ、staticじゃないやつはprefixをつけた方がい
いと思っています。今は、mGLibとかそのまま出ちゃっていますが、
rbg_mGLibとかrg_mGLibにした方がいいと思っています。

>  * rubyからのIFになっている関数名は、rg_<メソッド名> とする
> 　（シングルトンメソッドの場合は、rg_s_<メソッド名>、モジュール関数の場合は、rg_m_<メソッド名>）

いいと思います。

> 　使用マクロ：G_DEF_METHOD、G_DEF_SMETHOD、G_DEF_MODFUNC

既存のマクロがG_DEF_はじまりなので揃えてくれたんですよね。
でも、これをチャンスにG_ではないprefixにしてもいいかなぁと思っ
ています。G_はGLibでも使っているので、同じのは使わないほうが
いいかなぁと思っています。

↓のマクロ名も同じように思っています。

>  * ? 付きメソッドの関数名は、末尾に ? の代わりに _q を付ける
> 　使用マクロ：G_DEF_METHOD_Q、G_DEF_SMETHOD_Q、G_DEF_MODFUNC_Q

qはquestionの略ですよね。
LispとかRuby本体ではpredicateな関数・メソッド（述語。真偽値
を返す関数・メソッド）に?をつけるので、_qではなく_pの方がい
いかなぁと思いました。


>  * ! 付きメソッドの関数名は、末尾に ! の代わりに _e を付ける
> 　使用マクロ：G_DEF_METHOD_E

eはexclamationの略ですよね。
Ruby本体ではbangを使っているのでそっちにあわせる方がいいかなぁ
と思いましたが、_bだとなんだかわからないんですよねぇ。_bang
でもいい気がしますが、1文字がいいんですよね。うーん。

>  * 演算子メソッドの関数名は、rg_(|s_|m_)operator_<任意> とする
> 　使用マクロ：G_DEF_METHOD_OPERATOR、G_DEF_SMETHOD_OPERATOR、G_DEF_MODFUNC_OPERATOR

いいと思います。

> 上記規則を適用した vte の変更したソース自体と差分を添付しますので、ご確認ください。
> 現時点では、マクロを rbvte.h に定義していますが、全体に適用できることになったら glib2 に移動したいと考えています。
> なお、コミットする際はいくつかの段階に分けて行う予定です。

個人的にはprefix関連は必ず解決したいことで、それ以外は青柳さ
んの意見を尊重する方向でいいかなぁと思っています。


やり過ぎ感をもう少し書いておくと、一回リポジトリからremoveす
る前のRuby/GIO2みたいな方向になっていくのを危惧しています。
ソースコードを見てもらえばわかると思うのですが、「たしかに
Rubyの拡張ライブラリを作っているCなんだけど、違う言語に見え
る」、という感じになっています。

r3724で削除したので、これで見れると思います。
  http://ruby-gnome2.svn.sourceforge.net/viewvc/ruby-gnome2/ruby-gnome2/trunk/gio/?pathrev=3723

[ruby-gnome2-devel-ja] 命名規則などの提案

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

青柳です。

自動化しやすくすることや冗長性を排除していくことを目的に、以下の規則を提案します。

 * 1ファイル＝1名前空間（クラスまたはモジュール）とする
 * ファイル名は rb<名前空間>.c とし、名前空間のネストは - で繋ぐ
　例）Vte::Terminal → rbvte-terminal.c
 * 名前空間の変数名（TARGET_NAMESPACE）は、m<モジュール名> とする
　（クラスの場合は、c<クラス名>）
　例）Vte::Terminal → cTerminal
 * rubyからのIFになっている関数名は、rg_<メソッド名> とする
　（シングルトンメソッドの場合は、rg_s_<メソッド名>、モジュール関数の場合は、rg_m_<メソッド名>）
　使用マクロ：G_DEF_METHOD、G_DEF_SMETHOD、G_DEF_MODFUNC
 * ? 付きメソッドの関数名は、末尾に ? の代わりに _q を付ける
　使用マクロ：G_DEF_METHOD_Q、G_DEF_SMETHOD_Q、G_DEF_MODFUNC_Q
 * ! 付きメソッドの関数名は、末尾に ! の代わりに _e を付ける
　使用マクロ：G_DEF_METHOD_E
 * 演算子メソッドの関数名は、rg_(|s_|m_)operator_<任意> とする
　使用マクロ：G_DEF_METHOD_OPERATOR、G_DEF_SMETHOD_OPERATOR、G_DEF_MODFUNC_OPERATOR

上記規則を適用した vte の変更したソース自体と差分を添付しますので、ご確認ください。
現時点では、マクロを rbvte.h に定義していますが、全体に適用できることになったら glib2 に移動したいと考えています。
なお、コミットする際はいくつかの段階に分けて行う予定です。

Re: [ruby-gnome2-devel-ja] 未実装APIの抽出について

[Kouhei S. <ko...@co...>]

須藤です。

In <CAM...@ma...>
  "Re: [ruby-gnome2-devel-ja] 未実装APIの抽出について" on Sat, 23 Jul 2011 17:24:22 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

>>>   *  Copyright (C) 20XX-20XX  Ruby-GNOME2 Project Team
>>> の部分は、
>>>   *  Copyright (C) since 20XX  Ruby-GNOME2 Project Team
>>> の形式に出来ると嬉しいように思いますが、いかがでしょうか？
>>> よろしければ、今いじっている vte に早速適用したいです。
>>
>> 何もいじらなくてもCopyrightの年を増やしたいということですよ
>> ね。うーん、変更していないのに勝手に増やしてもいいのかなぁと
>> 思いました。
>>
>> たとえば、Ruby/VTEをforkして開発を始めたとしたら、そのプロジェ
>> クトのところでも、Ruby-GNOME2 Project TeamのCopyrightの年が
>> 増えていくと思います。でも、forkした後にRuby-GNOME2 Project
>> Teamがforkした方のソースコードをいじっていなければ、
>> Copyrightの年を増やすのはなんか違うかなぁという気がします。
> 
> Copyright表示の後ろの年限は、最後に改変した年という意味でも
> 著作権の有効期限という意味でもなく、後ろの年限自体に意味はないと
> 理解しています。

あ、そうなんですか。。。

> ただ、詳しいわけでは全然ないので、須藤さんの提案どおりにvteに適用した
> 差分を添付します。
> よろしければ、コミットします。

私も詳しいわけではないので、とりあえず、これでコミットお願い
します！


>>> 後、別件ですが、関数の定義文の形式が一部違っているので、添付の修正をしたいです。
>>> よろしければ、コミット致します。
>>
>> 確認しました。
>> コミットお願いします！
> 
> コミットしました。

ありがとうございます！

Re: [ruby-gnome2-devel-ja] 未実装APIの抽出について

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

青柳です。

>>   *  Copyright (C) 20XX-20XX  Ruby-GNOME2 Project Team
>> の部分は、
>>   *  Copyright (C) since 20XX  Ruby-GNOME2 Project Team
>> の形式に出来ると嬉しいように思いますが、いかがでしょうか？
>> よろしければ、今いじっている vte に早速適用したいです。
>
> 何もいじらなくてもCopyrightの年を増やしたいということですよ
> ね。うーん、変更していないのに勝手に増やしてもいいのかなぁと
> 思いました。
>
> たとえば、Ruby/VTEをforkして開発を始めたとしたら、そのプロジェ
> クトのところでも、Ruby-GNOME2 Project TeamのCopyrightの年が
> 増えていくと思います。でも、forkした後にRuby-GNOME2 Project
> Teamがforkした方のソースコードをいじっていなければ、
> Copyrightの年を増やすのはなんか違うかなぁという気がします。

Copyright表示の後ろの年限は、最後に改変した年という意味でも
著作権の有効期限という意味でもなく、後ろの年限自体に意味はないと
理解しています。
ただ、詳しいわけでは全然ないので、須藤さんの提案どおりにvteに適用した
差分を添付します。
よろしければ、コミットします。


>> 後、別件ですが、関数の定義文の形式が一部違っているので、添付の修正をしたいです。
>> よろしければ、コミット致します。
>
> 確認しました。
> コミットお願いします！

コミットしました。

Re: [ruby-gnome2-devel-ja] 未実装APIの抽出について

[Kouhei S. <ko...@co...>]

須藤です。

In <CAM...@ma...>
  "Re: [ruby-gnome2-devel-ja] 未実装APIの抽出について" on Fri, 22 Jul 2011 21:14:57 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

> 長いこと放置してて、すみません。

いえいえ！
青柳さんがいろいろやってくれたおかげで1.0.0がリリースできま
した！（特にgem化とかdeprecatedなやつのdropとか）
ありがとうございます！

>>> * 添付したファイルのようなテンプレートファイルを出力するようにしましたが、
>>>    スタイル等、問題がありますでしょうか？
>>>    vte-pty.c は、クラス自体が新規の場合で、vte-terminal.c は既存クラスにメソッドを追加する場合です。
>>
>> これは
>>    if(error)
>>        RAISE_GERROR(error);
>>
>> こうして欲しいです。
>>    if (error)
>>        RAISE_GERROR(error);
> 
> 修正しました。

ありがとうございます！

>>> * 以下の enum は Vte::Terminal 配下に定義されるべきな気がしますが、いかがでしょうか？
>>>    * Vte::TerminalAntiAlias
>>
>> これはdeprecatedみたいですね。
>>
>>>    * Vte::TerminalCursorBlinkMode
>>>    * Vte::TerminalCursorShape
>>>    * Vte::TerminalEraseBinding
>>
>> Vte::TerminalCursorBlinkMode::SYSTEMとかの他に
>> Vte::Terminal::CURSOR_BLINK_SYSTEMとかを作るということです
>> よね？
> 
> これは、Vte::TerminalCursorBlinkMode::SYSTEM ではなく
> Vte::Terminal::CursorBlinkMode::SYSTEM のようにすべきでは?という意味でしたが、
> 定数まわりは、他にも思うところがあったので、別件にて相談させてください。

わかりましたー

>>> * パッケージによって、ソースファイル名の命名規則が統一されていないので、
>>>    統一したいと思うのですが、いかがでしょうか？
>>
>> いいと思います。
>>
>> 私はrb#{パッケージのプレフィックス}-XXX-YYY.cとかがいいです。
>>
>> なので、Ruby/VTEは↑の規則ですが、Ruby/GTK2は↑の規則に沿っ
>> ていないことになります。
>>
>> どういうのがよさそうでしょうか？
> 
> こちらも、ファイル名以外の規則の提案もしたいので、別件にて相談させてください。

はい。

>>>    その際、ソースファイルの先頭にファイル名をコメントとして埋め込んでいますが、
>>>    もし必要ないのであれば、消してしまいたいのですが、いかがでしょうか？
>>
>> いいと思います。
>>
>> たぶん、ソースの先頭のコメントのフォーマットも決めたいですよ
>> ね？今は独自のスタイルになっていますが、標準的な方がいいなぁ
>> と思います。なので、こんなフォーマットはいかがでしょうか？
>> Copyright表記とライセンス表記のみです。
>>
>>  /* -*- c-file-style: "ruby"; indent-tabs-mode: nil -*- */
>>  /*
>>   *  Copyright (C) 20XX-20XX  Ruby-GNOME2 Project Team
>>   *
>>   *  This library is free software; you can redistribute it and/or
>>   *  modify it under the terms of the GNU Lesser General Public
>>   *  License as published by the Free Software Foundation; either
>>   *  version 2.1 of the License, or (at your option) any later version.
>>   *
>>   *  This library is distributed in the hope that it will be useful,
>>   *  but WITHOUT ANY WARRANTY; without even the implied warranty of
>>   *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>   *  Lesser General Public License for more details.
>>   *
>>   *  You should have received a copy of the GNU Lesser General Public
>>   *  License along with this library; if not, write to the Free Software
>>   *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
>>   *  MA  02110-1301  USA
>>   */
> 
>   *  Copyright (C) 20XX-20XX  Ruby-GNOME2 Project Team
> の部分は、
>   *  Copyright (C) since 20XX  Ruby-GNOME2 Project Team
> の形式に出来ると嬉しいように思いますが、いかがでしょうか？
> よろしければ、今いじっている vte に早速適用したいです。

何もいじらなくてもCopyrightの年を増やしたいということですよ
ね。うーん、変更していないのに勝手に増やしてもいいのかなぁと
思いました。

たとえば、Ruby/VTEをforkして開発を始めたとしたら、そのプロジェ
クトのところでも、Ruby-GNOME2 Project TeamのCopyrightの年が
増えていくと思います。でも、forkした後にRuby-GNOME2 Project
Teamがforkした方のソースコードをいじっていなければ、
Copyrightの年を増やすのはなんか違うかなぁという気がします。


でも、別のプロジェクトでsinceを使っているものがあれば、
Ruby-GNOME2でも真似していいかなぁとは思います。そういうプロジェ
クトを知っていますか？


> 後、別件ですが、関数の定義文の形式が一部違っているので、添付の修正をしたいです。
> よろしければ、コミット致します。

確認しました。
コミットお願いします！

Re: [ruby-gnome2-devel-ja] 未実装APIの抽出について

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

青柳です。
長いこと放置してて、すみません。

>> * 添付したファイルのようなテンプレートファイルを出力するようにしましたが、
>>    スタイル等、問題がありますでしょうか？
>>    vte-pty.c は、クラス自体が新規の場合で、vte-terminal.c は既存クラスにメソッドを追加する場合です。
>
> これは
>    if(error)
>        RAISE_GERROR(error);
>
> こうして欲しいです。
>    if (error)
>        RAISE_GERROR(error);

修正しました。


>> * 以下の enum は Vte::Terminal 配下に定義されるべきな気がしますが、いかがでしょうか？
>>    * Vte::TerminalAntiAlias
>
> これはdeprecatedみたいですね。
>
>>    * Vte::TerminalCursorBlinkMode
>>    * Vte::TerminalCursorShape
>>    * Vte::TerminalEraseBinding
>
> Vte::TerminalCursorBlinkMode::SYSTEMとかの他に
> Vte::Terminal::CURSOR_BLINK_SYSTEMとかを作るということです
> よね？

これは、Vte::TerminalCursorBlinkMode::SYSTEM ではなく
Vte::Terminal::CursorBlinkMode::SYSTEM のようにすべきでは?という意味でしたが、
定数まわりは、他にも思うところがあったので、別件にて相談させてください。


>> * パッケージによって、ソースファイル名の命名規則が統一されていないので、
>>    統一したいと思うのですが、いかがでしょうか？
>
> いいと思います。
>
> 私はrb#{パッケージのプレフィックス}-XXX-YYY.cとかがいいです。
>
> なので、Ruby/VTEは↑の規則ですが、Ruby/GTK2は↑の規則に沿っ
> ていないことになります。
>
> どういうのがよさそうでしょうか？

こちらも、ファイル名以外の規則の提案もしたいので、別件にて相談させてください。


>>    その際、ソースファイルの先頭にファイル名をコメントとして埋め込んでいますが、
>>    もし必要ないのであれば、消してしまいたいのですが、いかがでしょうか？
>
> いいと思います。
>
> たぶん、ソースの先頭のコメントのフォーマットも決めたいですよ
> ね？今は独自のスタイルになっていますが、標準的な方がいいなぁ
> と思います。なので、こんなフォーマットはいかがでしょうか？
> Copyright表記とライセンス表記のみです。
>
>  /* -*- c-file-style: "ruby"; indent-tabs-mode: nil -*- */
>  /*
>   *  Copyright (C) 20XX-20XX  Ruby-GNOME2 Project Team
>   *
>   *  This library is free software; you can redistribute it and/or
>   *  modify it under the terms of the GNU Lesser General Public
>   *  License as published by the Free Software Foundation; either
>   *  version 2.1 of the License, or (at your option) any later version.
>   *
>   *  This library is distributed in the hope that it will be useful,
>   *  but WITHOUT ANY WARRANTY; without even the implied warranty of
>   *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>   *  Lesser General Public License for more details.
>   *
>   *  You should have received a copy of the GNU Lesser General Public
>   *  License along with this library; if not, write to the Free Software
>   *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
>   *  MA  02110-1301  USA
>   */

  *  Copyright (C) 20XX-20XX  Ruby-GNOME2 Project Team
の部分は、
  *  Copyright (C) since 20XX  Ruby-GNOME2 Project Team
の形式に出来ると嬉しいように思いますが、いかがでしょうか？
よろしければ、今いじっている vte に早速適用したいです。


後、別件ですが、関数の定義文の形式が一部違っているので、添付の修正をしたいです。
よろしければ、コミット致します。

[ruby-gnome2-devel-ja] [ANN] Ruby-GNOME2 1.0.0

[Kouhei S. <ko...@co...>]

須藤です。

Ruby-GNOME2プロジェクトはRuby-GNOME2 1.0.0をリリースしまし
た。
  http://downloads.sourceforge.net/ruby-gnome2/ruby-gtk2-1.0.0.tar.gz
  http://downloads.sourceforge.net/ruby-gnome2/ruby-gnome2-all-1.0.0.tar.gz

初のメジャーリリースです！
最初にリリースされた0.1が2002-11-23らしいので、実に9年越しの
メジャーリリースです。長かったですねぇ。

開発に参加してくれたみなさん、使ってくれているみなさん、あり
がとうございます！

=== インストール方法

  % gem install gtk2

=== このリリースの概要

初のメジャーリリースです！

=== 変更点

==== ドキュメント

  * 修正
    * READMEの非推奨リストを更新
      [Michal Suchanek, Kouhei Sutou]

==== Ruby/GLib2

  * 改良
    * GLib::IOChannelWin32Socketとして
      g_io_channel_win32_new_socket()をバインドしました。
      [Kouhei Sutou]

  * 修正
    * [#3312572] カッコ忘れを修正しました。
      [Evan Phoenix]

=== 感謝

  * Evan Phoenixさん
  * Michal Suchanekさん

[ruby-gnome2-devel-ja] [ANN] Ruby-GNOME2 0.90.9

[Kouhei S. <ko...@co...>]

須藤です。

Ruby-GNOME2プロジェクトはRuby-GNOME2 0.90.9をリリースしまし
た。
  http://downloads.sourceforge.net/ruby-gnome2/ruby-gtk2-0.90.9.tar.gz
  http://downloads.sourceforge.net/ruby-gnome2/ruby-gnome2-all-0.90.9.tar.gz

今回はVincent Carmonaさんが付属のサンプルスクリプトのRuby
1.9対応をやってくれました。実際に作業してくれたVincent
Carmonaさん、この作業を切り分けてみんなにお願いすればいいんじゃ
ない？とアイディアをくれた青柳さん、ありがとうございます！

=== インストール方法

  % gem install gtk2

=== このリリースの概要

0.90.8のバグフィックスリリースです。

そして、このリリースが0.90.x系の最後のリリースになります。
次のリリースはついに1.0.0になります！

=== 変更点

==== 全体

  * 修正
    * バージョン番号の問題を修正。
      [Grant Schoep, Vincent Carmona]
    * 'bundle install'の修正。

==== Ruby/GLib2

  * 改良
    * Windows上でのGLib::IOChannel.new(fd)、
      GLib::IOChannel#fd対応。
    * GLib::IOChannel#writeがselfではなく書き込んだバイト数
      を返すようになった。
      [後方非互換]

==== Ruby/GTK2

  * 修正
    * サンプルmisc/bindings.rbがRuby 1.9でも動くようになった。
      [Vincent Carmona]
    * [#3305589] Gtk::Window#add_accel_groupが追加するaccel
      groupの参照を持っていない問題を修正。
      [Piotr Korzuszek, Kouhei Sutou]
    * Ruby 1.9でcairo関連のサンプルが動かない問題を修正。
      [Jon, Kouhei Sutou]

==== Ruby/GStreamer

  * 改良
    * Gst::Registry.updateを追加。
      [Vincent Carmona]

==== Ruby/VTE

  * 修正
    * [#3199587] .pcのインストール関連の問題を修正。
      [OBATA Akio, Kouhei Sutou]

==== Ruby/Poppler

  * 修正
    * [#3292118] 必要のないテストを実行しないようにした。
      [Mamoru Tasaka, Kouhei Sutou]

==== Ruby/GtkSourceView2

  * 改良
    * Windows対応。
      [S.Kitagawa]

=== 感謝

  * Vincent Carmonaさん
  * おばたさん
  * Grant Schoepさん
  * Mamoru Tasakaさん
  * Piotr Korzuszekさん
  * S.Kitagawaさん
  * Jonさん

Re: [ruby-gnome2-devel-ja] プロジェクトページについて

[Kouhei S. <ko...@co...>]

須藤です。

In <201...@co...>
  "Re: [ruby-gnome2-devel-ja] プロジェクトページについて" on Thu, 24 Mar 2011 21:21:11 +0900 (JST),
  Kouhei Sutou <ko...@co...> wrote:

> In <AAN...@ma...>
>   "Re: [ruby-gnome2-devel-ja] プロジェクトページについて" on Wed, 23 Mar 2011 23:04:16 +0900,
>   ta...@gm... wrote:
> 
>> themeもまとめて指定したディレクトリにだせるようにしようとしています。
>> hikilconfall.rb に theme のパスを指定させようと考えているのですが、
>> 1点確認したいことがあります。
>> 
>> 現在、使用されているthemeは、リポジトリ内の
>> hiki/cgi-bin/hiki/theme
>> のものという認識であっているでしょうか?
> 
> あっています！

これ、もうやってくれていたのですね。
ありがとうございます！

（すみません、気づいていませんでした。。。）

ということで、静的HTMLへの変換を始めました。
内部リンクまわりでおかしくなるところがあるので、微調整してい
ます。

で、静的HTMLに変換するだけでも遅すぎるなぁと思って、Hiki本体
を少しいじったらだいぶ早くなりました。
（Hikiのmasterでは今回の問題はなさそうです。）

同様の変更をruby-gnome2.sourceforge.jpにも適用したらだいぶマ
シになりました。ほとんど5XXはでなくなったんじゃないかと思い
ます。
  http://ruby-gnome2.sourceforge.jp/

ただ、↓のページなどリンク先おかしくなっているところがあった
りします。（ページがあるのにないと認識されている。）
  http://ruby-gnome2.sourceforge.jp/hiki.cgi?Status

この問題も静的HTMLにするやつもちょこちょこと進めていこうと思
います。

Re: [ruby-gnome2-devel-ja] gtksourceview2-0.90.8-x86-mingw32 の gtksourceview2.rb について

[Kouhei S. <ko...@co...>]

須藤です。

In <214...@ni...>
  "[ruby-gnome2-devel-ja] gtksourceview2-0.90.8-x86-mingw32 の gtksourceview2.rb について" on Mon, 23 May 2011 04:20:51 +0900 (JST),
  "S.Kitagawa" <mxk...@ni...> wrote:

> 北川です。連絡先がこちらでいいのかわかりませんが、とりあえず投稿します。

はい！OKです！

> gtksourceview2-0.90.8のサンプルスクリプトが動かなかったので、試行錯誤した
> ところ、gtksourceview2.rbを以下のように修正することで動きました。パッチ(?)
> でなくてすみません。

ありがとうございます！
取り込みました！

> 書く必要はないと思いますが、こちらの環境はWindows XP/Ruby 1.9.2です。

いえいえー。
あると助かります。

[ruby-gnome2-devel-ja] gtksourceview2-0.90.8-x86-mingw32 の gtksourceview2.rb について

[S.Kitagawa <mxk...@ni...>]

北川です。連絡先がこちらでいいのかわかりませんが、とりあえず投稿します。

gtksourceview2-0.90.8のサンプルスクリプトが動かなかったので、試行錯誤した
ところ、gtksourceview2.rbを以下のように修正することで動きました。パッチ(?)
でなくてすみません。

（前）

require 'gtksourceview2.so'

（後）

base_dir = Pathname.new(__FILE__).dirname.dirname.expand_path
vendor_dir = base_dir + "vendor" + "local"
vendor_bin_dir = vendor_dir + "bin"
GLib.prepend_environment_path(vendor_bin_dir)
begin
  major, minor, micro, = RUBY_VERSION.split(/¥./)
  require "#{major}.#{minor}/gtksourceview2.so"
rescue LoadError
  require "gtksourceview2.so"
end

修正後のスクリプトはgtk2のbase.rbにあったものを一部改変しました。

書く必要はないと思いますが、こちらの環境はWindows XP/Ruby 1.9.2です。

Re: [ruby-gnome2-devel-ja] プロジェクトページについて

[<ta...@gm...>]

takkanmです。

すみません。だいぶ遅れてしまいましたが、
 * FrontPage.htmlをindex.htmlにする。
 * /theme/もoutdir以下にコピー。
 * /theme/を絶対パスから相対パスにする。
を実装したものをpushしました。

以上です。

2011年3月24日21:21 Kouhei Sutou <ko...@co...>:
> 須藤です。
>
> In <AAN...@ma...>
>  "Re: [ruby-gnome2-devel-ja] プロジェクトページについて" on Wed, 23 Mar 2011 23:04:16 +0900,
>  ta...@gm... wrote:
>
>> themeもまとめて指定したディレクトリにだせるようにしようとしています。
>> hikilconfall.rb に theme のパスを指定させようと考えているのですが、
>> 1点確認したいことがあります。
>>
>> 現在、使用されているthemeは、リポジトリ内の
>> hiki/cgi-bin/hiki/theme
>> のものという認識であっているでしょうか?
>
> あっています！
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> ruby-gnome2-devel-ja mailing list
> rub...@li...
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-ja
>

Re: [ruby-gnome2-devel-ja] プロジェクトページについて

[Kouhei S. <ko...@co...>]

須藤です。

In <AAN...@ma...>
  "Re: [ruby-gnome2-devel-ja] プロジェクトページについて" on Wed, 23 Mar 2011 23:04:16 +0900,
  ta...@gm... wrote:

> themeもまとめて指定したディレクトリにだせるようにしようとしています。
> hikilconfall.rb に theme のパスを指定させようと考えているのですが、
> 1点確認したいことがあります。
> 
> 現在、使用されているthemeは、リポジトリ内の
> hiki/cgi-bin/hiki/theme
> のものという認識であっているでしょうか?

あっています！

Re: [ruby-gnome2-devel-ja] プロジェクトページについて

[<ta...@gm...>]

takkanmです。

themeもまとめて指定したディレクトリにだせるようにしようとしています。
hikilconfall.rb に theme のパスを指定させようと考えているのですが、
1点確認したいことがあります。

現在、使用されているthemeは、リポジトリ内の
hiki/cgi-bin/hiki/theme
のものという認識であっているでしょうか?



2011年3月10日22:33  <ta...@gm...>:
> takkanmです。
>
> Linuxからだと、正常にcloneできてpushできました。
>
> 環境を作れたら、残りの機能をつくっていきます。
>
> 2011年3月8日22:46  <ta...@gm...>:
>> takkanm です。
>> 2011/03/08 22:27 "Kouhei Sutou" >  % git checkout .
>>>
>>> したらもとに戻りませんか？
>> checkout, reset --hardしても、戻らない感じですねぇ。。。
>> とりあえず、そのファイルを.gitignoreにすればよいかと思い試したのですが、
>> それもダメでした。。。
>>
>> ちょっと、Linuxいれて試してみようかと思います。
>

Re: [ruby-gnome2-devel-ja] プロジェクトページについて

[<ta...@gm...>]

takkanmです。

Linuxからだと、正常にcloneできてpushできました。

環境を作れたら、残りの機能をつくっていきます。

2011年3月8日22:46  <ta...@gm...>:
> takkanm です。
> 2011/03/08 22:27 "Kouhei Sutou" >  % git checkout .
>>
>> したらもとに戻りませんか？
> checkout, reset --hardしても、戻らない感じですねぇ。。。
> とりあえず、そのファイルを.gitignoreにすればよいかと思い試したのですが、
> それもダメでした。。。
>
> ちょっと、Linuxいれて試してみようかと思います。

Re: [ruby-gnome2-devel-ja] Gtk::Window#add_accel_group と Gtk::Entry の干渉

[Kouhei S. <ko...@co...>]

須藤です。

In <AAN...@ma...>
  "Re: [ruby-gnome2-devel-ja] Gtk::Window#add_accel_group と Gtk::Entry の干渉" on Sat, 19 Feb 2011 03:13:43 -0500,
  Sawada Tsuyoshi <saw...@gm...> wrote:

> 新しいルビーが出たようなので、アップグレードしました。環境は
> ruby 1.9.2p180 (2011-02-18 revision 30909) [i686-linux]
> gtk2 (0.90.7)
> になりましたが、同じ問題が続いています。お時間のとれるときに対応していただけたら幸です。

この問題が再現する人っていますか？
相変わらず私の手元だと再現しないです。。。

In <AAN...@ma...>
  "[ruby-gnome2-devel-ja] Gtk::Window#add_accel_group と Gtk::Entry の干渉" on Sat, 19 Feb 2011 01:09:02 -0500,
  Sawada Tsuyoshi <saw...@gm...> wrote:

> Gtk::Window#add_accel_group
> を使って、キーを割り当てようとするとき、Gtk::Entry（またはGtk::TextView）がWindow内にあり、かつキーが押されたときに実行されるべきブロックの中にある種のメソッド（例えばputs）があると、イベントが２重に発生するのですが、これは仕様ですか。１回しか発生させないようにするにはどうしたらいいですか。
> 
> 具体的には、下のコードで、(a), (b)の行のうちの一方がコメントアウトされたとき、1回Ctrl-Aをおすと、
> 
> This does not duplicate the event
> 
> と表示されますが、(a), (b)がともにある場合には、１回Ctrl-Aをおすと、
> 
> This does not duplicate the event
> But this does
> This does not duplicate the event
> But this does
> 
> と表示されてしまいます。
> 
> -------　コード　--------------------------------------------
> require 'gtk2'
> ag = Gtk::AccelGroup.new.
> connect(Gdk::Keyval::GDK_A, Gdk::Window::CONTROL_MASK, Gtk::ACCEL_VISIBLE) {
> 	p 'This does not duplicate the event'
> 	puts "But this does" # (a)
> }
> 
> Gtk::Window.new.
> add(Gtk::Entry.new). # (b)
> add_accel_group(ag).show_all
> Gtk.main
> -----------------------------------------------------------------

Re: [ruby-gnome2-devel-ja] 未実装APIの抽出について

[Kouhei S. <ko...@co...>]

須藤です。

In <AAN...@ma...>
  "Re: [ruby-gnome2-devel-ja] 未実装APIの抽出について" on Sat, 5 Mar 2011 09:24:08 +0900,
  青柳政聡 <mas...@gm...> wrote:

> 未実装APIを抽出してテンプレートファイルを出力するスクリプトを、ある程度書いたので、
> 試しにテンプレートファイルを元に vte の実装をしたいと考えています。

おぉ！

> そこで、いくつか確認させてください。
> 
> * 添付したファイルのようなテンプレートファイルを出力するようにしましたが、
>    スタイル等、問題がありますでしょうか？
>    vte-pty.c は、クラス自体が新規の場合で、vte-terminal.c は既存クラスにメソッドを追加する場合です。

これは
    if(error)
        RAISE_GERROR(error);

こうして欲しいです。
    if (error)
        RAISE_GERROR(error);

後はよさそうな気がします。


> * 以下の enum は Vte::Terminal 配下に定義されるべきな気がしますが、いかがでしょうか？
>    * Vte::TerminalAntiAlias

これはdeprecatedみたいですね。

>    * Vte::TerminalCursorBlinkMode
>    * Vte::TerminalCursorShape
>    * Vte::TerminalEraseBinding

Vte::TerminalCursorBlinkMode::SYSTEMとかの他に
Vte::Terminal::CURSOR_BLINK_SYSTEMとかを作るということです
よね？

いいと思います。


> * パッケージによって、ソースファイル名の命名規則が統一されていないので、
>    統一したいと思うのですが、いかがでしょうか？

いいと思います。

私はrb#{パッケージのプレフィックス}-XXX-YYY.cとかがいいです。

なので、Ruby/VTEは↑の規則ですが、Ruby/GTK2は↑の規則に沿っ
ていないことになります。

どういうのがよさそうでしょうか？

>    その際、ソースファイルの先頭にファイル名をコメントとして埋め込んでいますが、
>    もし必要ないのであれば、消してしまいたいのですが、いかがでしょうか？

いいと思います。

たぶん、ソースの先頭のコメントのフォーマットも決めたいですよ
ね？今は独自のスタイルになっていますが、標準的な方がいいなぁ
と思います。なので、こんなフォーマットはいかがでしょうか？
Copyright表記とライセンス表記のみです。

  /* -*- c-file-style: "ruby"; indent-tabs-mode: nil -*- */
  /*
   *  Copyright (C) 20XX-20XX  Ruby-GNOME2 Project Team
   *
   *  This library is free software; you can redistribute it and/or
   *  modify it under the terms of the GNU Lesser General Public
   *  License as published by the Free Software Foundation; either
   *  version 2.1 of the License, or (at your option) any later version.
   *
   *  This library is distributed in the hope that it will be useful,
   *  but WITHOUT ANY WARRANTY; without even the implied warranty of
   *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   *  Lesser General Public License for more details.
   *
   *  You should have received a copy of the GNU Lesser General Public
   *  License along with this library; if not, write to the Free Software
   *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
   *  MA  02110-1301  USA
   */

Re: [ruby-gnome2-devel-ja] プロジェクトページについて

[<ta...@gm...>]

takkanm です。
2011/03/08 22:27 "Kouhei Sutou" >  % git checkout .
>
> したらもとに戻りませんか？
checkout, reset --hardしても、戻らない感じですねぇ。。。
とりあえず、そのファイルを.gitignoreにすればよいかと思い試したのですが、
それもダメでした。。。

ちょっと、Linuxいれて試してみようかと思います。