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

Re: [ruby-gnome2-devel-ja] Unicode Manipulation

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

むとうです。

On Sat, 09 Dec 2006 20:33:27 +0900 (JST)
Kouhei Sutou <ko...@co...> wrote:

> 須藤です．
> 
> In <200...@co...>
>   "Re: [ruby-gnome2-devel-ja] Unicode Manipulation" on Fri, 01 Dec 2006 23:45:42 +0900 (JST),
>   Kouhei Sutou <ko...@co...> wrote:
> 
> > > > GLibのUnicode Manipulationのセクションの関数（具体的には
> > > > g_ucs4_to_utf8()）を使いたいので，ここのセクションの関数を
> > > > Ruby/GLib2に実装してもよいでしょうか？
> > > 
> > > はい。
> > 
> > わかりました．
> > では，ちょこちょこ実装していきます．
> 
> やりました．
> テストとドキュメントも更新しておきました．
> 
> GLib::Unicode::*やGLib::UnicodeBreak::*などを
> GLib::UNICODE_*, GLib::UNICODE_BREAK_*としても定義しましたが，
> これらは定義しなかった方がよかったでしょうか．もしそうなら直

それもそうなんですけど、メソッドの定義って
以下のような感じじゃないんでしたっけ？

g_unichar_foo => GLib::Unichar.foo
g_unicode_foo => GLib::Unicode.foo
g_utf8_foo => GLib::Utf8.foo

GLibトップレベルで、文字操作関連がやたらと
増えるのがちょっと抵抗があるのですが・・・。
＃それぞれをClassに定義するのはさすがにやりすぎな気がしますので
＃Moduleのままで良いとは思うのですが。

Re: [ruby-gnome2-devel-ja] Unicode Manipulation

[Kouhei S. <ko...@co...>]

須藤です．

In <200...@co...>
  "Re: [ruby-gnome2-devel-ja] Unicode Manipulation" on Fri, 01 Dec 2006 23:45:42 +0900 (JST),
  Kouhei Sutou <ko...@co...> wrote:

> > > GLibのUnicode Manipulationのセクションの関数（具体的には
> > > g_ucs4_to_utf8()）を使いたいので，ここのセクションの関数を
> > > Ruby/GLib2に実装してもよいでしょうか？
> > 
> > はい。
> 
> わかりました．
> では，ちょこちょこ実装していきます．

やりました．
テストとドキュメントも更新しておきました．

GLib::Unicode::*やGLib::UnicodeBreak::*などを
GLib::UNICODE_*, GLib::UNICODE_BREAK_*としても定義しましたが，
これらは定義しなかった方がよかったでしょうか．もしそうなら直
してしまってください．

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?UnVieS9HTGliMhskQiRHGyhC?= =?iso-2022-jp?b?Z2xpYi1ta2VudW1zGyRCJHI7SCQkJD8kJBsoQg==?=

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

むとうです。

On Thu, 7 Dec 2006 10:02:18 +0900
"Kouhei Sutou" <ko...@co...> wrote:

> 須藤です．
> 
> 06/12/07 に Masao Mutoh<mu...@hi...> さんは書きました:
> 
> > > > ・GLib直下にメソッドを作らずにGLibMkenumsにまとめる。
> > > > →GLibMkenumsはGlib::Mkenumsの方が良いかもしれませんね。
> > > > ・GLib直下に配置していたメソッド名はcreate_, runと変えてみました。
> > > >     create_, run以外でもexecuteとかでもいいかもしれません。
> > >
> > > > まぁ、GLib直下にメソッドを作らなければModuleでもClassでも
> > > > いいかなぁ、と思いますが、どうでしょう。
> > >
> > > はい，私はそれでもかまいません．
> >
> > えっと、どうしましょう。インプリまでしていただけると
> > 非常に助かるんですが、私がやった方がよいですか？
> >
> > > ただ，「Mkenums」という「M」だけが大きい字面が気に入らない
> > > ので，もう少しいい名前があればなぁと思います．
> >
> > まぁ、元のツールの名前を踏襲するというのはある意味しょうがない
> > んじゃないでしょうか。GLib::MkEnums, GLib::MKEnumsでも良いか
> > もしれません。
> 
> 名前がピンとこないので自分で実装するのは気が引けます．
> この名前のままいくのであればお願いしたいです．
>
> GLib::UtilsとかGLib::Commandsの下にバラまくというのの
> なら私がやりますが．．．ただそうするとcreate{,_c,_h}と
> いう名前にはmkenusという単語がないと変な気がするので
> むとうさんの好みには合わなくなると思います．

GLib::Commands.mkenums ですか・・・。
pkg-configもGLib::Commands.pkg_configとかを用意するって感じですかね。

まぁ、好みといわれればそうかもしれませんが、
上記のようなまとめ方をするんだったらGLib::MkEnumsとかの方が
良いような気がします。

まぁ、そんな感じで近いうちに修正しますね。

それでは。

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?UnVieS9HTGliMhskQiRHGyhC?= =?iso-2022-jp?b?Z2xpYi1ta2VudW1zGyRCJHI7SCQkJD8kJBsoQg==?=

[Kouhei S. <ko...@co...>]

須藤です．

06/12/07 に Masao Mutoh<mu...@hi...> さんは書きました:

> > > ・GLib直下にメソッドを作らずにGLibMkenumsにまとめる。
> > > →GLibMkenumsはGlib::Mkenumsの方が良いかもしれませんね。
> > > ・GLib直下に配置していたメソッド名はcreate_, runと変えてみました。
> > >     create_, run以外でもexecuteとかでもいいかもしれません。
> >
> > > まぁ、GLib直下にメソッドを作らなければModuleでもClassでも
> > > いいかなぁ、と思いますが、どうでしょう。
> >
> > はい，私はそれでもかまいません．
>
> えっと、どうしましょう。インプリまでしていただけると
> 非常に助かるんですが、私がやった方がよいですか？
>
> > ただ，「Mkenums」という「M」だけが大きい字面が気に入らない
> > ので，もう少しいい名前があればなぁと思います．
>
> まぁ、元のツールの名前を踏襲するというのはある意味しょうがない
> んじゃないでしょうか。GLib::MkEnums, GLib::MKEnumsでも良いか
> もしれません。

名前がピンとこないので自分で実装するのは気が引けます．
この名前のままいくのであればお願いしたいです．

GLib::UtilsとかGLib::Commandsの下にバラまくというのの
なら私がやりますが．．．ただそうするとcreate{,_c,_h}と
いう名前にはmkenusという単語がないと変な気がするので
むとうさんの好みには合わなくなると思います．

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?UnVieS9HTGliMhskQiRHGyhC?= =?iso-2022-jp?b?Z2xpYi1ta2VudW1zGyRCJHI7SCQkJD8kJBsoQg==?=

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

むとうです。

On Wed, 6 Dec 2006 10:04:20 +0900
"Kouhei Sutou" <ko...@co...> wrote:

> 須藤です．
> 
> 06/12/06 に Masao Mutoh<mu...@hi...> さんは書きました:
> 
> > この際なので、ちと、API整理しちゃっていいですか？
> 
> あぁ！！！ごめんなさい！！！
> GLibMkenumsはpkg-config.rbからコピペしたときにまるっと
> 残ったままでした．．．なので，GLibMkenumsは全然必要
> ないです．．．
> 
> > ・GLib直下にメソッドを作らずにGLibMkenumsにまとめる。
> > →GLibMkenumsはGlib::Mkenumsの方が良いかもしれませんね。
> > ・GLib直下に配置していたメソッド名はcreate_, runと変えてみました。
> >     create_, run以外でもexecuteとかでもいいかもしれません。
> 
> > まぁ、GLib直下にメソッドを作らなければModuleでもClassでも
> > いいかなぁ、と思いますが、どうでしょう。
> 
> はい，私はそれでもかまいません．

えっと、どうしましょう。インプリまでしていただけると
非常に助かるんですが、私がやった方がよいですか？

> ただ，「Mkenums」という「M」だけが大きい字面が気に入らない
> ので，もう少しいい名前があればなぁと思います．

まぁ、元のツールの名前を踏襲するというのはある意味しょうがない
んじゃないでしょうか。GLib::MkEnums, GLib::MKEnumsでも良いか
もしれません。

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?UnVieS9HTGliMhskQiRHGyhC?= =?iso-2022-jp?b?Z2xpYi1ta2VudW1zGyRCJHI7SCQkJD8kJBsoQg==?=

[Kouhei S. <ko...@co...>]

須藤です．

06/12/06 に Masao Mutoh<mu...@hi...> さんは書きました:

> この際なので、ちと、API整理しちゃっていいですか？

あぁ！！！ごめんなさい！！！
GLibMkenumsはpkg-config.rbからコピペしたときにまるっと
残ったままでした．．．なので，GLibMkenumsは全然必要
ないです．．．

> ・GLib直下にメソッドを作らずにGLibMkenumsにまとめる。
> →GLibMkenumsはGlib::Mkenumsの方が良いかもしれませんね。
> ・GLib直下に配置していたメソッド名はcreate_, runと変えてみました。
>     create_, run以外でもexecuteとかでもいいかもしれません。

> まぁ、GLib直下にメソッドを作らなければModuleでもClassでも
> いいかなぁ、と思いますが、どうでしょう。

はい，私はそれでもかまいません．
ただ，「Mkenums」という「M」だけが大きい字面が気に入らない
ので，もう少しいい名前があればなぁと思います．

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?UnVieS9HTGliMhskQiRHGyhC?= =?iso-2022-jp?b?Z2xpYi1ta2VudW1zGyRCJHI7SCQkJD8kJBsoQg==?=

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

むとうです。

On Tue, 05 Dec 2006 23:56:41 +0900 (JST)
Kouhei Sutou <ko...@co...> wrote:

> 須藤です．
> 
> In <200...@hi...>
>   "Re: [ruby-gnome2-devel-ja] Ruby/GLib2でglib-mkenumsを使いたい" on Tue, 5 Dec 2006 02:26:21 +0900,
>   Masao Mutoh <mu...@hi...> wrote:
> 
> > > ただ，Ruby/GLib2はGObjectに依存しているので，Ruby/GLib2側で
> > > GLibのヘッダーファイルからglib-mkenumsを用いてGTypeを作って
> > > も問題なさそうに思います．私は，Ruby/GLib2内でGLibのenumを定
> > > 義するためにG_DEF_CONSTANTSを使いたいので，こんなパッチを当
> > > ててもいいですか？
> > 
> > なるほど。便利ですね。当ててくださいませ。
> > ＃ただ、これ、当てた後、既存のコード部分で定数を使っている
> > ＃ところも修正が必要じゃないですか？
> 
> RVAL2GENUM()がIntegerの場合でも頑張って動いてくれるので大丈
> 夫だと思います．

まぁ、そうですね。ま、せっかくですので、おいおい対応していきましょうか。
 
> > ただ、せっかくですので、pkg-config.rbのように、
> > glib/src/lib/glib-mkenums.rb というファイルを作って、
> > 他のライブラリからも呼び出すことができるようにして
> > いただけるとさらにうれしいです ;)。
> 
> そうしました．

この際なので、ちと、API整理しちゃっていいですか？

現在：
module GLib
  def mkenums(prefix, files, g_type_prefix, include_files)
  def mkenums_c(prefix, files, include_files)
  def mkenums_h(prefix, files, g_type_prefix)
  def run_mkenums(output, config, files)
end
module GLibMkenums
  def exist?(pkg)
  def libs(pkg)
  def libs_only_L(pkg)
  def libs_only_l(pkg)
  def cflags(pkg)
  def cflags_only_I(pkg)
  def cflags_only_other(pkg)
  def variable(pkg, var)
  def modversion(pkg)
  def version
  def list_all
  def name(pkg)
  def description(pkg)
  def provides(pkg)
  def requires(pkg)
  def check_version?(pkg, major = 0, minor = 0, micro = 0)
  def have_package(pkg, major = nil, minor = 0, micro = 0)
end

変更案：

module GLibMkenums
  def create(prefix, files, g_type_prefix, include_files)  #was mkenums
  def create_c(prefix, files, include_files)      #was mkenum_c
  def create_h(prefix, files, g_type_prefix)      #was mkenum_h
  def run(output, config, files)  #was run_mkenums

  def exist?(pkg)
  def libs(pkg)
  def libs_only_L(pkg)
  def libs_only_l(pkg)
  def cflags(pkg)
  def cflags_only_I(pkg)
  def cflags_only_other(pkg)
  def variable(pkg, var)
  def modversion(pkg)
  def version
  def list_all
  def name(pkg)
  def description(pkg)
  def provides(pkg)
  def requires(pkg)
  def check_version?(pkg, major = 0, minor = 0, micro = 0)
  def have_package(pkg, major = nil, minor = 0, micro = 0)
end

・GLib直下にメソッドを作らずにGLibMkenumsにまとめる。
　→GLibMkenumsはGlib::Mkenumsの方が良いかもしれませんね。
・GLib直下に配置していたメソッド名はcreate_, runと変えてみました。
    create_, run以外でもexecuteとかでもいいかもしれません。　

exist?以下の配置を見るとClassにしても良いかなぁ、
とちょっと思いました。
PKGconfigも同じ構成なんですよねぇ。まぁ、歴史的な経緯もあるので
それはひとまず棚にあげて。

module GLib
 class Mkenums
  def self.create(prefix, files, g_type_prefix, include_files)  #was mkenums
  def self.create_c(prefix, files, include_files)      #was mkenum_c
  def self.create_h(prefix, files, g_type_prefix)      #was mkenum_h
  def self.run(output, config, files)  #was run_mkenums
  def self.version
  def self.list_all

  def initialize(pkg)
  def exist?
  def libs
  def libs_only_L
  def libs_only_l
  def cflags
  def cflags_only_I
  def cflags_only_other
  def variable(var)
  def modversion
  def name
  def description
  def provides
  def requires
  def check_version?(major = 0, minor = 0, micro = 0)
  def have_package(major = nil, minor = 0, micro = 0)
 end
end

例：
mkenums = GLib::Mkenums.new(pkg)
mkenums.cflags
mkenums.libs

って。こっちはちょっとやりすぎですかね？

まぁ、GLib直下にメソッドを作らなければModuleでもClassでも
いいかなぁ、と思いますが、どうでしょう。

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?UnVieS9HTGliMhskQiRHGyhC?= =?iso-2022-jp?b?Z2xpYi1ta2VudW1zGyRCJHI7SCQkJD8kJBsoQg==?=

[Kouhei S. <ko...@co...>]

須藤です．

In <200...@hi...>
  "Re: [ruby-gnome2-devel-ja] Ruby/GLib2でglib-mkenumsを使いたい" on Tue, 5 Dec 2006 02:26:21 +0900,
  Masao Mutoh <mu...@hi...> wrote:

> > ただ，Ruby/GLib2はGObjectに依存しているので，Ruby/GLib2側で
> > GLibのヘッダーファイルからglib-mkenumsを用いてGTypeを作って
> > も問題なさそうに思います．私は，Ruby/GLib2内でGLibのenumを定
> > 義するためにG_DEF_CONSTANTSを使いたいので，こんなパッチを当
> > ててもいいですか？
> 
> なるほど。便利ですね。当ててくださいませ。
> ＃ただ、これ、当てた後、既存のコード部分で定数を使っている
> ＃ところも修正が必要じゃないですか？

RVAL2GENUM()がIntegerの場合でも頑張って動いてくれるので大丈
夫だと思います．

> ただ、せっかくですので、pkg-config.rbのように、
> glib/src/lib/glib-mkenums.rb というファイルを作って、
> 他のライブラリからも呼び出すことができるようにして
> いただけるとさらにうれしいです ;)。

そうしました．

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?UnVieS9HTGliMhskQiRHGyhC?= =?iso-2022-jp?b?Z2xpYi1ta2VudW1zGyRCJHI7SCQkJD8kJBsoQg==?=

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

むとうです。

On Mon, 04 Dec 2006 23:49:39 +0900 (JST)
Kouhei Sutou <ko...@co...> wrote:

> 須藤です．
> 
> GLibはGType(GObject)に依存していないため，glib-mkenumsで自動
> 生成できるGTypeを提供していません．そのため，enumを定義する
> ためにRuby/GLib2が提供している便利マクロG_DEF_CONSTANTSを使
> えません．
> 
> ただ，Ruby/GLib2はGObjectに依存しているので，Ruby/GLib2側で
> GLibのヘッダーファイルからglib-mkenumsを用いてGTypeを作って
> も問題なさそうに思います．私は，Ruby/GLib2内でGLibのenumを定
> 義するためにG_DEF_CONSTANTSを使いたいので，こんなパッチを当
> ててもいいですか？

なるほど。便利ですね。当ててくださいませ。
＃ただ、これ、当てた後、既存のコード部分で定数を使っている
＃ところも修正が必要じゃないですか？

ただ、せっかくですので、pkg-config.rbのように、
glib/src/lib/glib-mkenums.rb というファイルを作って、
他のライブラリからも呼び出すことができるようにして
いただけるとさらにうれしいです ;)。
＃まぁ、でも、ライブラリ化は別の機会にでも構いません。

[ruby-gnome2-devel-ja] =?iso-2022-jp?b?UnVieS9HTGliMhskQiRHGyhC?= =?iso-2022-jp?b?Z2xpYi1ta2VudW1zGyRCJHI7SCQkJD8kJBsoQg==?=

[Kouhei S. <ko...@co...>]

須藤です．

GLibはGType(GObject)に依存していないため，glib-mkenumsで自動
生成できるGTypeを提供していません．そのため，enumを定義する
ためにRuby/GLib2が提供している便利マクロG_DEF_CONSTANTSを使
えません．

ただ，Ruby/GLib2はGObjectに依存しているので，Ruby/GLib2側で
GLibのヘッダーファイルからglib-mkenumsを用いてGTypeを作って
も問題なさそうに思います．私は，Ruby/GLib2内でGLibのenumを定
義するためにG_DEF_CONSTANTSを使いたいので，こんなパッチを当
ててもいいですか？

Re: [ruby-gnome2-devel-ja] Unicode Manipulation

[Kouhei S. <ko...@co...>]

須藤です．

In <200...@hi...>
  "Re: [ruby-gnome2-devel-ja] Unicode Manipulation" on Fri, 1 Dec 2006 23:22:08 +0900,
  Masao Mutoh <mu...@hi...> wrote:

> > GLibのUnicode Manipulationのセクションの関数（具体的には
> > g_ucs4_to_utf8()）を使いたいので，ここのセクションの関数を
> > Ruby/GLib2に実装してもよいでしょうか？
> 
> はい。

わかりました．
では，ちょこちょこ実装していきます．

Re: [ruby-gnome2-devel-ja] Unicode Manipulation

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

むとうです。

On Fri, 01 Dec 2006 23:00:28 +0900 (JST)
Kouhei Sutou <ko...@co...> wrote:

> 須藤です．
> 
> GLibのUnicode Manipulationのセクションの関数（具体的には
> g_ucs4_to_utf8()）を使いたいので，ここのセクションの関数を
> Ruby/GLib2に実装してもよいでしょうか？

はい。

> もし，なにか実装していない理由があるのであれば，Uconvで代用
> できるのでRuby/GLib2に実装するのはやめます．

いや、特に理由はないです。よろしくお願いします。

Ruby/GLib2は案外実装が難しいんで後手後手になってます（苦笑）。

[ruby-gnome2-devel-ja] Unicode Manipulation

[Kouhei S. <ko...@co...>]

須藤です．

GLibのUnicode Manipulationのセクションの関数（具体的には
g_ucs4_to_utf8()）を使いたいので，ここのセクションの関数を
Ruby/GLib2に実装してもよいでしょうか？

もし，なにか実装していない理由があるのであれば，Uconvで代用
できるのでRuby/GLib2に実装するのはやめます．

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?GyRCJVYlbSVDJS8kTjxCGyhC?= =?iso-2022-jp?b?GyRCQXUkSyREJCQkRhsoQg==?=

[Kouhei S. <ko...@co...>]

須藤です．

06/11/08 に Masao Mutoh<mu...@hi...> さんは書きました:

> > Gladeのやつはパッチをつけて返事をしておきました．
>
> ありがとうございます。これってCVSにあげていただいてあります？
> まだでしたらあげてくださいませ。

コミットしました．

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?GyRCJVYlbSVDJS8kTjxCGyhC?= =?iso-2022-jp?b?GyRCQXUkSyREJCQkRhsoQg==?=

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

むとうです。

On Tue, 7 Nov 2006 13:49:44 +0900
"Kouhei Sutou" <ko...@co...> wrote:

> 須藤です．
> 
> 06/11/07 に Masao Mutoh<mu...@hi...> さんは書きました:
> 
> > enの方で出てるClosure周りの問題って
> > リプライしていただけないでしょうか。
> 
> Gladeのやつはパッチをつけて返事をしておきました．

ありがとうございます。これってCVSにあげていただいてあります？
まだでしたらあげてくださいませ。

> 他のやつは解決していますよね？

たぶん・・・。
でも、Nicholasの話だとまだ完全じゃないみたいですね・・・。

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?GyRCJVYlbSVDJS8kTjxCGyhC?= =?iso-2022-jp?b?GyRCQXUkSyREJCQkRhsoQg==?=

[Kouhei S. <ko...@co...>]

須藤です．

06/11/07 に Masao Mutoh<mu...@hi...> さんは書きました:

> enの方で出てるClosure周りの問題って
> リプライしていただけないでしょうか。

Gladeのやつはパッチをつけて返事をしておきました．
他のやつは解決していますよね？

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?GyRCJVYlbSVDJS8kTjxCGyhC?= =?iso-2022-jp?b?GyRCQXUkSyREJCQkRhsoQg==?=

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

須藤さん

enの方で出てるClosure周りの問題って
リプライしていただけないでしょうか。
＃すみません。時間取れなくて・・・。

On Tue, 7 Nov 2006 01:17:25 +0900
Masao Mutoh <mu...@hi...> wrote:

> むとうです。
> 
> 了解しました。
> 
> 依存関係を（ソース単位で）減らしたいと言うのは
> 理解できましたが、ソースコードの単純さを考えて
> mGtkを使うようにしたいと思います。
> ＃好みがうるさくてすみません。
> 
> あ、そうそう。もともとのコンセプトである、
> 「クラスオブジェクトに付けることでselfがGCされても
> 　 GCされないようにする」
> 
> というのは良いですね。なるべくこれを使うように
> 直していきます。
> ＃G_RELATIVEは廃止かなぁ。
> 
> それでは。
> 
> On Mon, 6 Nov 2006 11:46:11 +0900
> "Kouhei Sutou" <ko...@co...> wrote:
> 
> > 須藤です．
> > 
> > 06/11/04 に Masao Mutoh<mu...@hi...> さんは書きました:
> > 
> > > 「クラスオブジェクトに付けることでselfがGCされても
> > > GCされないようにする」
> > > という意図でいいですか？
> > 
> > はい．
> > 
> > > gPrintJobではなくmGtkなど、よりグローバルな変数を
> > > 使えば、gPrintJob自体を外出し（ファイルの頭で宣言）する必要が
> > > ないと思うのですが、ファイルごとにG_CHILD_ADDするものを
> > > 分けたのは何か意図がありますか？
> > 
> > 依存関係をrbgtkprintjob.cの中で完結させたかったからです．
> > 
> > むとうさんのおっしゃるとおりmGtkを使用して，gPrintJobを
> > 使わずにすませる方法でもよいと思います．
> > 私はどちらでも構いませんので，むとうさんの判断にお任せし
> > ます．
> > 
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > ruby-gnome2-devel-ja mailing list
> > rub...@li...
> > https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-ja
> > 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> ruby-gnome2-devel-ja mailing list
> rub...@li...
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-ja
> 

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?GyRCJVYlbSVDJS8kTjxCGyhC?= =?iso-2022-jp?b?GyRCQXUkSyREJCQkRhsoQg==?=

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

むとうです。

了解しました。

依存関係を（ソース単位で）減らしたいと言うのは
理解できましたが、ソースコードの単純さを考えて
mGtkを使うようにしたいと思います。
＃好みがうるさくてすみません。

あ、そうそう。もともとのコンセプトである、
「クラスオブジェクトに付けることでselfがGCされても
　 GCされないようにする」

というのは良いですね。なるべくこれを使うように
直していきます。
＃G_RELATIVEは廃止かなぁ。

それでは。

On Mon, 6 Nov 2006 11:46:11 +0900
"Kouhei Sutou" <ko...@co...> wrote:

> 須藤です．
> 
> 06/11/04 に Masao Mutoh<mu...@hi...> さんは書きました:
> 
> > 「クラスオブジェクトに付けることでselfがGCされても
> > GCされないようにする」
> > という意図でいいですか？
> 
> はい．
> 
> > gPrintJobではなくmGtkなど、よりグローバルな変数を
> > 使えば、gPrintJob自体を外出し（ファイルの頭で宣言）する必要が
> > ないと思うのですが、ファイルごとにG_CHILD_ADDするものを
> > 分けたのは何か意図がありますか？
> 
> 依存関係をrbgtkprintjob.cの中で完結させたかったからです．
> 
> むとうさんのおっしゃるとおりmGtkを使用して，gPrintJobを
> 使わずにすませる方法でもよいと思います．
> 私はどちらでも構いませんので，むとうさんの判断にお任せし
> ます．
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> ruby-gnome2-devel-ja mailing list
> rub...@li...
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-ja
> 

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?GyRCJVYlbSVDJS8kTjxCGyhC?= =?iso-2022-jp?b?GyRCQXUkSyREJCQkRhsoQg==?=

[Kouhei S. <ko...@co...>]

須藤です．

06/11/04 に Masao Mutoh<mu...@hi...> さんは書きました:

> 「クラスオブジェクトに付けることでselfがGCされても
> GCされないようにする」
> という意図でいいですか？

はい．

> gPrintJobではなくmGtkなど、よりグローバルな変数を
> 使えば、gPrintJob自体を外出し（ファイルの頭で宣言）する必要が
> ないと思うのですが、ファイルごとにG_CHILD_ADDするものを
> 分けたのは何か意図がありますか？

依存関係をrbgtkprintjob.cの中で完結させたかったからです．

むとうさんのおっしゃるとおりmGtkを使用して，gPrintJobを
使わずにすませる方法でもよいと思います．
私はどちらでも構いませんので，むとうさんの判断にお任せし
ます．

[ruby-gnome2-devel-ja] =?iso-2022-jp?b?GyRCJVYlbSVDJS8kTjxCGyhC?= =?iso-2022-jp?b?GyRCQXUkSyREJCQkRhsoQg==?=

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

須藤さん

むとうです。

ブロックの実装部分について質問です。

たとえば、rbgtkprinjob.cで以下のような
実装をされていると思います。

static VALUE
pj_send(VALUE self)
{
    VALUE block = G_BLOCK_PROC();
    G_CHILD_ADD(gPrintJob, block);
    gtk_print_job_send(_SELF(self), complete_func, (gpointer)block,
                       remove_callback_reference);
    return self;
}

で、質問は、G_CHILD_ADDのところなのですが、
これって、今まではG_RELATIVE(self, block)とやっていたと
思うのですが、
「クラスオブジェクトに付けることでselfがGCされても
　GCされないようにする」
という意図でいいですか？

上記が正しいとして。
gPrintJobではなくmGtkなど、よりグローバルな変数を
使えば、gPrintJob自体を外出し（ファイルの頭で宣言）する必要が
ないと思うのですが、ファイルごとにG_CHILD_ADDするものを
分けたのは何か意図がありますか？

それでは。

Re: [ruby-gnome2-devel-ja] About GtkPrinter

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

むとうです。

On Thu, 26 Oct 2006 00:41:21 +0900 (JST)
Kouhei Sutou <ko...@co...> wrote:

> 須藤です．

> > rbgtkprinter.cで、
> > 
> > #ifdef HAVE_GTK_GTKPRINTER_H
> > 
> > を使っていますが、
> > 
> > #if GTK_CHECK_VERSION(2,10,0)
> > 
> > を使わないのは何か理由がありますか？
> > 
> > 環境によっては
> > GTK+-2.10.0以降なのにgtk/gtkprinter.hが
> > 存在しない、ということがありうるのでしょうか？
> 
> GTK+のMakefile.amをみてみましたが，ありえないと思います．
> 直してもらえますか？

りょうかいです。
 
> かえっていろいろ迷惑をかけているようで，すいません．．．

いえいえ。新規で実装するよりは全然楽ですよ。助かりました。

ではでは。

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

Re: [ruby-gnome2-devel-ja] About GtkPrinter

[Kouhei S. <ko...@co...>]

須藤です．

In <200...@hi...>
  "[ruby-gnome2-devel-ja] About GtkPrinter" on Thu, 26 Oct 2006 00:17:07 +0900,
  Masao Mutoh <mu...@hi...> wrote:

> rbgtkprinter.cで、
> 
> #ifdef HAVE_GTK_GTKPRINTER_H
> 
> を使っていますが、
> 
> #if GTK_CHECK_VERSION(2,10,0)
> 
> を使わないのは何か理由がありますか？
> 
> 環境によっては
> GTK+-2.10.0以降なのにgtk/gtkprinter.hが
> 存在しない、ということがありうるのでしょうか？

GTK+のMakefile.amをみてみましたが，ありえないと思います．
直してもらえますか？

かえっていろいろ迷惑をかけているようで，すいません．．．

[ruby-gnome2-devel-ja] About GtkPrinter

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

須藤さん

むとうです。

rbgtkprinter.cで、

#ifdef HAVE_GTK_GTKPRINTER_H

を使っていますが、

#if GTK_CHECK_VERSION(2,10,0)

を使わないのは何か理由がありますか？

環境によっては
GTK+-2.10.0以降なのにgtk/gtkprinter.hが
存在しない、ということがありうるのでしょうか？

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

[ruby-gnome2-devel-ja] =?iso-2022-jp?b?R3RrOjpQYWdlU2V0dXA=?= =?iso-2022-jp?b?GyRCQj4bKEI=?=

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

むとうです。

Gtk::PageSetup他で、引数のあるgetterがNaming Ruleに
従っていないことに今さらながら気づいたので、わたしの方で修正します。

× foo(a)
○ get_foo(a)

get_を省略できるのは、引数がないgetterのみです。

get_foo() => foo()

です。ちょっとあいまいな書き方があったので、Naming Rules
の方も修正しました。
http://ruby-gnome2.sourceforge.jp/hiki.cgi?Naming+and+Conversion+Rules#Accessors+%28Setter%2FGetter+methods%29

とりあえず、Gtk::PageSetupのみ修正しました。

＃遅くなってすみません。

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

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?bGliZ2xhZGUyGyRCJE4bKEI=?= =?iso-2022-jp?b?GyRCJVElQyVBGyhC?=

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

むとうです。

On Sun, 15 Oct 2006 11:15:16 +0900 (JST)
Kouhei Sutou <ko...@co...> wrote:

> 須藤です．
> 
> In <200...@hi...>
>   "Re: [ruby-gnome2-devel-ja] libglade2のパッチ" on Sun, 15 Oct 2006 00:50:50 +0900,
>   Masao Mutoh <mu...@hi...> wrote:
> 
> > ちなみに、
> > make_parent_widgets_for_a_widget_that_has_a_window_in_ancestors()
> > ＃な、ながい・・・。
> > 
> > を、分割した理由はありますか？
> 
> 何をやっているのかをコメントとして書きたくなかったというのが
> 理由です．後で見たときに，どうして↓がGCのための処理なのかは
> わからないと思います．

それは、コメントを残すべきでしょう。
再利用性が無い（かつ、他に特別な理由がない）のに、
コメントと同様のことをAPIで実現しようと言うのは本末転倒だと思います。

> > それから、
> > make_parent_widgets_for_a_widget_that_has_a_window_in_ancestors()
> > の名称ですが、別だしにするならもう少し適切な名称にしませんか。
> 
> 変な英語ですいません．．．

APIとして用意する以上、他から使われる前提で物事を考えるべきではないでしょうか。
コメントなら後から修正しても問題はないですが、APIの場合は仕様変更になりますし。

> > ただ、やっぱり分ける意味を感じないし他の人が見たら理解しづらいですよね。
> 
> わかりました．
> では，統合してしまってください．

直しておきました。

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