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?
on 2010-06-04 16:28
on 2010-06-11 19:54
On Fri, Jun 4, 2010 at 16:27, Nikolai Weibull <now@bitwi.se> wrote:
> I’m very disappointed to see that gio was removed.
Bump. What’s going on?
on 2010-06-12 12:47
Hi, In <AANLkTimzlAwQLNuFQB2o4jL1BlIq1nSTwy9K4qTUovx3@mail.gmail.com> "[ruby-gnome2-devel-en] gio" on Fri, 4 Jun 2010 16:27:42 +0200, Nikolai Weibull <now@bitwi.se> 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. > > VALUE block; > > if that kind of $B!H(Bbehind the scenes$B!I(B 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
on 2010-06-12 13:01
2010/6/12 Kouhei Sutou <kou@cozmixng.org>: > 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?
on 2010-06-12 13:09
Hi, In <AANLkTinaY3o48eMs-A2dP8JMdXhFZeuev2FsRE5vpL62@mail.gmail.com> "Re: [ruby-gnome2-devel-en] gio" on Sat, 12 Jun 2010 13:00:32 +0200, Nikolai Weibull <now@bitwi.se> 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
on 2010-06-12 13:23
2010/6/12 Kouhei Sutou <kou@cozmixng.org>: >> 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!
on 2010-06-17 16:22
On Sat, Jun 12, 2010 at 13:22, Nikolai Weibull <now@bitwi.se> wrote: > 2010/6/12 Kouhei Sutou <kou@cozmixng.org>: >>>> 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.
on 2010-06-17 16:26
On Tue, Jun 15, 2010 at 15:59, Nikolai Weibull <now@bitwi.se> wrote: > 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.
on 2010-06-20 12:34
Hi, In <AANLkTinAE7ychRaxEq9bBMoC1tb7YX971NofAcRINTYh@mail.gmail.com> "Re: [ruby-gnome2-devel-en] gio" on Wed, 16 Jun 2010 16:17:04 +0200, Nikolai Weibull <now@bitwi.se> wrote: > 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
on 2010-06-20 14:31
On Sun, Jun 20, 2010 at 12:33, Kouhei Sutou <kou@cozmixng.org> wrote: >  Nikolai Weibull <now@bitwi.se> 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?
on 2010-07-03 11:32
On Sun, Jun 20, 2010 at 14:30, Nikolai Weibull <now@bitwi.se> 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!
on 2010-07-04 10:35
Hi, In <AANLkTinylYvsZeTf9VIEohWAHU0dPOsrHsZnZKqdm-OA@mail.gmail.com> "Re: [ruby-gnome2-devel-en] gio" on Sat, 3 Jul 2010 11:31:49 +0200, Nikolai Weibull <now@bitwi.se> 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
on 2010-07-08 23:21
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.
on 2010-07-12 11:06
On Thu, Jul 8, 2010 at 23:21, Nikolai Weibull <now@bitwi.se> 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?
on 2010-07-12 14:44
Hi, Sorry for my late response. In <AANLkTim-Uojkhg7-5oxms2_ZKP9WFKUJsunUwgNFdq9-@mail.gmail.com> "Re: [ruby-gnome2-devel-en] gio" on Mon, 12 Jul 2010 11:06:12 +0200, Nikolai Weibull <now@bitwi.se> 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
on 2010-07-12 18:37
2010/7/12 Kouhei Sutou <kou@cozmixng.org>: > Sorry for my late response. No problem! > In <AANLkTim-Uojkhg7-5oxms2_ZKP9WFKUJsunUwgNFdq9-@mail.gmail.com> >  "Re: [ruby-gnome2-devel-en] gio" on Mon, 12 Jul 2010 11:06:12 +0200, >  Nikolai Weibull <now@bitwi.se> wrote: > 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_*?
Please log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.