Menu
▾
▴
ruby-gnome2-devel-ja — Ruby-GNOME2 developer's Mailing list. in Japanese.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(60) |
Jul
(52) |
Aug
(67) |
Sep
(167) |
Oct
(186) |
Nov
(173) |
Dec
(220) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(37) |
Feb
(66) |
Mar
(89) |
Apr
(71) |
May
(32) |
Jun
(61) |
Jul
(64) |
Aug
(99) |
Sep
(33) |
Oct
(31) |
Nov
(50) |
Dec
(41) |
| 2004 |
Jan
(9) |
Feb
(9) |
Mar
(25) |
Apr
(23) |
May
(8) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(1) |
Oct
(31) |
Nov
(38) |
Dec
|
| 2005 |
Jan
(16) |
Feb
(49) |
Mar
(14) |
Apr
(1) |
May
|
Jun
(12) |
Jul
(25) |
Aug
(18) |
Sep
(48) |
Oct
(76) |
Nov
(20) |
Dec
|
| 2006 |
Jan
(16) |
Feb
(12) |
Mar
(4) |
Apr
(5) |
May
(77) |
Jun
(37) |
Jul
(15) |
Aug
|
Sep
(3) |
Oct
(15) |
Nov
(7) |
Dec
(27) |
| 2007 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(7) |
Jun
(18) |
Jul
(44) |
Aug
(12) |
Sep
(1) |
Oct
(13) |
Nov
(15) |
Dec
(5) |
| 2008 |
Jan
|
Feb
|
Mar
(16) |
Apr
(2) |
May
(8) |
Jun
(1) |
Jul
|
Aug
|
Sep
(8) |
Oct
(6) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(3) |
| 2010 |
Jan
(8) |
Feb
(8) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(17) |
Oct
(7) |
Nov
(3) |
Dec
|
| 2011 |
Jan
(34) |
Feb
(47) |
Mar
(12) |
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
(20) |
Aug
(4) |
Sep
(31) |
Oct
(16) |
Nov
(26) |
Dec
(40) |
| 2012 |
Jan
(10) |
Feb
(8) |
Mar
|
Apr
(5) |
May
(8) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(8) |
| 2013 |
Jan
(2) |
Feb
(33) |
Mar
(21) |
Apr
(10) |
May
(29) |
Jun
(19) |
Jul
(6) |
Aug
(4) |
Sep
|
Oct
(21) |
Nov
(21) |
Dec
(7) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(4) |
May
(12) |
Jun
|
Jul
|
Aug
(5) |
Sep
(23) |
Oct
(29) |
Nov
(2) |
Dec
(1) |
| 2015 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(8) |
|
From: Masao M. <mu...@hi...> - 2003-10-26 16:33:22
|
むとうです。
On Sun, 26 Oct 2003 01:00:45 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> さかいです。
> ではとりあえずサンプルを。
>
> require 'gtk2'
> Gtk.init
>
> class MyButton < Gtk::Button
> register_type("MyButton")
>
> def initialize(label = nil)
> # XXX: register_typeするとsuperがGLib#initialize相当になる
なるほど。これは良いアイデアだと思います。
register_typeは活かして上記は採用と言うことで。
> super("label" => label)
> @fuga = 0
> end
> # 既存のシグナルのデフォルトハンドラをオーバーライド
> def do_clicked(*args)
> puts "MyButton#do_clicked enter"
> #p caller
> super
> puts "MyButton#do_clicked leave"
> end
> # 新しいシグナルを定義
> signal_new("hoge", # 名前
> GLib::Signal::RUN_FIRST, # フラグ
> nil, # accumulator (XXX: 仕様が未確定)
> GLib::Type["void"], # 返り値の型
> GLib::Type["gint"], GLib::Type["gint"] # 引数の型
> )
> # 新しいシグナルのデフォルトハンドラ
> def do_hoge(a, b)
> puts "MyButton#do_hoge enter"
> #p caller
> puts "MyButton#do_hoge leave"
> end
たぶん、私が"Rubyっぽく"とお願いしたからだとは思うのですが
以下の点が気になります。
・メソッド定義の形になっている。
他のメソッドと用途がかなり違う。また、
signal_connect()みたいブロックを受け付ける形とも違う
・do_*の名前がちと汎用的すぎるような...。
・signal_overrideのdo_clickedが突然現れ、do_clickedの意味が
ちょっとわかりづらい気がする。
＃もちろん、register_typeを知ってれば気にならないと言う人
＃もいるとは思いますが。
逆に、以下のような記法はどうでしょうか。
signal_override("clicked") {|args,...|
:
super
:
}
signal_new("hoge", ..... ){|args,...|
:
}
これでdo_*のようなメソッドを定義する必要もなくブロック内の
ロジックの使用用途が見た目上、限定できるような気がします。
実装が難しいようでしたら、逆に以下のようにするとか。
signal_override("clicked")
def signal_do_clicked(args,...)
:
super
:
}
signal_new("hoge", ..... )
def signal_do_hoge(args,...)
:
}
もちろん、さかいさんの実装を見てしまうと、
上記ではsignal_override("clicked")は冗長なものに
なるとは思いますが、
要は、signal_newとsignal_overrideの位置づけを同様にして
見た目上の一貫性を持たせることを意図しています。
-------
あとそれとは別に、GLib::Typeの部分ってRubyのクラスを
使うようにはできないですかね。
> signal_new("hoge", # 名前
> GLib::Signal::RUN_FIRST, # フラグ
> nil, # accumulator (XXX: 仕様が未確定)
> GLib::Type["void"], # 返り値の型
> GLib::Type["gint"], GLib::Type["gint"] # 引数の型
> )
signal_new("hoge", # 名前
GLib::Signal::RUN_FIRST, # フラグ
nil, # accumulator (XXX: 仕様が未確定)
nil, # 返り値の型
Integer, Integer, # 引数の型
)
両方使えるようにするとかでも構いませんけど...。
> # 新しいプロパティの作成
> install_property(GLib::Param::Int.new("fuga", # name
> "Fuga", # nick
> "fuga hoge", # blurb
> 0, # min
> 10000, # max
> 0, # default
> GLib::Param::READABLE |
> GLib::Param::WRITABLE))
> # プロパティの実装
> def fuga
> puts "MyButton#fuga is called"
> @fuga
> end
> def fuga=(arg)
> puts "MyButton#fuga= is called"
> @fuga = arg
> end
> end
これって、def fugaとfuga=は必要ですか？
上記の形でinstall_propertyを読んだら、
1. @fugaというインスタンス変数が定義される
2. fuga, fuga=, set_fugaが生成される
の２つを自動で行うのが良いと思うのですがいかがでしょうか？
＃実装上難しいのかな。
fuga, fuga=, set_fugaの各メソッドのオーバーライドは可能だと
なお良いかも。
あり？
そういえばこの場合、@fugaって定義する必要ありましたっけ？
通常、propertiesってsetter/getterはあるけどインスタンス変数
としては存在しないと思ってたのですが、そうではない？
----
それ以外は良いと思います。
あと一歩だと思いますので、次のリリースまでには何とかしたいですね〜。
それでは。
--
.:% Masao Mutoh<mu...@hi...>
|
|
From: Masahiro S. ()
<sa...@to...> - 2003-10-26 14:53:44
|
さかいです。 From: Masao Mutoh <mu...@hi...> Date: Sat, 18 Oct 2003 01:45:03 +0900 > さかいさん > > むとうです。 > > Gdk::Keymapをインプリしていて気づいたのですが、 > 以下のサンプルが動作しません。 > 実行した後、ウインドウをアクティブにしてから > 何かキーを入力してください。 > ＃あ、CVSの最新版で試してください。 > で、色々やった結果、Ruby/GLib2の方に以下のパッチを適用すると > 動作するようになりました。 > ＃ってただ、チェックを外しただけなのですが。 > > これってこの対応で良いですかね？ > それとも、Gdk::Keymap#translate_keyboard_state側で対処すべき？ GFlagsで範囲外の値をどうするかという問題ですよね。 GEnumでも問題になりましたし、範囲外の値を扱うにしても、 扱わないにしても、GFlagsとGEnumで同じ対応にした方が良さそうですね。 とりあえず、glib-2.2.2の内部で範囲外の値をどう扱っているか調べてみると、 * g_value_set_enum/g_value_set_flags では一切チェックしない * g_param_value_validate ではチェックしている (そのためプロパティには範囲外の値をセットすることは出来ない) ようです。 -- 酒井 政裕 / Masahiro Sakai |
|
From: Masahiro S. ()
<sa...@to...> - 2003-10-26 14:39:36
|
さかいです。 From: Masao Mutoh <mu...@hi...> Subject: Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] Ruby/GTK2チュートリアル Date: Fri, 24 Oct 2003 00:22:20 +0900 > むとうです。 > > > arg->query.param_types[i]の指す値が微妙におかしかったです。 > > > ＃本当に期待するGType + 1みたいな。 > > > > あー、なるほど。 > > G_SIGNAL_TYPE_STATIC_SCOPEがここで効いてくるのか。 > > > > G_SIGNAL_TYPE_STATIC_SCOPE については良くわかってないんですが、 > > 添付したような感じにすればよいのかな…… > > なるほど。 > 0が渡らないようにしてるんでしょうかね。 > > 動いてるようでしたらこれでお願いします。 > ＃未確認ですみません。 commitしました。 -- 酒井 政裕 / Masahiro Sakai |
|
From: Masahiro S. ()
<sa...@to...> - 2003-10-25 16:06:37
|
さかいです。
From: Masao Mutoh <mu...@hi...>
Subject: [ruby-gnome2-devel-ja] GLibのregister_type周辺
Date: Tue, 14 Oct 2003 23:25:59 +0900
> さかいさん
>
> むとうです。
>
> Nikolaiにもせっつかれてしまいましたが、
> そろそろ、結論を出したいな、と思っています。
>
> たぶん、一番大きな問題は、私が現在のGLibの
> 実装ってどういうところまでできてるのか
> きちんと把握していないことだと思います。
>
> サンプルみたいなのをあげて説明していただけ
> るととっても助かるんですが、いかがでしょう。
ではとりあえずサンプルを。
require 'gtk2'
Gtk.init
class MyButton < Gtk::Button
register_type("MyButton")
def initialize(label = nil)
# XXX: register_typeするとsuperがGLib#initialize相当になる
super("label" => label)
@fuga = 0
end
# 既存のシグナルのデフォルトハンドラをオーバーライド
def do_clicked(*args)
puts "MyButton#do_clicked enter"
#p caller
super
puts "MyButton#do_clicked leave"
end
# 新しいシグナルを定義
signal_new("hoge", # 名前
GLib::Signal::RUN_FIRST, # フラグ
nil, # accumulator (XXX: 仕様が未確定)
GLib::Type["void"], # 返り値の型
GLib::Type["gint"], GLib::Type["gint"] # 引数の型
)
# 新しいシグナルのデフォルトハンドラ
def do_hoge(a, b)
puts "MyButton#do_hoge enter"
#p caller
puts "MyButton#do_hoge leave"
end
# 新しいプロパティの作成
install_property(GLib::Param::Int.new("fuga", # name
"Fuga", # nick
"fuga hoge", # blurb
0, # min
10000, # max
0, # default
GLib::Param::READABLE |
GLib::Param::WRITABLE))
# プロパティの実装
def fuga
puts "MyButton#fuga is called"
@fuga
end
def fuga=(arg)
puts "MyButton#fuga= is called"
@fuga = arg
end
end
class MyButton2 < MyButton
register_type("MyButton2")
# clickedシグナルのデフォルトハンドラをオーバーライド
def do_clicked(*args)
puts "MyButton2#do_clicked enter"
super(*args)
puts "MyButton2#do_clicked leave"
end
# hogeシグナルのデフォルトハンドラをオーバーライド
def do_hoge(a, b)
puts "MyButton2#do_hoge enter"
#p caller
super
puts "MyButton2#do_hoge leave"
end
end
b = MyButton2.new("Hello")
p b
p b.label
p b.gtype
b.clicked
b.signal_emit("hoge", 1, 2)
p b.get_property("fuga")
b.set_property("fuga", 1)
p b.get_property("fuga")
--
酒井 政裕 / Masahiro Sakai
|
|
From: Masao M. <mu...@hi...> - 2003-10-23 18:58:28
|
むとうです。 On Thu, 23 Oct 2003 01:52:19 +0900 (JST) Masahiro Sakai (酒井政裕) <sa...@to...> wrote: > さかいです。 > > > ここでRVAL2GTYPEを使うのはまずいです。 > > > # nilが渡ってきたりしたときに引数からGTypeを決定出来ないので > > > > nilが渡ってきたらG_TYPE_NONEになるから大丈夫かと思ってたのですが...。 > > 違いましたっけ？ > > _register_fundamental_klass_to_gtype()ってこういうときのために > > 使うモノかと思ってたのですが...。 > > G_TYPE_NONEはVALUE_TYPEではないので、 > GValueに値を格納するのには使えなくて、 > こういう場合にはまずいです。 > オブジェクトのクラスによらずにGValueのGTypeが決定可能な場合は、 > そっちを使う方が望ましいと思います。 なるほど。 > > > たしかにこの変更で Segmentation Fault しなくなったんですが、 > > > 何でなのか私にはサッパリわからないので、少し説明してもらえませんか? > > > > arg->query.param_types[i]の指す値が微妙におかしかったです。 > > ＃本当に期待するGType + 1みたいな。 > > あー、なるほど。 > G_SIGNAL_TYPE_STATIC_SCOPEがここで効いてくるのか。 > > G_SIGNAL_TYPE_STATIC_SCOPE については良くわかってないんですが、 > 添付したような感じにすればよいのかな…… なるほど。 0が渡らないようにしてるんでしょうかね。 動いてるようでしたらこれでお願いします。 ＃未確認ですみません。 > > > それと、↓の変更って全然意味がないような…… > > > > あー、これは他と揃えるという意味で。 > > とにかく他に正常に動作してるモノと一つずつ合わせていったんです。 > > GTypeが原因って気づくまでスゲー時間かかったんですよ(^^;)。 > > お手数をおかけしました。 どういたしまして;) ではでは。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masahiro S. ()
<sa...@to...> - 2003-10-22 17:11:36
|
さかいです。 From: Masao Mutoh <mu...@hi...> Subject: Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] Ruby/GTK2チュートリアル Date: Wed, 22 Oct 2003 22:18:13 +0900 > むとうです。 > > ここでRVAL2GTYPEを使うのはまずいです。 > > # nilが渡ってきたりしたときに引数からGTypeを決定出来ないので > > nilが渡ってきたらG_TYPE_NONEになるから大丈夫かと思ってたのですが...。 > 違いましたっけ？ > _register_fundamental_klass_to_gtype()ってこういうときのために > 使うモノかと思ってたのですが...。 G_TYPE_NONEはVALUE_TYPEではないので、 GValueに値を格納するのには使えなくて、 こういう場合にはまずいです。 オブジェクトのクラスによらずにGValueのGTypeが決定可能な場合は、 そっちを使う方が望ましいと思います。 > > たしかにこの変更で Segmentation Fault しなくなったんですが、 > > 何でなのか私にはサッパリわからないので、少し説明してもらえませんか? > > arg->query.param_types[i]の指す値が微妙におかしかったです。 > ＃本当に期待するGType + 1みたいな。 あー、なるほど。 G_SIGNAL_TYPE_STATIC_SCOPEがここで効いてくるのか。 G_SIGNAL_TYPE_STATIC_SCOPE については良くわかってないんですが、 添付したような感じにすればよいのかな…… > > それと、↓の変更って全然意味がないような…… > > あー、これは他と揃えるという意味で。 > とにかく他に正常に動作してるモノと一つずつ合わせていったんです。 > GTypeが原因って気づくまでスゲー時間かかったんですよ(^^;)。 お手数をおかけしました。 -- 酒井 政裕 / Masahiro Sakai |
|
From: Masao M. <mu...@hi...> - 2003-10-22 13:20:36
|
むとうです。
On Wed, 22 Oct 2003 00:42:01 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> さかいです。
>
> 返事が遅くなってすいません。
いえいえ、いろいろお疲れのようで(^^;)。
> | Index: rbgobj_signal.c
> | ===================================================================
> | RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/glib/src/rbgobj_signal.c,v
> | retrieving revision 1.39
> | retrieving revision 1.40
> | diff -u -d -r1.39 -r1.40
> | --- rbgobj_signal.c 23 Sep 2003 05:23:02 -0000 1.39
> | +++ rbgobj_signal.c 14 Oct 2003 13:30:24 -0000 1.40
> | @@ -302,9 +302,11 @@
> | {
> | GValue* params = arg->instance_and_params->values + 1;
> | int i;
> | + VALUE val;
> | for (i = 0; i < arg->query.n_params; i++){
> | - g_value_init(params + i, arg->query.param_types[i]);
> | - rbgobj_rvalue_to_gvalue(rb_ary_entry(arg->args, i), params + i);
> | + val = rb_ary_entry(arg->args, i);
> | + g_value_init(params + i, RVAL2GTYPE(val));
> | + rbgobj_rvalue_to_gvalue(val, params + i);
> | }
> | }
>
> ここでRVAL2GTYPEを使うのはまずいです。
> # nilが渡ってきたりしたときに引数からGTypeを決定出来ないので
nilが渡ってきたらG_TYPE_NONEになるから大丈夫かと思ってたのですが...。
違いましたっけ？
_register_fundamental_klass_to_gtype()ってこういうときのために
使うモノかと思ってたのですが...。
> たしかにこの変更で Segmentation Fault しなくなったんですが、
> 何でなのか私にはサッパリわからないので、少し説明してもらえませんか?
arg->query.param_types[i]の指す値が微妙におかしかったです。
＃本当に期待するGType + 1みたいな。
> それと、↓の変更って全然意味がないような……
あー、これは他と揃えるという意味で。
とにかく他に正常に動作してるモノと一つずつ合わせていったんです。
GTypeが原因って気づくまでスゲー時間かかったんですよ(^^;)。
ではでは。
--
.:% Masao Mutoh<mu...@hi...>
|
|
From: Masahiro S. ()
<sa...@to...> - 2003-10-21 16:30:15
|
さかいです。
返事が遅くなってすいません。
From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] Ruby/GTK2チュートリアル
Date: Tue, 14 Oct 2003 22:43:04 +0900
> むとうです。
>
> signal_emitの件ですが、対応してみました。
> ＃２ヶ月も放置してすみません
どうもありがとうございます。
> glibの方にも手を入れました。
> 一応動いてはいるのですが、
> イマイチわかってないので間違えてるかも。
>
> 確認よろしくです。＞さかいさん
というわけで……
| Index: rbgobj_signal.c
| ===================================================================
| RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/glib/src/rbgobj_signal.c,v
| retrieving revision 1.39
| retrieving revision 1.40
| diff -u -d -r1.39 -r1.40
| --- rbgobj_signal.c 23 Sep 2003 05:23:02 -0000 1.39
| +++ rbgobj_signal.c 14 Oct 2003 13:30:24 -0000 1.40
| @@ -302,9 +302,11 @@
| {
| GValue* params = arg->instance_and_params->values + 1;
| int i;
| + VALUE val;
| for (i = 0; i < arg->query.n_params; i++){
| - g_value_init(params + i, arg->query.param_types[i]);
| - rbgobj_rvalue_to_gvalue(rb_ary_entry(arg->args, i), params + i);
| + val = rb_ary_entry(arg->args, i);
| + g_value_init(params + i, RVAL2GTYPE(val));
| + rbgobj_rvalue_to_gvalue(val, params + i);
| }
| }
ここでRVAL2GTYPEを使うのはまずいです。
# nilが渡ってきたりしたときに引数からGTypeを決定出来ないので
たしかにこの変更で Segmentation Fault しなくなったんですが、
何でなのか私にはサッパリわからないので、少し説明してもらえませんか?
それと、↓の変更って全然意味がないような……
| Index: rbgdkevent.c
| ===================================================================
| RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/gtk/src/rbgdkevent.c,v
| retrieving revision 1.35
| retrieving revision 1.36
| diff -u -d -r1.35 -r1.36
| --- rbgdkevent.c 30 Aug 2003 18:40:02 -0000 1.35
| +++ rbgdkevent.c 14 Oct 2003 13:34:08 -0000 1.36
| @@ -608,9 +608,9 @@
|
| /* MISC */
| static VALUE
| -gdkevent_g2r(const GValue *from)
| +gdkevent_g2r(const GValue *values)
| {
| - return make_gdkevent(g_value_get_boxed(from));
| + return make_gdkevent(g_value_get_boxed(&values[0]));
| }
|
| void
--
酒井 政裕 / Masahiro Sakai
|
|
From: Masao M. <mu...@hi...> - 2003-10-18 12:33:42
|
さかいさん
むとうです。
Gdk::Keymapをインプリしていて気づいたのですが、
以下のサンプルが動作しません。
実行した後、ウインドウをアクティブにしてから
何かキーを入力してください。
＃あ、CVSの最新版で試してください。
----------
require 'gtk2'
Gtk.init
window = Gtk::Window.new
keymap = Gdk::Keymap.default
window.set_events(Gdk::Event::KEY_PRESS_MASK)
window.signal_connect("key_press_event") do |w, e|
p keymap.translate_keyboard_state(e.hardware_keycode, e.state, e.group)
end
window.show_all
Gtk.main
----------
で、色々やった結果、Ruby/GLib2の方に以下のパッチを適用すると
動作するようになりました。
＃ってただ、チェックを外しただけなのですが。
これってこの対応で良いですかね？
それとも、Gdk::Keymap#translate_keyboard_state側で対処すべき？
Index: rbgobj_enums.c
===================================================================
RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/glib/src/rbgobj_enums.c,v
retrieving revision 1.12
diff -u -r1.12 rbgobj_enums.c
--- rbgobj_enums.c 31 Aug 2003 05:39:57 -0000 1.12
+++ rbgobj_enums.c 17 Oct 2003 16:36:17 -0000
@@ -568,8 +568,6 @@
p->value = p->info->value;
} else {
p->value = NUM2UINT(arg);
- if ((p->gclass->mask & p->value) != p->value)
- rb_raise(rb_eArgError, "invalid argument");
}
}
--
.:% Masao Mutoh<mu...@hi...>
|
|
From: Masao M. <mu...@hi...> - 2003-10-14 14:26:04
|
さかいさん むとうです。 Nikolaiにもせっつかれてしまいましたが、 そろそろ、結論を出したいな、と思っています。 たぶん、一番大きな問題は、私が現在のGLibの 実装ってどういうところまでできてるのか きちんと把握していないことだと思います。 サンプルみたいなのをあげて説明していただけ るととっても助かるんですが、いかがでしょう。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masao M. <mu...@hi...> - 2003-10-14 13:43:07
|
むとうです。 signal_emitの件ですが、対応してみました。 ＃２ヶ月も放置してすみません glibの方にも手を入れました。 一応動いてはいるのですが、 イマイチわかってないので間違えてるかも。 確認よろしくです。＞さかいさん On Sat, 16 Aug 2003 04:16:11 +0900 Masao Mutoh <mu...@hi...> wrote: > むとうです。 > > On Fri, 15 Aug 2003 17:05:01 +0900 (JST) > Masahiro Sakai (酒井政裕) <sa...@to...> wrote: > > > さかいです。 > > > > From: きた <ki...@ki...> > > Subject: Re: [ruby-gnome2-devel-ja] Ruby/GTK2チュートリアル > > Date: Fri, 15 Aug 2003 12:38:51 +0900 > > > > > きたです． > > > > > あ，あと Gtk::Ruler の motion_notify_event をどうイジればいいか分かり > > > ません．いろいろと試してみたんですが… > > > > > > http://ruby-gnome2.sourceforge.jp/ja/hiki.cgi?ruby-gtk-Tutorials+Rulers > > > > > > もし分かる方いらっしゃいましたら教えて下さい． > > > > signal_emitで落ちるのは > > ↓と同じ原因だと思うのですが、今のところ原因不明です。 > > > > たぶん、Gdk::Event（とそのサブクラス）の作りが悪いんだと思うんですよね。 > ちと、後で見てみます。 > > それでは。 > -- > .:% Masao Mutoh<mu...@hi...> > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > ruby-gnome2-devel-ja mailing list > rub...@li... > https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-ja > -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masao M. <mu...@hi...> - 2003-10-14 10:58:02
|
むとうです。 On Tue, 14 Oct 2003 13:09:38 +0900 (JST) Masahiro Sakai (酒井政裕) <sa...@to...> wrote: > さかいです。 > > From: Masao Mutoh <mu...@hi...> > Subject: Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] GCについての質問 > Date: Sun, 5 Oct 2003 22:25:09 +0900 > > > むとうです。 > > > > g_object_run_dispose()の宣言には /*< protected >*/ がついています。 > > > つまり、サブクラスが内部で呼び出すためのもので、 > > > それ以外のところから呼び出すべきではないと思います。 > > > > protectedってそういう意味なんですか。 > > glibやgtk+ではそういう意味で使っているように思えます。 なるほど。以後、気をつけます。 > > であれば、例えば、GLib::Object#destroyメソッドを作って > > （中身はrun_disposeと同じ）それを呼び出すというのでもダメですか？ > > ＃同じことですけど。 > > > > 要は、明示的にGLib::Objectのインスタンスを破壊できるような > > メソッドが無いかなぁという話なんですが。 > > 実のところ、GObject一般を明示的に破壊するような > 公開された関数は無いはずです。 > > にしてもなんでダメなんだろう。 > > 一言で言えば「想定していない」からでは? > > そのオブジェクトを使ってる他のコードが、 > オブジェクトが明示的に破棄されることを想定していない場合、 > Segmentation Fault する可能性だってありますし。 > > > ってか通常のアプリケーションはどうやって解放しているんだろう。 > > 明示的に破壊せずに、単にunrefするだけです。 要は、Gtk::Object#destroyに相当するモノがあれば良いなぁ、 というつもりだったんですが、考えてみれば要はそれがundefですね。 Rubyからunrefが明示的に呼び出せないので、その代わりになるものが あれば良いのに、と思っていたのですが、それは結局、RubyのGCが やるべきってことですよねぇ。 となると、Ruby-GNOME2的には大きなオブジェクトを作る際はある程度 明示的にGC.startを行わないといけないと。 そう考えると、もともと大きなオブジェクトを作ることが想定される Gdk::Pixbuf等では、以前、いがらしさんのメールにあった、 「ある程度メモリを使ったであろう時点で明示的にGCを起動」 ということをやった方が良さそう（明示的にGC.startを行う確率が減る） ですねぇ。 とはいえ、「ある程度のメモリ使用量」というのはちょっと難しい ような気もします。 何か良い判断基準があれば良いのですが。何かアイデアありませんか？ 単純に回数っていう手もありますね。Gdk::Pixbuf.newを10回したら GC.startを1回やる、とか。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masahiro S. ()
<sa...@to...> - 2003-10-14 04:09:19
|
さかいです。 From: Masao Mutoh <mu...@hi...> Subject: Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] GCについての質問 Date: Sun, 5 Oct 2003 22:25:09 +0900 > むとうです。 > > g_object_run_dispose()の宣言には /*< protected >*/ がついています。 > > つまり、サブクラスが内部で呼び出すためのもので、 > > それ以外のところから呼び出すべきではないと思います。 > > protectedってそういう意味なんですか。 glibやgtk+ではそういう意味で使っているように思えます。 > であれば、例えば、GLib::Object#destroyメソッドを作って > （中身はrun_disposeと同じ）それを呼び出すというのでもダメですか？ > ＃同じことですけど。 > > 要は、明示的にGLib::Objectのインスタンスを破壊できるような > メソッドが無いかなぁという話なんですが。 実のところ、GObject一般を明示的に破壊するような 公開された関数は無いはずです。 > 結局のところ、なんでダメなの？という部分が全く解決できてないので > 堂々巡りの質問になっちゃってますね。 > どこかに参考になるモノないかなー。 > ＃ちこっとググッたんですけどみつからなかったもんで。 > ＃見落としかもしれませんが。 > > にしてもなんでダメなんだろう。 一言で言えば「想定していない」からでは? そのオブジェクトを使ってる他のコードが、 オブジェクトが明示的に破棄されることを想定していない場合、 Segmentation Fault する可能性だってありますし。 > ってか通常のアプリケーションはどうやって解放しているんだろう。 明示的に破壊せずに、単にunrefするだけです。 -- 酒井 政裕 / Masahiro Sakai |
|
From: Masao M. <mu...@hi...> - 2003-10-13 13:31:20
|
むとうです。
遅くなりました。
On Sun, 12 Oct 2003 14:04:32 +0900
KATO Kazuyoshi <kz...@us...> wrote:
> 和良です。
>
> gtk/sample/misc/pointer_grab.rb で「Grab Window!」をクリックすると
> SEGV になります。
>
> ちょっと追ってみたんですけど、
> rbgobj_get_enum(glib/src/rbgobj_enums.c) の
> enum_get_holder(obj)->value->value としている部分で
> enum_get_holder(obj)->value が変な場所を指してるっぽいです。
すみません。
これ、Gdk.pointer_grabでRVAL2FLAGSを指定すべきところでRVAL2GENUMを
指定してました。
＃なんか、他にもありそうな予感(^^;)。
CVS上では直しておきましたが、念のためパッチです。
Index: rbgdk.c
===================================================================
RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/gtk/src/rbgdk.c,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -d -r1.28 -r1.29
--- rbgdk.c 29 Aug 2003 19:14:53 -0000 1.28
+++ rbgdk.c 13 Oct 2003 13:28:28 -0000 1.29
@@ -146,7 +146,7 @@
{
return GENUM2RVAL(gdk_pointer_grab(GDK_WINDOW(RVAL2GOBJ(win)),
RTEST(owner_events),
- RVAL2GENUM(event_mask, GDK_TYPE_EVENT_MASK),
+ RVAL2GFLAGS(event_mask, GDK_TYPE_EVENT_MASK),
NIL_P(confine_to)?NULL:GDK_WINDOW(RVAL2GOBJ(confine_to)),
NIL_P(cursor)?NULL:(GdkCursor*)RVAL2BOXED(cursor, GDK_TYPE_CURSOR),
NUM2INT(time)), GDK_TYPE_GRAB_STATUS);
--
.:% Masao Mutoh<mu...@hi...>
|
|
From: KATO K. <kz...@us...> - 2003-10-12 05:00:14
|
和良です。 gtk/sample/misc/pointer_grab.rb で「Grab Window!」をクリックすると SEGV になります。 ちょっと追ってみたんですけど、 rbgobj_get_enum(glib/src/rbgobj_enums.c) の enum_get_holder(obj)->value->value としている部分で enum_get_holder(obj)->value が変な場所を指してるっぽいです。 -- KATO Kazuyoshi +++[>+++++[>+++++<-]<-]>>.----------.>+++++[<+ ++++>-]<.-----.++++.----------.++++.-----------.+.>++++++++++. |
|
From: Masao M. <mu...@hi...> - 2003-10-07 16:38:15
|
むとうです。 ちと古い話ですが。 On Tue, 19 Aug 2003 18:28:57 +0900 Masao Mutoh <mu...@hi...> wrote: > むとうです。 > > 1. まんま Gdk::Window#user_data として実装する > > 他のクラスには user_data はないのに、Gdk::Window だけもつのは、混 > > 乱のもとにならないか? > > 特別に必要なのであれば、それは特に問題ないと思いますが...。 > > > 2. user_data を持ってるものでは、全部 user_data を使えるようにする > > 大変そう。本来 user_data って仕組みは Ruby にはいらないはず。 > > 私もいらないと思いますので、Gdk::Window自身のメソッド > ってことで、Gdk::Windowだけに定義すれば良いのではないでしょうか。 > > > 3. なんか別の名前でアクセスできるようにする > > 他の言語になれた人が混乱しそう。 > > 適切な名前であれば、他の言語（たぶん、Cがメインだろうけど）になれた人の > ことはあまり意識しないで良いと思います。 > 滅多に使わないメソッドだし、そのときは覚えてもらえば良いだけですし。 > > ただ、もし、Gdk::Window#gtk_widget、Gdk::Window#widget等という名前に > するのでしたら正直抵抗があります。Gdk側からはGtkのウィジェットを意識 > させるべきではないと思いますので。 > > > と、いい方法が思いつきません。 > > > > どうするのがいいと思いますか? > > 先にも書きましたが、アクセスしないで済むのならそれが理想です。 > なんか同等の機能を他のやり方で実現できないでしょうか....。 > 難しいかなぁ。 > どうしても、ということであれば、1.ではないでしょうか。 ということで、1.を採用してGdk::Window#user_data, Gdk::Window#set_user_data として実装しました。 使い方についてはAPIリファレンスの方でフォローしたいと思います。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masao M. <mu...@hi...> - 2003-10-05 13:25:13
|
むとうです。 On Sun, 05 Oct 2003 21:58:50 +0900 (JST) Masahiro Sakai (酒井政裕) <sa...@to...> wrote: > さかいです。 > > えーとイマイチ意味がわかりませんでした。 > > 確かにGtk::Objectのサブクラスではg_object_run_disposeではなく > > gtk_object_destroy()を呼ぶべきだとは思いますが、 > > それより上位のクラスでGObjectのサブクラス（今回のようなケース） > > ではg_object_run_dispose()を呼んでも良いと思うのですが....。 > > > > そういうことではない？ > > g_object_run_dispose()の宣言には /*< protected >*/ がついています。 > つまり、サブクラスが内部で呼び出すためのもので、 > それ以外のところから呼び出すべきではないと思います。 protectedってそういう意味なんですか。 であれば、例えば、GLib::Object#destroyメソッドを作って （中身はrun_disposeと同じ）それを呼び出すというのでもダメですか？ ＃同じことですけど。 要は、明示的にGLib::Objectのインスタンスを破壊できるような メソッドが無いかなぁという話なんですが。 結局のところ、なんでダメなの？という部分が全く解決できてないので 堂々巡りの質問になっちゃってますね。 どこかに参考になるモノないかなー。 ＃ちこっとググッたんですけどみつからなかったもんで。 ＃見落としかもしれませんが。 にしてもなんでダメなんだろう。 ってか通常のアプリケーションはどうやって解放しているんだろう。 GdkPixbuf使って画像をいっぱい使ってるアプリケーションの実装を 見てみればよいのかな。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masahiro S. ()
<sa...@to...> - 2003-10-05 12:58:45
|
さかいです。 From: Masao Mutoh <mu...@hi...> Subject: Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] GCについての質問 Date: Sun, 5 Oct 2003 19:16:57 +0900 > むとうです。 > > g_object_run_dispose() はサブクラス用の関数で、 > > ユーザーが直接呼ぶための関数ではないです。 > > えーとイマイチ意味がわかりませんでした。 > 確かにGtk::Objectのサブクラスではg_object_run_disposeではなく > gtk_object_destroy()を呼ぶべきだとは思いますが、 > それより上位のクラスでGObjectのサブクラス（今回のようなケース） > ではg_object_run_dispose()を呼んでも良いと思うのですが....。 > > そういうことではない？ g_object_run_dispose()の宣言には /*< protected >*/ がついています。 つまり、サブクラスが内部で呼び出すためのもので、 それ以外のところから呼び出すべきではないと思います。 -- 酒井 政裕 / Masahiro Sakai |
|
From: Masao M. <mu...@hi...> - 2003-10-05 10:17:00
|
むとうです。 On Sun, 05 Oct 2003 18:28:48 +0900 (JST) Masahiro Sakai (酒井政裕) <sa...@to...> wrote: > さかいです。 > > From: Masao Mutoh <mu...@hi...> > Subject: Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] GCについての質問 > Date: Sun, 5 Oct 2003 17:49:14 +0900 > > > むとうです。 > > > > > そういえば、g_mem_set_vtable()を使って、 > > > > glibのメモリ管理そのものを置き換えてしまうという手も > > > > 使えるかも知れません。 > > > > これ、良いですね。まずはこれあてちゃってください。 > > あてときました。 どうもです。 > > > ・明示的なリソース解放手段の提供 > > > > gtk_object_destroy()の中身ってg_object_run_dispose()呼んでる > > だけなんですね。これを実装すれば良いのかな。 > > g_object_run_dispose() はサブクラス用の関数で、 > ユーザーが直接呼ぶための関数ではないです。 えーとイマイチ意味がわかりませんでした。 確かにGtk::Objectのサブクラスではg_object_run_disposeではなく gtk_object_destroy()を呼ぶべきだとは思いますが、 それより上位のクラスでGObjectのサブクラス（今回のようなケース） ではg_object_run_dispose()を呼んでも良いと思うのですが....。 そういうことではない？ -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masahiro S. ()
<sa...@to...> - 2003-10-05 09:28:39
|
さかいです。 From: Masao Mutoh <mu...@hi...> Subject: Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] GCについての質問 Date: Sun, 5 Oct 2003 17:49:14 +0900 > むとうです。 > > > そういえば、g_mem_set_vtable()を使って、 > > > glibのメモリ管理そのものを置き換えてしまうという手も > > > 使えるかも知れません。 > > これ、良いですね。まずはこれあてちゃってください。 あてときました。 > > ・明示的なリソース解放手段の提供 > > gtk_object_destroy()の中身ってg_object_run_dispose()呼んでる > だけなんですね。これを実装すれば良いのかな。 g_object_run_dispose() はサブクラス用の関数で、 ユーザーが直接呼ぶための関数ではないです。 -- 酒井 政裕 / Masahiro Sakai |
|
From: Masao M. <mu...@hi...> - 2003-10-05 08:49:18
|
むとうです。
On Sun, 05 Oct 2003 10:14:22 +0900
Hiroshi IGARASHI <ig...@ru...> wrote:
> いがらしです。
>
> At Sun, 05 Oct 2003 03:30:53 +0900 (JST),
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> >
> > そういえば、g_mem_set_vtable()を使って、
> > glibのメモリ管理そのものを置き換えてしまうという手も
> > 使えるかも知れません。
これ、良いですね。まずはこれあてちゃってください。
実際、試してみたんですけど、前回は”固まった”ものが、
ひととおり最後までは処理できます。
もちろん、メモリの限界（？）までGCされないので、
GC.startを明示的に行うよりは重くなります。ま、当たり前ですね。
> これができるなら、同プロセス内のglib管理下のメモリに
> 関しては解決できるでしょうね。ただこれ以外にも
>
> ・メモリ以外のリソース(File Descriptorなど)
> ・他プロセス(ex. Xサーバ)側のリソース
>
> があって、
>
> ・オブジェクト生成時の救済
> (リソースが足りなかったらrb_gc()を呼んでから再試行。
> ex. rubyのio.c, socket.c)
rb_fopen()等を見てみたのですが、それを参考にするとしたら
オブジェクト生成時の救済はGdk::Pixbuf.new内のgdk_pixbuf_new()がNULL
を返したらrb_gc()を入れて再度gdk_pixbuf_new()してみれば良いのかな。
> ・明示的なリソース解放手段の提供
gtk_object_destroy()の中身ってg_object_run_dispose()呼んでる
だけなんですね。これを実装すれば良いのかな。
ってやってみたら、イマイチ効果がわかりませんでした。
オブジェクトはきちんとdestroyedになるようだけど。
rb_gc()との合わせ技だとかなり効果的ですがどうでしょうか。
サンプル
require 'gnome2'
Gtk.init
app = Gtk::Window.new
img = Gtk::Image.new
app.add img.show
app.show
file = ARGV[0]
Thread.new do
300.times do
pb = Gdk::Pixbuf.new(file)
img.pixbuf = pb
pb.run_dispose
p pb, i
end
end
Gtk.main
Index: rbgobj_object.c
===================================================================
RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/glib/src/rbgobj_object.c,v
retrieving revision 1.52
diff -u -r1.52 rbgobj_object.c
--- rbgobj_object.c 3 Sep 2003 07:11:02 -0000 1.52
+++ rbgobj_object.c 5 Oct 2003 08:46:57 -0000
@@ -352,6 +352,15 @@
}
static VALUE
+gobj_run_dispose(self)
+ VALUE self;
+{
+ g_object_run_dispose(G_OBJECT(RVAL2GOBJ(self)));
+ rb_gc();
+ return Qnil;
+}
+
+static VALUE
gobj_inspect(self)
VALUE self;
{
@@ -593,6 +602,7 @@
rb_define_method(cGObject, "notify", gobj_notify, 1);
rb_define_method(cGObject, "thaw_notify", gobj_thaw_notify, 0);
rb_define_method(cGObject, "destroyed?", gobj_is_destroyed, 0);
+ rb_define_method(cGObject, "run_dispose", gobj_run_dispose, 0);
rb_define_method(cGObject, "initialize", gobj_initialize, -1);
rb_define_method(cGObject, "ref_count", gobj_ref_count, 0); /* for debugging */
--
.:% Masao Mutoh<mu...@hi...>
|
|
From: Hiroshi I. <ig...@ru...> - 2003-10-05 01:14:27
|
いがらしです。 At Sun, 05 Oct 2003 03:30:53 +0900 (JST), Masahiro Sakai (酒井政裕) <sa...@to...> wrote: > > そういえば、g_mem_set_vtable()を使って、 > glibのメモリ管理そのものを置き換えてしまうという手も > 使えるかも知れません。 これができるなら、同プロセス内のglib管理下のメモリに 関しては解決できるでしょうね。ただこれ以外にも ・メモリ以外のリソース(File Descriptorなど) ・他プロセス(ex. Xサーバ)側のリソース があって、 ・オブジェクト生成時の救済 (リソースが足りなかったらrb_gc()を呼んでから再試行。 ex. rubyのio.c, socket.c) ・明示的なリソース解放手段の提供 も必要になる場面はあると思います。 もちろん、まず酒井さんのパッチは入れるべきだと思います。 -- 五十嵐 宏 (Hiroshi IGARASHI) |
|
From: Masahiro S. ()
<sa...@to...> - 2003-10-04 18:31:49
|
さかいです。 From: Hiroshi IGARASHI <ig...@ru...> Subject: Re: [ruby-gnome2-devel-ja] GCについての質問 Date: Sat, 04 Oct 2003 21:48:40 +0900 > いがらしです。 > > At Sat, 4 Oct 2003 02:04:17 +0900, > Masao Mutoh <mu...@hi...> wrote: > > > > [ 814787 ] Memory leak in Gdk::Pixbuf > > http://sourceforge.net/tracker/index.php?func=detail&aid=814787&group_id=53614&atid=470969 > > > > の件で、確認をしているのですが、 > > 確かに上記にあるサンプルを動かすと画面が固まります。 > > > > でも、GC.startを入れれば正常に動作します。 > > いまはobsoleteなGdk::Imlibでも同じ問題がありました。 > http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-ext/1630 > まさ私のやり残しですね。ごめんなさい。 なるほど、そういう問題でしたか。 > ruby-gnomeのGdk::Imlib#renderでは、こんな風に > 外部ライブラリが内部である程度メモリを使ったであろう時点で > 明示的にGCを起動しています。rb_gdkimlib_render_limitを > いくつにすればいいのかというのが難しいんですが。 > > render_count += FIX2INT(w) * FIX2INT(h); > if(render_count > rb_gdkimlib_render_limit){ > rb_gc(); > render_count = 0; > } そういえば、g_mem_set_vtable()を使って、 glibのメモリ管理そのものを置き換えてしまうという手も 使えるかも知れません。 -- 酒井 政裕 / Masahiro Sakai |
|
From: Masahiro S. ()
<sa...@to...> - 2003-10-04 18:05:36
|
さかいです。 From: Masao Mutoh <mu...@hi...> Subject: [ruby-gnome2-devel-ja] GCについての質問 Date: Sat, 4 Oct 2003 02:04:17 +0900 > むとうです。 > 「GC.startをすればメモリリークが起きないのであれば > Ruby-GNOME2としては問題ない」 > > と考えて良いのですかね？ そう思います。 > あと、(1)でref_countの値が2のままだと指摘されて > ますが（たぶん）、これは、 > img.pixbuf = pb で + 1される > pb.ref_countのGOBJ2RVALで+1される > から、2で問題ないですよね？ 2で問題ないです。 # pb = Gdk::Pixbuf.new(file) でオブジェクトが作られた時点で1、 # img.pixbuf = pb で + 1 されて 2 ですね。 # pb.ref_count では、Ruby側のオブジェクトが既に存在しているので、 # GOBJ2RVALはリファレンスカウンタを増やさないはずです。 -- 酒井 政裕 / Masahiro Sakai |
|
From: Hiroshi I. <ig...@ru...> - 2003-10-04 12:48:46
|
いがらしです。 At Sat, 4 Oct 2003 02:04:17 +0900, Masao Mutoh <mu...@hi...> wrote: > > [ 814787 ] Memory leak in Gdk::Pixbuf > http://sourceforge.net/tracker/index.php?func=detail&aid=814787&group_id=53614&atid=470969 > > の件で、確認をしているのですが、 > 確かに上記にあるサンプルを動かすと画面が固まります。 > > でも、GC.startを入れれば正常に動作します。 いまはobsoleteなGdk::Imlibでも同じ問題がありました。 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-ext/1630 まさ私のやり残しですね。ごめんなさい。 ruby-gnomeのGdk::Imlib#renderでは、こんな風に 外部ライブラリが内部である程度メモリを使ったであろう時点で 明示的にGCを起動しています。rb_gdkimlib_render_limitを いくつにすればいいのかというのが難しいんですが。 render_count += FIX2INT(w) * FIX2INT(h); if(render_count > rb_gdkimlib_render_limit){ rb_gc(); render_count = 0; } > で、これの考え方なんですが、 > > 「GC.startをすればメモリリークが起きないのであれば > Ruby-GNOME2としては問題ない」 > > と考えて良いのですかね？ そうですねぇ。でもそれなりにコストの大きいGCを 起動したくないという場面もあるかも。画像以外にも たくさんオブジェクトがいるときとか。 IO#closeのように明示的にリソース解放できるのが 一番いいかと思うのですが、Gdk::Pixbuf#destroy なんていうのはないんですよね。Cレベルでは あるのかは調べてません。 > あと、(1)でref_countの値が2のままだと指摘されて > ますが（たぶん）、これは、 > img.pixbuf = pb で + 1される > pb.ref_countのGOBJ2RVALで+1される > から、2で問題ないですよね？ たぶん。 -- 五十嵐 宏 (Hiroshi IGARASHI) |
10 messages has been excluded from this view by a project administrator.
