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

[ruby-gnome2-devel-ja] G_DEF_CLASS4 (was Re: Atk::TextRange)

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masahiro Sakai (酒井政裕) <sa...@to...>
Date: Mon, 16 Jul 2007 12:04:52 +0900 (JST)

> 酒井です。
> 
> From: Masao Mutoh <mu...@hi...>
> Date: Mon, 16 Jul 2007 00:22:54 +0900
> 
> > むとうです。
> > 
> > On Sun, 15 Jul 2007 15:53:55 +0900 (JST)
> > Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> 
> > > ちなみに、
> > >   http://developer.gnome.org/doc/API/2.0/atk/AtkText.html#AtkTextRange
> > > ではメンバとして
> > >   AtkTextRectangle bounds;  A rectangle giving the bounds of the text range
> > > と書かれています。
> > > 継承関係を意図しているのならばこのような書き方はしないでしょう。
> > 
> > そうですね。まぁ、きちんとドキュメントを読め、ということですね。
> > 
> > ついでといってはなんですが、実装の方も直しておいていただけると助かります ;)。
> 
> 直しておきました。

なお、これによって G_DEF_CLASS4 の唯一の使用例が無くなりました。
G_DEF_CLASS4 って必要ですか?

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Atk::TextRange

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Mon, 16 Jul 2007 00:22:54 +0900

> むとうです。
> 
> On Sun, 15 Jul 2007 15:53:55 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> > ちなみに、
> >   http://developer.gnome.org/doc/API/2.0/atk/AtkText.html#AtkTextRange
> > ではメンバとして
> >   AtkTextRectangle bounds;  A rectangle giving the bounds of the text range
> > と書かれています。
> > 継承関係を意図しているのならばこのような書き方はしないでしょう。
> 
> そうですね。まぁ、きちんとドキュメントを読め、ということですね。
> 
> ついでといってはなんですが、実装の方も直しておいていただけると助かります ;)。

直しておきました。
Atk::TextRangeをテストするにはどうすれば良いのかわからないので、
テストはしていません。

--
酒井 政裕 / Masahiro Sakai

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

[Masahiro S. () <sa...@to...>]

From: Masao Mutoh <mu...@hi...>
Date: Mon, 16 Jul 2007 00:28:05 +0900

> むとうです。
> 
> On Mon, 16 Jul 2007 00:07:05 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> > それはそうと、rbgdkatom.c は GdkAtomData と GdkAtom の使い方が混乱して
> > る気がします。
> 
> そうですか？
> 何となくうまく動作しているようですが・・・。

例えば、以下のような振る舞いは意図されていないのではないかと思います。

Gdk::Atom::NONE.name #=> "NONE"
Gdk::Atom::NONE.dup.name #=> nil !?

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?MjAwMxskQkcvSHdLOk8/GyhC?=

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

むとうです。

On Sun, 15 Jul 2007 18:37:54 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
> 
> From: Masao Mutoh <mu...@hi...>
> Date: Wed, 31 Dec 2003 04:46:29 +0900
> 
> > むとうです。
> > 
> > ２００３年はご協力どうもありがとうございました。
> > いろいろ大変な一年でしたが、Ruby-GNOME2も徐々に知名度が
> > あがってきたので、２００４年は是非、飛躍の年にしたいですね。
> > ＃その前に1.0.0を出さねば....。
> 
> そういえば、これから既に3年以上経っているんですね。
> 懐かしいなぁ……

そうですねぇ。

> # 1.0.0 はいまだ遠い!?

酒井さんに本格的に戻ってきていただけるのなら、
あっという間じゃないですかね、とか言ってみる（笑）。

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

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

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

むとうです。

On Mon, 16 Jul 2007 00:07:05 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
 
> > そうですね。
> > まだ使っている人も少ないでしょうから削除しておいていただけますか。
> 
> 削除しました。

ありがとうございました。
 
> それはそうと、rbgdkatom.c は GdkAtomData と GdkAtom の使い方が混乱して
> る気がします。

そうですか？
何となくうまく動作しているようですが・・・。

といってもここは私も汚い実装だなぁ、と思っているところではあるので
良いアイデアがあれば再実装していただいても構いません。

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

Re: [ruby-gnome2-devel-ja] Atk::TextRange

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

むとうです。

On Sun, 15 Jul 2007 15:53:55 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
 
> > > 「ポインタをキャストできるならば is-a」という考えに従うならば、
> > > 上のコード例の AtkTextRectangle* は int* にキャストできるため
> > > AtkTextRectangle と int が is-a の関係にあることになってしまいますよ。
> > 
> > ちょっと説明が足りませんでした。この場合構造体だけで考えてました。
> > ＃構造体をクラスと見立てています。
> > 「ポインタをキャストした後の各変数に正しくアクセスができる」
> > という考え方ですかね。
> > 
> > ただ、これは一般論として言ってるわけではなく、GTKでは
> > （たとえば、GtkWindowはGtkBinのみをPointerではなく持っていま
> > す）、継承関係的な位置づけがあるものはそういったポリシーで定義
> > しているんじゃないかなと（勝手に）思っていたわけなんですが。
> 
> gtkでは継承関係を構造体の埋め込みとしてエンコードしているわけですが、
> 逆に構造体が埋め込まれていたからといって、それが継承関係を表したものと
> は限らないでしょう。

まぁ、確かにそうですね。
 
> > > メモリ管理といよりは、int等と同じように単なる値として扱いたいということ
> > > だと思いますが。
> > 
> > 初心者みたいな質問して申し訳ないんですが(苦笑)
> > 値として扱いたい場合とポインタとして扱いたい場合の違いって
> > 何でしょうか。
> 
> 基本的には、同一性(identity)に意味がある場合にポインタとして扱い、
> 同一性に意味がなく同値性のみが重要な場合に値として扱うのだと思います。
> 
> > それからさかいさんがis-aではないと思った理由って具体的には
> > なんでしょうか。
> 
> rangeという概念とrectangleという概念は、上位概念・下位概念の
> 関係にはないと感じたためです。
> 
> > rectangleを拡張したのがrangeと考えるのか、rangeはrectangleを持つ
> > と考えたかの違いだとは思うんですけど・・・。
> 
> ちなみに、
>   http://developer.gnome.org/doc/API/2.0/atk/AtkText.html#AtkTextRange
> ではメンバとして
>   AtkTextRectangle bounds;  A rectangle giving the bounds of the text range
> と書かれています。
> 継承関係を意図しているのならばこのような書き方はしないでしょう。

そうですね。まぁ、きちんとドキュメントを読め、ということですね。

ついでといってはなんですが、実装の方も直しておいていただけると助かります ;)。

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

Re: [ruby-gnome2-devel-ja] rbgobj_abstract_but_create_instance_class(gtype)

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

むとうです。

On Sun, 15 Jul 2007 23:49:05 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。

> > > これなのですが、rbgobj_abstract_but_create_instance_class は廃止して、
> > > とりあえず常に allocate 出来るようにしようかと思います。
> > > 
> > > というのも、rbgobj_abstract_but_create_instance_class で指定する方式だ
> > > と、gtk側の実装(≠仕様)が変わるたびに対応が必要になってしまうためです。
> > 
> > それって、AbstractなクラスであってもFoo.newができる、ということでしょうか。
> > だとしたら現状のまま(Abstractなクラスはnewできない)の方が良いような気がします。
> 
> そうです。
> ただ、Abstractなクラスに対しては Foo#initialize を自動的に定義して、
> そっちでエラーにするということは出来るでしょうけど。

エラーにしないとSegfaultとかおかしな動作になりません？

> > gtk側の実装が変わるたびに従わなければいけない、というのはしょうが
> > ないといえばしょうがないわけですし。
> 
> それを仕方がないと言ってしまうのには、かなり抵抗があります。
> 
> gtk側の「仕様」が変更されたのなら仕方がないですが、内部の実装が変わった
> くらいで正しく動作しなくなったり、変更が必要になったりというのでは、と
> ても dependable なソフトウェアとは言えないのではないでしょうか?

この場合、G_TYPE_FLAG_ABSTRACTでなかったものがそのように変更された
というGTK側の仕様が変更されたのではないでしょうか。
決して内部の実装が変わっただけの話ではないのでは？

まぁ、でも、仕様変更か内部の実装かという話はともかく
例えば、前のバージョンではBoxedなオブジェクトとして定義されていなかったけど
今回のバージョンではBoxedで定義され直したりってのも結構あったりして、
それらはバージョンによって変更が必要になっています。
それらに対応するのは仕方がないのではないでしょうか。

＃それに私にとってRuby-GNOME2がdependableなソフトウェアである必要があるか、
＃といわれると別にどっちでもよいです。ってかdependableなソフトの定義も
＃しりませんし（苦笑）。

今回のケースでは、Abstractなクラスをnewして変な結果が返らないように
エラーになるのであれば内部の実装は酒井さんの案の方が良いと思います。

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

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

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Sun, 15 Jul 2007 23:24:03 +0900

> むとうです。
> 
> On Sun, 15 Jul 2007 17:40:56 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> > gdk_atom_intern_static_string() は引数となる文字列が存在し続けることを
> > 前提として、コピーを行わないというメソッドなので、こういう使い方はまず
> > いです。
> > http://developer.gnome.org/doc/API/2.2/gdk/gdk-Properties-and-Atoms.html#gdk-atom-intern-static-string
> > 
> > Gdk::Atom.intern_static_string は不要でしょう。
> 
> そうですね。
> まだ使っている人も少ないでしょうから削除しておいていただけますか。

削除しました。

それはそうと、rbgdkatom.c は GdkAtomData と GdkAtom の使い方が混乱して
る気がします。

--
酒井 政裕 / Masahiro Sakai

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

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

むとうです。

On Sun, 15 Jul 2007 18:26:48 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
> 
> 昔のメールを見返していると、全然覚えてなくて困ります(汗

確かに。

> > > ■ GDKのFactory関連
> > > GDKでは、実装がWin32の時やX11の時でそれぞれ別々のGTypeを
> > > 持ちます。
> > > で、実は、いくつかのGdk関連のクラスで現在問題になっている
> > > のですが、Ruby側から登録されていないGTypeがあるために、
> > > 無名クラスとして値が返されるメソッドが結構あったりして
> > > そのままでは使えない状態になっています。
> > > たとえば、Gdk::Screen.defaultなど。
> 
> そもそも、これって無名クラスだと何か問題があるのでしたっけ?

名前がわからないのが嫌だという問題かと。

> 単にinspectで無名クラスが表示されてイヤということであれば、inspectに細
> 工して少し分かりやすい文字列を返せばよいのではないかと思いました。

そうですね。
 
> 何故、こんなことを言い出したかというと、現在G_DEF_CLASS3が以下のような
> 使われ方をしていますが、これだとgtk側の内部実装が変わったり、新しいバッ
> クエンドが追加されただけで、Ruby-GNOME2側も変更しなくてはならなくなって
> しまうためです。

これはやむなし、というのが当時の意見です。

> foo_get_type() が非公開ということは、
> その型をユーザーに直接扱って欲しくないということだと思います。
> 
> 本当にGdkScreenX11等を直接扱う必要があるのでしょうか?

直接GdkScreenX11オブジェクトにアクセスするかどうか、という意味であれば
Yesです。
ただ、その名前である必要があるか、というと別に理由はないです。
＃前で述べたようにGdkScreenで問題ない。ただgtypeが違うのに同じ
＃オブジェクトになるのが気持ち悪い、無名だと分かりづらい、という程度。

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

Re: [ruby-gnome2-devel-ja] rbgobj_abstract_but_create_instance_class(gtype)

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Sun, 15 Jul 2007 22:57:07 +0900

> むとうです。
> 
> On Sun, 15 Jul 2007 15:57:51 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> 
> > 酒井です。
> 
> > > Ruby/GTKをGTK+-2.2環境で動作確認をしていたのですが、
> > > Gdk::GC.newで、"abstract class"というTypeErrorが
> > > 出てインスタンスが生成できないことがわかりました。
> > > #このエラーはgobj_s_allocate()が出します。
> 
> > > とはいえ、このままだとGdk::GC.newを生成できないので、
> > > glib/src/rbgobj_object.cに以下の関数を追加しました。
> > > 
> > > void　rbgobj_abstract_but_create_instance_class(gtype);
> > > 
> > > ここで登録しておいたクラスはG_TYPE_FLAG_ABSTRACTであっても
> > > allocateできるようになります。
> > > 
> > > とりあえず、Ruby-GNOME-0.3はこれで行きたいと思いますが、
> > > 別の良案があれば教えてください。
> > 
> > これなのですが、rbgobj_abstract_but_create_instance_class は廃止して、
> > とりあえず常に allocate 出来るようにしようかと思います。
> > 
> > というのも、rbgobj_abstract_but_create_instance_class で指定する方式だ
> > と、gtk側の実装(≠仕様)が変わるたびに対応が必要になってしまうためです。
> 
> それって、AbstractなクラスであってもFoo.newができる、ということでしょうか。
> だとしたら現状のまま(Abstractなクラスはnewできない)の方が良いような気がします。

そうです。
ただ、Abstractなクラスに対しては Foo#initialize を自動的に定義して、
そっちでエラーにするということは出来るでしょうけど。

> gtk側の実装が変わるたびに従わなければいけない、というのはしょうが
> ないといえばしょうがないわけですし。

それを仕方がないと言ってしまうのには、かなり抵抗があります。

gtk側の「仕様」が変更されたのなら仕方がないですが、内部の実装が変わった
くらいで正しく動作しなくなったり、変更が必要になったりというのでは、と
ても dependable なソフトウェアとは言えないのではないでしょうか?

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] gdk_atom_intern_static_string (Re: [ruby-gnome2-cvs] CVS: ruby-gnome2/gtk/src rbgdkatom.c, 1.12, 1.13 rbgdkcairo.c, 1.2, 1.3 rbgdkdisplay.c, 1.19, 1.20 rbgdkpixmap.c, 1.25, 1.26 rbgdkscreen.c, 1.17, 1.18 rbgdkwindow.c, 1.60, 1.61)

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

むとうです。

On Sun, 15 Jul 2007 17:40:56 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
> 
> From: Masao Mutoh <mu...@us...>
> Subject: [ruby-gnome2-cvs] CVS: ruby-gnome2/gtk/src rbgdkatom.c, 1.12, 1.13 rbgdkcairo.c, 1.2, 1.3 rbgdkdisplay.c, 1.19, 1.20 rbgdkpixmap.c, 1.25, 1.26 rbgdkscreen.c, 1.17, 1.18 rbgdkwindow.c, 1.60, 1.61
> Date: Sat, 25 Nov 2006 09:50:44 -0800
> 
> > Log Message:
> 
> > 	* src/rbgdkatom.c: Added Gdk::Atom.intern_static_string for GTK+-2.10. 
> 
> > Index: rbgdkatom.c
> > ===================================================================
> > RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/gtk/src/rbgdkatom.c,v
> > retrieving revision 1.12
> > retrieving revision 1.13
> > diff -u -d -r1.12 -r1.13
> > --- rbgdkatom.c	30 Jul 2005 11:22:15 -0000	1.12
> > +++ rbgdkatom.c	25 Nov 2006 17:50:41 -0000	1.13
> > @@ -61,6 +61,16 @@
> >                        GDK_TYPE_ATOM);
> >  }
> >  
> > +#if GTK_CHECK_VERSION(2,10,0)
> > +static VALUE
> > +gdkatom_s_intern_static_string(self, name)
> > +    VALUE self, name;
> > +{
> > +    return BOXED2RVAL(gdk_atom_intern_static_string(RVAL2CSTR(name)), 
> > +                      GDK_TYPE_ATOM);
> > +}
> > +#endif
> > +
> 
> gdk_atom_intern_static_string() は引数となる文字列が存在し続けることを
> 前提として、コピーを行わないというメソッドなので、こういう使い方はまず
> いです。
> http://developer.gnome.org/doc/API/2.2/gdk/gdk-Properties-and-Atoms.html#gdk-atom-intern-static-string
> 
> Gdk::Atom.intern_static_string は不要でしょう。

そうですね。
まだ使っている人も少ないでしょうから削除しておいていただけますか。

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

Re: [ruby-gnome2-devel-ja] rbgobj_abstract_but_create_instance_class(gtype)

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

むとうです。

On Sun, 15 Jul 2007 15:57:51 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。

> > Ruby/GTKをGTK+-2.2環境で動作確認をしていたのですが、
> > Gdk::GC.newで、"abstract class"というTypeErrorが
> > 出てインスタンスが生成できないことがわかりました。
> > #このエラーはgobj_s_allocate()が出します。

> > とはいえ、このままだとGdk::GC.newを生成できないので、
> > glib/src/rbgobj_object.cに以下の関数を追加しました。
> > 
> > void　rbgobj_abstract_but_create_instance_class(gtype);
> > 
> > ここで登録しておいたクラスはG_TYPE_FLAG_ABSTRACTであっても
> > allocateできるようになります。
> > 
> > とりあえず、Ruby-GNOME-0.3はこれで行きたいと思いますが、
> > 別の良案があれば教えてください。
> 
> これなのですが、rbgobj_abstract_but_create_instance_class は廃止して、
> とりあえず常に allocate 出来るようにしようかと思います。
> 
> というのも、rbgobj_abstract_but_create_instance_class で指定する方式だ
> と、gtk側の実装(≠仕様)が変わるたびに対応が必要になってしまうためです。

それって、AbstractなクラスであってもFoo.newができる、ということでしょうか。
だとしたら現状のまま(Abstractなクラスはnewできない)の方が良いような気がします。
gtk側の実装が変わるたびに従わなければいけない、というのはしょうが
ないといえばしょうがないわけですし。

そうでないとしたら、allocateできるようになっても構わないと思います。

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

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?MjAwMxskQkcvSHdLOk8/GyhC?=

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Wed, 31 Dec 2003 04:46:29 +0900

> むとうです。
> 
> ２００３年はご協力どうもありがとうございました。
> いろいろ大変な一年でしたが、Ruby-GNOME2も徐々に知名度が
> あがってきたので、２００４年は是非、飛躍の年にしたいですね。
> ＃その前に1.0.0を出さねば....。

そういえば、これから既に3年以上経っているんですね。
懐かしいなぁ……
# 1.0.0 はいまだ遠い!?

--
酒井 政裕 / Masahiro Sakai

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

[Masahiro S. () <sa...@to...>]

酒井です。

昔のメールを見返していると、全然覚えてなくて困ります(汗
昔と意見が変わっている点も多いと思いますが、すみません。

From: Masao Mutoh <mu...@hi...>
Date: Mon, 23 Feb 2004 02:07:34 +0900

> むとうです。
> 
> 以前、直すと宣言していたものの中で、以下の件に
> ついて対応しました。
> 
> On Wed, 31 Dec 2003 04:46:29 +0900
> Masao Mutoh <mu...@hi...> wrote:
> 
> > ■ GDKのFactory関連
> > GDKでは、実装がWin32の時やX11の時でそれぞれ別々のGTypeを
> > 持ちます。
> > で、実は、いくつかのGdk関連のクラスで現在問題になっている
> > のですが、Ruby側から登録されていないGTypeがあるために、
> > 無名クラスとして値が返されるメソッドが結構あったりして
> > そのままでは使えない状態になっています。
> > たとえば、Gdk::Screen.defaultなど。

そもそも、これって無名クラスだと何か問題があるのでしたっけ?

単にinspectで無名クラスが表示されてイヤということであれば、inspectに細
工して少し分かりやすい文字列を返せばよいのではないかと思いました。

何故、こんなことを言い出したかというと、現在G_DEF_CLASS3が以下のような
使われ方をしていますが、これだとgtk側の内部実装が変わったり、新しいバッ
クエンドが追加されただけで、Ruby-GNOME2側も変更しなくてはならなくなって
しまうためです。

#ifdef GDK_WINDOWING_X11
    G_DEF_CLASS3("GdkGCX11", "GCX11", mGdk);
#elif defined(GDK_WINDOWING_WIN32)         
    G_DEF_CLASS3("GdkGCWin32", "GCWin32", mGdk);
#elif defined(GDK_WINDOWING_FB)
    G_DEF_CLASS3("GdkGCFB", "GCFB", mGdk);
#endif

> > で、以下の２つの対応方法を考えてみました。
> > 
> > 1. GdkGCX11やGdkGCWin32はGdk::GCとして見えるようにする
> > 2. GdkGCX11はGdk::GCX11に、GdkGCWin32はGdk::GCWin32にする
> > 　 
> > 1.の場合、GOBJ2RVAL2(val, gtype)というのを作って明示的にRuby化
> > されるときのクラスを決定してしまう、という比較的安易な対応が
> > できると思います。
> > 
> > 2.の場合、すべて手作業でG_DEF_CLASSをするという手もありますが
> > 結構面倒くさいかなーと。
> > プラッガブルに追加されるようなものを想定すると、
> > 自動でクラスとgtypeのマッピングを生成するようなことを考える
> > 必要がありますが、タイミング的にそれはちと難しいかなぁと
> > 思っています。
> > 
> > 実装の問題は置いておいて、本来どっちであるべきかというのも
> > 実は悩ましいです。
> > 
> > GTK+は一つの環境には基本的に１つの実装(X11 or Win32 or linuxfb)
> > がインストールされると思うのですが、その場合、rbbrなどで見たときに
> > すべてのGdkクラス群が１つのサブクラス（というか実体）を持つという
> > 感じになるのがちょっと冗長かな、と。
> > ドキュメント書くのも面倒くさいし（ホンネ）。
> > 
> > あー、でもここまで書いてきて思ったのですが、
> > やっぱり2の方が良さそうだなぁ。手動でもそんなに数が多いわけでも
> > ないし。
> 
> 結局、2.の案を採用しました。
> 
> 具体的には、
> G_DEF_CLASS3(gtype_name, ruby_name, module);
> というのを用意しました。
> 
> G_DEF_CLASS3("GdkScreenX11", "ScreenX11", Gdk);
> のように使います。
> これで、Gdk::Screen.defaultを呼び出すとClassの代わりにGdk::ScreenX11
> が呼び出されるようになり、その後はGdk::ScreenX11を使うことができます。

From: Masao Mutoh <mu...@hi...>
Date: Mon, 23 Feb 2004 02:20:31 +0900

> むとうです。
> 
> 補足です。
> 
> G_DEF_CLASS3は基本的にはfoo_get_type()メソッドが非公開のものに
> 対して使います。
> foo_get_type()を明示的に呼び出すことができないために、foo_get_type()
> が呼び出されたであろう直後(実際はruby側からGDKの関数を呼び出した後)に
> Rubyのクラスを生成するようにしています。
> そのときGdkScreenX11等の文字列を利用してgtypeを取得します。

foo_get_type() が非公開ということは、
その型をユーザーに直接扱って欲しくないということだと思います。

本当にGdkScreenX11等を直接扱う必要があるのでしょうか?

--
酒井 政裕 / Masahiro Sakai

[ruby-gnome2-devel-ja] gdk_atom_intern_static_string (Re: [ruby-gnome2-cvs] CVS: ruby-gnome2/gtk/src rbgdkatom.c, 1.12, 1.13 rbgdkcairo.c, 1.2, 1.3 rbgdkdisplay.c, 1.19, 1.20 rbgdkpixmap.c, 1.25, 1.26 rbgdkscreen.c, 1.17, 1.18 rbgdkwindow.c, 1.60, 1.61)

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@us...>
Subject: [ruby-gnome2-cvs] CVS: ruby-gnome2/gtk/src rbgdkatom.c, 1.12, 1.13 rbgdkcairo.c, 1.2, 1.3 rbgdkdisplay.c, 1.19, 1.20 rbgdkpixmap.c, 1.25, 1.26 rbgdkscreen.c, 1.17, 1.18 rbgdkwindow.c, 1.60, 1.61
Date: Sat, 25 Nov 2006 09:50:44 -0800

> Log Message:

> 	* src/rbgdkatom.c: Added Gdk::Atom.intern_static_string for GTK+-2.10. 

> Index: rbgdkatom.c
> ===================================================================
> RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/gtk/src/rbgdkatom.c,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -u -d -r1.12 -r1.13
> --- rbgdkatom.c	30 Jul 2005 11:22:15 -0000	1.12
> +++ rbgdkatom.c	25 Nov 2006 17:50:41 -0000	1.13
> @@ -61,6 +61,16 @@
>                        GDK_TYPE_ATOM);
>  }
>  
> +#if GTK_CHECK_VERSION(2,10,0)
> +static VALUE
> +gdkatom_s_intern_static_string(self, name)
> +    VALUE self, name;
> +{
> +    return BOXED2RVAL(gdk_atom_intern_static_string(RVAL2CSTR(name)), 
> +                      GDK_TYPE_ATOM);
> +}
> +#endif
> +

gdk_atom_intern_static_string() は引数となる文字列が存在し続けることを
前提として、コピーを行わないというメソッドなので、こういう使い方はまず
いです。
http://developer.gnome.org/doc/API/2.2/gdk/gdk-Properties-and-Atoms.html#gdk-atom-intern-static-string

Gdk::Atom.intern_static_string は不要でしょう。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] rbgobj_abstract_but_create_instance_class(gtype)

[Masahiro S. () <sa...@to...>]

酒井です。

またまた昔のメールを発掘。

From: Masao Mutoh <mu...@hi...>
Date: Sun, 9 Feb 2003 14:12:26 +0900

> むとうです。
> 
> Ruby/GTKをGTK+-2.2環境で動作確認をしていたのですが、
> Gdk::GC.newで、"abstract class"というTypeErrorが
> 出てインスタンスが生成できないことがわかりました。
> #このエラーはgobj_s_allocate()が出します。
> 
> これは、gdk_gc_get_type()がGTK+-2.0系から
> 以下のように変更になっているのが原因でした。
> 
> GTK+-2.0.6
>       object_type = g_type_register_static (G_TYPE_OBJECT,
>                                             "GdkGC",
>                                             &object_info, 0);
> 
> GTK+-2.2.0
>       object_type = g_type_register_static (G_TYPE_OBJECT,
>                                             "GdkGC",
>                                             &object_info,
>                                             G_TYPE_FLAG_ABSTRACT);
> 
> この変更の経緯を知らないので何とも言えないのですが、
> Abstractなんだけどインスタンスを生成できる(newとかは存在する)
> クラスというのはちょっと気持ち悪いですね.....。
> あ、でも、gtk_widget_newとかg_object_newとかあるからそうでもないか。
> 
> とはいえ、このままだとGdk::GC.newを生成できないので、
> glib/src/rbgobj_object.cに以下の関数を追加しました。
> 
> void　rbgobj_abstract_but_create_instance_class(gtype);
> 
> ここで登録しておいたクラスはG_TYPE_FLAG_ABSTRACTであっても
> allocateできるようになります。
> 
> とりあえず、Ruby-GNOME-0.3はこれで行きたいと思いますが、
> 別の良案があれば教えてください。

これなのですが、rbgobj_abstract_but_create_instance_class は廃止して、
とりあえず常に allocate 出来るようにしようかと思います。

というのも、rbgobj_abstract_but_create_instance_class で指定する方式だ
と、gtk側の実装(≠仕様)が変わるたびに対応が必要になってしまうためです。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Atk::TextRange

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Sun, 15 Jul 2007 15:08:16 +0900

> むとうです。
> 
> On Sun, 15 Jul 2007 13:28:59 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> 
> > 酒井です。
> 
> > > まぁ、キャストができるからis aか、と言われると違うと言われれば
> > > 違うような気もしますが、でもキャストができるんだからis aなんじゃ
> > > なかろうかというような気もしないでもないです。
> > 
> > 「ポインタをキャストできるならば is-a」という考えに従うならば、
> > 上のコード例の AtkTextRectangle* は int* にキャストできるため
> > AtkTextRectangle と int が is-a の関係にあることになってしまいますよ。
> 
> ちょっと説明が足りませんでした。この場合構造体だけで考えてました。
> ＃構造体をクラスと見立てています。
> 「ポインタをキャストした後の各変数に正しくアクセスができる」
> という考え方ですかね。
> 
> ただ、これは一般論として言ってるわけではなく、GTKでは
> （たとえば、GtkWindowはGtkBinのみをPointerではなく持っていま
> す）、継承関係的な位置づけがあるものはそういったポリシーで定義
> しているんじゃないかなと（勝手に）思っていたわけなんですが。

gtkでは継承関係を構造体の埋め込みとしてエンコードしているわけですが、
逆に構造体が埋め込まれていたからといって、それが継承関係を表したものと
は限らないでしょう。

> > メモリ管理といよりは、int等と同じように単なる値として扱いたいということ
> > だと思いますが。
> 
> 初心者みたいな質問して申し訳ないんですが(苦笑)
> 値として扱いたい場合とポインタとして扱いたい場合の違いって
> 何でしょうか。

基本的には、同一性(identity)に意味がある場合にポインタとして扱い、
同一性に意味がなく同値性のみが重要な場合に値として扱うのだと思います。

> それからさかいさんがis-aではないと思った理由って具体的には
> なんでしょうか。

rangeという概念とrectangleという概念は、上位概念・下位概念の
関係にはないと感じたためです。

> rectangleを拡張したのがrangeと考えるのか、rangeはrectangleを持つ
> と考えたかの違いだとは思うんですけど・・・。

ちなみに、
  http://developer.gnome.org/doc/API/2.0/atk/AtkText.html#AtkTextRange
ではメンバとして
  AtkTextRectangle bounds;  A rectangle giving the bounds of the text range
と書かれています。
継承関係を意図しているのならばこのような書き方はしないでしょう。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Atk::TextRange

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

むとうです。

On Sun, 15 Jul 2007 13:28:59 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。

> > まぁ、キャストができるからis aか、と言われると違うと言われれば
> > 違うような気もしますが、でもキャストができるんだからis aなんじゃ
> > なかろうかというような気もしないでもないです。
> 
> 「ポインタをキャストできるならば is-a」という考えに従うならば、
> 上のコード例の AtkTextRectangle* は int* にキャストできるため
> AtkTextRectangle と int が is-a の関係にあることになってしまいますよ。

ちょっと説明が足りませんでした。この場合構造体だけで考えてました。
＃構造体をクラスと見立てています。
「ポインタをキャストした後の各変数に正しくアクセスができる」
という考え方ですかね。

ただ、これは一般論として言ってるわけではなく、GTKでは
（たとえば、GtkWindowはGtkBinのみをPointerではなく持っていま
す）、継承関係的な位置づけがあるものはそういったポリシーで定義
しているんじゃないかなと（勝手に）思っていたわけなんですが。

> > でも、逆に、なんでここって、
> > 
> > typedef struct _AtkTextRange {
> >   AtkTextRectangle* bounds;  /* これ */
> >   int start_offset;
> > } AtkTextRange;
> > 
> > じゃないんですかね。これだったらis aの関係ではないと
> > 私もわかるんですけど・・・。
> > Pointerにしなかったのは単にメモリ管理が楽だから？
> 
> メモリ管理といよりは、int等と同じように単なる値として扱いたいということ
> だと思いますが。

初心者みたいな質問して申し訳ないんですが(苦笑)
値として扱いたい場合とポインタとして扱いたい場合の違いって
何でしょうか。

それからさかいさんがis-aではないと思った理由って具体的には
なんでしょうか。
rectangleを拡張したのがrangeと考えるのか、rangeはrectangleを持つ
と考えたかの違いだとは思うんですけど・・・。

この辺が客観的なものとして明らかにできれば、今後の実装の参考に
できるのではないかと思います。
＃前述したとおり、GTKの場合、私は単にポインタで他の構造体を
＃持っていればそれはhas-a、そうじゃなければis-aくらいに考えてました。

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

Re: [ruby-gnome2-devel-ja] Atk::TextRange

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Sun, 15 Jul 2007 12:04:31 +0900

> むとうです。
> 
> On Sun, 15 Jul 2007 00:45:00 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> 
> > 酒井です。
> > 
> > 現在、Atk::TextRange は ATk::TextRectangle のサブクラスとして実装されて
> > いますが、この両者が is a の関係とは思えないので、これは変ではないでしょ
> > うか?
> 
> うーん。
> たぶん、以下のコードをイメージしてRangeはRectangleとis aの関係だと
> 思って実装したんじゃないかと思います。
> 
> ----
> #include <stdio.h>
> #include <stdlib.h>
> 
> typedef struct _AtkTextRectangle {
>   int x;
> } AtkTextRectangle;
> 
> typedef struct _AtkTextRange {
>   AtkTextRectangle bounds;
>   int start_offset;
> } AtkTextRange;
> 
> int
> main(int argc, char *argv[])
> {
>   AtkTextRange *a = malloc(sizeof(AtkTextRange));
>   a->start_offset = 1;
>   ((AtkTextRectangle*)a)->x = 5;   /* このキャストができる。*/
> 
>   printf("start_offset = %d\n", a->start_offset);
>   printf("x = %d\n", ((AtkTextRectangle*)a)->x);   /* このキャストができる。*/
> }
> ----
> 
> まぁ、キャストができるからis aか、と言われると違うと言われれば
> 違うような気もしますが、でもキャストができるんだからis aなんじゃ
> なかろうかというような気もしないでもないです。

「ポインタをキャストできるならば is-a」という考えに従うならば、
上のコード例の AtkTextRectangle* は int* にキャストできるため
AtkTextRectangle と int が is-a の関係にあることになってしまいますよ。

> でも、逆に、なんでここって、
> 
> typedef struct _AtkTextRange {
>   AtkTextRectangle* bounds;  /* これ */
>   int start_offset;
> } AtkTextRange;
> 
> じゃないんですかね。これだったらis aの関係ではないと
> 私もわかるんですけど・・・。
> Pointerにしなかったのは単にメモリ管理が楽だから？

メモリ管理といよりは、int等と同じように単なる値として扱いたいということ
だと思いますが。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Atk::TextRange

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

むとうです。

On Sun, 15 Jul 2007 00:45:00 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
> 
> 現在、Atk::TextRange は ATk::TextRectangle のサブクラスとして実装されて
> いますが、この両者が is a の関係とは思えないので、これは変ではないでしょ
> うか?

うーん。
たぶん、以下のコードをイメージしてRangeはRectangleとis aの関係だと
思って実装したんじゃないかと思います。

----
#include <stdio.h>
#include <stdlib.h>

typedef struct _AtkTextRectangle {
  int x;
} AtkTextRectangle;

typedef struct _AtkTextRange {
  AtkTextRectangle bounds;
  int start_offset;
} AtkTextRange;

int
main(int argc, char *argv[])
{
  AtkTextRange *a = malloc(sizeof(AtkTextRange));
  a->start_offset = 1;
  ((AtkTextRectangle*)a)->x = 5;   /* このキャストができる。*/

  printf("start_offset = %d\n", a->start_offset);
  printf("x = %d\n", ((AtkTextRectangle*)a)->x);   /* このキャストができる。*/
}
----

まぁ、キャストができるからis aか、と言われると違うと言われれば
違うような気もしますが、でもキャストができるんだからis aなんじゃ
なかろうかというような気もしないでもないです。

でも、逆に、なんでここって、

typedef struct _AtkTextRange {
  AtkTextRectangle* bounds;  /* これ */
  int start_offset;
} AtkTextRange;

じゃないんですかね。これだったらis aの関係ではないと
私もわかるんですけど・・・。
Pointerにしなかったのは単にメモリ管理が楽だから？

この辺、まともに勉強してきていないので、どう考えるのが正しいのか
教えていただけると（というか文献等でも）ありがたいのですが・・・。

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

[ruby-gnome2-devel-ja] Atk::TextRange

[Masahiro S. () <sa...@to...>]

酒井です。

現在、Atk::TextRange は ATk::TextRectangle のサブクラスとして実装されて
いますが、この両者が is a の関係とは思えないので、これは変ではないでしょ
うか?

/**
 * AtkTextRectangle:
 * @x: The horizontal coordinate of a rectangle
 * @y: The vertical coordinate of a rectangle
 * @width: The width of a rectangle
 * @height: The height of a rectangle
 *
 * A structure used to store a rectangle used by AtkText.
 **/

typedef struct _AtkTextRectangle AtkTextRectangle;

struct _AtkTextRectangle {
  gint x;
  gint y;
  gint width;
  gint height;
};

/**
 * AtkTextRange:
 * @bounds: A rectangle giving the bounds of the text range
 * @start_offset: The start offset of a AtkTextRange
 * @end_offset: The end offset of a AtkTextRange
 * @content: The text in the text range
 *
 * A structure used to describe a text range.
 **/
typedef struct _AtkTextRange AtkTextRange;

struct _AtkTextRange {
  AtkTextRectangle bounds;
  gint start_offset;
  gint end_offset;
  gchar* content;
};

--
酒井 政裕 / Masahiro Sakai

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

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

むとうです。

On Sun, 08 Jul 2007 12:32:14 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。

> > それはそうと、G_BLOCK_PROC()をやめる事自体は良いと思います。
> > sed一発だとは思いますが、全部のライブラリ、
> > さかいさんにお願いしちゃっていいですか？
> 
> 作業しました、
> sedわかんないのでrubyで (^^;

ありがとうございます。

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

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

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Sun, 8 Jul 2007 10:48:42 +0900

> むとうです。
> 
> On Sun, 08 Jul 2007 10:28:22 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> 
> > 酒井です。
> > 
> > 1.6への対応をやめたことですし、G_BLOCK_PROC() を使うのをやめて、
> > rb_block_proc() を直接使うことにしませんか?
> > 
> > そもそも、rb_f_lambda() が rb_block_proc() になった時に、
> > G_BLOCK_PROC() という新しいAPIを発明すべきではなくて、
> > 単に以下のようにしておけば良かったのだと思います。
> > #ifndef HAVE_RB_BLOCK_PROC
> > #define rb_block_proc() (rb_f_lambda())
> > #endif
> 
> 確かに。まぁ、今さら言われても困りますが（苦笑）。

そりゃそーですよね(笑

> それはそうと、G_BLOCK_PROC()をやめる事自体は良いと思います。
> sed一発だとは思いますが、全部のライブラリ、
> さかいさんにお願いしちゃっていいですか？

作業しました、
sedわかんないのでrubyで (^^;

--
酒井 政裕 / Masahiro Sakai

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

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

むとうです。

On Sun, 08 Jul 2007 10:28:22 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
> 
> 1.6への対応をやめたことですし、G_BLOCK_PROC() を使うのをやめて、
> rb_block_proc() を直接使うことにしませんか?
> 
> そもそも、rb_f_lambda() が rb_block_proc() になった時に、
> G_BLOCK_PROC() という新しいAPIを発明すべきではなくて、
> 単に以下のようにしておけば良かったのだと思います。
> #ifndef HAVE_RB_BLOCK_PROC
> #define rb_block_proc() (rb_f_lambda())
> #endif

確かに。まぁ、今さら言われても困りますが（苦笑）。

それはそうと、G_BLOCK_PROC()をやめる事自体は良いと思います。
sed一発だとは思いますが、全部のライブラリ、
さかいさんにお願いしちゃっていいですか？
 
-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] G_BLOCK_PROC

[Masahiro S. () <sa...@to...>]

酒井です。

1.6への対応をやめたことですし、G_BLOCK_PROC() を使うのをやめて、
rb_block_proc() を直接使うことにしませんか?

そもそも、rb_f_lambda() が rb_block_proc() になった時に、
G_BLOCK_PROC() という新しいAPIを発明すべきではなくて、
単に以下のようにしておけば良かったのだと思います。

#ifndef HAVE_RB_BLOCK_PROC
#define rb_block_proc() (rb_f_lambda())
#endif

参考までに、G_BLOCK_PROCが導入されたときのメールを以下に引用します。

From: Masao Mutoh <mu...@hi...>
Subject: [ruby-gnome2-devel-ja] G_BLOCK_PROC
Date: Fri, 27 Jun 2003 00:48:23 +0900

> むとうです。
> 
> glib/src/rbgutil.hに G_BLOCK_PROCを用意しました。
> 
> これは、rb_f_lambdaと、1.8系で導入された
> rb_block_procに対応するものです。
> 
> 各コードは、rb_f_lambda, rb_block_procを直接
> 使うのではなく、こちらを使うようにしてください。
> 
> ---
> すでにCVS上のruby-gnome2配下のライブラリには適用済みです。
> 1.8系で出ている以下のWarningが出なくなります。
> 
>  warning: rb_f_lambda() is deprecated; use rb_block_proc() instead

--
酒井 政裕 / Masahiro Sakai