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

Re: [ruby-gnome2-devel-ja] Action signals

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

さかい％年金は難しいなぁ です。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] Action signals
Date: Thu, 24 Jul 2003 02:13:17 +0900

> さかいさ〜ん！
> 
> むとうです。
> 
> ちと、この件なんですが。
> ＃もしかして試験中？だったらごめんなさい。

ようやく試験が終りました。
残るはレポートが2つと……(以下略)

> これ、やっぱり、まずくないですか？
> 
> gtk_window_set_focus()を見ると、
> 
> なんかいろいろ設定とか
> 　　　↓
> g_signal_emitでset_focusイベントをemit
> 
> って流れになってしまいます。
> 
> なので、単純にこのラッパを作ってしまうと
> gtk_window_set_focus()を呼べなくなってしまいます。

GtkWindowのset-focusシグナルはアクションシグナルではないので、
emitするメソッドを自動定義してはいないはずです。

  Gtk::Window.signal("set-focus").action?
  #=> false

また、自動定義されるメソッドはG_DEF_CLASSからリターンする前に定義され
るので、その後に定義される通常のメソッドを上書きしたりはしないです。

> 逆に、すでにメソッドが定義されている場合は
> このラッパではなく、元のメソッドを呼び出す
> ということも考えられますが、これだと一貫性
> がなくなり、きっとわかりづらくなるのでやめ
> たいです。

一貫性がないというのは否定しませんが、
プロパティへのアクセス用に自動生成されるメソッドも既にあるわけですし、
それらに比べて特別分かりづらいと言うこともないと思います。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Action signals

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

さかいさ〜ん！

むとうです。

ちと、この件なんですが。
＃もしかして試験中？だったらごめんなさい。

これ、やっぱり、まずくないですか？

gtk_window_set_focus()を見ると、

なんかいろいろ設定とか
　　　↓
g_signal_emitでset_focusイベントをemit

って流れになってしまいます。

なので、単純にこのラッパを作ってしまうと
gtk_window_set_focus()を呼べなくなってしまいます。

逆に、すでにメソッドが定義されている場合は
このラッパではなく、元のメソッドを呼び出す
ということも考えられますが、これだと一貫性
がなくなり、きっとわかりづらくなるのでやめ
たいです。


On Sun, 20 Jul 2003 18:04:54 +0900
Masao Mutoh <mu...@hi...> wrote:

> むとうです。
> 
> On Sun, 20 Jul 2003 15:54:56 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> 
> > さかいです。
>  
> > > > > これのメリットって何でしょうか。
> > > > > 例えば、単純にsignal_emit("cancel")をする場合に比べ、
> > > > > 
> > > > > def cancel
> > > > >   signal_emit("cancel")
> > > > > end
> > > > > 
> > > > > が自動定義されるとうれしいことって何かありますか。
> > > > > 
> > > > > 単にメソッドが増えるだけだとあまりうれしくないなぁと。
> > > > 
> > > > "They can also be thought of as by third-party code generically
> > > > callable object methods."と書いてあるので、メソッドと考えられるものは
> > > > 実際にメソッドにしてしまったほうが分かりやすいと考えました。
> > > 
> > > なるほど...。
> > > 
> > > 確かにわかりやすくなりますね。
> > > 
> > > ちと、普通のメソッド（やプロパティ）とメソッド名が重複しないか
> > > 心配ですが、とくに問題ないようでしたら、experimentalではなく
> > > 本採用ということでどうでしょうか。
> > 
> > これもすっかり忘れてましたが、
> > デフォルトで有効にしておきました。
> 
> 今、サンプルを作ろうとして気づいたのですが....。
> 
> Gtk::Window#set_focusというメソッドが元からあるのですが、
> set_focusシグナルもあります。
> 
> どちらも、引数はGtkWindow, GtkWidget(gpointerはRubyから使わないので無視)
> なので、たまたま、このままでも問題ないですが、
> やはり重複すると都合の悪いパターンがありそうな気がしてきました。
> 
> どうでしょうか。
> 
> -- 
> .:% Masao Mutoh<mu...@hi...>
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> ruby-gnome2-devel-ja mailing list
> rub...@li...
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-ja
> 


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

[ruby-gnome2-devel-ja] Next Release

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

むとうです。

来週末、（私の仕事がトラブら無い＆大きな不具合が見つからなければ）
次のリリースをしたいと思います。

できれば、CVSを使ってイロイロ叩いてみてください。
＃これからバグ仕込む可能性もなきにしもあらずですが(^^;)。

MS Windowsなんかで試してみていただけると助かりマスです。

それでは。

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

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

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

むとうです。

On Mon, 21 Jul 2003 01:23:30 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 

> > $ruby test.rb
> > test.rb:12: warning: unexpected jump occured in GClosure invocation
> > 
> > warningの場所がGtk.mainの行になるんですよね。
> > 
> > そこで、以下のようなパッチを書いてみました。
> > 
> > test.rb:7: warning: unexpected jump occured in GClosure invocation
> >
> > ちょっとはわかりやすくなると思うのですがどうでしょうか？
> 
> 良さそうですね。
> チェックインしちゃって下さい。

チェックインしました。
 
> > ＃でも、この場合はこの場でエラーとして終了してしまっても良いような
> > ＃気がしないでもないですが...。
> 
> うーみゅ。
> 
> 他の拡張ライブラリではどう対処してるのかなぁ……

このようなコールバック系の使い方だとするとGUI関係の拡張ライブラリ
が参考にはなると思いますが....。
まぁ、メッセージが出ればエラー箇所を特定できるので、現状でも
良いと思います。

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

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

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

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: [ruby-gnome2-devel-ja] rclosure_marshal
Date: Sun, 20 Jul 2003 18:43:27 +0900

> さかいさん
> 
> むとうです。
> 
> 今、以下のようなサンプルを書いてて気づいたのですが、
> signalブロック内のwarningの場所がとてもわかりづらいです。
> 
> ----------
> require 'gtk2'
> 
> Gtk.init
> 
> b = Gtk::Button.new("click")
> b.signal_connect("clicked") do |b|
> hoge
> end
> 
> Gtk::Window.new.add(b).set_default_size(100,100).show_all
> 
> 
> ---------
> 
> $ruby test.rb
> test.rb:12: warning: unexpected jump occured in GClosure invocation
> 
> warningの場所がGtk.mainの行になるんですよね。
> 
> そこで、以下のようなパッチを書いてみました。
> 
> test.rb:7: warning: unexpected jump occured in GClosure invocation
>
> ちょっとはわかりやすくなると思うのですがどうでしょうか？

良さそうですね。
チェックインしちゃって下さい。

> ＃でも、この場合はこの場でエラーとして終了してしまっても良いような
> ＃気がしないでもないですが...。

うーみゅ。

他の拡張ライブラリではどう対処してるのかなぁ……

--
酒井 政裕 / Masahiro Sakai

[ruby-gnome2-devel-ja] rclosure_marshal

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

さかいさん

むとうです。

今、以下のようなサンプルを書いてて気づいたのですが、
signalブロック内のwarningの場所がとてもわかりづらいです。

----------
require 'gtk2'
                                                                                
Gtk.init
                                                                                
b = Gtk::Button.new("click")
b.signal_connect("clicked") do |b|
hoge
end
                                                                                
Gtk::Window.new.add(b).set_default_size(100,100).show_all
                                                                                
Gtk.main
---------

$ruby test.rb
test.rb:12: warning: unexpected jump occured in GClosure invocation

warningの場所がGtk.mainの行になるんですよね。

そこで、以下のようなパッチを書いてみました。

test.rb:7: warning: unexpected jump occured in GClosure invocation

ちょっとはわかりやすくなると思うのですがどうでしょうか？
＃でも、この場合はこの場でエラーとして終了してしまっても良いような
＃気がしないでもないですが...。

-----
diff -u -r1.19 rbgobj_closure.c
--- rbgobj_closure.c    18 Jul 2003 05:27:21 -0000      1.19
+++ rbgobj_closure.c    20 Jul 2003 09:40:09 -0000
@@ -89,7 +89,7 @@
 {
     struct marshal_arg arg;
     int state;
-
+
     arg.closure         = closure;
     arg.return_value    = return_value;
     arg.n_param_values  = n_param_values;
@@ -99,8 +99,13 @@
  
     rb_protect((VALUE (*)())&rclosure_marshal_body, (VALUE)&arg, &state);
  
-    if (state)
-        rb_warn("unexpected jump occured in GClosure invocation");
+    if (state){
+        char buf[BUFSIZ];
+        snprintf(buf, BUFSIZ,
+                 "%s:%d: warning: unexpected jump occured in GClosure invocation
\n",
+                 ruby_sourcefile, ruby_sourceline);
+        rb_write_deferr(buf);
+    }
 }
  
 static VALUE rclosure_marker_list;





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

Re: [ruby-gnome2-devel-ja] Action signals

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

むとうです。

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

> さかいです。
 
> > > > これのメリットって何でしょうか。
> > > > 例えば、単純にsignal_emit("cancel")をする場合に比べ、
> > > > 
> > > > def cancel
> > > >   signal_emit("cancel")
> > > > end
> > > > 
> > > > が自動定義されるとうれしいことって何かありますか。
> > > > 
> > > > 単にメソッドが増えるだけだとあまりうれしくないなぁと。
> > > 
> > > "They can also be thought of as by third-party code generically
> > > callable object methods."と書いてあるので、メソッドと考えられるものは
> > > 実際にメソッドにしてしまったほうが分かりやすいと考えました。
> > 
> > なるほど...。
> > 
> > 確かにわかりやすくなりますね。
> > 
> > ちと、普通のメソッド（やプロパティ）とメソッド名が重複しないか
> > 心配ですが、とくに問題ないようでしたら、experimentalではなく
> > 本採用ということでどうでしょうか。
> 
> これもすっかり忘れてましたが、
> デフォルトで有効にしておきました。

今、サンプルを作ろうとして気づいたのですが....。

Gtk::Window#set_focusというメソッドが元からあるのですが、
set_focusシグナルもあります。

どちらも、引数はGtkWindow, GtkWidget(gpointerはRubyから使わないので無視)
なので、たまたま、このままでも問題ないですが、
やはり重複すると都合の悪いパターンがありそうな気がしてきました。

どうでしょうか。

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

Re: [ruby-gnome2-devel-ja] Action signals

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

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] Action signals
Date: Sat, 12 Apr 2003 00:34:37 +0900

> むとうです。
> 
> On Fri, 11 Apr 2003 11:05:25 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> 
> > さかいです。
> > 
> > From: Masao Mutoh <mu...@hi...>
> > Subject: Re: [ruby-gnome2-devel-ja] Action signals
> > Date: Fri, 11 Apr 2003 03:20:50 +0900
> > 
> > > むとうです。
> > 
> > > これのメリットって何でしょうか。
> > > 例えば、単純にsignal_emit("cancel")をする場合に比べ、
> > > 
> > > def cancel
> > >   signal_emit("cancel")
> > > end
> > > 
> > > が自動定義されるとうれしいことって何かありますか。
> > > 
> > > 単にメソッドが増えるだけだとあまりうれしくないなぁと。
> > 
> > "They can also be thought of as by third-party code generically
> > callable object methods."と書いてあるので、メソッドと考えられるものは
> > 実際にメソッドにしてしまったほうが分かりやすいと考えました。
> 
> なるほど...。
> 
> 確かにわかりやすくなりますね。
> 
> ちと、普通のメソッド（やプロパティ）とメソッド名が重複しないか
> 心配ですが、とくに問題ないようでしたら、experimentalではなく
> 本採用ということでどうでしょうか。

これもすっかり忘れてましたが、
デフォルトで有効にしておきました。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] enum/flags =?iso-2022-jp?B?GyRCJE4lLyVpJTkyPRsoQg==?=

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

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] enum/flags のクラス化
Date: Sun, 20 Jul 2003 03:43:52 +0900

> むとうです。
> 
> ＃さかいさんもお疲れのようで(^^;)

今期も後少しなんですけど、その少しがなかなか… (^^;

> > > rbg_enum_add_constants(GTYPE2CLASS(GTK_TYPE_WINDOW), GTK_TYPE_WINDOW_TYPE,
> > >                        "GTK_WINDOW_")
> > > のように書けるようにするのが良さそうな気がして来ました。
> > 
> > このアイディアを実装してみました。
> > 値は整数のまま変更していません。
> 
> これ、良いですね。まずは第１段階ということで。
> 
> ただ、これだけ頻繁に使われるのでマクロを用意しておきたいです。
> 他のものにあわせて
> 
> G_DEF_CONSTANTS(klass, gtype, strip_prefix)
> 
> でどうでしょうか？
> 問題ないようでしたらCVSにあてちゃってください。

G_DEF_CONSTANTSにしてチェックインしました。

> ところで、第２段階としてクラス化したとすると、
> 関数内でINT2NUMとかを使ってる部分が結構悩ましいですね。

そうですね。
量が量ですし。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] enum/flags =?ISO-2022-JP?B?GyRCJE4lLyVpJTkyPRsoQg==?=

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

むとうです。

＃さかいさんもお疲れのようで(^^;)

On Sat, 19 Jul 2003 20:51:29 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> From: Masahiro Sakai (酒井政裕) <sa...@to...>
> Subject: Re: [ruby-gnome2-devel-ja] enum/flags のクラス化
> Date: Sat, 19 Jul 2003 14:20:57 +0900 (JST)
> 
> > > コーディング上は、Cレベルでrb_define_constしてたところ辺りを
> > > ざっくり削除して、
> > > 
> > > G_DEF_CONST("GtkWindowType");
> > > 
> > > とか書けたりしたら、それだけでもかなり便利になるような気がします。
> > > ＃ここでは自動化はしない方がRuby/GTKの好きなクラスにEnumsを配置できるので
> > > ＃良いような気がします。
> > 
> > 今調べてみたところ、PyGtkでは
> > pyg_enum_add_constants(PyObject *module, GType enum_type,
> >                        const gchar *strip_prefix)
> > という関数を使って定数を定義しているようです。
> > 
> > これにならって、
> > rbg_enum_add_constants(GTYPE2CLASS(GTK_TYPE_WINDOW), GTK_TYPE_WINDOW_TYPE,
> >                        "GTK_WINDOW_")
> > のように書けるようにするのが良さそうな気がして来ました。
> 
> このアイディアを実装してみました。
> 値は整数のまま変更していません。

これ、良いですね。まずは第１段階ということで。

ただ、これだけ頻繁に使われるのでマクロを用意しておきたいです。
他のものにあわせて

G_DEF_CONSTANTS(klass, gtype, strip_prefix)

でどうでしょうか？
問題ないようでしたらCVSにあてちゃってください。

--
ところで、第２段階としてクラス化したとすると、
関数内でINT2NUMとかを使ってる部分が結構悩ましいですね。

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

Re: [ruby-gnome2-devel-ja] enum/flags =?iso-2022-jp?B?GyRCJE4lLyVpJTkyPRsoQg==?=

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

さかいです。

From: Masahiro Sakai (酒井政裕) <sa...@to...>
Subject: Re: [ruby-gnome2-devel-ja] enum/flags のクラス化
Date: Sat, 19 Jul 2003 14:20:57 +0900 (JST)

> > コーディング上は、Cレベルでrb_define_constしてたところ辺りを
> > ざっくり削除して、
> > 
> > G_DEF_CONST("GtkWindowType");
> > 
> > とか書けたりしたら、それだけでもかなり便利になるような気がします。
> > ＃ここでは自動化はしない方がRuby/GTKの好きなクラスにEnumsを配置できるので
> > ＃良いような気がします。
> 
> 今調べてみたところ、PyGtkでは
> pyg_enum_add_constants(PyObject *module, GType enum_type,
>                        const gchar *strip_prefix)
> という関数を使って定数を定義しているようです。
> 
> これにならって、
> rbg_enum_add_constants(GTYPE2CLASS(GTK_TYPE_WINDOW), GTK_TYPE_WINDOW_TYPE,
>                        "GTK_WINDOW_")
> のように書けるようにするのが良さそうな気がして来ました。

このアイディアを実装してみました。
値は整数のまま変更していません。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] enum/flags =?iso-2022-jp?B?GyRCJE4lLyVpJTkyPRsoQg==?=

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

さかい％テストで失敗してさらに現実逃避に拍車が… です。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] enum/flags のクラス化
Date: Sat, 19 Jul 2003 03:17:45 +0900

> むとうです。
> 
> 連絡遅れてすみません。ちと仕事で徹夜してました(^^;)。

お疲れ様です。

> On Thu, 17 Jul 2003 15:29:50 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> > 現状をまとめると、
> > 
> > * 互換性にはそれなりに気を配ったので、
> >   これまで動作した大抵のコードは動作しなくなったりはしないはず
> 
> 互換性を残してというのは、今までのものはそのまま残して
> 新たに定義したこちらと併用するというイメージでしょうか。
> ２つあると、ドキュメントが大変になりそうな気が....(T_T)。

これまでのものをそのまま残して……というよりは
ユーザーのコードのことをあまり気にせずに、
こっそり徐々に移行していく事が出来るというイメージです。

> > > とりあえず、手元では以下のような事が出来るようになっています。
> > > 
> > > require 'gtk2'
> > > Gtk::Window::Type = GLib::Type['GtkWindowType'].to_class
> > > 
> > > p Gtk::Window::Type.values
> > > #=> [#<Gtk::Window::Type value=0 name="GTK_WINDOW_TOPLEVEL" nick="toplevel">,
> > > #    #<Gtk::Window::Type value=1 name="GTK_WINDOW_POPUP" nick="popup">]
> > > 
> > > p Gtk::Window::Type::TOPLEVEL
> > > #=> #<Gtk::Window::Type value=0 name="GTK_WINDOW_TOPLEVEL" nick="toplevel">
> 
> これ、どういう風に使うのでしょうか。
> 
> Gtk::Window.new(Gtk::Window::Type::TOPLEVEL)
> 
> と書くイメージでよろしいですか？

はい。

また、
w = Gtk::Window.new
w.get_property("type")
等としたときも、整数ではなくこのオブジェクトが返るようになります。

> この認識で良いとして、
> 技術的にはコーディングの作業を少なくしたりできそうですし、ユーザ的にも
> 定数値の分類を、irb等から簡単に見つけることができるのが便利そうですね。
> 
> ただ、ちと定数値が長くなりすぎてるような気もしないでもないです。
> やはり、上記の場合は、
> Gtk::Window.new(Gtk::Window::TOPLEVEL)
> がいっぱいいっぱいの長さじゃないでしょうか（あくまでも私の感覚ですが）。

同感です。
# 「::」を打つのって案外億劫なんですよね (^^;

自動的に定義される定数名は上記のとおりなんですが、
実際にユーザの使う定数名についてはこれから議論して、
これまで通りの名前をaliasとして用意しようと考えていました。

> 定数値は今までと変更無しの
>   Gtk::Window::TOPLEVEL
>   Gtk::Window::POPUP
> 
> のような感じでアクセスできて、その実、以下のように変わってるってのは
> どうでしょうか？
> 
> p Gtk::Window::TOPLEVEL
>   #=> #<GtkWindowType value=0 name="GTK_WINDOW_TOPLEVEL" nick="toplevel">
> 
> この１番目のGtkWindowTypeの部分でソートできれば、見た目上もイイでしょうし。

この1番目の部分にクラス名以外のものが入っているのは、
ユーザーを混乱させませんか?

> ---
> コーディング上は、Cレベルでrb_define_constしてたところ辺りを
> ざっくり削除して、
> 
> G_DEF_CONST("GtkWindowType");
> 
> とか書けたりしたら、それだけでもかなり便利になるような気がします。
> ＃ここでは自動化はしない方がRuby/GTKの好きなクラスにEnumsを配置できるので
> ＃良いような気がします。

今調べてみたところ、PyGtkでは
pyg_enum_add_constants(PyObject *module, GType enum_type,
                       const gchar *strip_prefix)
という関数を使って定数を定義しているようです。

これにならって、
rbg_enum_add_constants(GTYPE2CLASS(GTK_TYPE_WINDOW), GTK_TYPE_WINDOW_TYPE,
                       "GTK_WINDOW_")
のように書けるようにするのが良さそうな気がして来ました。

また、下でむとうさんが書いているように、共通部分を自動的に見付けるよう
にして、"GTK_WINDOW_"を明示的に指定しないで済むようにするのも良いかも
知れません。

> あ、そうそう、一つ気になったのですが、上記例のTOPLEVELって、
> どのように抽出してるのでしょうか。その前のGtkWindowTypeから同じ部分を
> 削除してます？
> （イメージ）
>  GtkWindowType -> GTK_WINDOW_TYPE -> GTK_WINDOW_まで同じ
> だから削除

以下のような構造体でglibから情報を引き出せるので、
value_nickをupcaseしたものを使ってます。

struct  _GEnumClass
{
  GTypeClass  g_type_class;
  
  gint        minimum;
  gint        maximum;
  guint       n_values;
  GEnumValue *values;
};

struct _GEnumValue
{
  gint   value;
  gchar *value_name;
  gchar *value_nick;
};

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Gtk::TextBuffer#insert SEGV

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

むとうです。

On Fri, 18 Jul 2003 22:46:56 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> From: Nobuyoshi Nakada <nob...@so...>
> Subject: Re: [ruby-gnome2-devel-ja] Gtk::TextBuffer#insert SEGV
> Date: Thu, 17 Jul 2003 02:31:17 +0900
> 
> > なかだです。
> > 
> > At Thu, 17 Jul 2003 02:09:03 +0900,
> > Masao Mutoh wrote:
> > > rbglib_convert.cみたいに StringValue(str)してから、RSTRING(str)->ptr/len
> > > を使えば良い？
> > 
> > それでいいはずです。
> 
> 気がついた所は直しておきました。

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

ついでといっては何ですが、signalsとpropertiesのデフォルトを
instance_methodsの仕様に合わせて、superclass
まで全部読み込むように仕様変更するってやつやりませんか？
＃やるやると言ってて全然手をつけてません....。

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

Re: [ruby-gnome2-devel-ja] enum/flags =?ISO-2022-JP?B?GyRCJE4lLyVpJTkyPRsoQg==?=

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

むとうです。

連絡遅れてすみません。ちと仕事で徹夜してました(^^;)。

On Thu, 17 Jul 2003 15:29:50 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> From: Masahiro Sakai (酒井政裕) <sa...@to...>
> Subject: [ruby-gnome2-devel-ja] enum/flags のクラス化
> Date: Sun, 06 Apr 2003 20:57:47 +0900 (JST)
> 
> > GEnum/GFlagsの派生タイプを現在は整数として扱っていますが、
> > これをそれぞれのクラスのオブジェクトとして扱うように
> > 変更しようかと考えています。
> 
> すっかり忘れていたのですが、これどうしましょっか?
> 
> 自分では結構気に入っているのですが、少々やりすぎという気もしています。

なるほど。
 
> 現状をまとめると、
> 
> * 互換性にはそれなりに気を配ったので、
>   これまで動作した大抵のコードは動作しなくなったりはしないはず

互換性を残してというのは、今までのものはそのまま残して
新たに定義したこちらと併用するというイメージでしょうか。
２つあると、ドキュメントが大変になりそうな気が....(T_T)。
 
> * 下のサンプルのように、各クラスに定数を自動定義する事は出来てます。
>   ですが、これは定数の定義場所と名前が現在のルールと違うので、
>   現在のルールを維持するには結局個別の対応が必要。
> 
> といったところです。
> 
> > とりあえず、手元では以下のような事が出来るようになっています。
> > 
> > require 'gtk2'
> > Gtk::Window::Type = GLib::Type['GtkWindowType'].to_class
> > 
> > p Gtk::Window::Type.values
> > #=> [#<Gtk::Window::Type value=0 name="GTK_WINDOW_TOPLEVEL" nick="toplevel">,
> > #    #<Gtk::Window::Type value=1 name="GTK_WINDOW_POPUP" nick="popup">]
> > 
> > p Gtk::Window::Type::TOPLEVEL
> > #=> #<Gtk::Window::Type value=0 name="GTK_WINDOW_TOPLEVEL" nick="toplevel">

これ、どういう風に使うのでしょうか。

Gtk::Window.new(Gtk::Window::Type::TOPLEVEL)

と書くイメージでよろしいですか？

この認識で良いとして、
技術的にはコーディングの作業を少なくしたりできそうですし、ユーザ的にも
定数値の分類を、irb等から簡単に見つけることができるのが便利そうですね。

ただ、ちと定数値が長くなりすぎてるような気もしないでもないです。
やはり、上記の場合は、
Gtk::Window.new(Gtk::Window::TOPLEVEL)
がいっぱいいっぱいの長さじゃないでしょうか（あくまでも私の感覚ですが）。

定数値は今までと変更無しの
  Gtk::Window::TOPLEVEL
  Gtk::Window::POPUP

のような感じでアクセスできて、その実、以下のように変わってるってのは
どうでしょうか？

p Gtk::Window::TOPLEVEL
  #=> #<GtkWindowType value=0 name="GTK_WINDOW_TOPLEVEL" nick="toplevel">

この１番目のGtkWindowTypeの部分でソートできれば、見た目上もイイでしょうし。

例えば、Type別に情報を取得したい場合なんかは

p Gtk::Window.enums
 #=> ["GtkWindowType", ..., ...]

とかを用意しておいて

Gtk::Window.enums.each do |enum|
   p GLib::Type[enum]
end

とかすると情報が出てくるとか。

---
コーディング上は、Cレベルでrb_define_constしてたところ辺りを
ざっくり削除して、

G_DEF_CONST("GtkWindowType");

とか書けたりしたら、それだけでもかなり便利になるような気がします。
＃ここでは自動化はしない方がRuby/GTKの好きなクラスにEnumsを配置できるので
＃良いような気がします。

あ、そうそう、一つ気になったのですが、上記例のTOPLEVELって、
どのように抽出してるのでしょうか。その前のGtkWindowTypeから同じ部分を
削除してます？
（イメージ）
 GtkWindowType -> GTK_WINDOW_TYPE -> GTK_WINDOW_まで同じ
だから削除


相当検討違いなこと言ってたら、すみません。
徹夜続きで頭ぼーっとしてますんで(T_T)。

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

Re: [ruby-gnome2-devel-ja] Gtk::TextBuffer#insert SEGV

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

さかいです。

From: Nobuyoshi Nakada <nob...@so...>
Subject: Re: [ruby-gnome2-devel-ja] Gtk::TextBuffer#insert SEGV
Date: Thu, 17 Jul 2003 02:31:17 +0900

> なかだです。
> 
> At Thu, 17 Jul 2003 02:09:03 +0900,
> Masao Mutoh wrote:
> > rbglib_convert.cみたいに StringValue(str)してから、RSTRING(str)->ptr/len
> > を使えば良い？
> 
> それでいいはずです。

気がついた所は直しておきました。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] enum/flags =?iso-2022-jp?B?GyRCJE4lLyVpJTkyPRsoQg==?=

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

さかいです。

From: Masahiro Sakai (酒井政裕) <sa...@to...>
Subject: [ruby-gnome2-devel-ja] enum/flags のクラス化
Date: Sun, 06 Apr 2003 20:57:47 +0900 (JST)

> GEnum/GFlagsの派生タイプを現在は整数として扱っていますが、
> これをそれぞれのクラスのオブジェクトとして扱うように
> 変更しようかと考えています。

すっかり忘れていたのですが、これどうしましょっか?

自分では結構気に入っているのですが、少々やりすぎという気もしています。

現状をまとめると、

* 互換性にはそれなりに気を配ったので、
  これまで動作した大抵のコードは動作しなくなったりはしないはず

* 下のサンプルのように、各クラスに定数を自動定義する事は出来てます。
  ですが、これは定数の定義場所と名前が現在のルールと違うので、
  現在のルールを維持するには結局個別の対応が必要。

といったところです。

> とりあえず、手元では以下のような事が出来るようになっています。
> 
> require 'gtk2'
> Gtk::Window::Type = GLib::Type['GtkWindowType'].to_class
> 
> p Gtk::Window::Type.values
> #=> [#<Gtk::Window::Type value=0 name="GTK_WINDOW_TOPLEVEL" nick="toplevel">,
> #    #<Gtk::Window::Type value=1 name="GTK_WINDOW_POPUP" nick="popup">]
> 
> p Gtk::Window::Type::TOPLEVEL
> #=> #<Gtk::Window::Type value=0 name="GTK_WINDOW_TOPLEVEL" nick="toplevel">

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Gtk::TextBuffer#insert SEGV

[Nobuyoshi N. <nob...@so...>]

なかだです。

At Thu, 17 Jul 2003 02:09:03 +0900,
Masao Mutoh wrote:
> rbglib_convert.cみたいに StringValue(str)してから、RSTRING(str)->ptr/len
> を使えば良い？

それでいいはずです。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

Re: [ruby-gnome2-devel-ja] Gtk::TextBuffer#insert SEGV

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

むとうです。

On Wed, 16 Jul 2003 22:15:11 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> From: Nobuyoshi Nakada <nob...@so...>
> Subject: Re: [ruby-gnome2-devel-ja] Gtk::TextBuffer#insert SEGV
> Date: Wed, 16 Jul 2003 19:20:41 +0900
> 
> > なかだです。
> > 
> > At Wed, 16 Jul 2003 18:08:58 +0900,
> > KATO Kazuyoshi wrote:
> > > Gtk::TextBuffer#insert の文字列を渡すべき部分に nil を渡すと
> > >   TextView_insert.rb:8: [BUG] Segmentation fault
> > > となって SEGV で落ちます。
> > > 
> > > もちろん、使いかたが間違っているんですが、SEGV で落ちるよりは例外を投
> > > げるべきじゃないでしょうか？
> > 
> > RVAL2CSTR(=StringValuePtr)とRSTRING()->lenを同じ式で使うのは、
> > 評価順序が未定義なのでまずいでしょうね。
> 
> うわぁ、確かに。
> 
> しかも他にも同じ事をしてる箇所が結構あるなぁ……

すみませんすみません。全部私です(T_T)。

で、これってどうすれば良いんですか？(^^;)

rbglib_convert.cみたいに StringValue(str)してから、RSTRING(str)->ptr/len
を使えば良い？

＃今日は寝ます....。 

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

Re: [ruby-gnome2-devel-ja] Gtk::TextBuffer#insert SEGV

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

さかいです。

From: Nobuyoshi Nakada <nob...@so...>
Subject: Re: [ruby-gnome2-devel-ja] Gtk::TextBuffer#insert SEGV
Date: Wed, 16 Jul 2003 19:20:41 +0900

> なかだです。
> 
> At Wed, 16 Jul 2003 18:08:58 +0900,
> KATO Kazuyoshi wrote:
> > Gtk::TextBuffer#insert の文字列を渡すべき部分に nil を渡すと
> >   TextView_insert.rb:8: [BUG] Segmentation fault
> > となって SEGV で落ちます。
> > 
> > もちろん、使いかたが間違っているんですが、SEGV で落ちるよりは例外を投
> > げるべきじゃないでしょうか？
> 
> RVAL2CSTR(=StringValuePtr)とRSTRING()->lenを同じ式で使うのは、
> 評価順序が未定義なのでまずいでしょうね。

うわぁ、確かに。

しかも他にも同じ事をしてる箇所が結構あるなぁ……

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Gtk::TextBuffer#insert SEGV

[Nobuyoshi N. <nob...@so...>]

なかだです。

At Wed, 16 Jul 2003 18:08:58 +0900,
KATO Kazuyoshi wrote:
> Gtk::TextBuffer#insert の文字列を渡すべき部分に nil を渡すと
>   TextView_insert.rb:8: [BUG] Segmentation fault
> となって SEGV で落ちます。
> 
> もちろん、使いかたが間違っているんですが、SEGV で落ちるよりは例外を投
> げるべきじゃないでしょうか？

RVAL2CSTR(=StringValuePtr)とRSTRING()->lenを同じ式で使うのは、
評価順序が未定義なのでまずいでしょうね。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

[ruby-gnome2-devel-ja] Gtk::TextBuffer#insert SEGV

[KATO K. <kz...@ro...>]

こんにちは。

Gtk::TextBuffer#insert の文字列を渡すべき部分に nil を渡すと
  TextView_insert.rb:8: [BUG] Segmentation fault
となって SEGV で落ちます。

もちろん、使いかたが間違っているんですが、SEGV で落ちるよりは例外を投
げるべきじゃないでしょうか？

以下のコードで再現します。

require 'gtk2'

Gtk.init
window = Gtk::Window.new

text_view = Gtk::TextView.new
iter = text_view.buffer.get_iter_at_offset(0)
text_view.buffer.insert(0, nil) # SEGV!

window.add(button)
window.show_all

Gtk.main

--
KATO Kazuyoshi  +++[>+++++[>+++++<-]<-]>>.----------.>+++++[<+
++++>-]<.-----.++++.----------.++++.-----------.+.>++++++++++.

[ruby-gnome2-devel-ja] Module names

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

むとうです。

ちと、enの方で話題になった（話題にした(^^;)）のですが
みなさんのご意見を聞きたいと思います。

今、NikolaiがGnomeVFSをインプリしてくれているのですが、
モジュール名の付け方におや？と思いました。

具体的には、 GnomeVFS::Directory, GnomeVFS::File
という感じです。
これ自体は、まぁ、違和感ないのですが、他ライブラリと
一緒に見てしまうとちと整合性に欠けるかなと言う気がします。

例えば、GnomeCanvasItemはGnomeCanvas::Itemではなく
Gnome::CanvasItemですし、GdkPixbufAnimationは
GdkPixbuf::AnimationではなくGdk::PixbufAnimationです。

＃もしかしたら、Gdk::Pixbuf::Animationのようにさらに
＃わけるべきだったのかもしれませんが、個人的にはあまり
＃階層分けをするのは冗長すぎると思っています。

とはいえ、GnomeVFSの上記のクラスを他に合わせると

Gnome::VFSDirectory, Gnome::VFSFileとなり、それはそれで
ちょっと気持ち悪いかなぁという感じもします。

ただ、includeする時なんかはこっちの方が良いかもしれない
とも思っています。
＃include GnomeVFSとやってしまうと、Fileクラスが標準添付の
＃Fileクラスと重複してしまいます（よね？）。

とまぁ、つれづれなく考えては見たのですが、みなさんは
どうお考えでしょうか？

1. 何らかのルールを作る（例えばGtkとかGnomeとかついてたら
　　そこで分割するとか）か、ケースバイケースにするか。

2. ルールはともかくGnomeVFSはGnomeVFS::Directoryか
　　Gnome::VFSDirectoryかGnome::VFS::Directoryか。
　　＃Gnome::VFS::Directoryというのは個人的には好きでは
　　＃ないですがそれも候補に入れましょう(^^;)。

P.S.
従来あるクラスについては変更するつもりはありませんので
ご安心（？）を。

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

Re: [ruby-gnome2-devel-ja] FW:Re: [ruby-gnome2-devel-en] Segmentation fault in rbbr from cvs

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

むとうです。

On Tue, 15 Jul 2003 13:55:00 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> From: Masao Mutoh <mu...@hi...>
> Subject: Re: [ruby-gnome2-devel-ja] FW:Re: [ruby-gnome2-devel-en] Segmentation fault in rbbr from cvs
> Date: Tue, 15 Jul 2003 01:24:10 +0900
> 
> > むとうです。
> 
> > いやぁ、良かったです。無事、動いています。
> > p Gtk::Buttonが落ちるってとこまではわかってたんですけどねぇ。
> > それから先がダメだったんですよ。
> > さかいさんは、こういう時ってデバッグどういう風にやられてるんですか？
> > ＃どうも、こういうバグを見つけるのは苦手で....。
> 
> Cygwinのgdbでlibrubyのシンボルが正しく表示されなかったので、
> 今回はprintfデバッグです (^^;
> # 実は最初はRubyのバグだと思いました。

うお、強烈ですね(^^;)。
 
> librubyにprintfを大量に埋め込んだ結果、
> variable.cのfc_i()からTYPE()に0x6eという不正な値が渡されている、
> すなわち定数のVALUEが壊れている壊れている事が分かりました。

あー、私、gdbでfc_i()まではわかったんですけど、0x6eが不正という判断が
できなかったのでした。はー、修行が足りん...(T_T)。
 
> そこで、とりあえずrb_define_const()に0x6eが渡されて来たら
> その名前を表示するようにしてみて、今回のバグに行き当たりました。

なるほど。
結構、rb_define_const()ってINT2NUMとか忘れちゃうんでこれから似たような
バグが出たらまず疑ってみることにします(^^;)。

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

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

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

むとうです。

On Tue, 15 Jul 2003 21:54:10 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> From: Masao Mutoh <mu...@hi...>
> Subject: Re: [ruby-gnome2-devel-ja] rbbr
> Date: Mon, 14 Apr 2003 00:15:10 +0900
> 
> > むとうです。
> 
> > > ところで、プロパティのBlurbはリストビューに表示するには長すぎなので、
> > > DocViewerの部分に表示したいのですが、どうでしょうか?
> > 
> > いいっすよ。やっちゃってください。
> 
> すっかり忘れていましたが、チェックインしました。
> # ad-hoc な実装方法なので、誰か改良してくれると嬉しいです

おー、ありがとうございます。

そういえば、そろそろrbbrもいじらないとですねぇ。
いろいろやりたいことはあるんですが(^^;)。

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

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

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

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] rbbr
Date: Mon, 14 Apr 2003 00:15:10 +0900

> むとうです。

> > ところで、プロパティのBlurbはリストビューに表示するには長すぎなので、
> > DocViewerの部分に表示したいのですが、どうでしょうか?
> 
> いいっすよ。やっちゃってください。

すっかり忘れていましたが、チェックインしました。
# ad-hoc な実装方法なので、誰か改良してくれると嬉しいです

--
酒井 政裕 / Masahiro Sakai