From: Masao M. <mu...@hi...> - 2002-08-03 11:11:02
|
むとうです。 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...> |