ruby-gnome-users-ja — Ruby-GNOME user's Mailing List in Japanese.

[ruby-gnome-users-ja] Re: text on Gdk Drawable

[Masahiro S. <s01...@sf...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome-users-ja] text on Gdk Drawable
Date: Sun, 4 Aug 2002 01:08:01 +0900

> 前も書きましたが、以下の手順で再現しませんか？
> 私の環境（後述）だと100%確実に再現します。

100%確実に再現するなら、
gdbでバックトレースを取ってみると良いかも。

例)

% gdb ruby
(gdb) run testgnome.rb
Starting program: /usr/bin/ruby test-gnome.rb

Program received signal SIGSEGV, Segmentation fault.
0x402eccf8 in signal_callback () from /usr/lib/ruby/1.6/i586-linux/gtk.so
(gdb) bt
#0  0x402eccf8 in signal_callback () from /usr/lib/ruby/1.6/i586-linux/gtk.so
#1  0x404c5a77 in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0
#2  0xca15 in ?? () at eval.c:41
Cannot access memory at address 0x50

うーむ。

> > 3つの affine 変換
> >    rotate = Art::Affine.rotate(45)
> >    shear = Art::Affine.shear(45)
> >    translate = Art::Affine.translate(50, 20)
> > を結合するとき、クラスの場合は、
> >    rotate * shear * translate
> > で済みますが、配列にすると、
> >    Art::Affine.multiply(Art::Affine.multiply(rotate, shear), translate)
> > となります。これはちょっと使い難い。
> 
> すみません。ここ、全く理解できませんでした。
> ちょっと時間をください。もうちょっと勉強してみます。

「*」や「multiply」は写像としての結合を表わしているのでしょう。
# アフィン変換は写像で、しかも写像としての結合に関して閉じています。
# もっといえば、群になるはずです。

僕も配列ではなくクラス化するのに一票です。
どうせなので、Affine#pointをAffine#callとAffine#[]にaliasしても良いかも。

-- さかい

Re: [ruby-gnome-users-ja] text on Gdk Drawable

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

むとうです。

On Sun, 04 Aug 2002 00:19:31 +0900
KUBO Takehiro <ku...@ji...> wrote:

> 久保＠茅ヶ崎市です。
> 

> > という形にしたいですね。久保さんの方でlibart_gplの別ライブラリ化
> > ができますか？
> 
> それは大丈夫です。
> 明日は用事があるので、月曜の夜にでも出します。

それは助かります。

> 
> >>  * test-gnome に Art::Affine のサンプルを追加
> >>    新規: gnome/sample/test-gnome/canvas-affine.rb
> >>    修正: gnome/sample/test-gnome/canvas.rb
> >
> > これも、libart_gplの方に持っていった方が良いでしょうね。
> > 例の内容も、gnomeを使った場合やgtkを使った場合が考えられる
> > と思います。
> 
> 思いっきり、Gnome::Canvas に依存しているので、これはこのままで良いので
> はないかと。
> Art::Affine しかない状況では、Gnome::Canvas を使用しない例は考えられま
> せん。libart_lgpl の関数をすべて実装したらな、Gdk を使った例が作れるか
> もしれませんが、私には Gdk の知識はないもんで......。

いや、久保さんにGdkのサンプルを書いて欲しいとか、そういうことを言ってる
わけではありません。

libartを利用したサンプルは、Gnome::Canvasのサンプルと言うより、libartの
機能を勉強する例としてGnome::Canvasを使うというイメージになると思いますので、
それは、libart側のsampleにしましょうといことが私の主旨です。

もしかしたら私や別の人がlibartを使う上での例としてGtk, Gdkやあるいは
Tkなど他のツールキットでのサンプルを作るかもしれません。
例えばGdkからlibartを使うサンプルを書いたとして、それをGtkのサンプルに入れる
ことはないと思います。それと同じことだと考えています。

逆にGnome::Canvasに依存しているからそれをGnome側のsampleに入れるという
ことをすると、今後、pango等のサブプロジェクトについても同様（sampleをGnome
に入れる）のことが必要となり、やはり変な感じがします。

> >> ですが、ついでに
> >>  * Gnome::CanvasPoints のバグの修正
> >>    修正: gnome/src/rbgnome-canvas-util.c
> >> 
> >> もはいっています。

> 元々は、Gnome;:CanvasPoints#free が二回呼ばれると、一回目の呼び出しで
> points_free の gcp が NULL になるので、
>     if (gcp->ref_count == 1) {
> で落ちるのを防止するのが目的でした。

ひょっとして、私が言っているセグメンテーション違反のバグはこれが
原因ですか？
＃私が確認しているのはこのパッチをあてる前のものです。

> ついでにいろんなところで、
>     Data_Get_Struct(self, GnomeCanvasPoints, gcp);
>     if (gcp == NULL) {
>         rb_raise(rb_eRuntimeError, "object is already freed.");
>     }
> としているのを抽出して、
>     get_gnome_canvas_points()
> としてまとめました。
> 
> ただ、ひとつの考えとして、これらのことはすべて、
>     Gnome;:CanvasPoints#free
> があることに起因しているので、このメソッドは削除して GC にメモリ回収を
> まかせるという手もあります。Cレベルで gnome_canvas_points_free() とい
> う API があるのは、C では自前でメモリ管理をしないといけないからで、
> ruby の場合 GC にまかせるという選択肢もあるのではないかと。
> 
> # もちろん、Data_Wrap_Struct の free に gnome_canvas_points_free を入
> # れるという前提で。
> 
> これはどちらが良いでしょうか？
>     Gnome;:CanvasPoints#free
> がないほうが実装はかなり単純になりそうです。

げげっ。
ここまでソースをおわなかったのですが....
おっしゃるとおり、free()はGCに任せるべきです。
というか、free()だけではなく、
ref/unrefに関してもはRuby/GNOMEのソース内で
吸収する必要があります。
＃この仕組みはgtkモジュールで頻繁に使われていますのでそちらも参考に
＃していただく必要があるかと思います。

ref/unref, malloc/freeの仕組みをユーザが考えずに済むというのが
は、Ruby-GNOMEの最大のウリの１つです。

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

Re: [ruby-gnome-users-ja] text on Gdk Drawable

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

むとうです。

On Sat, 03 Aug 2002 23:45:47 +0900
KUBO Takehiro <ku...@ji...> wrote:

> 久保＠茅ヶ崎市です。
> 
> Masao Mutoh <mu...@hi...> writes:
> 
> > えっと、この辺（だけではなくGnomeCanvas全体）、もう少し状況を追っていた
> > だけないでしょうか。
> > 正直、私の環境ではtest-gnomeを使った場合だけでも異常終了の再現性があり
> > ますのでこのまま次バージョンのRuby/GNOMEをリリースして良いのか決めかね
> > ています。
> 
> 確かに安定しないことにはリリースできませんね。だけど、私のところでは前
> のメールで書いた一回しか異常終了してないのです。GC.start を呼びまくっ
> たりもしたんですが再現なし。

1回異常終了したのであれば、やはり（システムがよほど不安定になったなどの
別の要素がない以上）再現性の可能性はあるわけで、
あとは手順が確定できるかどうかということになりますよね。

前も書きましたが、以下の手順で再現しませんか？
私の環境（後述）だと100%確実に再現します。

1. test-gnomeでcanvasを選択 -> GnomeCanvasのダイアログがポップアップ
2. 全てのイメージを1つずつマウスでドラッグしてずらしてみる
3. 次のタブで2.と同様のことを行う。
4. しばらくいろいろなタブで2.3.を繰り返す。
5. メニューの「ファイル」→「閉じる」

この手順で、

アプリケーション「ruby」（プロセスxxxx）は
致命的なえらーによってクラッシュしました。
（セグメンテーション違反です）

というダイアログが出ます。

この現象は、add_relative()の抜け等、RubyのGC周りで起きる症状に
酷似していますが厳密にそれが原因かどうかはわかりません。

私の環境は、
   Kondara MNU/Linux 2.1 (Asumi)
   linux kernel 2.4.18
   glibc  2.2.4-22k
   gcc    2.96 20000731
   ruby   ruby 1.7.2 (2002-07-30) [i686-linux]
   ruby   ruby 1.6.5 (2001-09-19) [i686-linux]  どちらの環境でも発生します。
   glib   1.2.10-10k
   gtk    1,2.10-14k
   gnome-libs 1.4.1.2-22k

> うーむ、Gdk::Drawable で自前で affine 変換するという目的には使えるかも
> しれない。ただそのためには、Art::Affine のみではなくて、libart_lgpl の
> 関数をひと通り用意しないといけないでしょう。

その通りです。
それがしやすいように最初から用意しておくと言うことです。

逆に言えば、Ruby-GNOME全体としてみたとき、gnomeモジュールのためだけに
libart_lgplをローカルに実装するということはできません。

> 現状では、Art::Affine のみなので、「モジュール名が Art なのに gnome.so
> に入っているのは気持ち悪い」ということしか別出しする意味はないと思いま
> す。

そういうわけではありません。
 
> けどまあ、そんなに手間じゃないので、別出しするようにしましょう。

よろしくおねがいします。
 
> > 例えば、Ruby-GNOME2ではglib, gtk, gnomeをそれぞれ別出しにしていますし、
> > pango, bonoboといったものもおそらく別出しになるでしょう。
> 
> 分割の基準は、tar-ball 毎ですか？ それとも作成されるライブラリ毎ですか？

一番大きいのは、それをRubyから別々にrequireしたいかどうかというところ
だと思います。

特にlibartのように汎用性が高いものは別だしにしておくと有効でしょう。

> GNOME2 ではライブラリ毎に tar-ball が作られるようなので、どちらにしろ
> libart_lgpl が別になるのは当然として gnome は gnome, gnomeui, gnomecanvas
> の３分割になるでしょう。

gnome, gnomeui, gnomecanvasをそれぞれ別々にrequireすることでどのような
メリット・デメリットがあるのかというのは議論が必要かと思います。

今のところ、Ruby/GNOMEはgnome, gnomeui, gnomecanvasは１つのrequireで
呼び出すことができるようになっています。
私は使用者の便宜を考えるとこのままで良いかなぁ、と漠然と思っていたのですが、
もし、久保さん（あるいは他の方）が、分けたいと言うことであれば、
それを分けるメリットをあげていただければ考えます。

> >> ・ruby の配列か？ それ用のクラスか？
> >> 
> >>   Cレベルでは affine 変換のデータは double[6] としてしか使用してなくて、
> >>   それ用の構造体を定義してない。double[6] ならば、ruby レベルでは
> >>   Float の配列としてもあつかえる。
> >> 
> >>   ruby の API 的には、それ用のクラスがあったのが良いけど、C レベルの
> >>   API とのストレートにマッピングすることを考えると、Float の配列をその
> >>   まま扱う手もあるのではないかと。
> >
> > 配列で良いと思います。
> 
> うーん、配列の要素が単独で意味を持つのなら配列である意味がありますけど、
> affine 変換の場合配列の個々の要素を参照することはないといって良いので
> ruby 側で配列である意味はありません。実際の使い方は不透明なデータ構造
> と同じあつかいです。
> 
> むしろ配列としてあつかうより、クラスにしたほうが API 的に使い易いです。
> 
> 3つの affine 変換
>    rotate = Art::Affine.rotate(45)
>    shear = Art::Affine.shear(45)
>    translate = Art::Affine.translate(50, 20)
> を結合するとき、クラスの場合は、
>    rotate * shear * translate
> で済みますが、配列にすると、
>    Art::Affine.multiply(Art::Affine.multiply(rotate, shear), translate)
> となります。これはちょっと使い難い。

すみません。ここ、全く理解できませんでした。
ちょっと時間をください。もうちょっと勉強してみます。
 
> だた、Gnome::CanvasPoints もこの API は使い難いと思いつつ、C と同じ
> API にしているので、Art::Affine だけ特別あつかいにするのは贔屓なのかな？
> 
> >> ・クラスの名前
> 
> libart_lgpl 別出しは了承しているので、スキップ

ふと思ったのですが、libart_lgplって、libartの方が良いでしょうか。
どちらが一般的なのかな。

> (snip)
> >>   art_affine_point という API は引数に ArtPoint という構造体を渡すので、
> >>   C と直接のマッピングをさせるのなら、Art::Point というクラスを用意して、
> >>     Art::Point.new(x, y)  -> anArt::Point
> >>     Art::Point#x          -> aFloat
> >>     Art::Point#y          -> aFloat
> >>     Art::Affine#point(anArt::Point) -> anArt::Point
> >
> > すみません、ちょっとこの見方がわかりません。
> > 例えば、「Art::Point#x　は、aFloatを返す」という意味でしょうか。
> 
> クラスはそのまま、インスタンスには a や an をつけています。
> "Programming Ruby" で戻り値や引数にこういう表記を使っていたので。
> だけど、メソッド名のみで、メソッドにクラスのサフィックスは付けてなかっ
> た......。
> 標準的な書き方があったら、それに従います。

いや、a, anはわかったのですが、 -> の意味が分かりませんでした。
（というかおよそ戻り値のことを言っているのかなぁとは思ったのですが
　はっきりとはわからなかったので）

標準的な書き方とか言うのは私はわかりません。
補足をしていただければどのような書き方でも構いませんよ。
＃要は伝われば良いと言うことです、当たり前ですが。

> 残っている論点は、affine 変換のデータは ruby では配列かクラス(Art::Affine)
> かの一点だけですね。

これは先ほども書きましたが、もうちょっと勉強してからリプライします。

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

Re: [ruby-gnome-users-ja] text on Gdk Drawable

[KUBO T. <ku...@ji...>]

久保＠茅ヶ崎市です。

あまり意味のないメールですけど.....。m(__)m

KUBO Takehiro <ku...@ji...> writes:

> だけど、メソッド名のみで、メソッドにクラスのサフィックスは付けてなかっ
> た......。
s/サフィックス/プレフィクス/g

では、再見
-- 
神奈川県茅ヶ崎市在住 久保 健洋
email: ku...@ji...
web:   http://www.jiubao.org
GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1  9F47 C001 1F93 AC08 2262

Re: [ruby-gnome-users-ja] text on Gdk Drawable

[KUBO T. <ku...@ji...>]

久保＠茅ヶ崎市です。

Masao Mutoh <mu...@hi...> writes:

>> # うーむ、コミット権もらったのが良いかな？
>> # 毎回、むとうさんにコミットしてもらうのもなんだし。
>
> そうですねぇ。これは今のところご遠慮ください。
> Ruby-GNOMEの場合は、Ruby-GNOME2とは異なり、
> 私の方で内容を吟味の上、コミットする形の方が良いでしょう。

了解。

> 先のメールで書きましたが、これは、
>
>   * Art::Affine のサポート
>     新規: libart_gpl/....
>     修正: gnome/src/rbgnome-canvas-item.c
>     修正: gnome/src/rbgnome-canvas.c
>     修正: gnome/src/rbgnome.c
>     修正: gnome/src/rbgnome.h

  追加修正: gnome/src/lib/gnome.rb

> という形にしたいですね。久保さんの方でlibart_gplの別ライブラリ化
> ができますか？

それは大丈夫です。
明日は用事があるので、月曜の夜にでも出します。

>>  * test-gnome に Art::Affine のサンプルを追加
>>    新規: gnome/sample/test-gnome/canvas-affine.rb
>>    修正: gnome/sample/test-gnome/canvas.rb
>
> これも、libart_gplの方に持っていった方が良いでしょうね。
> 例の内容も、gnomeを使った場合やgtkを使った場合が考えられる
> と思います。

思いっきり、Gnome::Canvas に依存しているので、これはこのままで良いので
はないかと。

Art::Affine しかない状況では、Gnome::Canvas を使用しない例は考えられま
せん。libart_lgpl の関数をすべて実装したらな、Gdk を使った例が作れるか
もしれませんが、私には Gdk の知識はないもんで......。

>> ですが、ついでに
>>  * Gnome::CanvasPoints のバグの修正
>>    修正: gnome/src/rbgnome-canvas-util.c
>> 
>> もはいっています。
>
> おっと、こちらはお手数をおかけしますが、バグの修正内容を教えてください。
> これは、私の方でパッチの意図と実装内容を簡単に確認したいと言うことと、
> ChangeLogに書く材料にしたいということから必要です。

元々は、Gnome;:CanvasPoints#free が二回呼ばれると、一回目の呼び出しで
points_free の gcp が NULL になるので、
    if (gcp->ref_count == 1) {
で落ちるのを防止するのが目的でした。

ついでにいろんなところで、
    Data_Get_Struct(self, GnomeCanvasPoints, gcp);
    if (gcp == NULL) {
        rb_raise(rb_eRuntimeError, "object is already freed.");
    }
としているのを抽出して、
    get_gnome_canvas_points()
としてまとめました。

ただ、ひとつの考えとして、これらのことはすべて、
    Gnome;:CanvasPoints#free
があることに起因しているので、このメソッドは削除して GC にメモリ回収を
まかせるという手もあります。Cレベルで gnome_canvas_points_free() とい
う API があるのは、C では自前でメモリ管理をしないといけないからで、
ruby の場合 GC にまかせるという選択肢もあるのではないかと。

# もちろん、Data_Wrap_Struct の free に gnome_canvas_points_free を入
# れるという前提で。

これはどちらが良いでしょうか？
    Gnome;:CanvasPoints#free
がないほうが実装はかなり単純になりそうです。

では、再見
-- 
神奈川県茅ヶ崎市在住 久保 健洋
email: ku...@ji...
web:   http://www.jiubao.org
GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1  9F47 C001 1F93 AC08 2262

Re: [ruby-gnome-users-ja] text on Gdk Drawable

[KUBO T. <ku...@ji...>]

久保＠茅ヶ崎市です。

Masao Mutoh <mu...@hi...> writes:

> えっと、この辺（だけではなくGnomeCanvas全体）、もう少し状況を追っていた
> だけないでしょうか。
> 正直、私の環境ではtest-gnomeを使った場合だけでも異常終了の再現性があり
> ますのでこのまま次バージョンのRuby/GNOMEをリリースして良いのか決めかね
> ています。

確かに安定しないことにはリリースできませんね。だけど、私のところでは前
のメールで書いた一回しか異常終了してないのです。GC.start を呼びまくっ
たりもしたんですが再現なし。

西澤さんのところではどうですか？

私の環境は、
  Debian GNU/Linux 開発版(Unstable version)
  linux kernel 2.4.18
  glibc  2.2.5
  gcc    2.95.4
  ruby   1.6.7
  glib   1.2.10
  gtk    1,2.10
  gnome  1.4.1.7
です。(kernel 以外はすべて deb パッケージを利用)

むとうさんの環境を教えていただいて、私のほうで同じものが入手可能ならば、
VMWare 上に同じ環境を用意しましょう。

>> 手許には、libart_lgpl/art_affine.h の関数を実装した GnomeCanvas の
>> affine 変換対応版があります。パッチを出したいけど、ちょっと迷っている
>> ところが数点。
>
> まず、大前提ですが、gnomeと同じレベルでlibart_lgplモジュールを
> 別出しする必要があると思いますがどうでしょうか。
>
> require 'gnome'を呼び出したときにはlibart_lgplが同時に読み込まれると
> 言うのは問題ないと思いますが、逆にlibart_lgplだけ単独で呼び出せるように
> して置いた方が良いと思うのです。

うーむ、Gdk::Drawable で自前で affine 変換するという目的には使えるかも
しれない。ただそのためには、Art::Affine のみではなくて、libart_lgpl の
関数をひと通り用意しないといけないでしょう。

現状では、Art::Affine のみなので、「モジュール名が Art なのに gnome.so
に入っているのは気持ち悪い」ということしか別出しする意味はないと思いま
す。

けどまあ、そんなに手間じゃないので、別出しするようにしましょう。

> 例えば、Ruby-GNOME2ではglib, gtk, gnomeをそれぞれ別出しにしていますし、
> pango, bonoboといったものもおそらく別出しになるでしょう。

分割の基準は、tar-ball 毎ですか？ それとも作成されるライブラリ毎ですか？

GNOME2 ではライブラリ毎に tar-ball が作られるようなので、どちらにしろ
libart_lgpl が別になるのは当然として gnome は gnome, gnomeui, gnomecanvas
の３分割になるでしょう。

GNOME 1.4 では、tar-ball毎なら libart_lgpl は gnome に含まれるし、ライ
ブラリ毎なら、libart_lgpl が別になるのは当然として、gnomeui も別出しに
なるでしょう。

>> ・ruby の配列か？ それ用のクラスか？
>> 
>>   Cレベルでは affine 変換のデータは double[6] としてしか使用してなくて、
>>   それ用の構造体を定義してない。double[6] ならば、ruby レベルでは
>>   Float の配列としてもあつかえる。
>> 
>>   ruby の API 的には、それ用のクラスがあったのが良いけど、C レベルの
>>   API とのストレートにマッピングすることを考えると、Float の配列をその
>>   まま扱う手もあるのではないかと。
>
> 配列で良いと思います。

うーん、配列の要素が単独で意味を持つのなら配列である意味がありますけど、
affine 変換の場合配列の個々の要素を参照することはないといって良いので
ruby 側で配列である意味はありません。実際の使い方は不透明なデータ構造
と同じあつかいです。

むしろ配列としてあつかうより、クラスにしたほうが API 的に使い易いです。

3つの affine 変換
   rotate = Art::Affine.rotate(45)
   shear = Art::Affine.shear(45)
   translate = Art::Affine.translate(50, 20)
を結合するとき、クラスの場合は、
   rotate * shear * translate
で済みますが、配列にすると、
   Art::Affine.multiply(Art::Affine.multiply(rotate, shear), translate)
となります。これはちょっと使い難い。

だた、Gnome::CanvasPoints もこの API は使い難いと思いつつ、C と同じ
API にしているので、Art::Affine だけ特別あつかいにするのは贔屓なのかな？

>> ・クラスの名前

libart_lgpl 別出しは了承しているので、スキップ

>> ・ArtPoint を用意するかどうか。
>
> これは、上記のクラスをあえて用意するのではなく、
>
> point = [0, 1]
>
> のように、配列でx, yを表現すると言うことを意図してますか？
> であれば、賛成です。

ええ。

(snip)
>>   art_affine_point という API は引数に ArtPoint という構造体を渡すので、
>>   C と直接のマッピングをさせるのなら、Art::Point というクラスを用意して、
>>     Art::Point.new(x, y)  -> anArt::Point
>>     Art::Point#x          -> aFloat
>>     Art::Point#y          -> aFloat
>>     Art::Affine#point(anArt::Point) -> anArt::Point
>
> すみません、ちょっとこの見方がわかりません。
> 例えば、「Art::Point#x　は、aFloatを返す」という意味でしょうか。

クラスはそのまま、インスタンスには a や an をつけています。
"Programming Ruby" で戻り値や引数にこういう表記を使っていたので。
だけど、メソッド名のみで、メソッドにクラスのサフィックスは付けてなかっ
た......。

標準的な書き方があったら、それに従います。

>>   をするのが自然でしょう。しかし、Art::Point は、Art::Affine#point の
>>   引数・戻り値としてしか使い途がない。それなら Art::Point は定義さず、
>>     Art::Affine#point(aFloat, aFloat) -> aFloat, aFloat
>>   でも良いのではないかと。
>
> これは、 Art::Affine#point(aFloat, aFloat)は、配列[aFloat, aFloat]を返す
> ということでしょうか？

そうです。

> それなら賛成です。

書いた当初の私の理由と、むとうさんの理由とは別のようですが、「終わり良
ければすべて良し」ということで。(^^;)

残っている論点は、affine 変換のデータは ruby では配列かクラス(Art::Affine)
かの一点だけですね。

では、再見
-- 
神奈川県茅ヶ崎市在住 久保 健洋
email: ku...@ji...
web:   http://www.jiubao.org
GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1  9F47 C001 1F93 AC08 2262

Re: [ruby-gnome-users-ja] text on Gdk Drawable

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

むとうです。

On Sat, 03 Aug 2002 00:19:02 +0900
KUBO Takehiro <ku...@ji...> wrote:

> 久保＠茅ヶ崎市です。
> 
> KUBO Takehiro <ku...@ji...> writes:
> 
> > まあ、とりあえず明日(8/2)の夜にでも現状のままパッチを作ります。
> 
> 最新の CVS に対するパッチを作りました。場所は、
>    http://www.jiubao.org/tmp/art-affine.dif.gz
> です。
> # うーむ、コミット権もらったのが良いかな？
> # 毎回、むとうさんにコミットしてもらうのもなんだし。

そうですねぇ。これは今のところご遠慮ください。
Ruby-GNOMEの場合は、Ruby-GNOME2とは異なり、
私の方で内容を吟味の上、コミットする形の方が良いでしょう。

> 主な変更は
>  * Art::Affine のサポート
>    新規: gnome/src/rbart-affine.c
>    修正: gnome/src/rbgnome-canvas-item.c
>    修正: gnome/src/rbgnome-canvas.c
>    修正: gnome/src/rbgnome.c
>    修正: gnome/src/rbgnome.h

先のメールで書きましたが、これは、

  * Art::Affine のサポート
    新規: libart_gpl/....
    修正: gnome/src/rbgnome-canvas-item.c
    修正: gnome/src/rbgnome-canvas.c
    修正: gnome/src/rbgnome.c
    修正: gnome/src/rbgnome.h

という形にしたいですね。久保さんの方でlibart_gplの別ライブラリ化
ができますか？
できればお任せしたいのですが、よくわからない場合は言ってください。
私の方でやりましょう。

>  * test-gnome に Art::Affine のサンプルを追加
>    新規: gnome/sample/test-gnome/canvas-affine.rb
>    修正: gnome/sample/test-gnome/canvas.rb

これも、libart_gplの方に持っていった方が良いでしょうね。
例の内容も、gnomeを使った場合やgtkを使った場合が考えられる
と思います。

> ですが、ついでに
>  * Gnome::CanvasPoints のバグの修正
>    修正: gnome/src/rbgnome-canvas-util.c
> 
> もはいっています。

おっと、こちらはお手数をおかけしますが、バグの修正内容を教えてください。
これは、私の方でパッチの意図と実装内容を簡単に確認したいと言うことと、
ChangeLogに書く材料にしたいということから必要です。

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

Re: [ruby-gnome-users-ja] text on Gdk Drawable

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

むとうです。

On Fri, 02 Aug 2002 04:55:08 +0900
KUBO Takehiro <ku...@ji...> wrote:

> 久保＠茅ヶ崎市です。
> 
> Masao Mutoh <mu...@hi...> writes:
> 
> > 文字列をGdk::Imageにして自前でaffine変換かますとかでしょうか。
> > あるいはCVS版のGnomeCanvasを使えばできるのかな....。
> 
> Gnome::CanvasItem#affine_relative, Gnome::CanvasItem#affine_absolute
> があるので、affine 変換で使用する Float の配列を自前で用意できれば不可
> 能ではないです。しかし、不可能でないからといって、現実的かどうかは疑問
> ですけど。あと、Gnome::CanvasText の回転・拡大・縮小は、AntiAlias モー
> ドのときのみ有効です。非 AntiAlias モードのときは並行移動のみ可能で、
> 回転・拡大・縮小は無効のようです。
> # AnitAlias モードは 非 AnitAlias モードと比べて不安定ですけど。(^^;)

えっと、この辺（だけではなくGnomeCanvas全体）、もう少し状況を追っていた
だけないでしょうか。
正直、私の環境ではtest-gnomeを使った場合だけでも異常終了の再現性があり
ますのでこのまま次バージョンのRuby/GNOMEをリリースして良いのか決めかね
ています。

> 手許には、libart_lgpl/art_affine.h の関数を実装した GnomeCanvas の
> affine 変換対応版があります。パッチを出したいけど、ちょっと迷っている
> ところが数点。

まず、大前提ですが、gnomeと同じレベルでlibart_lgplモジュールを
別出しする必要があると思いますがどうでしょうか。

require 'gnome'を呼び出したときにはlibart_lgplが同時に読み込まれると
言うのは問題ないと思いますが、逆にlibart_lgplだけ単独で呼び出せるように
して置いた方が良いと思うのです。
例えば、Ruby-GNOME2ではglib, gtk, gnomeをそれぞれ別出しにしていますし、
pango, bonoboといったものもおそらく別出しになるでしょう。

> ・ruby の配列か？ それ用のクラスか？
> 
>   Cレベルでは affine 変換のデータは double[6] としてしか使用してなくて、
>   それ用の構造体を定義してない。double[6] ならば、ruby レベルでは
>   Float の配列としてもあつかえる。
> 
>   ruby の API 的には、それ用のクラスがあったのが良いけど、C レベルの
>   API とのストレートにマッピングすることを考えると、Float の配列をその
>   まま扱う手もあるのではないかと。

配列で良いと思います。
 
> ・クラスの名前
> 
>   私のパッチではモジュール Art を用意して、Art::Affine というクラスを
>   定義しているのだが、名前がそれで良いのかどうか。

libart_lgplを別出しにした場合はそれで良いと思います。

>   Cレベルの API の名前から自然に類推するには、Art::Affine が良いんだろ
>   うけど、libart_lgpl/*.h の関数の中で、Ruby/Gnome から直接使用するの
>   は affine 変換程度でしょう。たったひとつのクラスのために Art という
>   モジュール名を使っても良いのか？

別ライブラリ化ということであれば、Artの方が自然だし、それはRuby/Gnome
とは別のものですよね。
となるとやはり、前述したとおり、gtk, gnome,panel_appletライブラリと同列に
libartライブラリを作ると方向で検討した方が良いでしょうね。 

>   Gnome の中で affine 変換を使っているのは GnomeCanvas のみなので、
>   Gnome::CanvasAffine でも別に問題ない。ちょっと C レベルの名前からの
>   類推が困難。

これはやめましょう。
 
> ・ArtPoint を用意するかどうか。

これは、上記のクラスをあえて用意するのではなく、

point = [0, 1]

のように、配列でx, yを表現すると言うことを意図してますか？
であれば、賛成です。
理由としては、GTK+側でもこのような構造体をあえてクラスとして定義せず、
配列として情報を持っているパターンが結構あるからです。

実際、以下のようなコードを書くとその煩雑さがわかります。

points = [ Art::Point.new(0,1), Art::Point.new(0,2), Art::Point.new(0,3) ... ]

これが配列であれば

points = [ [0, 1], [0, 2], [0, 3], .... ]

と書けるわけです。断然下の方が書きやすいと思います。 
 
>   art_affine_point という API は引数に ArtPoint という構造体を渡すので、
>   C と直接のマッピングをさせるのなら、Art::Point というクラスを用意して、
>     Art::Point.new(x, y)  -> anArt::Point
>     Art::Point#x          -> aFloat
>     Art::Point#y          -> aFloat
>     Art::Affine#point(anArt::Point) -> anArt::Point

すみません、ちょっとこの見方がわかりません。
例えば、「Art::Point#x　は、aFloatを返す」という意味でしょうか。

>   をするのが自然でしょう。しかし、Art::Point は、Art::Affine#point の
>   引数・戻り値としてしか使い途がない。それなら Art::Point は定義さず、
>     Art::Affine#point(aFloat, aFloat) -> aFloat, aFloat
>   でも良いのではないかと。

これは、 Art::Affine#point(aFloat, aFloat)は、配列[aFloat, aFloat]を返す
ということでしょうか？

それなら賛成です。

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

Re: [ruby-gnome-users-ja] text on Gdk Drawable

[Seiya N. <se...@ku...>]

西澤です。

お忙しいところありがとうございます。

> 久保＠茅ヶ崎市です。
> 
> Seiya Nishizawa <se...@ku...> writes:
> 
> >> GnomeCanvasをつかってやってみようと思います。
> > アンチエリアス(Gnome::Canvas.new_aa)だと
> > CanvasTextをmoveするとeventがとれなくなります。
> > (正確には元の場所と移動先が重なった場所以外はeventがとれません)
> > Gnome::Canvas.newだと問題ありません。
> > またアンチエリアスでもGnome::CanvasRectだと問題ありません。
> 
> test-gnome.rb のサンプルでも同様だし、C で書かれたオリジナルの
> test-gnome でも同様でした。

> とりあえず、透明な CanvasRect を貼りつけて、CanvasRect のほうでイベン
> トを取るようにしてみました。
なるほどそうすればいけますね。

> 上の例では GanvasRect の幅を試行錯誤で決めてます。本当は CanvasText の
> 幅を取得して、それを使用するのが良いんですが、まだ実装されてません。実
> 装するとしたら、
>    Gnome::CanvasText#get("text_width")
>    Gnome::CanvasText#get("text_height")
> という API になるでしょう。
これはぜひほしいですね。(って他人まかせな発言ですが。)



----------
Seiya Nishizawa
se...@ku...

Re: [ruby-gnome-users-ja] text on Gdk Drawable

[KUBO T. <ku...@ji...>]

久保＠茅ヶ崎市です。

Seiya Nishizawa <se...@ku...> writes:

>> GnomeCanvasをつかってやってみようと思います。
> アンチエリアス(Gnome::Canvas.new_aa)だと
> CanvasTextをmoveするとeventがとれなくなります。
> (正確には元の場所と移動先が重なった場所以外はeventがとれません)
> Gnome::Canvas.newだと問題ありません。
> またアンチエリアスでもGnome::CanvasRectだと問題ありません。

test-gnome.rb のサンプルでも同様だし、C で書かれたオリジナルの
test-gnome でも同様でした。

canvas-primitives.c でどうして make_anchor があるのか謎に思いつつ、
canvas-primitives.rb でも同じ関数を用意していたのですが、CanvasText に
対するイベントが取れなくなることがあるので、イベントを取るための把手が
必要だったのでしょう。

とりあえず、透明な CanvasRect を貼りつけて、CanvasRect のほうでイベン
トを取るようにしてみました。

西澤さんのサンプルの
  text = canvas.root.item_new(Gnome::CanvasText,
               "text", "Hello",
               "fill_color","black",
               "font","-b&h-lucida-bold-r-normal-*-14-*-*-*-p-*-iso8859-1",
               "anchor",Gtk::ANCHOR_WEST)
を
  text = canvas.root.item_new(Gnome::CanvasGroup)
  text.item_new(Gnome::CanvasText,
               "text", "Hello",
               "fill_color","black",
               "font","-b&h-lucida-bold-r-normal-*-14-*-*-*-p-*-iso8859-1",
               "anchor",Gtk::ANCHOR_WEST)
  text.item_new(Gnome::CanvasRect,
               "x1", 0,
               "y1", -10,
               "x2", 40,
               "y2", 10,
               "fill_color_rgba", 0x00000000)
にしてみてください。
fill_color_rgba の最後の1バイトを 0x00 にするのが肝要です。

上の例では GanvasRect の幅を試行錯誤で決めてます。本当は CanvasText の
幅を取得して、それを使用するのが良いんですが、まだ実装されてません。実
装するとしたら、
   Gnome::CanvasText#get("text_width")
   Gnome::CanvasText#get("text_height")
という API になるでしょう。

では、再見
-- 
神奈川県茅ヶ崎市在住 久保 健洋
email: ku...@ji...
web:   http://www.jiubao.org
GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1  9F47 C001 1F93 AC08 2262

Re: [ruby-gnome-users-ja] text on Gdk Drawable

[Seiya N. <se...@ku...>]

西澤です。

> > > 最新の CVS に対するパッチを作りました。場所は、
> > >    http://www.jiubao.org/tmp/art-affine.dif.gz
> > > です。

> > 結局、むとうさんがおっしゃるように、
> > ・文字列をGdk::Imageにして自前でaffine変換かます
> > ・CVS版のGnomeCanvasでもって全面的に書き直す。
> > のどちらかしかないでしょう。
> GnomeCanvasをつかってやってみようと思います。
アンチエリアス(Gnome::Canvas.new_aa)だと
CanvasTextをmoveするとeventがとれなくなります。
(正確には元の場所と移動先が重なった場所以外はeventがとれません)
Gnome::Canvas.newだと問題ありません。
またアンチエリアスでもGnome::CanvasRectだと問題ありません。


サンプルをつけます
require "gnome"

#canvas = Gnome::Canvas.new
canvas = Gnome::Canvas.new_aa
canvas.set_usize(300,300)

text = canvas.root.item_new(Gnome::CanvasText,
		     "text", "Hello",
		     "fill_color","black",
		     "font","-b&h-lucida-bold-r-normal-*-14-*-*-*-p-*-iso8859-1",
		     "anchor",Gtk::ANCHOR_WEST)

rect = canvas.root.item_new(Gnome::CanvasRect,
		     "x1",50,"y1",50,"x2",100,"y2",100,
		     "fill_color","white")


text.signal_connect("event"){|widget,event|
  events(widget,event)
}
rect.signal_connect("event"){|widget,event|
  events(widget,event)
}

def events(widget,event)
  case event.event_type
  when Gdk::BUTTON_PRESS
    item_x, item_y = widget.parent.w2i(event.x, event.y)
    @x = item_x
    @y = item_y
    widget.grab(Gdk::POINTER_MOTION_MASK | Gdk::BUTTON_RELEASE_MASK,
		nil,
		event.time)
    fleur.destroy
    @dragging = true
  when Gdk::MOTION_NOTIFY
    item_x, item_y = widget.parent.w2i(event.x,event.y)
    if @dragging then
      widget.move(item_x-@x, item_y-@y)
      @x = item_x
      @y = item_y
    end
  when Gdk::BUTTON_RELEASE

  widget.ungrab(event.time)
  @dragging = false
  end
end


window = Gtk::Window.new(Gtk::WINDOW_TOPLEVEL)
window.add(canvas)

window.show_all

Gtk.main




----------
Seiya Nishizawa
se...@ku...

Re: [ruby-gnome-users-ja] text on Gdk Drawable

[Seiya N. <se...@ku...>]

西澤です。

On Sat, 03 Aug 2002 03:22:44 +0900
KUBO Takehiro <ku...@ji...> wrote:

> 久保＠茅ヶ崎市です。
> 
> KUBO Takehiro <ku...@ji...> writes:
> 
> > 最新の CVS に対するパッチを作りました。場所は、
> >    http://www.jiubao.org/tmp/art-affine.dif.gz
> > です。
早速インストールしてみました。
昨日 C で少し試していたのですがやっぱり ruby で慣れているとたいへんでした。
ruby は最高ですね。

> 結局、むとうさんがおっしゃるように、
> ・文字列をGdk::Imageにして自前でaffine変換かます
> ・CVS版のGnomeCanvasでもって全面的に書き直す。
> のどちらかしかないでしょう。
GnomeCanvasをつかってやってみようと思います。


ありがとうございました。


----------
Seiya Nishizawa
se...@ku...

Re: [ruby-gnome-users-ja] text on Gdk Drawable

[KUBO T. <ku...@ji...>]

久保＠茅ヶ崎市です。

KUBO Takehiro <ku...@ji...> writes:

> 最新の CVS に対するパッチを作りました。場所は、
>    http://www.jiubao.org/tmp/art-affine.dif.gz
> です。

いわずもがなですが、これは Gnome::Canvas* で affine 変換(並行移動とか
回転とか)するためのもので、Gdk::Drawable には使用できません。

結局、むとうさんがおっしゃるように、
・文字列をGdk::Imageにして自前でaffine変換かます
・CVS版のGnomeCanvasでもって全面的に書き直す。
のどちらかしかないでしょう。

では、再見
-- 
神奈川県茅ヶ崎市在住 久保 健洋
email: ku...@ji...
web:   http://www.jiubao.org
GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1  9F47 C001 1F93 AC08 2262

Re: [ruby-gnome-users-ja] text on Gdk Drawable

[KUBO T. <ku...@ji...>]

久保＠茅ヶ崎市です。

KUBO Takehiro <ku...@ji...> writes:

> まあ、とりあえず明日(8/2)の夜にでも現状のままパッチを作ります。

最新の CVS に対するパッチを作りました。場所は、
   http://www.jiubao.org/tmp/art-affine.dif.gz
です。
# うーむ、コミット権もらったのが良いかな？
# 毎回、むとうさんにコミットしてもらうのもなんだし。

主な変更は
 * Art::Affine のサポート
   新規: gnome/src/rbart-affine.c
   修正: gnome/src/rbgnome-canvas-item.c
   修正: gnome/src/rbgnome-canvas.c
   修正: gnome/src/rbgnome.c
   修正: gnome/src/rbgnome.h

 * test-gnome に Art::Affine のサンプルを追加
   新規: gnome/sample/test-gnome/canvas-affine.rb
   修正: gnome/sample/test-gnome/canvas.rb

ですが、ついでに
 * Gnome::CanvasPoints のバグの修正
   修正: gnome/src/rbgnome-canvas-util.c

もはいっています。

では、再見
-- 
神奈川県茅ヶ崎市在住 久保 健洋
email: ku...@ji...
web:   http://www.jiubao.org
GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1  9F47 C001 1F93 AC08 2262

Re: [ruby-gnome-users-ja] text on Gdk Drawable

[KUBO T. <ku...@ji...>]

久保＠茅ヶ崎市です。

Masao Mutoh <mu...@hi...> writes:

> 文字列をGdk::Imageにして自前でaffine変換かますとかでしょうか。
> あるいはCVS版のGnomeCanvasを使えばできるのかな....。

Gnome::CanvasItem#affine_relative, Gnome::CanvasItem#affine_absolute
があるので、affine 変換で使用する Float の配列を自前で用意できれば不可
能ではないです。しかし、不可能でないからといって、現実的かどうかは疑問
ですけど。あと、Gnome::CanvasText の回転・拡大・縮小は、AntiAlias モー
ドのときのみ有効です。非 AntiAlias モードのときは並行移動のみ可能で、
回転・拡大・縮小は無効のようです。
# AnitAlias モードは 非 AnitAlias モードと比べて不安定ですけど。(^^;)

手許には、libart_lgpl/art_affine.h の関数を実装した GnomeCanvas の
affine 変換対応版があります。パッチを出したいけど、ちょっと迷っている
ところが数点。

・ruby の配列か？ それ用のクラスか？

  Cレベルでは affine 変換のデータは double[6] としてしか使用してなくて、
  それ用の構造体を定義してない。double[6] ならば、ruby レベルでは
  Float の配列としてもあつかえる。

  ruby の API 的には、それ用のクラスがあったのが良いけど、C レベルの
  API とのストレートにマッピングすることを考えると、Float の配列をその
  まま扱う手もあるのではないかと。

・クラスの名前

  私のパッチではモジュール Art を用意して、Art::Affine というクラスを
  定義しているのだが、名前がそれで良いのかどうか。

  Cレベルの API の名前から自然に類推するには、Art::Affine が良いんだろ
  うけど、libart_lgpl/*.h の関数の中で、Ruby/Gnome から直接使用するの
  は affine 変換程度でしょう。たったひとつのクラスのために Art という
  モジュール名を使っても良いのか？

  Gnome の中で affine 変換を使っているのは GnomeCanvas のみなので、
  Gnome::CanvasAffine でも別に問題ない。ちょっと C レベルの名前からの
  類推が困難。

・ArtPoint を用意するかどうか。

  art_affine_point という API は引数に ArtPoint という構造体を渡すので、
  C と直接のマッピングをさせるのなら、Art::Point というクラスを用意して、
    Art::Point.new(x, y)  -> anArt::Point
    Art::Point#x          -> aFloat
    Art::Point#y          -> aFloat
    Art::Affine#point(anArt::Point) -> anArt::Point
  をするのが自然でしょう。しかし、Art::Point は、Art::Affine#point の
  引数・戻り値としてしか使い途がない。それなら Art::Point は定義さず、
    Art::Affine#point(aFloat, aFloat) -> aFloat, aFloat
  でも良いのではないかと。

現状の API では、
 singleton methods
   Art::Affine.new(anArray_of_Float) -> anArt::Affine
   Art::Affine.identity()            -> anArt::Affine
   Art::Affine.scale(x, y)           -> anArt::Affine
   Art::Affine.rotate(theta)         -> anArt::Affine
   Art::Affine.shear(theta)          -> anArt::Affine
   Art::Affine.translate(theta)      -> anArt::Affine

 instance methods
   Art::Affine#point(aFloat, aFloat) -> aFloat, aFloat
   Art::Affine#invert()              -> anArt::Affine
   Art::Affine#invert!()             -> anArt::Affine
   Art::Affine#flip(x, y)            -> anArt::Affine
   Art::Affine#flip!(x, y)           -> anArt::Affine
   Art::Affine#to_s                  -> aString
   Art::Affine#to_a                  -> anArray_of_Float
   Art::Affine#expansion()           -> aFloat
   Art::Affine#rectiliner()          -> true or false

   Gnome::CanvasItem#affine_relative(anArt::Affine)  -> nil
    (引数の種類を anArray_of_Float から、anArt::Affine へ変更)
   Gnome::CanvasItem#affine_absolute(anArt::Affine)  -> nil
    (引数の種類を anArray_of_Float から、anArt::Affine へ変更)

   Gnome::CanvasItem#i2c_affine()    -> anArt::Affine
   Gnome::CanvasItem#i2w_affine()    -> anArt::Affine

   Gnome::Canvas#w2c_affine()        -> anArt::Affine
    (TYPO Gnome::Canvas#w2c_affline を削除)

 operators
   Art::Affine#*(anArt::Affine)      -> anArt::Affine
   Art::Affine#==(anArt::Affine)     -> true or false

となっています。
つまり affine 変換用のクラス Art::Affine を用意して、ArtPoint 用のクラ
スは用意してません。

まあ、とりあえず明日(8/2)の夜にでも現状のままパッチを作ります。

では、再見
-- 
神奈川県茅ヶ崎市在住 久保 健洋
email: ku...@ji...
web:   http://www.jiubao.org
GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1  9F47 C001 1F93 AC08 2262

Re: [ruby-gnome-users-ja] text on Gdk Drawable

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

むとうです。

こんばんわ。

On Thu, 1 Aug 2002 11:43:17 +0900
Seiya Nishizawa <se...@ku...> wrote:

> 西澤です。

> Gdk::Drawable
> にテキストを書きたいのですが、
> Gdk::Drawable.draw_string draw_text
> では文字列の角度を変えることができません。
> 
> 一度文字列用のGdk::Drawableを用意してそれを角度を変えて
> メインのGdk::Drawableに埋め込もうとも思ったのですが
> draw_pixmap も角度を変えることができません。

GDKレベルではそのような高機能なAPIを用意してない
と思うのですが....。

> 何か良い方法はないものでしょうか。

文字列をGdk::Imageにして自前でaffine変換かますとかでしょうか。
あるいはCVS版のGnomeCanvasを使えばできるのかな....。

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

[ruby-gnome-users-ja] text on Gdk Drawable

[Seiya N. <se...@ku...>]

西澤です。

いつも質問ばかりして申し訳ありません。

Gdk::Drawable
にテキストを書きたいのですが、
Gdk::Drawable.draw_string draw_text
では文字列の角度を変えることができません。

一度文字列用のGdk::Drawableを用意してそれを角度を変えて
メインのGdk::Drawableに埋め込もうとも思ったのですが
draw_pixmap も角度を変えることができません。

何か良い方法はないものでしょうか。

----------
Seiya Nishizawa
se...@ku...

[ruby-gnome-users-ja] Re: Gimp-Ruby

[Masahiro S. <s01...@sf...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome-users-ja] Re: Gimp-Ruby
Date: Tue, 30 Jul 2002 21:12:16 +0900
 
> > 現在のGimp-Rubyは、gtk+-2.0を使うgimp-1.3系に対応していないので、
> > ruby-gnomeの方に入れさせてもらおうと思います。
> > 
> > ……と思ったら、私はruby-gnomeの方のcommit権を持っていないのでした。
> > 何で、これまで気が付かなかったんだろう。(^^;)
> 
> commit権を払い出しました。これでやってみてください。

どうもありがとうございます。

以下のようにすれば良いんですよね。
% cd ruby-gimp
% cvs -d:ext:sa...@cv...:/cvsroot/ruby-gnome import ruby-gimp vendor start

手元で少しコードを整理してからimportしてみます。

-- さかい

Re: [ruby-gnome-users-ja] Re: Gnome::CanvasItem

[KUBO T. <ku...@ji...>]

久保＠茅ヶ崎市です。

Masahiro Sakai <s01...@sf...> writes:

> GNOME2でcanvas周りのAPIがどうなっているかまだ見てないのですが、
> GtkArgではなくGValueを使う事が出来るのならば、
> void rbgobj_rvalue_to_gvalue(VALUE val, GValue* result);
> を使って変換するようにすれば良いんじゃないかと思います。

ソースを見ると、glib の g_object_set_valist が呼ばれてその中で GValue
に変換してから設定しているのですが、canvas の API としては、
  void gnome_canvas_item_set (GnomeCanvasItem *item, const gchar *first_arg_name, ...);
  void gnome_canvas_item_set_valist (GnomeCanvasItem *item,
                                     const gchar *first_arg_name, va_list args);
しか用意されていません。

うーん、glib の g_object_set に対応する関数を用意するのが吉かな？

では、再見
-- 
神奈川県茅ヶ崎市在住 久保 健洋
email: ku...@ji...
web:   http://www.jiubao.org
GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1  9F47 C001 1F93 AC08 2262

Re: [ruby-gnome-users-ja] Re: Gimp-Ruby

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

むとうです。

On Tue, 30 Jul 2002 18:14:51 +0900
Masahiro Sakai <s01...@sf...> wrote:

> さかいです。
 
> 現在のGimp-Rubyは、gtk+-2.0を使うgimp-1.3系に対応していないので、
> ruby-gnomeの方に入れさせてもらおうと思います。
> 
> ……と思ったら、私はruby-gnomeの方のcommit権を持っていないのでした。
> 何で、これまで気が付かなかったんだろう。(^^;)

commit権を払い出しました。これでやってみてください。

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

[ruby-gnome-users-ja] Re: Gimp-Ruby

[Masahiro S. <s01...@sf...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome-users-ja] Gimp-Ruby (was Re: Ruby/GNOMEの呼び出し時の引数)
Date: Tue, 30 Jul 2002 00:10:21 +0900

> それでは、以下の2つのどちらかにしていただくというのはどうでしょうか。
> 
> 1. 一番トップディレクトリのruby-gnome2と同列にGimp-Rubyも入れる
> 　　→　再配布はruby-gnome/ruby-gnome2とは別。
> 
> 2. ruby-gnome/ruby-gnome2の配下にgimpというディレクトリを作りそこに入れる
> 　　→　特に更新等が無くてもruby-gnome/ruby-gnome2と一緒に配布する。
> 
> ちなみに、ruby-gconfは2.のやり方で良いかなと考えてます。
> 
> Gimp-Rubyはさかいさんの好きな方でやっちゃってください。

では、1の方にしようと思います。

> また、ruby-gnomeと一緒にするのか、ruby-gnome2と一緒にするのか、どちらも
> 一緒にするのかも、さかいさんの考えで決めてもらって良いですよ。

現在のGimp-Rubyは、gtk+-2.0を使うgimp-1.3系に対応していないので、
ruby-gnomeの方に入れさせてもらおうと思います。

……と思ったら、私はruby-gnomeの方のcommit権を持っていないのでした。
何で、これまで気が付かなかったんだろう。(^^;)

-- さかい

[ruby-gnome-users-ja] Re: Gnome::CanvasItem

[Masahiro S. <s01...@sf...>]

さかいです。

From: KUBO Takehiro <ku...@ji...>
Subject: [ruby-gnome-users-ja] Re: Gnome::CanvasItem
Date: Tue, 30 Jul 2002 02:27:42 +0900

> Ruby/GNOME2 では rbgobj_paramspecs.c がちゃんと実装されていれば簡
> 単に書き直せると思う。rbgobj_paramspecs.c がちゃんと実装されている
> かどうかチェックしてませんけど。p(^^;)

rbgobj_paramspecs.cは機能を使う機会がこれまでなかったので、
ad-hoc な実装のままになってます。

GNOME2でcanvas周りのAPIがどうなっているかまだ見てないのですが、
GtkArgではなくGValueを使う事が出来るのならば、
void rbgobj_rvalue_to_gvalue(VALUE val, GValue* result);
を使って変換するようにすれば良いんじゃないかと思います。

-- さかい

[ruby-gnome-users-ja] Re: Gnome::CanvasItem

[KUBO T. <ku...@ji...>]

久保＠茅ヶ崎市です。

Masao Mutoh <mu...@hi...> writes:

> おぉ、すばらしい。
> さっそく取り込まさせていただきました。
> test-gnomeでポリゴンがぐりぐり動くのは見る価値ありですね。

そう言っていただけると、やったかいがあります。

> ただ、私の環境だと、しばらくいじってる後にメニューの「閉じる」とかを
> クリックするとエラーSIGSEGVだったりそうじゃなかったり、簡単に試した
> ところで、特定できませんでしたがどうもメモリ系のエラーっぽいです。

さっき一回だけ SIGSEGV になりました。けど再現方法がはっきりしない。
core を吐かせるようにして色々いじりまくるしかないかな。

>> このソースで使っている方法は Ruby/GNOME2 には適用できません。
>> Ruby/GNOME2 のためには rbgnome-canvas-item.c の先頭部分は書き直し
>> でしょう。
>
> そのまま適用しちゃいました。また、暇なときにでも面倒みてください(^^;)。

Ruby/GNOME2 では rbgobj_paramspecs.c がちゃんと実装されていれば簡
単に書き直せると思う。rbgobj_paramspecs.c がちゃんと実装されている
かどうかチェックしてませんけど。p(^^;)

では、再見
-- 
神奈川県茅ヶ崎市在住 久保 健洋
email: ku...@ji...
web:   http://www.jiubao.org
GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1  9F47 C001 1F93 AC08 2262

Re: [ruby-gnome-users-ja] Gnome::CanvasItem

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

むとうです。

＃はー、今日はダメかも....(^^;)

On Tue, 30 Jul 2002 01:05:27 +0900
Masao Mutoh <mu...@hi...> wrote:

> むとうです。

> ただ、私の環境だと、しばらくいじってる後にメニューの「閉じる」とかを
> クリックするとエラーSIGSEGVだったりそうじゃなかったり、簡単に試した

「クリックするとエラーが出ます。エラーの出方はSIGSEGVだったり.....」
に訂正してください(^^;)。


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

Re: [ruby-gnome-users-ja] Gnome::CanvasItem

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

むとうです。

On Mon, 29 Jul 2002 01:56:57 +0900
KUBO Takehiro <ku...@ji...> wrote:

> 久保＠茅ヶ崎市です。
> 
> ずっと以前に一回やったことあるのですが、Gnome::CanvasItem 対応を再
> 度行いました。以前は test-gnome.rb の Antialias でも SIGSEGV が起
> こったのですが、今回は今のところ問題なし。

おぉ、すばらしい。
さっそく取り込まさせていただきました。
test-gnomeでポリゴンがぐりぐり動くのは見る価値ありですね。

ただ、私の環境だと、しばらくいじってる後にメニューの「閉じる」とかを
クリックするとエラーSIGSEGVだったりそうじゃなかったり、簡単に試した
ところで、特定できませんでしたがどうもメモリ系のエラーっぽいです。

> このソースで使っている方法は Ruby/GNOME2 には適用できません。
> Ruby/GNOME2 のためには rbgnome-canvas-item.c の先頭部分は書き直し
> でしょう。

そのまま適用しちゃいました。また、暇なときにでも面倒みてください(^^;)。
＃そういや、今のRuby/GNOME2ってコンパイルすら通らないですね。
＃ま、おいおいやっていきましょう。

それでは。

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