From: Nikolai W. <no...@bi...> - 2010-06-04 14:27:51
|
I’m very disappointed to see that gio was removed. What would it take to get it re-added? > And please don't use DECLARE*, DEF_*, SCAN_* family > macros. Please keep coding style with other bindings. I have now removed all DECLARE* and DEF_*; four hours of work, even with automation. What exactly is the problem with SCAN_*? I can rename them to RBGIO2_SCAN_*, but I have absolutely no desire to duplicate that kind of code for exactly the reasons I stated previously: > … sometimes order is important and then we have a problem if it is done > in different ways I can also make the argument and block variables name explicit, that is, instead of GCancellable *cancellable; VALUE block; SCAN_1_ARG_WITH_BLOCK("01", cancellable, RVAL2GCANCELLABLE); g_drive_poll_for_media(_SELF(self), cancellable, rbgio_async_ready_callback, (gpointer)block); return self; we can have GCancellable *cancellable; VALUE block; RBGIO2_SCAN_1_ARG_WITH_BLOCK(argc, argv, "01", cancellable, RVAL2GCANCELLABLE, block); g_drive_poll_for_media(_SELF(self), cancellable, rbgio_async_ready_callback, (gpointer)block); return self; if that kind of “behind the scenes” action is confusing. Is this an acceptable compromise? |
From: Nikolai W. <no...@bi...> - 2010-06-11 17:54:01
|
On Fri, Jun 4, 2010 at 16:27, Nikolai Weibull <no...@bi...> wrote: > I’m very disappointed to see that gio was removed. Bump. What’s going on? |
From: Kouhei S. <ko...@co...> - 2010-06-12 10:46:52
|
Hi, In <AAN...@ma...> "[ruby-gnome2-devel-en] gio" on Fri, 4 Jun 2010 16:27:42 +0200, Nikolai Weibull <no...@bi...> wrote: > What would it take to get it re-added? If Ruby/GIO uses Ruby-GNOME2 style, we are welcome to re-add Ruby/GIO. >> And please don't use DECLARE*, DEF_*, SCAN_* family >> macros. Please keep coding style with other bindings. > > I have now removed all DECLARE* and DEF_*; four hours of work, even > with automation. Thanks!!! > What exactly is the problem with SCAN_*? I can > rename them to RBGIO2_SCAN_*, but I have absolutely no desire to > duplicate that kind of code for exactly the reasons I stated > previously: Please don't use the macros too. >> … sometimes order is important and then we have a problem if it is done >> in different ways > > I can also make the argument and block variables name explicit, that > is, instead of > > GCancellable *cancellable; > VALUE block; > > SCAN_1_ARG_WITH_BLOCK("01", cancellable, RVAL2GCANCELLABLE); > > g_drive_poll_for_media(_SELF(self), > cancellable, > rbgio_async_ready_callback, > (gpointer)block); > > return self; > > we can have > > GCancellable *cancellable; > VALUE block; > > RBGIO2_SCAN_1_ARG_WITH_BLOCK(argc, argv, "01", cancellable, > RVAL2GCANCELLABLE, block); > > g_drive_poll_for_media(_SELF(self), > cancellable, > rbgio_async_ready_callback, > (gpointer)block); > > return self; > > if that kind of “behind the scenes” action is confusing. > > Is this an acceptable compromise? Uhm... I can't accept it. If we need to change 1 argument to 2 arguments, we need to change XXX_SCAN_1_XXX to XXX_SCAN_2_XXX and "01" to "02". We also can't handle selectable argument. For example, we write like the following when we want to accept ID or NAME as an argument: VALUE id_or_name, id = Qnil, name = Qnil; rb_scan_args(argc, argv, "10", &id_or_name); if (TYPE(id_or_name) == T_STRING) { name = id_or_name; } else { id = id_or_name; } If we accept the such argument, we need to define a macro for the case. So I don't think the XXX_SCAN_N_XXX approach is a good idea for readability, writability and extensibility in the Ruby-GNOME2 project. Thanks, -- kou |
From: Nikolai W. <no...@bi...> - 2010-06-12 11:00:40
|
2010/6/12 Kouhei Sutou <ko...@co...>: > So I don't think the XXX_SCAN_N_XXX approach is a good idea > for readability, writability and extensibility in the > Ruby-GNOME2 project. OK. I’ll remove them. May I then re-add it, or do you want a patch instead? |
From: Kouhei S. <ko...@co...> - 2010-06-12 11:09:02
|
Hi, In <AAN...@ma...> "Re: [ruby-gnome2-devel-en] gio" on Sat, 12 Jun 2010 13:00:32 +0200, Nikolai Weibull <no...@bi...> wrote: >> So I don't think the XXX_SCAN_N_XXX approach is a good idea >> for readability, writability and extensibility in the >> Ruby-GNOME2 project. > > OK. I’ll remove them. Thanks! > May I then re-add it, or do you want a patch instead? You can re-add it. But if there are some problems, we will comment them. In the case, please fix them. Thanks, -- kou |
From: Nikolai W. <no...@bi...> - 2010-06-12 11:22:56
|
2010/6/12 Kouhei Sutou <ko...@co...>: > Hi, > > In <AAN...@ma...> > "Re: [ruby-gnome2-devel-en] gio" on Sat, 12 Jun 2010 13:00:32 +0200, > Nikolai Weibull <no...@bi...> wrote: > >>> So I don't think the XXX_SCAN_N_XXX approach is a good idea >>> for readability, writability and extensibility in the >>> Ruby-GNOME2 project. >> >> OK. I’ll remove them. > > Thanks! > >> May I then re-add it, or do you want a patch instead? > > You can re-add it. But if there are some problems, we will > comment them. In the case, please fix them. OK, great! |
From: Nikolai W. <no...@bi...> - 2010-06-16 14:17:11
|
On Tue, Jun 15, 2010 at 15:59, Nikolai Weibull <no...@bi...> wrote: > On Sat, Jun 12, 2010 at 13:22, Nikolai Weibull <no...@bi...> wrote: >> 2010/6/12 Kouhei Sutou <ko...@co...>: > >>>>> So I don't think the XXX_SCAN_N_XXX approach is a good idea >>>>> for readability, writability and extensibility in the >>>>> Ruby-GNOME2 project. > >>>> OK. I’ll remove them. > > OK, now I remember why I created the SCAN_* macros. When you take a > block you have to convert all the parameters first, as any errors have > to be raised before you save the block…this is so boring. OK, so this is now done. Can we perhaps consider moving to Git in the future. Subversion is seriously a pain to work with. There are still a bunch of TODOs that remain of the “I need input from others on how to resolve them” kind, so please search for TODO in *.c and see if you have any suggestions. Enjoy. |
From: Kouhei S. <ko...@co...> - 2010-06-20 10:33:43
|
Hi, In <AAN...@ma...> "Re: [ruby-gnome2-devel-en] gio" on Wed, 16 Jun 2010 16:17:04 +0200, Nikolai Weibull <no...@bi...> wrote: >>>>>> So I don't think the XXX_SCAN_N_XXX approach is a good idea >>>>>> for readability, writability and extensibility in the >>>>>> Ruby-GNOME2 project. >> >>>>> OK. I’ll remove them. >> >> OK, now I remember why I created the SCAN_* macros. When you take a >> block you have to convert all the parameters first, as any errors have >> to be raised before you save the block…this is so boring. > > OK, so this is now done. Thanks! > There are still a bunch of TODOs that remain of the “I need input from > others on how to resolve them” kind, so please search for TODO in *.c > and see if you have any suggestions. Please also check the bug? https://sourceforge.net/tracker/?func=detail&atid=470969&aid=3018618&group_id=53614 Thanks, -- kou |
From: Nikolai W. <no...@bi...> - 2010-07-03 09:31:56
|
On Sun, Jun 20, 2010 at 14:30, Nikolai Weibull <no...@bi...> wrote: > Also, what is the current target for Ruby-GNOME2? 2.22? 2.24? I’ve brought the bindings up to 2.24 compatibility and implemented many missing classes and the unix interface as well. I have some questions, though. How do I know when to use rbgobj_boxed_not_copy_obj? What name do we prefer, GLib::File::Enumerator or GLib::FileEnumerator? Same for GLib::File::Info versus GLib::FileInfo? (Ruby has File::Stat.) When should I be using G_PROTECT_CALLBACK? Thanks! |
From: Kouhei S. <ko...@co...> - 2010-07-04 08:34:58
|
Hi, In <AAN...@ma...> "Re: [ruby-gnome2-devel-en] gio" on Sat, 3 Jul 2010 11:31:49 +0200, Nikolai Weibull <no...@bi...> wrote: > How do I know when to use rbgobj_boxed_not_copy_obj? It's a time to use rbgobj_boxed_not_copy_obj() when a boxed object cannot be created by user. (If you don't provide BoxedClass.new, you need to use rbgobj_boxed_not_copy_obj().) > What name do we prefer, GLib::File::Enumerator or GLib::FileEnumerator? > > Same for GLib::File::Info versus GLib::FileInfo? (Ruby has File::Stat.) GLib::FileEnumerator and GLib::FileInfo. See also: http://ruby-gnome2.sourceforge.jp/hiki.cgi?Naming+and+Conversion+Rules > When should I be using G_PROTECT_CALLBACK? When you allow user to use callback block. Thanks, -- kou |
From: Nikolai W. <no...@bi...> - 2010-07-12 09:06:21
|
On Thu, Jul 8, 2010 at 23:21, Nikolai Weibull <no...@bi...> wrote: > OK, almost done. Quite a few to-dos, but I’m quite happy with it now. OK, done. GIO has been updated to 2.24.1, should compile under Ruby 1.9.* and has a lot fewer to-dos. Implementing GConverter remains to be done. There’s code in the repository for it, but it doesn’t work. I don’t exactly know how to solve it, actually, as it seems that the API more or less requires that you keep auxiliary data around between calls (like ext/iconv/* does as well), but I can’t figure out a good way of doing so. > Another question, though: > > How do I know when to use GOBJ2RVAL_UNREF? Should I use it as soon as > a new, freshly allocated, GObject * is returned? It seems that quite > a few uses of GOBJ2RVAL may be incorrect in, for example, gtk/src/*.c, > if that’s the case. I really would like this question answered. Also, I think that rbg_cstr2rval_with_free should be rewritten, wrapping it in a rb_ensure that ensures that that g_free is called even if rb_str_new2 throws an error. What do you think? |
From: Kouhei S. <ko...@co...> - 2010-07-12 12:43:10
|
Hi, Sorry for my late response. In <AAN...@ma...> "Re: [ruby-gnome2-devel-en] gio" on Mon, 12 Jul 2010 11:06:12 +0200, Nikolai Weibull <no...@bi...> wrote: > OK, done. GIO has been updated to 2.24.1, should compile under Ruby > 1.9.* and has a lot fewer to-dos. Great! >> How do I know when to use GOBJ2RVAL_UNREF? Should I use it as soon as >> a new, freshly allocated, GObject * is returned? GOBJ2RVAL_UNREF is a convenience macro. It meens that the following: ruby_object = GOBJE2RVAL(g_object); g_object_unref(g_object); You can use GOBJ2RVAL_UNREF when you need to unref converted GObject. >> It seems that quite >> a few uses of GOBJ2RVAL may be incorrect in, for example, gtk/src/*.c, >> if that’s the case. Please give us a patch. > Also, I think that rbg_cstr2rval_with_free should be rewritten, > wrapping it in a rb_ensure that ensures that that g_free is called > even if rb_str_new2 throws an error. What do you think? I agree with you. Thanks, -- kou |
From: Nikolai W. <no...@bi...> - 2010-07-12 16:37:25
|
2010/7/12 Kouhei Sutou <ko...@co...>: > Sorry for my late response. No problem! > In <AAN...@ma...> > "Re: [ruby-gnome2-devel-en] gio" on Mon, 12 Jul 2010 11:06:12 +0200, > Nikolai Weibull <no...@bi...> wrote: >>> How do I know when to use GOBJ2RVAL_UNREF? Should I use it as soon as >>> a new, freshly allocated, GObject * is returned? > > GOBJ2RVAL_UNREF is a convenience macro. It meens that the > following: > > ruby_object = GOBJE2RVAL(g_object); > g_object_unref(g_object); > > You can use GOBJ2RVAL_UNREF when you need to unref converted > GObject. >>> It seems that quite >>> a few uses of GOBJ2RVAL may be incorrect in, for example, gtk/src/*.c, >>> if that’s the case. So, use GOBJ2RVAL_UNREF whenever a function returns a freshly allocated/new GObject *? Also, I noticed quite a few uses of G_CHILD_ADD that I don’t understand. For example, in gtk/src/rbgdkdraw.c we have gdkdraw_set_colormap that does G_CHILD_REMOVE/G_CHILD_ADD for the colormap that we’re setting. Why? I mean, if the colormap goes out of Ruby scope it’ll still be referenced by the GdkDrawable, right? So why all the fuss with managing it as a child with G_CHILD_*? |
From: Nikolai W. <no...@bi...> - 2010-07-08 21:21:10
|
OK, almost done. Quite a few to-dos, but I’m quite happy with it now. Another question, though: How do I know when to use GOBJ2RVAL_UNREF? Should I use it as soon as a new, freshly allocated, GObject * is returned? It seems that quite a few uses of GOBJ2RVAL may be incorrect in, for example, gtk/src/*.c, if that’s the case. |
From: Nikolai W. <no...@bi...> - 2010-06-20 12:30:54
|
On Sun, Jun 20, 2010 at 12:33, Kouhei Sutou <ko...@co...> wrote: > Nikolai Weibull <no...@bi...> wrote: >> There are still a bunch of TODOs that remain of the “I need input from >> others on how to resolve them” kind, so please search for TODO in *.c >> and see if you have any suggestions. > Please also check the bug? > https://sourceforge.net/tracker/?func=detail&atid=470969&aid=3018618&group_id=53614 I'll fix it tomorrow. Also, what is the current target for Ruby-GNOME2? 2.22? 2.24? |
From: Nikolai W. <no...@bi...> - 2010-06-15 14:00:01
|
On Sat, Jun 12, 2010 at 13:22, Nikolai Weibull <no...@bi...> wrote: > 2010/6/12 Kouhei Sutou <ko...@co...>: >>>> So I don't think the XXX_SCAN_N_XXX approach is a good idea >>>> for readability, writability and extensibility in the >>>> Ruby-GNOME2 project. >>> OK. I’ll remove them. OK, now I remember why I created the SCAN_* macros. When you take a block you have to convert all the parameters first, as any errors have to be raised before you save the block…this is so boring. |