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

[ruby-gnome2-devel-ja] Re: =?iso-2022-jp?B?R0xpYjIbJEJGSSRzJEckXyReJDckPxsoQg==?=

[Masahiro S. <s01...@sf...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] Re: GLib2読んでみました
Date: Thu, 20 Jun 2002 01:56:00 +0900

> > - mark用の関数をtype markerとして使うのは無理があるので、gobj_markは消す。
> > - cinfo->freeが本当に要らないのかどうかは確信が持てないので保留。
> > - rbgobj_lookup_*のAPIを練り直すことで、cinfoがNULLにならないようにする。
> > 
> > って感じでどうでしょうか。
> 
> 良いですね。特に3つ目で、cinfoがNULLになる場合を想定するというのが変な
> 感じがしてました。

ではそうしましょう。

> あ、なんかわかってきたような。
> rbgobj_object.cでこれを登録しているって言うことは、
> ひょっとして、全てのGValue(当然GObjectも含む)<->VALUEの変換を
> rbgobj_gvalue_to_rvalue(),rbgobj_rvalue_to_gvalue()でやって
> しまうというのが意図ですか？ ・・・（１）

その通りです。
# ただ、現在登録されている変換関数は圧倒的に不足していてますが。

> > 2.でrefしなくても実質的にはうまく行くんじゃないかとは思ってますが、
> > これは気持悪いし、あまり自信がないです。
> > 一方、2.でrefする事にすると、initialize側でunrefする必要があるはずで、
> > 面倒臭そう……
> 
> initialize側で毎回unrefするというのは実装上、バグが多発しそうな気がします。
> と考えると2.でrefしないというのも手ですよね。

そうですね。最初は気持悪いと思っていたのですが、
rbgobj_set_gobject()の用法を、initializeでのこの使い方に限定すれば、
refしないのがむしろ自然だという気が段々としてきました。

> > floating object の事とか見落としていたので、
> > リファレンスカウンタについては、ちゃんと考え直そうと思います。
> 
> うぅぅ。ついていけませんでした(-_-;)。
> ＃私もついていけるように勉強します。

http://developer.gnome.org/doc/API/2.0/gtk/gtkobject.html
を見ると、以下のように書かれています。

The most interesting difference between GtkObject and GObject is the
"floating" reference count. A GObject is created with a reference
count of 1, owned by the creator of the GObject. (The owner of a
reference is the code section that has the right to call
g_object_unref() in order to remove that reference.) A GtkObject is
created with a reference count of 1 also, but it isn't owned by
anyone; calling g_object_unref() on the newly-created GtkObject is
incorrect. Instead, the initial reference count of a GtkObject is
"floating". The floating reference can be removed by anyone at any
time, by calling gtk_object_sink(). gtk_object_sink() does nothing if
an object is already sunk (has no floating reference).

多分互換性のためだと思うけど、気持悪いなぁ。

でも、何となく分かってきた気がする……
単にgtkの方のset_gobject()を以下のように変更すれば、
最小限の変更で現在のコードと整合性が取れそう。

void
set_gobject(obj, gtkobj)
    VALUE obj;
    GtkObject *gtkobj;
{
    gtkobj = gtk_object_ref(gtkobj);
    gtk_object_sink(gtkobj);
    rbgobj_set_gobject(obj, G_OBJECT(gtkobj));
}

> > > さらに、INT2FIXみたいなマクロを用意するとスッキリするかも。
> > > 
> > >  GOBJ2GVAL()
> > >  RVAL2GVAL()
> > >  GOBJ2RVAL()
> > >  RVAL2GOBJ()
> 
> もし、（１）の部分が正しいのであれば、上記は
> 
> > >  RVAL2GVAL()
> > >  GVAL2RVAL()
> 
> の２つですみます？

GValueを得ても、実際に具体的な操作をするには
さらにそこからGObject*等を取り出さなくてはいけないので、
他の二つもあった方が便利で良いと思います。


ところで、この辺りのAPIを整理しようと
gtkディレクトリとgnomeディレクトリのソースを眺めていて、
make_gobject()が思いの外使われていることに気が付きました。

rbgtk.cで使われているものを除いて、これらは全て
get_value_from_gobject()で必要十分だと思うのですが、
make_gobject()が敢えて使われているのには何か理由があるのでしょうか?

make_gobject()は、gtk/glib側のオブジェクトとRuby側のオブジェクトの
一対一対応関係を崩す危険があるので、APIとしては廃止したいのです。

-- さかい

PS:
glibのコーディングスタイルで、指摘された部分は修正しました。
他にも合っていない部分があったら直して下さいませ。

PPS:
Ruby/Gtkって
http://www.gtk.org/bindings.html
には載ってないんですね……

Re: [ruby-gnome2-devel-ja] Re: =?ISO-2022-JP?B?R0xpYjIbJEJGSRsoQg==?= =?ISO-2022-JP?B?GyRCJHMkRyRfJF4kNyQ/GyhC?=

[Masao M. <mu...@hi...>]

むとうです。

On Wed, 19 Jun 2002 15:20:18 +0900
Masahiro Sakai <s01...@sf...> wrote:

> さかいです。
 
> > > XXXと書いたのは、cinfo->freeを呼ばなくしてしまった事についてでした。
> > > 何故そうしたかというと、先のメールでは書き忘れてしまいましたが
> > > GObjectのリファレンスカウンタを実験的に使おうとしていたからです。
> > > 
> > > ちゃんと呼ぶようにも出来るのですが、cinfo->freeは現在使われていないので、
> > > 後回しでいっかと思って。(^^;;
> > 
> > えっと、まぁそうなんですが、使わないなら、gobj_mark()もいらなくなりますし
> > この際、削除した方がスッキリすると思います。
> 
> - mark用の関数をtype markerとして使うのは無理があるので、gobj_markは消す。
> - cinfo->freeが本当に要らないのかどうかは確信が持てないので保留。
> - rbgobj_lookup_*のAPIを練り直すことで、cinfoがNULLにならないようにする。
> 
> って感じでどうでしょうか。

良いですね。特に3つ目で、cinfoがNULLになる場合を想定するというのが変な
感じがしてました。
 
> > ふと思ったのですが、g_object_ref/unref前後（じゃなくても良いけど）のGObject
> > ってmalloc/freeって必要ないんですかね....。
> 
> えっと、ちょっと想像できないのですが、どういうことでしょう?

ごめんなさい。ちょっと寝ぼけてた（る）かも...。
忘れてください。
 
> > あ、ちょっと説明が悪かったですね。実は、Init_gobject_gobj()内の
> > 
> > rbgobj_register_r2g_func(rbgobj_cGObject, &_gobject_from_ruby);
> > rbgobj_register_g2r_func(G_TYPE_OBJECT, &_gobject_to_ruby);
> > 
> > の意図がちょっとわからなかったんです。
> > これって何を意図してるんでしょうか。
> 
> rbgobj_cGObjectの派生クラス用のVALUE->GValueの変換関数として、
> _gobject_from_ruby() を登録し、
> G_TYPE_OBJECTの派生タイプ用のGValue->VALUEの変換関数として
> _gobject_to_ruby() を登録しています。

あ、なんかわかってきたような。
rbgobj_object.cでこれを登録しているって言うことは、
ひょっとして、全てのGValue(当然GObjectも含む)<->VALUEの変換を
rbgobj_gvalue_to_rvalue(),rbgobj_rvalue_to_gvalue()でやって
しまうというのが意図ですか？ ・・・（１）
 
> # そういえば、この辺りはGClosureを使うようにしたときに
> # だいぶヘボいコードにしてしまったので、rbgobj_closure.cの方とあわせて、
> # どなたか改良して貰えると助かります。

じゃ、おいおいやっていきましょう。
 
> > > リファレンスカウンタについては僕もだいぶ混乱しているのですが、
> > > 現状だと、各クラスのinitializeの実装はunrefしないので、
> > > ここでrefしてしまうのはまずそうな気がします。
> > > # もちろん、unrefするようにinitializeの方を変更すれば良いのですが……
> > 
> > initializeの方でunrefって、unrefしたオブジェクトを使い回すということに
> > なるので、ちょっと気持ち悪い気がします。
> 
> initializeからリターンする前に最初のリファレンスをunrefしても、
> set_gobject()でのrefによってRubyのオブジェクト自身が
> 新しいリファレンスを保持している事になるので、
> 僕はあんまし気持悪いとは感じてません。
> 
> > > 1. initializeメソッド内で、hogehoge_new()を呼び出して、
> > >    新しく作成されたオブジェクトのリファレンスを得る。
> > >    この時点で、リファレンスカウンタは1
> > 
> > これって、例えば、rbgtkbutton.cのbutton_initialize()とかのことを言ってますか？
> > どこでリファレンスカウンタが1になるのでしたっけ。ちょっとわからないんですが...。
> 
> その例でしたら、gtk_button_new()からリターンした時点で
> 既にリファレンスカウンタは1になっていると思います。
> ちなみに、具体的に1をセットしているのはg_object_init()

あぁ、そうか。それならrefの方は不要ですね。

> # と思ったら、gtk+側では floating object なんて概念もあるのか。
> # ややこしい……
>
> > > 5. glib側のオブジェクトは解放されない。
> > 
> > えっと、これって今のRuby/GTKの実装がってことでいいでしょうか？
> 
> 「他を変更せずにset_objectでrefするようにすると」です。
> 
> > さかいさん的には、2.でrefしなくても良いんじゃないかって解釈で良いでしょうか？
> 
> 2.でrefしなくても実質的にはうまく行くんじゃないかとは思ってますが、
> これは気持悪いし、あまり自信がないです。
> 一方、2.でrefする事にすると、initialize側でunrefする必要があるはずで、
> 面倒臭そう……

initialize側で毎回unrefするというのは実装上、バグが多発しそうな気がします。
と考えると2.でrefしないというのも手ですよね。

> 
> と思っていたのですが、
> floating object の事とか見落としていたので、
> リファレンスカウンタについては、ちゃんと考え直そうと思います。

うぅぅ。ついていけませんでした(-_-;)。
＃私もついていけるように勉強します。


> > さらに、INT2FIXみたいなマクロを用意するとスッキリするかも。
> > 
> >  GOBJ2GVAL()
> >  RVAL2GVAL()
> >  GOBJ2RVAL()
> >  RVAL2GOBJ()

もし、（１）の部分が正しいのであれば、上記は

> >  RVAL2GVAL()
> >  GVAL2RVAL()

の２つですみます？
それだと、 G2VALUE, VALUE2Gでも良いかも（短すぎ？）。

> この名前短くて良いですね。
> # そういえば、rvalueやRVALって「右辺値」を連想してしまいそう。(^^;;

ははは。GVALはGlobal Valueを連想してしまったりして。
まぁ、たくさん使われる名前だから覚えてもらえるでしょう。


-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] Re: =?iso-2022-jp?B?R0xpYjIbJEJGSSRzJEckXyReJDckPxsoQg==?=

[Masahiro S. <s01...@sf...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] Re: GLib2読んでみました
Date: Tue, 18 Jun 2002 00:36:20 +0900

> まずはシンプルにして頭の中を整理したいなと。

そうですね。

> んじゃ、いったん削除しましょう。GErrorを実装するときがあれば
> そのときにまた考えましょう。

了解。

> > XXXと書いたのは、cinfo->freeを呼ばなくしてしまった事についてでした。
> > 何故そうしたかというと、先のメールでは書き忘れてしまいましたが
> > GObjectのリファレンスカウンタを実験的に使おうとしていたからです。
> > 
> > ちゃんと呼ぶようにも出来るのですが、cinfo->freeは現在使われていないので、
> > 後回しでいっかと思って。(^^;;
> 
> えっと、まぁそうなんですが、使わないなら、gobj_mark()もいらなくなりますし
> この際、削除した方がスッキリすると思います。

- mark用の関数をtype markerとして使うのは無理があるので、gobj_markは消す。
- cinfo->freeが本当に要らないのかどうかは確信が持てないので保留。
- rbgobj_lookup_*のAPIを練り直すことで、cinfoがNULLにならないようにする。

って感じでどうでしょうか。

> ふと思ったのですが、g_object_ref/unref前後（じゃなくても良いけど）のGObject
> ってmalloc/freeって必要ないんですかね....。

えっと、ちょっと想像できないのですが、どういうことでしょう?

> あ、ちょっと説明が悪かったですね。実は、Init_gobject_gobj()内の
> 
> rbgobj_register_r2g_func(rbgobj_cGObject, &_gobject_from_ruby);
> rbgobj_register_g2r_func(G_TYPE_OBJECT, &_gobject_to_ruby);
> 
> の意図がちょっとわからなかったんです。
> これって何を意図してるんでしょうか。

rbgobj_cGObjectの派生クラス用のVALUE->GValueの変換関数として、
_gobject_from_ruby() を登録し、
G_TYPE_OBJECTの派生タイプ用のGValue->VALUEの変換関数として
_gobject_to_ruby() を登録しています。
 
> > > ・gobj_smethod_added()って何に使うんでしょうか？
> > 
> > シグナルハンドラを特異メソッドとして書くためのもののようです。
> 
> 具体的にはどのようなコードを意図してるんでしょうか。
> 
> win = Gtk::Window.new
> win.singleton_method_added(?????)
> ????
> あり？全然イメージできないです....。ごめんなさい、教えてください。

yashiさんの書いている通りだと思います。

# そういえば、この辺りはGClosureを使うようにしたときに
# だいぶヘボいコードにしてしまったので、rbgobj_closure.cの方とあわせて、
# どなたか改良して貰えると助かります。

> > リファレンスカウンタについては僕もだいぶ混乱しているのですが、
> > 現状だと、各クラスのinitializeの実装はunrefしないので、
> > ここでrefしてしまうのはまずそうな気がします。
> > # もちろん、unrefするようにinitializeの方を変更すれば良いのですが……
> 
> initializeの方でunrefって、unrefしたオブジェクトを使い回すということに
> なるので、ちょっと気持ち悪い気がします。

initializeからリターンする前に最初のリファレンスをunrefしても、
set_gobject()でのrefによってRubyのオブジェクト自身が
新しいリファレンスを保持している事になるので、
僕はあんまし気持悪いとは感じてません。

> > 1. initializeメソッド内で、hogehoge_new()を呼び出して、
> >    新しく作成されたオブジェクトのリファレンスを得る。
> >    この時点で、リファレンスカウンタは1
> 
> これって、例えば、rbgtkbutton.cのbutton_initialize()とかのことを言ってますか？
> どこでリファレンスカウンタが1になるのでしたっけ。ちょっとわからないんですが...。

その例でしたら、gtk_button_new()からリターンした時点で
既にリファレンスカウンタは1になっていると思います。
ちなみに、具体的に1をセットしているのはg_object_init()

# と思ったら、gtk+側では floating object なんて概念もあるのか。
# ややこしい……

> > 5. glib側のオブジェクトは解放されない。
> 
> えっと、これって今のRuby/GTKの実装がってことでいいでしょうか？

「他を変更せずにset_objectでrefするようにすると」です。

> さかいさん的には、2.でrefしなくても良いんじゃないかって解釈で良いでしょうか？

2.でrefしなくても実質的にはうまく行くんじゃないかとは思ってますが、
これは気持悪いし、あまり自信がないです。
一方、2.でrefする事にすると、initialize側でunrefする必要があるはずで、
面倒臭そう……

と思っていたのですが、
floating object の事とか見落としていたので、
リファレンスカウンタについては、ちゃんと考え直そうと思います。

> さらに、INT2FIXみたいなマクロを用意するとスッキリするかも。
> 
>  GOBJ2GVAL()
>  RVAL2GVAL()
>  GOBJ2RVAL()
>  RVAL2GOBJ()

この名前短くて良いですね。
# そういえば、rvalueやRVALって「右辺値」を連想してしまいそう。(^^;;

-- さかい

Re: [ruby-gnome2-devel-ja] Re: =?ISO-2022-JP?B?R0xpYjIbJEJGSRsoQg==?= =?ISO-2022-JP?B?GyRCJHMkRyRfJF4kNyQ/GyhC?=

[Masao M. <mu...@hi...>]

むとうです。こんばんわ。

やすしさんご無沙汰です(^^;)。

On Tue, 18 Jun 2002 02:59:44 +0900
Yasushi Shoji <ya...@ya...> wrote:

> やすしです。
> 
> わかるとこだけ…

ありがとうございます、助かります。

> > > > ・gobj_smethod_added()って何に使うんでしょうか？
> > > 
> > > シグナルハンドラを特異メソッドとして書くためのもののようです。
> > 
> > 具体的にはどのようなコードを意図してるんでしょうか。
> > 
> > win = Gtk::Window.new
> 
> def win.show
>   # do some
> end
> 
> ってな具合に、object winに特異メソッドを定義すると ruby は 
> Object#singleton_method_addedを呼びだすので、gobj_smethod_added()で 
> overrideしてあるはず。

なるほど、そういえば、五十嵐さんの書かれたRuby/GTKの記事
にもbutton.clickedみたいなのが載ってた記憶が...。
と思ったら、README.EXTにも書いてありますね(^^;)。


-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Re: =?ISO-2022-JP?B?R0xpYjI=?= =?ISO-2022-JP?B?GyRCRkkkcyRHJF8kXiQ3JD8bKEI=?=

[Yasushi S. <ya...@ya...>]

やすしです。

わかるとこだけ…

At Tue, 18 Jun 2002 00:36:20 +0900,
Masao Mutoh wrote:

[...]

> > > ・gobj_smethod_added()って何に使うんでしょうか？
> > 
> > シグナルハンドラを特異メソッドとして書くためのもののようです。
> 
> 具体的にはどのようなコードを意図してるんでしょうか。
> 
> win = Gtk::Window.new

def win.show
  # do some
end

ってな具合に、object winに特異メソッドを定義すると ruby は 
Object#singleton_method_addedを呼びだすので、gobj_smethod_added()で 
overrideしてあるはず。

# はずしてたらごめんなさい…
--
       yashi

Re: [ruby-gnome2-devel-ja] Re: =?ISO-2022-JP?B?R0xpYjIbJEJGSRsoQg==?= =?ISO-2022-JP?B?GyRCJHMkRyRfJF4kNyQ/GyhC?=

[Masao M. <mu...@hi...>]

むとうです。

まずはシンプルにして頭の中を整理したいなと。

On Mon, 17 Jun 2002 03:52:06 +0900
Masahiro Sakai <s01...@sf...> wrote:

> さかいです。
(略)
> > rbglib.c:
> > 前から疑問だったのですが...gErrorって使っていないですよね。
> > もし使っていないようだったら削除しちゃいませんか？
> >     gError = rb_define_class_under(mGLib, "Error", rb_eRuntimeError);
> 
> 使っていないとは思いますが、
> glib-2.0ではエラーを一手に扱うGErrorという構造体があるので、
> ひょっとしたらそれをラップする事もあるかなと思って、
> 一応そのまま持ってきました。

んじゃ、いったん削除しましょう。GErrorを実装するときがあれば
そのときにまた考えましょう。

> > rbgobj_object.c:

> >   ・/* XXX */のところでcinfoがNULLの時ってあるんですか？
> > 　　異常系のみの場合は、rb_bug()かなんかの方が良くないですか？
> 
> XXXと書いたのは、cinfo->freeを呼ばなくしてしまった事についてでした。
> 何故そうしたかというと、先のメールでは書き忘れてしまいましたが
> GObjectのリファレンスカウンタを実験的に使おうとしていたからです。
> 
> ちゃんと呼ぶようにも出来るのですが、cinfo->freeは現在使われていないので、
> 後回しでいっかと思って。(^^;;

えっと、まぁそうなんですが、使わないなら、gobj_mark()もいらなくなりますし
この際、削除した方がスッキリすると思います。

ふと思ったのですが、g_object_ref/unref前後（じゃなくても良いけど）のGObject
ってmalloc/freeって必要ないんですかね....。

> > ・clear_gobject()って使う予定アリですか？
> 
> これもgtkからそのまま持ってきました。
> gtkではgobj_destroy()がこの関数を使っているようですが、
> GtkObjectと違ってGObjectにはdestroyが無いのでglibでは不要のはず。
> gtkの方ではどうだろう……

gtkのgobj_destroy()の中でもあえて別関数化する必要は無さそうですねぇ。
当初は何か意図があったのかもしれませんが、これもいったん削除ということで。
 
> > ・_gobject_to_ruby(), _gobject_from_ruby()って何に使うんですか？
> > 　（不勉強ですみません）
> 
> rbgobj_gvalue_to_rvalue()とrbgobj_rvalue_to_gvalue()による
> VALUE<->GValueの相互自動変換に使われます。

あ、ちょっと説明が悪かったですね。実は、Init_gobject_gobj()内の

rbgobj_register_r2g_func(rbgobj_cGObject, &_gobject_from_ruby);
rbgobj_register_g2r_func(G_TYPE_OBJECT, &_gobject_to_ruby);

の意図がちょっとわからなかったんです。
これって何を意図してるんでしょうか。
 
> > ・gobj_smethod_added()って何に使うんでしょうか？
> 
> シグナルハンドラを特異メソッドとして書くためのもののようです。

具体的にはどのようなコードを意図してるんでしょうか。

win = Gtk::Window.new
win.singleton_method_added(?????)
????
あり？全然イメージできないです....。ごめんなさい、教えてください。
 
> > ・rbgobj_param_spec_get_struct()とrbgobj_param_spec_wrap()って、
> > 　Ruby/GTKで言うところのget_xxxxとmake_xxxxですよね....。この辺の
> > 　名称ってできればRuby/GTK統一したいですね...。
> > 　＃この辺、後述します。
> 
> rbgobj_param.cは手をつけてはみたけど、今のコードは捨てたいなぁ。
> GObjectでないGTypeInstanceをうまく扱えるような枠組みを作った上で、
> 書き直したい感じ。

ひとまず、Ruby/GTKなんかに影響しない範囲であれば一度ざっくり削っちゃ
っていただいて構いません。

> > ・rbgobj_class_infoですが、新たに2つのメンバを追加しませんか。
> > 　
> 扱う対象をGObjectの派生クラスに限定するならば、
> refとunrefはg_object_ref(),g_object_unref()だけでおっけーのはずなので、
> ref,unrefは不要だと思います。
> # gtk_object_ref(), gtk_widget_ref(), etc... はただの糖衣構文。

おぉ。なるほど、気づきませんでした。なら不要ですね。

> > んで、rbgobj_gobject.cのrbgobj_set_gobject()を以下のような感じ。
> > ----------------
> > void
> > rbgobj_set_gobject(obj, gobj)
> >     VALUE obj;
> >     GObject* gobj;
> > {
> >     VALUE data;
> > 
> >     const rbgobj_class_info* cinfo = rbgobj_lookup_class(rb_class_of(obj));
> > 
> >     if (cinfo)
> > 	cinfo->ref(gobj);
> 
> リファレンスカウンタについては僕もだいぶ混乱しているのですが、
> 現状だと、各クラスのinitializeの実装はunrefしないので、
> ここでrefしてしまうのはまずそうな気がします。
> # もちろん、unrefするようにinitializeの方を変更すれば良いのですが……

initializeの方でunrefって、unrefしたオブジェクトを使い回すということに
なるので、ちょっと気持ち悪い気がします。

> ストーリィ
> 
> 1. initializeメソッド内で、hogehoge_new()を呼び出して、
>    新しく作成されたオブジェクトのリファレンスを得る。
>    この時点で、リファレンスカウンタは1

これって、例えば、rbgtkbutton.cのbutton_initialize()とかのことを言ってますか？
どこでリファレンスカウンタが1になるのでしたっけ。ちょっとわからないんですが...。


> 2. set_gobject()する
>    ここでrefしてリファレンスカウンタは2になる。
>    新しいリファレンスはrb_cDataのインスタンスが持っている。
> 
> 3. initializeからリターン
>    ここではunrefしていないので、リファレンスカウンタは2のまま。
> 
> 4. Ruby側のラッパがGCされる。
>    rb_cDataのインスタンスが持っていたリファレンスがunrefされるので、
>    リファレンスカウンタは1
> 
> 5. glib側のオブジェクトは解放されない。

えっと、これって今のRuby/GTKの実装がってことでいいでしょうか？
さかいさん的には、2.でrefしなくても良いんじゃないかって解釈で良いでしょうか？
 
> > rbgobj_value.cのrbgobj_gvalue_to_rvalue()とrbgobj_rvalue_to_gvalue()ですが、
> > これって、結局のところVALUE<->GValueの相互自動変換ですよね？
> 
> そうです。
> シグナルハンドラの引数と返り値の変換を個別に書かなくても
> 良いようにするために導入してみました。
> 
> > であれば、rbgobj_make_gobject()とかも同様のメソッド名で統一できたらすっきり
> > しそうな気がするのですがいかがでしょう？
> > 
> > rbgobj_gvalue2r()
> > rbgobj_r2gvalue()
> > rbgobj_gobj2r()　　→ rbgobj_get_value_from_gobject(),rbgobj_make_gobject()の置き換え
> > rbgobj_r2gobj()　　→rbgobj_get_gobject()の置き換え
> 
> これも賛成。
> 多分、問題ないと思います。

さらに、INT2FIXみたいなマクロを用意するとスッキリするかも。

 GOBJ2GVAL()
 RVAL2GVAL()
 GOBJ2RVAL()
 RVAL2GOBJ()

-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] Re: =?iso-2022-jp?B?R0xpYjIbJEJGSSRzJEckXyReJDckPxsoQg==?=

[Masahiro S. <s01...@sf...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: [ruby-gnome2-devel-ja] GLib2読んでみました
Date: Mon, 17 Jun 2002 01:15:47 +0900

> さかいさんのglibですが、遅ればせながらざっと見てみました。
> 短い期間にここまで作るのってすごいですね。私には無理かも...(^^;)。

どういたしまして。
# でも、基本的にはgtkの方からコードを持ってきただけなので、
# そんな大した仕事じゃなかったですよん。

> 他の方も何かコメントあったらメールしてくださいね。
> ここって、Ruby-GNOME2のキモの部分だと思いますんで奮ってご参加ください。
> ＃このメールに対しても、glibのソースに対してでも構いません。

そうそう。僕からもお願いします。
今のコードはただの「たたき台」だと思って、
色々と改良してもらえると助かります。

> ====
> 全体：
> ・関数の宣言を他(gtkとか)と合わせませんか？
>   static
>   VALUE hoge
>     ↓
>   static VALUE
>   hoge

そうですね。
合わせようと思います。

> rbglib.c:
> 前から疑問だったのですが...gErrorって使っていないですよね。
> もし使っていないようだったら削除しちゃいませんか？
>     gError = rb_define_class_under(mGLib, "Error", rb_eRuntimeError);

使っていないとは思いますが、
glib-2.0ではエラーを一手に扱うGErrorという構造体があるので、
ひょっとしたらそれをラップする事もあるかなと思って、
一応そのまま持ってきました。

> rbgobj_object.c:
> ・rbgobj_set_gobj()で、
>   ・Data_Wrap_Struct(rb_cData, cinfo->mark, &g_object_unref, gobj);
>     って、&が必要ですか？（gtkなんかはこのパターンの時、使っていないので...）

あってもなくても、C言語の仕様的に同じはずです。
gtkに合わせて消しましょう。

>   ・/* XXX */のところでcinfoがNULLの時ってあるんですか？
> 　　異常系のみの場合は、rb_bug()かなんかの方が良くないですか？

XXXと書いたのは、cinfo->freeを呼ばなくしてしまった事についてでした。
何故そうしたかというと、先のメールでは書き忘れてしまいましたが
GObjectのリファレンスカウンタを実験的に使おうとしていたからです。

ちゃんと呼ぶようにも出来るのですが、cinfo->freeは現在使われていないので、
後回しでいっかと思って。(^^;;

> ・clear_gobject()って使う予定アリですか？

これもgtkからそのまま持ってきました。
gtkではgobj_destroy()がこの関数を使っているようですが、
GtkObjectと違ってGObjectにはdestroyが無いのでglibでは不要のはず。
gtkの方ではどうだろう……

> ・rbgobj_make_gobject()を廃止してrbgobj_make_gobject_auto_type()に
> 　統合しちゃマズイですかね？

むとうさんの下の提案にあるように、結局
rbgobj_get_value_from_gobject()相当のものさえあれば
十分なんじゃないかという気がしてきました。

> 　んで、名前も汎用的なモノにしてgtk/gnome等でも使うと。
> 　なんか、この辺、複雑すぎる気がするんですよね...。

同感。たしかに複雑ですよね。

> ・_gobject_to_ruby(), _gobject_from_ruby()って何に使うんですか？
> 　（不勉強ですみません）

rbgobj_gvalue_to_rvalue()とrbgobj_rvalue_to_gvalue()による
VALUE<->GValueの相互自動変換に使われます。

> ・gobj_smethod_added()って何に使うんでしょうか？

シグナルハンドラを特異メソッドとして書くためのもののようです。

> rbgobj_param.c:
> ・例えば、rb_define_method(rbgobj_cParamSpec, "name", &get_name, 0);
> 　で、&get_nameなのはなぜでしょうか。

&が付いているのは、ただの癖です。
gtkに合わせて消しましょう。

> ・rbgobj_param_spec_get_struct()とrbgobj_param_spec_wrap()って、
> 　Ruby/GTKで言うところのget_xxxxとmake_xxxxですよね....。この辺の
> 　名称ってできればRuby/GTK統一したいですね...。
> 　＃この辺、後述します。

rbgobj_param.cは手をつけてはみたけど、今のコードは捨てたいなぁ。
GObjectでないGTypeInstanceをうまく扱えるような枠組みを作った上で、
書き直したい感じ。

> ===
> 以下、提案
> ・rbgobj_class_info形を RGObjClassInfoみたいに大文字使ってちょっと短く
> 　して、かつ、いかにも型っぽくしません？

賛成です。

> ・rbgobj_class_infoですが、新たに2つのメンバを追加しませんか。
> 　
> struct _rbgobj_class_info {
>     VALUE klass;
>     GType gtype;
>     void (*mark)(GObject *);
>     void (*free)(GObject *);
>     void (*ref)(GObject *);     
>     void (*unref)(GObject *);
> };

扱う対象をGObjectの派生クラスに限定するならば、
refとunrefはg_object_ref(),g_object_unref()だけでおっけーのはずなので、
ref,unrefは不要だと思います。
# gtk_object_ref(), gtk_widget_ref(), etc... はただの糖衣構文。

> んで、rbgobj_gobject.cのrbgobj_set_gobject()を以下のような感じ。
> ----------------
> void
> rbgobj_set_gobject(obj, gobj)
>     VALUE obj;
>     GObject* gobj;
> {
>     VALUE data;
> 
>     const rbgobj_class_info* cinfo = rbgobj_lookup_class(rb_class_of(obj));
> 
>     if (cinfo)
> 	cinfo->ref(gobj);

リファレンスカウンタについては僕もだいぶ混乱しているのですが、
現状だと、各クラスのinitializeの実装はunrefしないので、
ここでrefしてしまうのはまずそうな気がします。
# もちろん、unrefするようにinitializeの方を変更すれば良いのですが……

ストーリィ

1. initializeメソッド内で、hogehoge_new()を呼び出して、
   新しく作成されたオブジェクトのリファレンスを得る。
   この時点で、リファレンスカウンタは1
   
2. set_gobject()する
   ここでrefしてリファレンスカウンタは2になる。
   新しいリファレンスはrb_cDataのインスタンスが持っている。

3. initializeからリターン
   ここではunrefしていないので、リファレンスカウンタは2のまま。

4. Ruby側のラッパがGCされる。
   rb_cDataのインスタンスが持っていたリファレンスがunrefされるので、
   リファレンスカウンタは1

5. glib側のオブジェクトは解放されない。

> rbgobj_value.cのrbgobj_gvalue_to_rvalue()とrbgobj_rvalue_to_gvalue()ですが、
> これって、結局のところVALUE<->GValueの相互自動変換ですよね？

そうです。
シグナルハンドラの引数と返り値の変換を個別に書かなくても
良いようにするために導入してみました。

> であれば、rbgobj_make_gobject()とかも同様のメソッド名で統一できたらすっきり
> しそうな気がするのですがいかがでしょう？
> 
> rbgobj_gvalue2r()
> rbgobj_r2gvalue()
> rbgobj_gobj2r()　　→ rbgobj_get_value_from_gobject(),rbgobj_make_gobject()の置き換え
> rbgobj_r2gobj()　　→rbgobj_get_gobject()の置き換え

これも賛成。
多分、問題ないと思います。

-- さかい

Re: [ruby-gnome2-devel-ja] =?ISO-2022-JP?B?R0xpYjIbJEJGSSRzJEcbKEI=?= =?ISO-2022-JP?B?GyRCJF8kXiQ3JD8bKEI=?=

[Masao M. <mu...@hi...>]

むとうです。

On Mon, 17 Jun 2002 01:15:47 +0900
Masao Mutoh <mu...@hi...> wrote:

> むとうです。
> 
(略)
> ===
> 以下、提案
> ・rbgobj_class_info形を RGObjClassInfoみたいに大文字使ってちょっと短く
> 　して、かつ、いかにも型っぽくしません？
> ・rbgobj_class_infoですが、新たに2つのメンバを追加しませんか。
> 　
> struct _rbgobj_class_info {
>     VALUE klass;
>     GType gtype;
>     void (*mark)(GObject *);
>     void (*free)(GObject *);
>     void (*ref)(GObject *);     
>     void (*unref)(GObject *);
> };

あ、これダメかな。gtk_widget_ref(GtkWidget *)とかを考えると 
先ほどの例では、rbgobj_set_gobject(obj, gobj)の中で、refに渡す
gobjを動的にキャストしないとですね。
なんかうまい手はないかなぁ。

-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] =?ISO-2022-JP?B?R0xpYjIbJEJGSSRzJEckXyReJDckPxsoQg==?=

[Masao M. <mu...@hi...>]

むとうです。

さかいさんのglibですが、遅ればせながらざっと見てみました。
短い期間にここまで作るのってすごいですね。私には無理かも...(^^;)。

んで、一応、質問など。
正直確認してないのにコメントしてるところがありますがご容赦ください。

他の方も何かコメントあったらメールしてくださいね。
ここって、Ruby-GNOME2のキモの部分だと思いますんで奮ってご参加ください。
＃このメールに対しても、glibのソースに対してでも構いません。

====
全体：
・関数の宣言を他(gtkとか)と合わせませんか？
  static
  VALUE hoge
    ↓
  static VALUE
  hoge

rbglib.c:
前から疑問だったのですが...gErrorって使っていないですよね。
もし使っていないようだったら削除しちゃいませんか？
    gError = rb_define_class_under(mGLib, "Error", rb_eRuntimeError);

rbgobj_object.c:
・rbgobj_set_gobj()で、
  ・Data_Wrap_Struct(rb_cData, cinfo->mark, &g_object_unref, gobj);
    って、&が必要ですか？（gtkなんかはこのパターンの時、使っていないので...）
  ・/* XXX */のところでcinfoがNULLの時ってあるんですか？
　　異常系のみの場合は、rb_bug()かなんかの方が良くないですか？

・clear_gobject()って使う予定アリですか？

・rbgobj_make_gobject()を廃止してrbgobj_make_gobject_auto_type()に
　統合しちゃマズイですかね？
　んで、名前も汎用的なモノにしてgtk/gnome等でも使うと。
　なんか、この辺、複雑すぎる気がするんですよね...。

・_gobject_to_ruby(), _gobject_from_ruby()って何に使うんですか？
　（不勉強ですみません）

・gobj_smethod_added()って何に使うんでしょうか？


rbgobj_param.c:
・例えば、rb_define_method(rbgobj_cParamSpec, "name", &get_name, 0);
　で、&get_nameなのはなぜでしょうか。

・rbgobj_param_spec_get_struct()とrbgobj_param_spec_wrap()って、
　Ruby/GTKで言うところのget_xxxxとmake_xxxxですよね....。この辺の
　名称ってできればRuby/GTK統一したいですね...。
　＃この辺、後述します。


===
以下、提案
・rbgobj_class_info形を RGObjClassInfoみたいに大文字使ってちょっと短く
　して、かつ、いかにも型っぽくしません？
・rbgobj_class_infoですが、新たに2つのメンバを追加しませんか。
　
struct _rbgobj_class_info {
    VALUE klass;
    GType gtype;
    void (*mark)(GObject *);
    void (*free)(GObject *);
    void (*ref)(GObject *);     
    void (*unref)(GObject *);
};

んで、rbgobj_gobject.cのrbgobj_set_gobject()を以下のような感じ。
----------------
void
rbgobj_set_gobject(obj, gobj)
    VALUE obj;
    GObject* gobj;
{
    VALUE data;

    const rbgobj_class_info* cinfo = rbgobj_lookup_class(rb_class_of(obj));

    if (cinfo)
	cinfo->ref(gobj);
	data = Data_Wrap_Struct(rb_cData, cinfo->mark, cinfo->unref, gobj);
    else
	data = Data_Wrap_Struct(rb_cData, gobj_mark, g_object_unref, gobj); 
        /* ↑ここ必要かなぁ？ */

    g_object_set_data_full(gobj, RUBY_GOBJECT_OBJ_KEY,
                           (gpointer)obj, delete_gobject);

    rb_ivar_set(obj, id_relatives, Qnil);
    rb_ivar_set(obj, id_gobject_data, data);

    st_add_direct(gobject_object_list, (char*)obj, (char*)obj);
}
----------------
こうすれば、make_hoge()って全部マクロにできると思うんですよね。
＃rbgtk.cとか独自でhoge_refしてるところは全部修正しないとですがきれいに
＃なるかなと。

===
よくわかってないのでとんちんかんなことを言っているかもしれませんが...
rbgobj_value.cのrbgobj_gvalue_to_rvalue()とrbgobj_rvalue_to_gvalue()ですが、
これって、結局のところVALUE<->GValueの相互自動変換ですよね？

であれば、rbgobj_make_gobject()とかも同様のメソッド名で統一できたらすっきり
しそうな気がするのですがいかがでしょう？

rbgobj_gvalue2r()
rbgobj_r2gvalue()
rbgobj_gobj2r()　　→ rbgobj_get_value_from_gobject(),rbgobj_make_gobject()の置き換え
rbgobj_r2gobj()　　→rbgobj_get_gobject()の置き換え


無理かなぁ？実装してもいないで勝手に言ってます。すみません(^^;)

-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] =?ISO-2022-JP?B?GyRCJWklJCU7JXMlOSRLJEQkJCRGGyhC?=

[Masao M. <mu...@hi...>]

むとうです。

Ruby-GNOME2のライセンスですが、全てLGPLにしたいと思います。

Ruby-GNOMEの前メンテナであるNeilにはOKもらいました。
前々メンテナである五十嵐さんもOKであると理解しています。

今週末くらいにライセンスを変更したいと思うのですが、
異論がある場合はそれまでにお願いします。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Re: GLib2

[Masao M. <mu...@hi...>]

むとうです。

今日は猛烈に眠いのでこれ書いたら寝ます...。

On Thu, 13 Jun 2002 05:48:00 +0900
Masahiro Sakai <s01...@sf...> wrote:

> さかいです。
 
> とりあえず現状の報告(と、自分用メモ)

ありがとうございます。
とりあえず、さかいさんの思うところで
先に進んじゃっていただいて良いですよ。

ちょっと週末にならないとコードを追う時間が取れなさ
そうなんです。申し訳ないです。

> > それと、いきなりでなんですが、
> > ひとまず、lib/gtk2.rbは今のところrequireだけなので、
> > rbgtk.cでrb_require("glib2");して、gtk2.rb自体は削除しませんか。
> 
> むとうさんの所ではそれで動いてるんですか?
> 
> 僕のとこだと、あらかじめglib2.soがロードされていないと、
> rubyがgtk2.soのdlopen()自体に失敗してしまいます。

おっしゃるとおりです。やってみたらダメでした(^^;)。

-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] Re: GLib2

[Masahiro S. <s01...@sf...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: [ruby-gnome2-devel-ja] GLib2
Date: Wed, 12 Jun 2002 07:57:04 +0900

> さかいさん：
> ある程度GLib2周りが落ち着いたら、ここにアナウンスしてください。
> 途中でも結構です。

とりあえず現状の報告(と、自分用メモ)

- これまでgtk.soで行っていた、型とクラスの管理をglib.soに移しました。
  私の趣味で若干名前が変更されていたりしますが、
  本質的な変更はしてないはずです。

- signalはGClosureを使って実装してみました。
  GClosureを使って実装するという方向は正しいと思うけど、
  この辺りは良く理解していないので不安。

- ここでの、Ruby<=>glib(GValue) のデータの変換は、
  変換用の関数を rbgobj_register_r2g_func() と
  rbgobj_register_g2r_func() で登録するようにしてみました。
  もっと良い方法がありそう……

- gtk-2.0では、gdkの幾つかの構造体がGObjectを継承したオブジェクトに
  なっているので、それへの対応が必要なのですが、まだ作業していません。
  
- gtk-2.0では、gdkの(オブジェクトになっていない)幾つかの構造体は、
  GValueへ格納されるときはGBoxedのサブタイプとして格納されるのですが、
  これについてもまだです。

もっと先の事。
細かい事は全然考えてない。(ただの妄想ともいう)

- g_class_list_properties(), g_set_property(), g_get_property()という
  関数があるので、これを使うとsetter/getterを手書きする必要がなくなりそう。

- GTypeInterfaceは何に使うのだろう?

- 「(GObject以下の)GType → Rubyのクラス」の写像が単射になるようにした方が、
  setter/getterを自動定義する事や、他の色々な事に都合が良いかも。
  具体的な実装方法としては
  - この写像を実現する関数は、対応するRubyのクラスがまだ存在しない場合に
    対応するクラスを無名クラスとして再帰的に作成/登録して、それを返す。
  - これまでrb_define_class_under()を使ってクラスを定義していた部分は、
    この関数を使って得たクラスで定数を束縛するコードに置き換える。
  とか……

> それと、いきなりでなんですが、
> ひとまず、lib/gtk2.rbは今のところrequireだけなので、
> rbgtk.cでrb_require("glib2");して、gtk2.rb自体は削除しませんか。

むとうさんの所ではそれで動いてるんですか?

僕のとこだと、あらかじめglib2.soがロードされていないと、
rubyがgtk2.soのdlopen()自体に失敗してしまいます。

-- さかい

[ruby-gnome2-devel-ja] GLib2

[Masao M. <mu...@hi...>]

むとうです。

さかいさん：
ある程度GLib2周りが落ち着いたら、ここにアナウンスしてください。
途中でも結構です。

それから若干コードを読み合わせ（というか主に私からの質問になる
と思いますが...(^^;)）をしましょう。

それと、いきなりでなんですが、
ひとまず、lib/gtk2.rbは今のところrequireだけなので、
rbgtk.cでrb_require("glib2");して、gtk2.rb自体は削除しませんか。

それでは。
-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] =?ISO-2022-JP?B?UnVieS1HTk9NRTIbJEIzKztPJEtFdiQ/JEMkRhsoQig0KSAbJEJEahsoQg==?= =?ISO-2022-JP?B?GyRCP3RDTSROMDckJBsoQg==?=

[Masao M. <mu...@hi...>]

むとうです。

定数値の扱いについてみなさんのご意見をお聞かせください。
前から書こうと思ってたんですが、延び延びになってしまいました。
突然書こうと思ったのは、
Re: [ruby-gnome-users-ja] patch of add selection-copy for Ruby/GTK
のスレッドで、やはり今のうちに方向性を決めておかなきゃいかんと
感じたからです。

----
現在、定数値はその扱いがバラバラです。ある定数はクラスの定数として
存在し、ある定数はGtkモジュール直下の定数になって、また、ある定数はContants
というモジュール配下にある....などです。

これを1つの体系にまとめたいと考えてます。

とりあえず、前提として以下をあげます。
・Gtk, Gdk直下に全ての定数を宣言するのはやめる
・ある程度のグループ化を図る
・Gtk::ItemFactory::Constantsというような括り方はやめる

一応、3つ案を考えました。これ以外でもっと良い案があったら教えてください。

例として、GdkSelectionType, GtkJustificationの2つのenumをあげます。

GdkSelectionType:
  GDK_SELECTION_TYPE_ATOM = 4,
  GDK_SELECTION_TYPE_BITMAP = 5

GtkJustification
  GTK_JUSTIFY_LEFT,
  GTK_JUSTIFY_RIGHT


■(案1）enum系のものは全てモジュールとして定義する

これは、
Gdk::SelectionType::ATOM
Gdk::SelectionType::BITMAP

Gtk::Justification::LEFT
Gtk::Justification::RIGHT

と定義されます。いがらしさんの自動生成されたコードも確かこの方法を
取っていたと思います。

利点：
・GTK+から類推しやすい

欠点：
・定数用モジュール数がとんでもなく多くなってしまう
・どのクラスで使用される定数値なのかがわかりづらい

■(案2）ある程度母体となるクラス・モジュールを持つモノに関してはそれに入れてしまい
　　それに当てはまらない（グローバルに使うようなモノ）に関しては案1と同じにする

例えば、上記の場合、
GdkSelectionType:
  GDK_SELECTION_TYPE_ATOM = 4,
  GDK_SELECTION_TYPE_BITMAP = 5,

これは、
Gdk::Selection::TYPE_ATOM
Gdk::Selection::TYPE_BITMAP

となります。上記は、GdkSelectionTypeを意識せず、あくまでもGDK_SELECTION_TYPE_*という
文字に着目していることになります。

ただし、この例では、ベースとなるクラス・モジュールが存在しない場合があります。

それらは、
Gtk::Justify::LEFT
Gtk::Justify::RIGHT

のようにします。

利点：
・rbbr.rb等のクラスブラウザ見た場合にそのクラスがどのような定数を持っているのか
　わかりやすい
・定数用モジュール数が案1に比べ少なくて済む

欠点：
・GTK+から類推する場合は実際の定数値から類推するようにする必要がある
　＃これは欠点になるのかな...ルールを覚えれば問題ないと思ってます。


■(案3)クラス・モジュールの中でさらにサブモジュール化する。

Gdk::Selection::Type::ATOM
Gdk::Selection::Type::BITMAP

Gtk::Justificationの方は変わらないですね。
Gtk::Justification::LEFT
Gtk::Justification::RIGHT

となります。

利点：
・include Gdk::Selection::Typeなどという書き方も可能

欠点：
・モジュール数は案1と同じ数だけできる

----
クラス・モジュールが、「ある機能のまとまり」であることを
考えると、定数値も含めて案2が良いかなと思っています。

いずれの案でも、これに特化したやり方であれば自動生成ができそうな
気はしてますので、純粋に仕様としてどれを採用した方が良いかという
部分でみなさんの率直な意見をお伺いしたいです。


それでは。
-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Re: glib

[Masao M. <mu...@hi...>]

むとうです。

On Tue, 11 Jun 2002 23:59:42 +0900
Masahiro Sakai <s01...@sf...> wrote:

> From: Masao Mutoh <mu...@hi...>
> Subject: Re: [ruby-gnome2-devel-ja] glib
> Date: Fri, 7 Jun 2002 01:10:34 +0900
> 
> > > こんな感じの実装で良いでしょうか?
> > 
> > はい。気が向いたら、
> > ディレクトリ構成とかはGTKにあわせていただいた上で
> > CVSにあげていただいても良いですよ。
> 
> 遅くなりましたが、glibの方は若干修正してCVSに入れました。

ありがとうございます！
 
> gtkの方に対するパッチは、gdk周りの変更がだいぶ必要そうなので、
> まだcommitしていません。

そうですねぇ。どうしましょう。

いずれ、変更しなきゃならないのはわかっているのでパッチあてちゃい
ませんか？
今のCVS版は動くことを期待する必要はないと思いますし、
どうしても動かしたい人がパッチ作ると思いますよ(^^;)。


ところで、ライセンスはLGPLですね。そうかぁ、LGPLにした方が自然なのかぁ。

LGPLでないのはRuby/GTKですよね。五十嵐さんのOKもあるし、
あとはNeilに聞いて、全部、LGPLで揃えましょうか。

-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] Re: glib

[Masahiro S. <s01...@sf...>]

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] glib
Date: Fri, 7 Jun 2002 01:10:34 +0900

> > こんな感じの実装で良いでしょうか?
> 
> はい。気が向いたら、
> ディレクトリ構成とかはGTKにあわせていただいた上で
> CVSにあげていただいても良いですよ。

遅くなりましたが、glibの方は若干修正してCVSに入れました。

gtkの方に対するパッチは、gdk周りの変更がだいぶ必要そうなので、
まだcommitしていません。

-- さかい

Re: [ruby-gnome2-devel-ja] glib

[Masao M. <mu...@hi...>]

むとうです。

On Thu, 06 Jun 2002 23:40:26 +0900
Masahiro Sakai <s01...@sf...> wrote:

> From: Masahiro Sakai <s01...@sf...>
> Subject: [ruby-gnome2-devel-ja] Re: Ruby-GNOME2開始に当たって(1)
> Date: Sat, 01 Jun 2002 16:11:12 +0900
> 
> > > ところで、この辺実装しますか(^^;)？　＞　さかいさん
> > 
> > やってみます。
> 
> 思ったよりも苦戦してます。
> 
> でも、とりあえずsignal_connect出来るようになったので、
> 現在作業中のコードを
> http://web.sfc.keio.ac.jp/~s01397ms/tmp/ruby-glib-20020606.tar.gz
> http://web.sfc.keio.ac.jp/~s01397ms/tmp/ruby-gtk-20020606.diff
> に置きました。

すばらしい。ちょっとだけいじってみました。
まだ、sampleとかで動かないのもあるみたいですが良い感じです。
 
> こんな感じの実装で良いでしょうか?

はい。気が向いたら、
ディレクトリ構成とかはGTKにあわせていただいた上で
CVSにあげていただいても良いですよ。
そのときはファイルのヘッダにコピーライトつけてくださいね。
＃コメントの英語化も(^^;)。

-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] glib

[Masahiro S. <s01...@sf...>]

From: Masahiro Sakai <s01...@sf...>
Subject: [ruby-gnome2-devel-ja] Re: Ruby-GNOME2開始に当たって(1)
Date: Sat, 01 Jun 2002 16:11:12 +0900

> > ところで、この辺実装しますか(^^;)？　＞　さかいさん
> 
> やってみます。

思ったよりも苦戦してます。

でも、とりあえずsignal_connect出来るようになったので、
現在作業中のコードを
http://web.sfc.keio.ac.jp/~s01397ms/tmp/ruby-glib-20020606.tar.gz
http://web.sfc.keio.ac.jp/~s01397ms/tmp/ruby-gtk-20020606.diff
に置きました。

こんな感じの実装で良いでしょうか?

-- さかい

Re: [ruby-gnome2-devel-ja] wrapper generation

[Masao M. <mu...@hi...>]

むとうです。

On Mon, 03 Jun 2002 03:16:50 +0900
Hiroshi IGARASHI <ig...@ru...> wrote:

> いがらしです。
> 
> なんか、言い訳がましい弁明が続きますが、
> # 実際言い訳に過ぎないのですが...
> あくまでメンテナ当時の考えを説明している訳で
> もう自動生成にこだわっているわけではないので。

いや、むしろ私の方がこだわっているかもしれません。
これができると大変楽なので。
 
> At Sat, 1 Jun 2002 12:19:49 +0900,
> Masao Mutoh <mu...@hi...> wrote:
> > 
> > defsファイル自体は自動生成されるものではないのですね。

（ざっくり略）

> 自動生成に関しての作業は少なくとも当面は中止して、
> 他の作業に注力しようと思います。

了解です。
まずは自動化を念頭にベースの部分を整えましょうか。


-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] wrapper generation

[Hiroshi I. <ig...@ru...>]

いがらしです。

なんか、言い訳がましい弁明が続きますが、
# 実際言い訳に過ぎないのですが...
あくまでメンテナ当時の考えを説明している訳で
もう自動生成にこだわっているわけではないので。

At Sat, 1 Jun 2002 12:19:49 +0900,
Masao Mutoh <mu...@hi...> wrote:
> 
> defsファイル自体は自動生成されるものではないのですね。

はい。1.2時代はヘッダファイル等から生成していましたが、
いつからか生成しないことになったようです。
きちんと経緯を調べたわけではありませんが、
おそらく各言語バインディングのAPIをヘッダファイル等から
導き出すには自明でない情報が必要で、結局手でメンテせざるを
得ないということになったのでは、と思います。

「自明でない情報」として以下のようなものがあります。
* あるメソッド(関数)・定数が属すべきクラス・モジュール
* あるクラス・モジュールに属するとして、その名前
* メソッドの省略可能引数およびそのデフォルト値
* 公開するオブジェクト(構造体)のメンバ
このあたりを記述できるように、defsファイルの
フォーマットが拡張されてきているようです。

> > 現在の gnome-python/pygtk/gtk/gdk.defs には含まれています。
> > 例えばGdk::Drawable#draw_rgb_32_imageなら以下の通りです。
(snip)
> っていうか、これを書かなきゃいけないってコトですよね...。
> まぁ、今は、すでにgnome-pythonのがあるということでそれを流用しようと
> いうことだとは思いますが、将来的には。
> ＃gnome-pythonが未サポートなクラス・メソッドが無い場合は
> ＃独自実装するか、自分で上記フォーマットのファイルを作ってpatchを
> ＃gnome-pythonに送るかしないといけないってコトですよね。

まあ、そういうことになりますが、今の勢いなら
主要なAPIはカバーしていくと思いますよ。

> これの仕様を覚えて、これを関数毎に書き、いがらしさんのツールを
> メンテナンスしつつ、さらにRubyによるWrapperを書くというプロセス
> を考えるのなら、従来通りC言語でプログラム書いた方が速いと思うのは
> 私だけでしょうか。

私もコードを書く人がいてコントロールできれば
従来通りが速いと思います。

> 
> なんか、正直、自動生成に切り替えるメリットがわからなく
> なってきました。
> あ、いや、ヒューマンエラーを無くすことができるというのは
> 自動生成時には常に言われることなのでそれを置いておいたとして。

これは、当時の私にとっては大きかったのです。
未実装部分を補うたくさんのパッチを送っていただきましたが、
* 品質・コーディングスタイルにむらがある。
* on-demandに自分が欲しいメソッド・定数だけ実装している。
等があって、マージする負荷が高かったので自動生成に向かっていました。
まあきちんとメンテナとしてコントロールできなかったのが
そもそもの原因でしたので、それが解決できれば従来通りで
問題ないと思います。

> すでにある*.defsをgnome-pythonからもらってきて、
> それからいがらしさんのツールでCのソースを生成して、
> それをベースにRuby-GNOMEに無いメソッドやクラス・ライブラリ(bonoboなど)
> を開発するということであれば十分使えると思うのですが。

はい、現在はそれで充分だと思っています。
あるいは、未実装ライブラリについても
* 自動生成したAPIに後からRubyらしいAPIを手でかぶせるコスト
  (あるいはRubyらしいAPIを吐かせるためにツールをメンテするコスト)
* 最初からC(+Ruby)でRubyらしいAPIを定義・実装するコスト
の後者が小さければ、ツールを使うことはないでしょう。
Pythonより拡張ライブラリが書きやすい(一部逆の部分もありますが)
こともあって、そういう場合の方が多いのかも知れません。

> それから、さらに生成されたソースを追ってはいるので追加質問です。
> 
> gtk_item_factory_create_items()のようにオブジェクトの配列を
> 渡すようなのはどうなっているのでしょうか？
> defsで定義された引数が配列かどうかをどのように判別しているのか
> ということと、配列の場合は引数のVALUEが配列であるとしそれを適切な
> Cの型に変換する部分について知りたいです。

配列についてはサポートしていません。

At Sun, 2 Jun 2002 10:44:59 +0900,
Masao Mutoh <mu...@hi...> wrote:
> 
> 構造体のメンバへのアクセス方法って提供されない
> のでしょうか。gtkcustom.cで対応するのかな？
> ＃*.defsには無いようでしたので。

これも提供していません。
構造体メンバも直接アクセスしていいものとまずいものがあるので、
gnome-pythonの新しいdefsファイルでは明示的に必要なメンバ名を
記述するようになっています。やるとしたら、これに対応した
メソッドを生成するのでしょうけど...


こうして考えてみると、わざわざ検討して頂くほどのものでは
なかったかも。余計なお時間を取らせてしまいすみませんでした。
自動生成に関しての作業は少なくとも当面は中止して、
他の作業に注力しようと思います。

--
五十嵐  宏  (Hiroshi IGARASHI)

Re: [ruby-gnome2-devel-ja] wrapper generation

[Masao M. <mu...@hi...>]

むとうです。

さらに追加で質問です。

構造体のメンバへのアクセス方法って提供されない
のでしょうか。gtkcustom.cで対応するのかな？
＃*.defsには無いようでしたので。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Re: =?ISO-2022-JP?B?UnVieS1HTk9NRTIbJEIzKxsoQg==?= =?ISO-2022-JP?B?GyRCO08kS0V2JD8kQyRGGyhCKDEp?=

[Masao M. <mu...@hi...>]

むとうです。

On Sat, 01 Jun 2002 16:11:12 +0900
Masahiro Sakai <s01...@sf...> wrote:

> あ、もう一つ理由がありました。
> gtkの方はウィンドウシステム毎に別のバイナリが必要なので、
> ウィンドウシステムに依存しないglibは分けた方が気持良さそう。

そこは気づきませんでした。
 
> > ところで、この辺実装しますか(^^;)？　＞　さかいさん
> 
> やってみます。
> 

お願いしますね。
＃私も何かコード書かないとだな....。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Re: =?ISO-2022-JP?B?UnVieS1HTk9NRTIbJEIzKxsoQg==?= =?ISO-2022-JP?B?GyRCO08kS0V2JD8kQyRGGyhCKDEp?=

[Masao M. <mu...@hi...>]

むとうです。

On Sat, 01 Jun 2002 16:19:41 +0900
Masahiro Sakai <s01...@sf...> wrote:

> From: Masao Mutoh <mu...@hi...>
> Subject: Re: [ruby-gnome2-devel-ja] Re: Ruby-GNOME2開始に当たって(1)
> Date: Sat, 1 Jun 2002 01:26:56 +0900
> 
> > > でもgtk2.rbでrequrie 'glib'しておけばGTK+ユーザの使い勝手は
> > > 変わらないし、積極的に反対しているわけではないです。
> > 
> > 気分で答えます（もしかしたらころっと意見が変わるかもしれませんが）が、
> > 今のところ、gtk2.rbでrequire 'glib'する必要を感じません。
> 
> Gimp-Rubyの経験から言うと、これはrequireしておく必要があります。
> 
> タイプシステム等をglibベースにすると、
> gtk2.soはglib2.so内のシンボルを参照することになるので、
> gtk2.soよりも先にglib2.soがロードされていないと
> シンボルが解決出来なくなってしまいます。

あ、そうなんですか。考え及ばずですね、いかんいかん(^^;)。



-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] Re: =?iso-2022-jp?B?UnVieS1HTk9NRTIbJEIzKztPJEtFdiQ/JEMkRhsoQigxKQ==?=

[Masahiro S. <s01...@sf...>]

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] Re: Ruby-GNOME2開始に当たって(1)
Date: Sat, 1 Jun 2002 01:26:56 +0900

> > でもgtk2.rbでrequrie 'glib'しておけばGTK+ユーザの使い勝手は
> > 変わらないし、積極的に反対しているわけではないです。
> 
> 気分で答えます（もしかしたらころっと意見が変わるかもしれませんが）が、
> 今のところ、gtk2.rbでrequire 'glib'する必要を感じません。

Gimp-Rubyの経験から言うと、これはrequireしておく必要があります。

タイプシステム等をglibベースにすると、
gtk2.soはglib2.so内のシンボルを参照することになるので、
gtk2.soよりも先にglib2.soがロードされていないと
シンボルが解決出来なくなってしまいます。

-- さかい

[ruby-gnome2-devel-ja] Re: =?iso-2022-jp?B?UnVieS1HTk9NRTIbJEIzKztPJEtFdiQ/JEMkRhsoQigxKQ==?=

[Masahiro S. <s01...@sf...>]

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] Re: Ruby-GNOME2開始に当たって(1)
Date: Fri, 31 May 2002 20:31:44 +0900

> > > glib関係のコードはglib用の新しい拡張ライブラリを作りましょうか?
> > > それともgtk拡張ライブラリの方に入れてしまいましょうか?
> > 
> > たぶんRubyからglibだけを使うことはないので、
> > gtkにまとめてもいいかなと私は思いますが。
> 
> これは分けましょう。
> 
> ・GTK+と１つにまとめるには大きすぎる
> ・もしかしたら、GLibのみを使いたい人がいるかもしれない。

あ、もう一つ理由がありました。
gtkの方はウィンドウシステム毎に別のバイナリが必要なので、
ウィンドウシステムに依存しないglibは分けた方が気持良さそう。

> ところで、この辺実装しますか(^^;)？　＞　さかいさん

やってみます。

-- さかい