Forum: Ruby-Gnome 2 gio

gio
Posted by Nikolai Weibull (Guest)
on 2010-06-04 16:28
(Received via mailing list)
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?
Posted by Nikolai Weibull (Guest)
on 2010-06-11 19:54
(Received via mailing list)
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?
Posted by Kouhei Sutou (Guest)
on 2010-06-12 12:47
(Received via mailing list)
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
Posted by Nikolai Weibull (Guest)
on 2010-06-12 13:01
(Received via mailing list)
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?
Posted by Kouhei Sutou (Guest)
on 2010-06-12 13:09
(Received via mailing list)
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
Posted by Nikolai Weibull (Guest)
on 2010-06-12 13:23
(Received via mailing list)
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!
Posted by Nikolai Weibull (Guest)
on 2010-06-17 16:22
(Received via mailing list)
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.
Posted by Nikolai Weibull (Guest)
on 2010-06-17 16:26
(Received via mailing list)
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.
Posted by Kouhei Sutou (Guest)
on 2010-06-20 12:34
(Received via mailing list)
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
Posted by Nikolai Weibull (Guest)
on 2010-06-20 14:31
(Received via mailing list)
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?
Posted by Nikolai Weibull (Guest)
on 2010-07-03 11:32
(Received via mailing list)
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!
Posted by Kouhei Sutou (Guest)
on 2010-07-04 10:35
(Received via mailing list)
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
Posted by Nikolai Weibull (Guest)
on 2010-07-08 23:21
(Received via mailing list)
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.
Posted by Nikolai Weibull (Guest)
on 2010-07-12 11:06
(Received via mailing list)
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?
Posted by Kouhei Sutou (Guest)
on 2010-07-12 14:44
(Received via mailing list)
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
Posted by Nikolai Weibull (Guest)
on 2010-07-12 18:37
(Received via mailing list)
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
No account? Register here.