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-11-20 07:13:28
|
青柳です。 現在の実装では、GtkFileChooserDialogのコンストラクタで gtk_file_chooser_dialog_new_with_backendを使用しておりますが、 deprecatedになりgtk_file_chooser_dialog_newを使用しろとのことです。 2つのAPIの違いはbackendだけなので、backendを無視するようにして 今までのコードでもwarningを出しつつ動くようにしたいと思います。 そこで、ダイアログのコンストラクタは大抵オプショナルな引数があるので、 ダイアログのコンストラクタは基本的にHash引数で受けるよう変更して 前の引数の形式をdeprecatedとしたいです。 いかがでしょうか？ |
|
From: Kouhei S. <ko...@co...> - 2011-11-19 10:48:25
|
須藤です。 In <CAMyNdeXHc+XbUACfC-EW7W-Tn9CD-L-=2uB...@ma...> "[ruby-gnome2-devel-ja] Keyvalの定数名について" on Sat, 19 Nov 2011 11:19:01 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > Keyvalのdefine名が、GDK_<keyname>からGDK_KEY_<keyname>に変更になったそうなので > 何も考えず、Gdk::Keyval::GDK_KEY_<keyname>のような名前の定数名にしてしまいましたが > 考えたらGdk::Keyval::<keyname>のような名前の方がいい気がします。 > 変更してもよろしいでしょうか？ いいと思います！ ただ、GDK_KEY_1をGdk::Keyval::1とかにはできないので、 Gdk::KEY_1とかでもいいのかなぁという気もします。 |
|
From: Masaaki A. <mas...@gm...> - 2011-11-19 02:19:07
|
青柳です。 Keyvalのdefine名が、GDK_<keyname>からGDK_KEY_<keyname>に変更になったそうなので 何も考えず、Gdk::Keyval::GDK_KEY_<keyname>のような名前の定数名にしてしまいましたが 考えたらGdk::Keyval::<keyname>のような名前の方がいい気がします。 変更してもよろしいでしょうか？ |
|
From: Masaaki A. <mas...@gm...> - 2011-11-16 09:52:59
|
青柳です。 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 |
|
From: Masaaki A. <mas...@gm...> - 2011-11-13 14:29:21
|
青柳です。 > よいと思います！ > vteもソースを分けちゃってもよさそうな気がしました。 ありがとうございます！ vteはソースを分ける選択も考えつつ作業します。 > GooCanvasは今年の2月にリリースされた2.0.0からGTK+ 3に対応し > ていますね。 > > Popplerも9月にリリースされた0.18.0からGDK関連のAPIを削除して > います。（もう少し細かく言うと開発版である0.17.0から） > > > GooCanvasもPopplerもGTK+ 3関連のことは後回しにしてもよさそう > な気がします。 なるほど。 goocanvasとpopplerは後回しにします。 |
|
From: Kouhei S. <ko...@co...> - 2011-11-13 04:31:21
|
須藤です。 In <CAM...@ma...> "[ruby-gnome2-devel-ja] GTK3対応について" on Sat, 12 Nov 2011 08:01:03 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > GTK3対応作業を以下のような方針で行おうと思います。 > * gtksourceviewのようにGTK2用とGTK3用が分かれているものは、 > gtksourceview2とgtksourceview3のようにソースを分ける > * vteのようにGTK2用とGTK3用が分かれていないものは、ソースは分けずに > GTK2用とGTK3用の両方のgemパッケージを生成できるようにする > （gemパッケージ名はvteとvte3とする） > * 名前空間など基本的にはGObjectIntrospectionに準じたものにしていく > 例）Gtk::SourceView -> GtkSource::View > * vteで行ったようなGLib::Deprecatableを使用して移行緩和を出来れば行う > > また、GTK3対応と同時に整理するため以下のことを行いたいです。 > * gtkパッケージをgdkとgtkに分離 > * 不要となるGTK2用のコードの削除 > * 公開するシンボルを最小限にしていく > * enumやflagsで定義しているG_DEF_CONSTANTSの削除 > > 作業の結果、増えるパッケージはgdk3、gtk3、gtksourceview3と考えています。 > ただ、gtkに依存したパッケージの中で、goocanvasとpopplerのGTK3への > 対応状況がまだよく分かっていないです。 > （popplerは現在gdkに依存しているのが、依存しなくなる気はしています） > > いかがでしょうか？ よいと思います！ vteもソースを分けちゃってもよさそうな気がしました。 GooCanvasは今年の2月にリリースされた2.0.0からGTK+ 3に対応し ていますね。 Popplerも9月にリリースされた0.18.0からGDK関連のAPIを削除して います。（もう少し細かく言うと開発版である0.17.0から） GooCanvasもPopplerもGTK+ 3関連のことは後回しにしてもよさそう な気がします。 |
|
From: Masaaki A. <mas...@gm...> - 2011-11-11 23:01:11
|
青柳です。 GTK3対応作業を以下のような方針で行おうと思います。 * gtksourceviewのようにGTK2用とGTK3用が分かれているものは、 gtksourceview2とgtksourceview3のようにソースを分ける * vteのようにGTK2用とGTK3用が分かれていないものは、ソースは分けずに GTK2用とGTK3用の両方のgemパッケージを生成できるようにする （gemパッケージ名はvteとvte3とする） * 名前空間など基本的にはGObjectIntrospectionに準じたものにしていく 例）Gtk::SourceView -> GtkSource::View * vteで行ったようなGLib::Deprecatableを使用して移行緩和を出来れば行う また、GTK3対応と同時に整理するため以下のことを行いたいです。 * gtkパッケージをgdkとgtkに分離 * 不要となるGTK2用のコードの削除 * 公開するシンボルを最小限にしていく * enumやflagsで定義しているG_DEF_CONSTANTSの削除 作業の結果、増えるパッケージはgdk3、gtk3、gtksourceview3と考えています。 ただ、gtkに依存したパッケージの中で、goocanvasとpopplerのGTK3への 対応状況がまだよく分かっていないです。 （popplerは現在gdkに依存しているのが、依存しなくなる気はしています） いかがでしょうか？ |
|
From: Kouhei S. <ko...@co...> - 2011-11-08 14:03:44
|
須藤です。 In <CAMyNdeWx=AB9d4EU89O6sMEyNAU0e=7-E...@ma...> "Re: [ruby-gnome2-devel-ja] 作業の経過報告" on Mon, 7 Nov 2011 00:54:57 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 今作業しているのは、アプリを作る上で不満（実装不足とリファレンスの不備）があって、 > それを解消するのが目的です。 はい、わかりました。 （私の動機も似たようなものです。） > が、名前空間など色々整理したいところもあるので、GTK2はそのままでGTK3で作業を > しちゃってもいい気がしてきました。 > > YARD対応（ソースにコメントを埋め込む作業）については、GObjectIntrospectionの > 安定版がGTK3からのようなので、やはりGTK3対応後に作業をしたいと思っています。 それでよいと思います。 |
|
From: Masaaki A. <mas...@gm...> - 2011-11-06 15:55:04
|
青柳です。 まず、あまり期待しすぎないでください。。。 今作業しているのは、アプリを作る上で不満（実装不足とリファレンスの不備）があって、 それを解消するのが目的です。 自分にはGTK2にこだわる理由はないので、GTK3で開発できるようになったら、 さっさと移行したいと思っています。 > まず、Ruby/GTK2とRuby/GTK3は互換性がなくなります。 > これは、GTK+ 2とGTK+ 3で互換性がなくなっているためです。 > > ライブラリ名やgem名を変えて(*1)、requireする名前も変える(*2) > のがよいと思っています。 > > (*1) Ruby/GTK2 -> Ruby/GTK3、gtk2 -> gtk3 > (*2) require 'gtk2' -> require 'gtk3' > > なので、GObjectIntrospectionを使うなど新しい仕組みを入れるな > らRuby/GTK3のタイミングがよいと思っています。 > > なお、GObjectIntrospectionで何ができるかとかはYARD対応作業の > 中で見えてくることを期待しています。 > > ただし、世間がGTK+ 2からGTK+ 3に移行するのはあと2-3年くらい > かかる気がするので、しばらくはRuby/GTK2の方がメインだと思い > ます。 > >> もし、GTK2の実装の延長線上でGTK3に対応するという事にならないのであれば >> 今GTK2系を頑張っても仕方がないなぁと。。。 > > Ruby/GTK2の実装の延長上でRuby/GTK3になるかどうかは > GObjectIntrospection次第（もし他の何かがあればそれも検討する > のかも）なのでまだわからないと思っています。ただし、Rubyレベ > ルに提供するAPIの方針である「GTK+そのままのCっぽいAPIではな > くよりRubyらしいAPIを提供する」というのはRuby/GTK2でも > Ruby/GTK3でも変わらないので、今Ruby/GTK2で使いやすいAPIを作っ > ておくとRuby/GTK3の時にも活かせるはずです。特に、GTK+ 2の後 > 半で追加されたAPIはGTK+ 3でも残っているので、Ruby/GTK2から > Ruby/GTK3になったときに捨てるものではないはずです。 > > もし、GObjectIntrospectionを使ってどうにかして自動的に生成す > るようにしたとしても、最初にその仕組みを作ったときに意図した > とおりに自動生成できているかを確認するフェーズがあるはずです。 > そのとき、Ruby/GTK2ですでに実装があるとその確認がしやすくなっ > て役立つと思っています。 > > > ということで、以下のような理由でRuby/GTK2を最新のGTK+ 2に対 > 応する作業は無駄にはならないと思っています。 > > 1. あと数年はGTK+ 2の方がメインなので、Ruby/GTK3よりも > Ruby/GTK2の方が需要がある。 > 2. Ruby/GTK2で実装されたものがあると参照できるので > Ruby/GTK3を実装しやすい。 > > ただ、YARD対応など他の作業の方が↑よりも重要だなぁということ > であればそっちを優先するのもアリだと思います！ 新しい仕組みを入れるタイミングとしてはいいとは思いますが、少なくとも自分には GObjectIntrospectionを利用してうまいことするアイディアは思いつかなそうです。 が、名前空間など色々整理したいところもあるので、GTK2はそのままでGTK3で作業を しちゃってもいい気がしてきました。 YARD対応（ソースにコメントを埋め込む作業）については、GObjectIntrospectionの 安定版がGTK3からのようなので、やはりGTK3対応後に作業をしたいと思っています。 |
|
From: Kouhei S. <ko...@co...> - 2011-11-06 03:24:46
|
須藤です。
In <CAMyNdeX5c-Qu7yy079d=DCj...@ma...>
"Re: [ruby-gnome2-devel-ja] 作業の経過報告" on Sun, 6 Nov 2011 07:53:27 +0900,
Masaaki Aoyagi <mas...@gm...> wrote:
>> GTK2はこれまで通りのやり方でいきますが、GTK3は、もし、
>> GObjectIntrospectionを使っていい感じにできるなら活用したいで
>> すねぇ。
>
> これは、どういう方向性を考えていますか？
まず、Ruby/GTK2とRuby/GTK3は互換性がなくなります。
これは、GTK+ 2とGTK+ 3で互換性がなくなっているためです。
ライブラリ名やgem名を変えて(*1)、requireする名前も変える(*2)
のがよいと思っています。
(*1) Ruby/GTK2 -> Ruby/GTK3、gtk2 -> gtk3
(*2) require 'gtk2' -> require 'gtk3'
なので、GObjectIntrospectionを使うなど新しい仕組みを入れるな
らRuby/GTK3のタイミングがよいと思っています。
なお、GObjectIntrospectionで何ができるかとかはYARD対応作業の
中で見えてくることを期待しています。
ただし、世間がGTK+ 2からGTK+ 3に移行するのはあと2-3年くらい
かかる気がするので、しばらくはRuby/GTK2の方がメインだと思い
ます。
> もし、GTK2の実装の延長線上でGTK3に対応するという事にならないのであれば
> 今GTK2系を頑張っても仕方がないなぁと。。。
Ruby/GTK2の実装の延長上でRuby/GTK3になるかどうかは
GObjectIntrospection次第（もし他の何かがあればそれも検討する
のかも）なのでまだわからないと思っています。ただし、Rubyレベ
ルに提供するAPIの方針である「GTK+そのままのCっぽいAPIではな
くよりRubyらしいAPIを提供する」というのはRuby/GTK2でも
Ruby/GTK3でも変わらないので、今Ruby/GTK2で使いやすいAPIを作っ
ておくとRuby/GTK3の時にも活かせるはずです。特に、GTK+ 2の後
半で追加されたAPIはGTK+ 3でも残っているので、Ruby/GTK2から
Ruby/GTK3になったときに捨てるものではないはずです。
もし、GObjectIntrospectionを使ってどうにかして自動的に生成す
るようにしたとしても、最初にその仕組みを作ったときに意図した
とおりに自動生成できているかを確認するフェーズがあるはずです。
そのとき、Ruby/GTK2ですでに実装があるとその確認がしやすくなっ
て役立つと思っています。
ということで、以下のような理由でRuby/GTK2を最新のGTK+ 2に対
応する作業は無駄にはならないと思っています。
1. あと数年はGTK+ 2の方がメインなので、Ruby/GTK3よりも
Ruby/GTK2の方が需要がある。
2. Ruby/GTK2で実装されたものがあると参照できるので
Ruby/GTK3を実装しやすい。
ただ、YARD対応など他の作業の方が↑よりも重要だなぁということ
であればそっちを優先するのもアリだと思います！
|
|
From: Masaaki A. <mas...@gm...> - 2011-11-05 22:53:34
|
青柳です。 > GTK2はこれまで通りのやり方でいきますが、GTK3は、もし、 > GObjectIntrospectionを使っていい感じにできるなら活用したいで > すねぇ。 これは、どういう方向性を考えていますか？ もし、GTK2の実装の延長線上でGTK3に対応するという事にならないのであれば 今GTK2系を頑張っても仕方がないなぁと。。。 |
|
From: Kouhei S. <ko...@co...> - 2011-11-05 13:21:11
|
須藤です。 In <CAM...@ma...> "[ruby-gnome2-devel-ja] 作業の経過報告" on Fri, 4 Nov 2011 21:18:34 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > RG_DEF_*マクロを使用するスタイルへの変更は、glibなど一部ややこしい箇所を除いて > ある程度終わったと思います。 おぉ！すばらしい！ > 確認していることは、 > * 差分の目視による確認 > * ビルドが通ること > * 作業前後で公開されているシンボルに変更がないこと（Init関数を除く） > * 作業前後で定義される定数とメソッドに変更がないこと > です。 > 一部ロジックを変更した箇所もあるのでエンバグしている可能性は否定できませんが、 > もしあったら、ごめんなさいします。 はい！ そのときは直しましょう！ > この後、GTK2系の最新バージョンの実装に移る予定です。 すばらしいです！ GTK2はこれまで通りのやり方でいきますが、GTK3は、もし、 GObjectIntrospectionを使っていい感じにできるなら活用したいで すねぇ。 > # rakeのバージョンを上げたら動かなくなったので、gnome2-raketask.rbを暫定対処していて思ったのですが、 > # define_package_tasksをdefine_win32_tasks内で定義しているのは、意図したものではない気がしました。 あぁ、そうですねぇ。 なんでここにいるのかしら。 |
|
From: Masaaki A. <mas...@gm...> - 2011-11-04 12:18:40
|
青柳です。 RG_DEF_*マクロを使用するスタイルへの変更は、glibなど一部ややこしい箇所を除いて ある程度終わったと思います。 確認していることは、 * 差分の目視による確認 * ビルドが通ること * 作業前後で公開されているシンボルに変更がないこと（Init関数を除く） * 作業前後で定義される定数とメソッドに変更がないこと です。 一部ロジックを変更した箇所もあるのでエンバグしている可能性は否定できませんが、 もしあったら、ごめんなさいします。 この後、GTK2系の最新バージョンの実装に移る予定です。 # rakeのバージョンを上げたら動かなくなったので、gnome2-raketask.rbを暫定対処していて思ったのですが、 # define_package_tasksをdefine_win32_tasks内で定義しているのは、意図したものではない気がしました。 |
|
From: Kouhei S. <ko...@co...> - 2011-11-03 05:11:00
|
須藤です。 In <CAMyNdeW6u+531xOn_P5Up5xNU0U8JD8uK=brR=ZXV...@ma...> "[ruby-gnome2-devel-ja] エントリポイント以外のInit関数について" on Wed, 2 Nov 2011 18:59:20 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > エントリポイント以外のInit関数に、G_GNUC_INTERNALを使用して > 隠すように変更してもよろしいでしょうか？ はい、よいと思います。 |
|
From: Kouhei S. <ko...@co...> - 2011-11-03 05:09:01
|
須藤です。
In <CAMyNdeUB5Xihz+a=zX=-re=9ap...@ma...>
"[ruby-gnome2-devel-ja] _page_get_image(poppler)について" on Tue, 1 Nov 2011 23:27:33 +0900,
Masaaki Aoyagi <mas...@gm...> wrote:
> rbpoppler-page.cを名前空間毎に分離しようとしていて、_page_get_imageが
> image_mapping_get_imageからも呼ばれているのですが、
>
> static VALUE
> image_mapping_get_image(VALUE self)
> {
> return rb_funcall(rb_iv_get(self, "@page"), rb_intern("get_image"),
> 1, INT2NUM(RVAL2IM(self)->image_id));
> }
>
> とすることで、_page_get_imageを呼ばずに済むように出来ると思います。
> また、それにより_page_get_imageが必要なくなるので、page_get_imageを
>
> static VALUE
> page_get_image(VALUE self, VALUE image_id)
> {
> return CRSURFACE2RVAL(poppler_page_get_image(SELF(self),
> NUM2INT(image_id)));
> }
>
> と変更し、_page_get_imageを削除したいと思います。
> よろしいでしょうか？
いいと思います。
> # Poppler::ImageMappingの@pageはnilになることは無いと理解しましたが
> # 合ってますでしょうか？
合っていると思います。
|
|
From: Masaaki A. <mas...@gm...> - 2011-11-02 09:59:26
|
青柳です。 エントリポイント以外のInit関数に、G_GNUC_INTERNALを使用して 隠すように変更してもよろしいでしょうか？ |
|
From: Masaaki A. <mas...@gm...> - 2011-11-01 14:29:42
|
青柳です。 >> 関数定義自体をマクロで行なっている箇所が散見されます。 >> これを基本的には展開する方向にしたいです。 >> とりあえず、アクセサを定義をするような単純なものを対象に >> 作業する予定です。 >> よろしいでしょうか？ > > YARD対応のためですか？ そうです。 順次必要になったら展開していくことにします。 |
|
From: Masaaki A. <mas...@gm...> - 2011-11-01 14:27:39
|
青柳です。
rbpoppler-page.cを名前空間毎に分離しようとしていて、_page_get_imageが
image_mapping_get_imageからも呼ばれているのですが、
static VALUE
image_mapping_get_image(VALUE self)
{
return rb_funcall(rb_iv_get(self, "@page"), rb_intern("get_image"),
1, INT2NUM(RVAL2IM(self)->image_id));
}
とすることで、_page_get_imageを呼ばずに済むように出来ると思います。
また、それにより_page_get_imageが必要なくなるので、page_get_imageを
static VALUE
page_get_image(VALUE self, VALUE image_id)
{
return CRSURFACE2RVAL(poppler_page_get_image(SELF(self),
NUM2INT(image_id)));
}
と変更し、_page_get_imageを削除したいと思います。
よろしいでしょうか？
# Poppler::ImageMappingの@pageはnilになることは無いと理解しましたが
# 合ってますでしょうか？
|
|
From: Kouhei S. <ko...@co...> - 2011-10-31 13:36:13
|
須藤です。 In <CAM...@ma...> "[ruby-gnome2-devel-ja] rbg_utf16_to_rval_lenなど" on Mon, 31 Oct 2011 22:15:43 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > rbglib_unicode.cを名前空間毎に分離しようとしていて、複数の名前空間から > rbg_ucs4_to_rval_lenとrbg_utf16_to_rval_lenが呼ばれていました。 > 両方共エンディアンによってエンコーディングを切り替えているだけなので、 > > #if G_BYTE_ORDER == G_LITTLE_ENDIAN > # define CSTR2RVAL_LEN_UCS4(s, l) (CSTR2RVAL_LEN_ENC(s, l, "UTF-32LE")) > # define CSTR2RVAL_LEN_UFT16(s, l) (CSTR2RVAL_LEN_ENC(s, l, "UTF-16LE")) > #else > # define CSTR2RVAL_LEN_UCS4(s, l) (CSTR2RVAL_LEN_ENC(s, l, "UTF-32BE")) > # define CSTR2RVAL_LEN_UFT16(s, l) (CSTR2RVAL_LEN_ENC(s, l, "UTF-16BE")) > #endif > > のようなマクロをrbglib.hに定義してしまいたいと思います。 > よろしいでしょうか？ はい。いいです。 |
|
From: Kouhei S. <ko...@co...> - 2011-10-31 13:31:30
|
須藤です。 In <CAMyNdeUkJ2fCT=FK1...@ma...> "[ruby-gnome2-devel-ja] 関数定義マクロの展開について" on Mon, 31 Oct 2011 19:14:14 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 関数定義自体をマクロで行なっている箇所が散見されます。 > これを基本的には展開する方向にしたいです。 > とりあえず、アクセサを定義をするような単純なものを対象に > 作業する予定です。 > よろしいでしょうか？ YARD対応のためですか？ であればOKです。 |
|
From: Masaaki A. <mas...@gm...> - 2011-10-31 13:15:49
|
青柳です。 rbglib_unicode.cを名前空間毎に分離しようとしていて、複数の名前空間から rbg_ucs4_to_rval_lenとrbg_utf16_to_rval_lenが呼ばれていました。 両方共エンディアンによってエンコーディングを切り替えているだけなので、 #if G_BYTE_ORDER == G_LITTLE_ENDIAN # define CSTR2RVAL_LEN_UCS4(s, l) (CSTR2RVAL_LEN_ENC(s, l, "UTF-32LE")) # define CSTR2RVAL_LEN_UFT16(s, l) (CSTR2RVAL_LEN_ENC(s, l, "UTF-16LE")) #else # define CSTR2RVAL_LEN_UCS4(s, l) (CSTR2RVAL_LEN_ENC(s, l, "UTF-32BE")) # define CSTR2RVAL_LEN_UFT16(s, l) (CSTR2RVAL_LEN_ENC(s, l, "UTF-16BE")) #endif のようなマクロをrbglib.hに定義してしまいたいと思います。 よろしいでしょうか？ |
|
From: Masaaki A. <mas...@gm...> - 2011-10-31 10:14:20
|
青柳です。 関数定義自体をマクロで行なっている箇所が散見されます。 これを基本的には展開する方向にしたいです。 とりあえず、アクセサを定義をするような単純なものを対象に 作業する予定です。 よろしいでしょうか？ |
|
From: Kouhei S. <ko...@co...> - 2011-10-30 01:18:34
|
須藤です。 In <CAMyNdeVAR_JS_XAzOuQZGp4QVTO9jTyphxM7Emw=PxU...@ma...> "Re: [ruby-gnome2-devel-ja] Init関数のパラメータについて" on Sun, 30 Oct 2011 01:33:05 +0900, Masaaki Aoyagi <mas...@gm...> wrote: >>> 今すぐに、どうこう言うことではないのですが、mGLibのようなシンボルを >>> 外部に出す必要はあるのでしょうか？ >>> const_getで取り出せると思うので、シンボルを公開するのはあまり >>> いい事ではないような気もします。 >> >> 後方互換性を維持する為です！ > > それ以外に理由が無ければ、GTK3系に対応するタイミングは > こういう事を修正するのにいいタイミングだと思ったので > ちょっと聞いてみました。 そういうタイミングでは削除してもいいと思います！ > 疎結合にするとかは、あまり気にしてないですかね。 後方互換性を壊してまでするものではないと思っています！ |
|
From: Masaaki A. <mas...@gm...> - 2011-10-29 16:33:11
|
青柳です。 >> 今すぐに、どうこう言うことではないのですが、mGLibのようなシンボルを >> 外部に出す必要はあるのでしょうか？ >> const_getで取り出せると思うので、シンボルを公開するのはあまり >> いい事ではないような気もします。 > > 後方互換性を維持する為です！ それ以外に理由が無ければ、GTK3系に対応するタイミングは こういう事を修正するのにいいタイミングだと思ったので ちょっと聞いてみました。 疎結合にするとかは、あまり気にしてないですかね。 |
|
From: Kouhei S. <ko...@co...> - 2011-10-29 15:13:03
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] Init関数のパラメータについて" on Sat, 29 Oct 2011 23:34:08 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 今すぐに、どうこう言うことではないのですが、mGLibのようなシンボルを > 外部に出す必要はあるのでしょうか？ > const_getで取り出せると思うので、シンボルを公開するのはあまり > いい事ではないような気もします。 後方互換性を維持する為です！ |
10 messages has been excluded from this view by a project administrator.
