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: Masaaki A. <mas...@gm...> - 2011-12-13 12:07:26
|
青柳です。 >> GtkSourceCompletionProviderやGtkSourceUndoManagerはinterfaceとなっており >> それを実装したGObjectが存在していないので、自前で実装する必要があるのだと思いますが >> interfaceの実装をruby側で行うような仕組みがあったりするのでしょうか？ >> ざっと見た感じ無さそうだとは思っているのですが、この辺りはどうしたもんでしょうか？ > > あれ、G_DEF_INTERFACE()で動きませんか？ 例えば、GtkSourceCompletionProvider自体はG_DEF_INTERFACEでモジュールとして定義できるのですが、 たぶんgtk_source_completion_add_providerあたりでGtkSourceCompletionProviderのインスタンスを 渡す必要があると思うのですが、実装したGObjectが存在しないため、インスタンス生成をどうやって行うかが 分からないです。 >> GObjectのみGTKWIDGET2RVAL方向の定義はせず、他は双方向を定義したいと思っています。 >> 合わせて以下のようなヘッダの構成に統一していきたいのですが、いかがでしょうか？ >> * rb<パッケージ名>.h >> 外部からincludeされうるヘッダ >> * rb<パッケージ名>conversions.h >> 変換マクロ用のヘッダ >> * rb<パッケージ名>private.h >> 内部からincludeされるヘッダ >> ※パッケージ名にはバージョンを含まない（例：rbgtk.h） > > うーん、debパッケージやrpmパッケージを作っている人たちが困り > そうです。。。debやrpmではgemみたいに各パッケージ毎にディレ > クトリを掘るのではなく、共通のディレクトリにヘッダーファイル > を置くのです。 > （/usr/lib/ruby/vendor_ruby/1.9.1/x86_64-linux/以下とか） > > なので、ヘッダーファイルにはrbgtk3.hの用にバージョンを入れた > 方がいいと思っています。 なるほど。そうなんですね。 ということで、バージョンを入れるようにしました。 |
|
From: Kouhei S. <ko...@co...> - 2011-12-11 04:07:18
|
須藤です。 In <CAMyNdeXNugFu-+bmmCW3V+kH+SFD2iRE12JVxjG=Faj...@ma...> "Re: [ruby-gnome2-devel-ja] 名前空間のGObjectIntrospection準拠について" on Thu, 8 Dec 2011 23:03:47 +0900, Masaaki Aoyagi <mas...@gm...> wrote: >> 次のリリースにはexperimental扱い（これからまだAPIを変更する >> かもしれないよ状態）でgtk3も含めようと思っています。なので、 >> 完全にできたという状態でなくてもよいので、ビルドできるとか何 >> かキリのよいところで教えてもらえますか？そこで一度リリースし >> てしまいます。 > > すみません。。。 > まだgtk3はリリースしていい状況には程遠いのでgtk3抜きで > リリースをお願いします。 わかりましたー |
|
From: Masaaki A. <mas...@gm...> - 2011-12-08 14:03:58
|
青柳です。 > 次のリリースにはexperimental扱い（これからまだAPIを変更する > かもしれないよ状態）でgtk3も含めようと思っています。なので、 > 完全にできたという状態でなくてもよいので、ビルドできるとか何 > かキリのよいところで教えてもらえますか？そこで一度リリースし > てしまいます。 すみません。。。 まだgtk3はリリースしていい状況には程遠いのでgtk3抜きで リリースをお願いします。 |
|
From: Kouhei S. <ko...@co...> - 2011-12-08 13:42:37
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] 名前空間のGObjectIntrospection準拠について" on Thu, 8 Dec 2011 22:37:46 +0900, Masaaki Aoyagi <mas...@gm...> wrote: >>> 今のところ、パッケージが分かれている >>> * gio2 (GLibからGioへ変更) >>> * gdk_pixbuf2 (GdkからGdkPixbufへ変更) >>> を変更したいと思っています。 >> >> うーん、gio2は正式リリースが最近であんまり使っている人がいな >> そうなので別にいいかなぁという気もしますが、gdk_pixbuf2はか >> なり昔からあるものなので、躊躇してしまいます。 >> とりあえず、一度、今の状態でリリースしてからにしませんか？ > > 分かりました。 > 名前空間の変更は、するにしてもリリース後にしましょう。 そうしましょう！ 次のリリースにはexperimental扱い（これからまだAPIを変更する かもしれないよ状態）でgtk3も含めようと思っています。なので、 完全にできたという状態でなくてもよいので、ビルドできるとか何 かキリのよいところで教えてもらえますか？そこで一度リリースし てしまいます。 > この提案は、gio2の実装をする必要が出てきて、ファイル名を命名規則に準じたものに > 変更しようと思ったのですが、gio2の名前空間がGObjectIntrospectionと違っていたため > 行いました。（今のままだとrbglibfile.cのような名前になる） > なので、ファイル名の変更も取り敢えず保留にしておきます。 > ただ、gio2の方は数も多いので、見通し良くする意味でも名前空間を変更したいです。 はい、gio2の方はやってしまってよいです。 >> うーん、GObjectとかGModuleは具体的に外にでてくる（ユーザーが >> 触るような）オブジェクトってありましたっけ？ > > 直接触ることは無さそうですね。 > 必要が出てきたら考えます。 そうしましょう！ |
|
From: Masaaki A. <mas...@gm...> - 2011-12-08 13:37:52
|
青柳です。 >> 今のところ、パッケージが分かれている >> * gio2 (GLibからGioへ変更) >> * gdk_pixbuf2 (GdkからGdkPixbufへ変更) >> を変更したいと思っています。 > > うーん、gio2は正式リリースが最近であんまり使っている人がいな > そうなので別にいいかなぁという気もしますが、gdk_pixbuf2はか > なり昔からあるものなので、躊躇してしまいます。 > とりあえず、一度、今の状態でリリースしてからにしませんか？ 分かりました。 名前空間の変更は、するにしてもリリース後にしましょう。 この提案は、gio2の実装をする必要が出てきて、ファイル名を命名規則に準じたものに 変更しようと思ったのですが、gio2の名前空間がGObjectIntrospectionと違っていたため 行いました。（今のままだとrbglibfile.cのような名前になる） なので、ファイル名の変更も取り敢えず保留にしておきます。 ただ、gio2の方は数も多いので、見通し良くする意味でも名前空間を変更したいです。 >> glib2についてはGLib、GObject、GModuleなどの名前空間があるようですが >> 準拠した方がいいかは迷っています。 > > うーん、GObjectとかGModuleは具体的に外にでてくる（ユーザーが > 触るような）オブジェクトってありましたっけ？ 直接触ることは無さそうですね。 必要が出てきたら考えます。 |
|
From: Kouhei S. <ko...@co...> - 2011-12-08 12:53:30
|
須藤です。 In <CAM...@ma...> "[ruby-gnome2-devel-ja] 名前空間のGObjectIntrospection準拠について" on Thu, 8 Dec 2011 01:14:22 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > GTK3対応で名前空間のGObjectIntrospection準拠をしましたが、GTK2と共通になっている > パッケージについても出来ればGObjectIntrospectionに準じたものに変えていきたいです。 > 以下のようなステップで移行することを考えていますが、いかがでしょうか？ > * 既存のものに加え準じた名前でもアクセスできるようにし、リファレンスには準じた名前のみ記載 > * 既存のものをdeprecatedとし、アクセス時にwarningを出力するようにする > * 既存のものを削除 > > 今のところ、パッケージが分かれている > * gio2 (GLibからGioへ変更) > * gdk_pixbuf2 (GdkからGdkPixbufへ変更) > を変更したいと思っています。 うーん、gio2は正式リリースが最近であんまり使っている人がいな そうなので別にいいかなぁという気もしますが、gdk_pixbuf2はか なり昔からあるものなので、躊躇してしまいます。 とりあえず、一度、今の状態でリリースしてからにしませんか？ > glib2についてはGLib、GObject、GModuleなどの名前空間があるようですが > 準拠した方がいいかは迷っています。 うーん、GObjectとかGModuleは具体的に外にでてくる（ユーザーが 触るような）オブジェクトってありましたっけ？ |
|
From: Masaaki A. <mas...@gm...> - 2011-12-07 16:14:31
|
青柳です。 GTK3対応で名前空間のGObjectIntrospection準拠をしましたが、GTK2と共通になっている パッケージについても出来ればGObjectIntrospectionに準じたものに変えていきたいです。 以下のようなステップで移行することを考えていますが、いかがでしょうか？ * 既存のものに加え準じた名前でもアクセスできるようにし、リファレンスには準じた名前のみ記載 * 既存のものをdeprecatedとし、アクセス時にwarningを出力するようにする * 既存のものを削除 今のところ、パッケージが分かれている * gio2 (GLibからGioへ変更) * gdk_pixbuf2 (GdkからGdkPixbufへ変更) を変更したいと思っています。 glib2についてはGLib、GObject、GModuleなどの名前空間があるようですが 準拠した方がいいかは迷っています。 |
|
From: Kouhei S. <ko...@co...> - 2011-12-07 11:56:11
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] リストからrubyオブジェクトへの変換について" on Wed, 7 Dec 2011 00:08:37 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > まだ確認してないのでpull requestはまだですが、取り敢えず > https://github.com/masaakiaoyagi/ruby-gnome2/commits/glist2rval > のような感じで実装してみました。 > * 要素の変換関数も渡せるようにして、公開するシンボルを少なくする > * rbg_filename_gslist_to_array_freeもまとめられるようにする > * prefixをrbgutilからrbgにする > といったところを当初の予定から変更しています。 だいたいよいと思います！ いくつか気になった点はこんなところです。 * ToRValueFuncはRGConvFuncとか「RG」（RBG?）プレフィックス みたいにした方がよさそう。（関数名のプレフィックスと同じ ような感じで。） * GType固定にしないで、gpointerを渡すようにして、使う人が 好きなデータを渡せるようにするとGLibっぽくてよいかも。 （でも、オーバースペックかもしれない。） 例えば、g_list_sorted_with_data()がそういうインターフェ イスで、他にもいろいろあるはず。 http://developer.gnome.org/glib/stable/glib-Doubly-Linked-Lists.html#g-list-sort-with-data * #ifdef __cplusplus extern "C" { #endif /* __cplusplus */ ... #ifdef __cplusplus } #endif /* __cplusplus */ の代わりに G_BEGIN_DECLS ... G_END_DECLS を使うのがGLibっぽくてよさそう。 http://developer.gnome.org/glib/stable/glib-Miscellaneous-Macros.html#G-BEGIN-DECLS:CAPS http://developer.gnome.org/glib/stable/glib-Miscellaneous-Macros.html#G-END-DECLS:CAPS > ちなみに、GListとGSListの現在の定義が > struct GList { > gpointer data; > GList *next; > GList *prev; > }; > struct GSList { > gpointer data; > GSList *next; > }; > となっていて、もしGListがGSList+prevという構造であることが保証されていれば > GList版とGSList版で関数を分けずにまとめられるなぁとか思ったのですが、 > そんな保証されてないですよね？ そうですねぇ。 まず変わることはないと思いますが、そこに依存するのはやめた方 がいいと思います。 |
|
From: Masaaki A. <mas...@gm...> - 2011-12-06 15:08:48
|
青柳です。 まだ確認してないのでpull requestはまだですが、取り敢えず https://github.com/masaakiaoyagi/ruby-gnome2/commits/glist2rval のような感じで実装してみました。 * 要素の変換関数も渡せるようにして、公開するシンボルを少なくする * rbg_filename_gslist_to_array_freeもまとめられるようにする * prefixをrbgutilからrbgにする といったところを当初の予定から変更しています。 何か問題がありそうでしたら、ご指摘ください。 ちなみに、GListとGSListの現在の定義が struct GList { gpointer data; GList *next; GList *prev; }; struct GSList { gpointer data; GSList *next; }; となっていて、もしGListがGSList+prevという構造であることが保証されていれば GList版とGSList版で関数を分けずにまとめられるなぁとか思ったのですが、 そんな保証されてないですよね？ |
|
From: Kouhei S. <ko...@co...> - 2011-12-04 05:22:00
|
須藤です。 In <CAMyNdeXp6C=B3G...@ma...> "Re: [ruby-gnome2-devel-ja] GitHub最新版でgtk-demoがSEGVするようです" on Sun, 4 Dec 2011 13:58:47 +0900, Masaaki Aoyagi <mas...@gm...> wrote: >>> 再現方法： >>> * gtk-demoを起動 >>> * 'Application main window'をダブルクリック >>> * 'Application main window'のウインドウを閉じる >>> * 'Button Boxes'をダブルクリック >>> >>> 環境： >>> ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux] >>> gtk+ 2.24.4 >> >> 手元だと再現しないのですが、なにかコツみたいなものはあります >> か？ >> >> % ruby1.9.1 -v >> ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux] >> % pkg-config --modversion gtk+-2.0 >> 2.24.8 > > すみません。ちょっと環境を変えてしまっているのですが、上の環境ではほぼ（だと思う） > 再現しました。 > が、今の環境ではかなり再現確率は低いようなので、rubyのバージョンなどに依存した所が > あるのかもしれません。ただ、それでも種類を変えながらウインドウを開いては閉じるを > 繰り返すと再現させることは出来ています。 > > 環境： > ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux] > gtk+ 2.24.6 ありがとうございます。 再現できたっぽいので修正しておきました！ |
|
From: Masaaki A. <mas...@gm...> - 2011-12-04 04:58:53
|
青柳です。 >> 再現方法： >> * gtk-demoを起動 >> * 'Application main window'をダブルクリック >> * 'Application main window'のウインドウを閉じる >> * 'Button Boxes'をダブルクリック >> >> 環境： >> ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux] >> gtk+ 2.24.4 > > 手元だと再現しないのですが、なにかコツみたいなものはあります > か？ > > % ruby1.9.1 -v > ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux] > % pkg-config --modversion gtk+-2.0 > 2.24.8 すみません。ちょっと環境を変えてしまっているのですが、上の環境ではほぼ（だと思う） 再現しました。 が、今の環境ではかなり再現確率は低いようなので、rubyのバージョンなどに依存した所が あるのかもしれません。ただ、それでも種類を変えながらウインドウを開いては閉じるを 繰り返すと再現させることは出来ています。 環境： ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux] gtk+ 2.24.6 |
|
From: Kouhei S. <ko...@co...> - 2011-12-04 04:28:10
|
須藤です。 In <CAM...@ma...> "[ruby-gnome2-devel-ja] GitHub最新版でgtk-demoがSEGVするようです" on Wed, 16 Nov 2011 18:52:53 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 1.0.3では問題ないのですが、GitHub最新版でgtk-demoが > SEGVするようになっているようです。 > 修正して頂けますでしょうか？ > > 再現方法： > * gtk-demoを起動 > * 'Application main window'をダブルクリック > * 'Application main window'のウインドウを閉じる > * 'Button Boxes'をダブルクリック > > 環境： > ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux] > gtk+ 2.24.4 手元だと再現しないのですが、なにかコツみたいなものはあります か？ % ruby1.9.1 -v ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux] % pkg-config --modversion gtk+-2.0 2.24.8 |
|
From: Masaaki A. <mas...@gm...> - 2011-12-03 07:27:56
|
青柳です。
> はい、基本的にはそれでよいと思います。
ありがとうございます！
>> struct gobjgslist2rval_args {
>> GSList *list;
>> GFreeFunc free_list;
>> GFreeFunc free_elem;
>> };
>
> GSListを解放する方法はg_slist_free()しかないと思うので、
> GFreeFuncなfree_listではなく、gbooleanで十分じゃないかと思い
> ました。
>
> もしかしたら、要素を解放するときはリスト自体も削除する、とい
> う風にしてしまって、free_list自体をなくしてしまってもいいか
> もしれません。要素だけを解放したい時ってあるのかしら。リスト
> の中に解放済み要素だけあっても意味無いですよねぇ。
確かに、あまりfree_listの存在意義はないかもしれません。ただ、
* リファレンスを見て、使えという関数をコピペすればいいので単純
* もしかしたら、解放されるタイミングで何か処理を入れたくなるかもしれない
という感じで今の仕様としました。
>> static VALUE
>> gobjgslist2rval_body(VALUE data)
>> {
>> struct gobjgslist2rval_args *args = (struct gobjgslist2rval_args *)data;
>> GSList *i;
>> VALUE ary;
>>
>> ary = rb_ary_new();
>> for (i = args->list; i != NULL; i = i->next)
>> rb_ary_push(ary, GOBJ2RVAL(i->data));
>>
>> return ary;
>> }
>
> 実は、個人的には
>
> GSList *node;
> ...
> for (node = args->list; node; node = g_slist_next(node))
> ...
>
> という書き方が好みだったりします。
> （より適切な名前を使っていると思うので。）
>
> もしよければ採用してもらえると嬉しいです。
現状に合わせただけなので、g_slist_nextを使用するようにします。
>> のようなものを定義し、マクロとしては
>>
>> #define GOBJGSLIST2RVAL(list) \
>> rbgutil_gobjgslist2rval(list, (GFreeFunc)NULL, (GFreeFunc)NULL)
>> #define GOBJGSLIST2RVAL_FREE(list, free_list, free_elem) \
>> rbgutil_gobjgslist2rval(list, (GFreeFunc)free_list,
>> (GFreeFunc)free_elem)
>
> GSListにはGObject以外にもgchar *とかも入っていそうなので、解
> 放する関数をGFreeFuncでカスタマイズできるようにするなら、最
> 初の「GOBJ」は抜いたほうがいいかなぁと思いました。
すみません。言葉足らずでしたが、GOBJ2RVALを型によって変更する必要があるので、
要素の型の数だけ同様のものを用意します。
（たぶんensureは共通にできるとは思っています）
|
|
From: Kouhei S. <ko...@co...> - 2011-12-03 05:35:42
|
須藤です。 In <CAMyNdeVpTtHfeBdegReX=DTDMUuXxawaBZc2Nc=jrN...@ma...> "[ruby-gnome2-devel-ja] リストからrubyオブジェクトへの変換について" on Sat, 3 Dec 2011 12:06:09 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > gtk_widget_path_iter_list_classes > gtk_widget_path_iter_list_regions > にて、戻り値の開放を要素はせず、リストのみ行うとのことなので、単純に対応したものを > https://github.com/ruby-gnome2/ruby-gnome2/pull/62 > で提案しました。が、今度は > gtk_file_chooser_get_files > にて、要素はg_object_unrefを、リストはg_slist_freeしろとのことで、色々なパターンが > ありそうです。そのため、柔軟に対応できるように ... > のように開放有り無しの2種類定義しておいて、解放する場合はその関数を渡せるようにしたら > いかがでしょうか？ > よろしければ、現在のものはdeprecatedとしてファイルを分けていって、置き換えていこうと思います。 > （例：rbgutil.c -> rbgutildeprecated.c） はい、基本的にはそれでよいと思います。 > struct gobjgslist2rval_args { > GSList *list; > GFreeFunc free_list; > GFreeFunc free_elem; > }; GSListを解放する方法はg_slist_free()しかないと思うので、 GFreeFuncなfree_listではなく、gbooleanで十分じゃないかと思い ました。 もしかしたら、要素を解放するときはリスト自体も削除する、とい う風にしてしまって、free_list自体をなくしてしまってもいいか もしれません。要素だけを解放したい時ってあるのかしら。リスト の中に解放済み要素だけあっても意味無いですよねぇ。 > static VALUE > gobjgslist2rval_body(VALUE data) > { > struct gobjgslist2rval_args *args = (struct gobjgslist2rval_args *)data; > GSList *i; > VALUE ary; > > ary = rb_ary_new(); > for (i = args->list; i != NULL; i = i->next) > rb_ary_push(ary, GOBJ2RVAL(i->data)); > > return ary; > } 実は、個人的には GSList *node; ... for (node = args->list; node; node = g_slist_next(node)) ... という書き方が好みだったりします。 （より適切な名前を使っていると思うので。） もしよければ採用してもらえると嬉しいです。 > のようなものを定義し、マクロとしては > > #define GOBJGSLIST2RVAL(list) \ > rbgutil_gobjgslist2rval(list, (GFreeFunc)NULL, (GFreeFunc)NULL) > #define GOBJGSLIST2RVAL_FREE(list, free_list, free_elem) \ > rbgutil_gobjgslist2rval(list, (GFreeFunc)free_list, > (GFreeFunc)free_elem) GSListにはGObject以外にもgchar *とかも入っていそうなので、解 放する関数をGFreeFuncでカスタマイズできるようにするなら、最 初の「GOBJ」は抜いたほうがいいかなぁと思いました。 |
|
From: Kouhei S. <ko...@co...> - 2011-12-03 05:20:21
|
須藤です。 In <CAMyNdeWeDybJ81gDHQPjCddVs8GLAgUJj_Of7=PL9...@ma...> "[ruby-gnome2-devel-ja] interfaceの実装など" on Tue, 29 Nov 2011 19:47:56 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > GtkSourceCompletionProviderやGtkSourceUndoManagerはinterfaceとなっており > それを実装したGObjectが存在していないので、自前で実装する必要があるのだと思いますが > interfaceの実装をruby側で行うような仕組みがあったりするのでしょうか？ > ざっと見た感じ無さそうだとは思っているのですが、この辺りはどうしたもんでしょうか？ あれ、G_DEF_INTERFACE()で動きませんか？ > それと、rubyのオブジェクトからgtkの型へ変換するのにRVAL2GOBJのみでキャストをしておらず、 > 不正なオブジェクトが渡された際にTypeErrorとならずにgtk側でエラーになる箇所があります。 > また、gtkの型がGObjectなのかGBoxedなのかなど気にするのが面倒なので、一部で使われているように > RVAL2GTKWIDGETのようなマクロを定義して、それを使うように統一したいです。 はい、よいと思います。 > GObjectのみGTKWIDGET2RVAL方向の定義はせず、他は双方向を定義したいと思っています。 > 合わせて以下のようなヘッダの構成に統一していきたいのですが、いかがでしょうか？ > * rb<パッケージ名>.h > 外部からincludeされうるヘッダ > * rb<パッケージ名>conversions.h > 変換マクロ用のヘッダ > * rb<パッケージ名>private.h > 内部からincludeされるヘッダ > ※パッケージ名にはバージョンを含まない（例：rbgtk.h） うーん、debパッケージやrpmパッケージを作っている人たちが困り そうです。。。debやrpmではgemみたいに各パッケージ毎にディレ クトリを掘るのではなく、共通のディレクトリにヘッダーファイル を置くのです。 （/usr/lib/ruby/vendor_ruby/1.9.1/x86_64-linux/以下とか） なので、ヘッダーファイルにはrbgtk3.hの用にバージョンを入れた 方がいいと思っています。 |
|
From: Kouhei S. <ko...@co...> - 2011-12-03 05:07:22
|
須藤です。 In <CAM...@ma...> "[ruby-gnome2-devel-ja] 属すべき名前空間などについて" on Sun, 27 Nov 2011 18:44:19 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 例えば、gtk_style_context_add_provider_for_screenのようなものは、そのままだと > Gtk::StyleContext.add_provider_for_screenのようなメソッドになると思いますが、 > 引数でGdkScreenを受けており、意味合い的にもGdk::Screen#add_providerと > した方がいいかなと思っています。 > このようなパターンは他にも見かけたのですが、同様な対応をしたいです。 いいと思います！ > gtk_widget_get_pathは、Gtk::Widget#pathにしたいですが、gtk_widget_pathで > すでに使用されています。そこで、 > * Gtk::Widget#pathをdeprecated扱いにする > * gtk_widget_get_pathはGtk::Widget#widget_pathとして定義する > * 一定期間後に、gtk_widget_get_pathをGtk::Widget#pathにする > という対応を考えています。 http://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-path を見るとgtk_widget_path()がdeprecatedなのでRuby/GTK3では gtk_widget_get_path()だけを提供ということでよいと思います。 > gtk_css_provider_load_from_data > gtk_css_provider_load_from_file > gtk_css_provider_load_from_path > というように、引数のパターンで分かれているものをGtk::CssProvider#load(arg) > というようにまとめて、基本はhash引数として、型で判断できるものは、そのものの指定も > できるようにしたらどうかと考えています。 > この例だと、 > prov = Gtk::CssProvider.new > # 基本はhash > prov.load(file: file) > prov.load(data: 'css data') > prov.load(path: 'hoge.css') > prov.load(file) # GFileの場合、そのままでもOK > prov.load('hoge.css') # 文字列の場合、dataかpathか分からないからNG > といった感じです。 いいと思います！ > また、GFileを見てて思ったのですが、gtkはgioに依存しているのでは > ないでしょうか？ そうですね！ |
|
From: Masaaki A. <mas...@gm...> - 2011-12-03 03:06:17
|
青柳です。 gtk_widget_path_iter_list_classes gtk_widget_path_iter_list_regions にて、戻り値の開放を要素はせず、リストのみ行うとのことなので、単純に対応したものを https://github.com/ruby-gnome2/ruby-gnome2/pull/62 で提案しました。が、今度は gtk_file_chooser_get_files にて、要素はg_object_unrefを、リストはg_slist_freeしろとのことで、色々なパターンが ありそうです。そのため、柔軟に対応できるように struct gobjgslist2rval_args { GSList *list; GFreeFunc free_list; GFreeFunc free_elem; }; static VALUE gobjgslist2rval_body(VALUE data) { struct gobjgslist2rval_args *args = (struct gobjgslist2rval_args *)data; GSList *i; VALUE ary; ary = rb_ary_new(); for (i = args->list; i != NULL; i = i->next) rb_ary_push(ary, GOBJ2RVAL(i->data)); return ary; } static VALUE gobjgslist2rval_ensure(VALUE data) { struct gobjgslist2rval_args *args = (struct gobjgslist2rval_args *)data; GSList *i; if (args->free_elem) for (i = args->list; i != NULL; i = i->next) args->free_elem(i->data); if (args->free_list) args->free_list(args->list); return Qnil; } VALUE rbgutil_gobjgslist2rval(GSList *const list, GFreeFunc free_list, GFreeFunc free_elem) { struct gobjgslist2rval_args args = {list, free_list, free_elem}; return rb_ensure(gobjgslist2rval_body, (VALUE)&args, gobjgslist2rval_ensure, (VALUE)&args); } のようなものを定義し、マクロとしては #define GOBJGSLIST2RVAL(list) \ rbgutil_gobjgslist2rval(list, (GFreeFunc)NULL, (GFreeFunc)NULL) #define GOBJGSLIST2RVAL_FREE(list, free_list, free_elem) \ rbgutil_gobjgslist2rval(list, (GFreeFunc)free_list, (GFreeFunc)free_elem) のように開放有り無しの2種類定義しておいて、解放する場合はその関数を渡せるようにしたら いかがでしょうか？ よろしければ、現在のものはdeprecatedとしてファイルを分けていって、置き換えていこうと思います。 （例：rbgutil.c -> rbgutildeprecated.c） |
|
From: Masaaki A. <mas...@gm...> - 2011-11-29 10:48:07
|
青柳です。 GtkSourceCompletionProviderやGtkSourceUndoManagerはinterfaceとなっており それを実装したGObjectが存在していないので、自前で実装する必要があるのだと思いますが interfaceの実装をruby側で行うような仕組みがあったりするのでしょうか？ ざっと見た感じ無さそうだとは思っているのですが、この辺りはどうしたもんでしょうか？ それと、rubyのオブジェクトからgtkの型へ変換するのにRVAL2GOBJのみでキャストをしておらず、 不正なオブジェクトが渡された際にTypeErrorとならずにgtk側でエラーになる箇所があります。 また、gtkの型がGObjectなのかGBoxedなのかなど気にするのが面倒なので、一部で使われているように RVAL2GTKWIDGETのようなマクロを定義して、それを使うように統一したいです。 GObjectのみGTKWIDGET2RVAL方向の定義はせず、他は双方向を定義したいと思っています。 合わせて以下のようなヘッダの構成に統一していきたいのですが、いかがでしょうか？ * rb<パッケージ名>.h 外部からincludeされうるヘッダ * rb<パッケージ名>conversions.h 変換マクロ用のヘッダ * rb<パッケージ名>private.h 内部からincludeされるヘッダ ※パッケージ名にはバージョンを含まない（例：rbgtk.h） |
|
From: Masaaki A. <mas...@gm...> - 2011-11-27 09:44:25
|
青柳です。
いくつかまとめて質問させてください。
例えば、gtk_style_context_add_provider_for_screenのようなものは、そのままだと
Gtk::StyleContext.add_provider_for_screenのようなメソッドになると思いますが、
引数でGdkScreenを受けており、意味合い的にもGdk::Screen#add_providerと
した方がいいかなと思っています。
このようなパターンは他にも見かけたのですが、同様な対応をしたいです。
gtk_widget_get_pathは、Gtk::Widget#pathにしたいですが、gtk_widget_pathで
すでに使用されています。そこで、
* Gtk::Widget#pathをdeprecated扱いにする
* gtk_widget_get_pathはGtk::Widget#widget_pathとして定義する
* 一定期間後に、gtk_widget_get_pathをGtk::Widget#pathにする
という対応を考えています。
gtk_css_provider_load_from_data
gtk_css_provider_load_from_file
gtk_css_provider_load_from_path
というように、引数のパターンで分かれているものをGtk::CssProvider#load(arg)
というようにまとめて、基本はhash引数として、型で判断できるものは、そのものの指定も
できるようにしたらどうかと考えています。
この例だと、
prov = Gtk::CssProvider.new
# 基本はhash
prov.load(file: file)
prov.load(data: 'css data')
prov.load(path: 'hoge.css')
prov.load(file) # GFileの場合、そのままでもOK
prov.load('hoge.css') # 文字列の場合、dataかpathか分からないからNG
といった感じです。
以上、いかがでしょうか？
また、GFileを見てて思ったのですが、gtkはgioに依存しているのでは
ないでしょうか？
|
|
From: Masaaki A. <mas...@gm...> - 2011-11-26 05:58:34
|
青柳です。 >> ただ、シンボルに対応するのに処理を纏めておきたかったので、削除はせずに纏めました。 >> シンボル対応と合わせてプルリクエストをしておきましたので、よろしければ >> マージして頂けますでしょうか？ > > マージしました。 ありがとうございました！ >> また、そろそろ未実装のAPIの実装を始めようかと思うので、作業の仕方として >> 確認して欲しいものはプルリクエストしてopenしたままにしておくので、 >> 須藤さんに確認とマージをお願いしたいのですが、いかがでしょうか？ > > わかりました。 > そのときはブランチを切ってからpull requestしてもらえますか？ > masterでpull requestすると、pull request後にコミットしたもの > までpull requestの中に含まれてしまうのです。 > masterでpull requestして、その後マージされるまでコミットしな > いという方法でもよいのですが、それだと不便でしょうし。。。 なるほど、そういうことなのですね。 ブランチ切るようにします。 |
|
From: Kouhei S. <ko...@co...> - 2011-11-26 04:18:08
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] enumやflagsの比較演算子について" on Thu, 24 Nov 2011 19:45:45 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > ただ、シンボルに対応するのに処理を纏めておきたかったので、削除はせずに纏めました。 > シンボル対応と合わせてプルリクエストをしておきましたので、よろしければ > マージして頂けますでしょうか？ マージしました。 > また、そろそろ未実装のAPIの実装を始めようかと思うので、作業の仕方として > 確認して欲しいものはプルリクエストしてopenしたままにしておくので、 > 須藤さんに確認とマージをお願いしたいのですが、いかがでしょうか？ わかりました。 そのときはブランチを切ってからpull requestしてもらえますか？ masterでpull requestすると、pull request後にコミットしたもの までpull requestの中に含まれてしまうのです。 masterでpull requestして、その後マージされるまでコミットしな いという方法でもよいのですが、それだと不便でしょうし。。。 |
|
From: Masaaki A. <mas...@gm...> - 2011-11-24 10:45:56
|
青柳です。 >> ただ、シンボルなどとの比較は出来ないようなので、これを出来るように変更したいです。 >> いかがでしょうか？ > > はい、よいと思います。 > 比較する前にシンボルとかを名前解決（？resolve）するんですよね。 > >> また、GLib::Flagsの==、>=、<=、>、<演算子についてはComparableをincludeすることで >> 削除出来るように思います。 >> 削除してもよろしいでしょうか？ > > はい、それで実現できるのであればそうしてもらってOKです。 すみません。Comparableのincludeでは出来ないことが分かりました。 ただ、シンボルに対応するのに処理を纏めておきたかったので、削除はせずに纏めました。 シンボル対応と合わせてプルリクエストをしておきましたので、よろしければ マージして頂けますでしょうか？ また、そろそろ未実装のAPIの実装を始めようかと思うので、作業の仕方として 確認して欲しいものはプルリクエストしてopenしたままにしておくので、 須藤さんに確認とマージをお願いしたいのですが、いかがでしょうか？ |
|
From: Kouhei S. <ko...@co...> - 2011-11-23 02:29:43
|
須藤です。 In <CAM...@ma...> "[ruby-gnome2-devel-ja] enumやflagsの比較演算子について" on Tue, 22 Nov 2011 18:50:32 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > enumやflagsを受ける引数で、Gtk::Dialog::Flags::DIALOGのような通常の指定の他、 > シンボルや文字列やその配列を指定できるようです。 > （この辺り気付いている人は多いんだろうか？） いやぁ、気づかないですよねぇ。。。 こう出来たほうが便利だったので前に入れたんですよ。 MLを漁ればそのときのやりとりが出てきそうですが。。。 > ただ、シンボルなどとの比較は出来ないようなので、これを出来るように変更したいです。 > いかがでしょうか？ はい、よいと思います。 比較する前にシンボルとかを名前解決（？resolve）するんですよね。 > また、GLib::Flagsの==、>=、<=、>、<演算子についてはComparableをincludeすることで > 削除出来るように思います。 > 削除してもよろしいでしょうか？ はい、それで実現できるのであればそうしてもらってOKです。 > この件と関係ありませんが、Gtk::ComboBox#initializeをhash引数に変更しました。 わかりました。 |
|
From: Masaaki A. <mas...@gm...> - 2011-11-22 09:50:42
|
青柳です。 enumやflagsを受ける引数で、Gtk::Dialog::Flags::DIALOGのような通常の指定の他、 シンボルや文字列やその配列を指定できるようです。 （この辺り気付いている人は多いんだろうか？） ただ、シンボルなどとの比較は出来ないようなので、これを出来るように変更したいです。 いかがでしょうか？ また、GLib::Flagsの==、>=、<=、>、<演算子についてはComparableをincludeすることで 削除出来るように思います。 削除してもよろしいでしょうか？ この件と関係ありませんが、Gtk::ComboBox#initializeをhash引数に変更しました。 |
|
From: Kouhei S. <ko...@co...> - 2011-11-20 09:09:53
|
須藤です。 In <CAM...@ma...> "[ruby-gnome2-devel-ja] GtkFileChooserDialogのコンストラクタについて" on Sun, 20 Nov 2011 16:13:21 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 現在の実装では、GtkFileChooserDialogのコンストラクタで > gtk_file_chooser_dialog_new_with_backendを使用しておりますが、 > deprecatedになりgtk_file_chooser_dialog_newを使用しろとのことです。 > 2つのAPIの違いはbackendだけなので、backendを無視するようにして > 今までのコードでもwarningを出しつつ動くようにしたいと思います。 > そこで、ダイアログのコンストラクタは大抵オプショナルな引数があるので、 > ダイアログのコンストラクタは基本的にHash引数で受けるよう変更して > 前の引数の形式をdeprecatedとしたいです。 > いかがでしょうか？ いいと思います！ |
10 messages has been excluded from this view by a project administrator.
