Ruby Forum Ruby-Gnome 2 > Release manager

Hi,

The Ruby-GNOME2 project lacks human resources. For example,
we doesn't release new version since 2006-12-29 even if we
keep developing.

We want a release manager who will do the following work:

  * You will try to build on supported platform that will be
    decided by you.
    (e.g. ruby >= 1.8.x, GTK+ >= 2.x.x, Linux, FreeBSD,
    Windows, MacOSX, ...)
    Some people who aren't a release manager but they have a
    supported platform will help you.

  * You will archive a new Ruby-GNOME2 package.

  * You will release the archived package on SF.net.
    (I have a release script for SF.net. It may help you.
     https://cutter.svn.sourceforge.net/svnroot/cutter/trunk/misc/release.rb)

  * You will announce the release on SF.net and related MLs.
    e.g.: 
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/231656

  * You will do the same work again after a few months ago.

We are waiting for your help!


Thanks,
--
kou

Hi,

I would like to participate.

> The Ruby-GNOME2 project lacks human resources. For example,
> we doesn't release new version since 2006-12-29 even if we
> keep developing.
Yes, it's a shame.
Also I think the bindings are pretty stable now and maybe the version 
0.16 may not "describe" the actual progress.

> We want a release manager who will do the following work:
> 
>   * You will try to build on supported platform that will be
>     decided by you.
>     (e.g. ruby >= 1.8.x, GTK+ >= 2.x.x, Linux, FreeBSD,
>     Windows, MacOSX, ...)
I have a i386 ubuntu linux machine here.

How do you test all the bindings ? Are there any automated tests 
available? Sure I can test it with all the applications I have and use, 
but they surely will not test every feature.

>   * You will archive a new Ruby-GNOME2 package.
Does it include precompiled binaries? The thing I don't have here is a 
Windows machine. Anyone else would need to do binary packages for win32.

Best Regards,
  Joachim Glauche

> > The Ruby-GNOME2 project lacks human resources. For example,
> > we doesn't release new version since 2006-12-29 even if we
> > keep developing.

Jep, I also thought about this... From my point of view, we should
release (at least) tar balls every six month. Even if we couldn't follow
the Gtk+ / GNOME release cycles with complete bindings, this will be a
good sign for the packagers of the destributions to release new packages
and to the "normal user" it will show, that ruby-gnome is still alive.

> I have a i386 ubuntu linux machine here.
> 
I have a PowerPc debian and an i386 debian setup here. For his i could
set up a build- and test bot. But...

> How do you test all the bindings ? Are there any automated tests 
> available?

...this is a big problem. There is no testframework at all. I'm not that
much an expert in this, but i think that a _usefull_ testframework is at
least as much work than the bindings itself.



>  Sure I can test it with all the applications I have and use, 
> but they surely will not test every feature.
> 
> >   * You will archive a new Ruby-GNOME2 package.

IMHO that is not a special need. Cause SF does not make any backups (at
least they tell so) someone has to make regularey backups from _all_
data.


Cheers detlef

Detlef Reichl wrote:

>>  Sure I can test it with all the applications I have and use, 
>> but they surely will not test every feature.
>> 
>> >   * You will archive a new Ruby-GNOME2 package.
> 
> IMHO that is not a special need. Cause SF does not make any backups (at
> least they tell so) someone has to make regularey backups from _all_
> data.

I think what he meant with this is:
- check out a specific svn version
- put new version number on it
- make a tarball out of it (=archive a new package)

11 mar 2008 kl. 23.31 skrev Detlef Reichl:

Hi,

Glad to see this discussion come up. I'm relatively new to Ruby-Gnome2
but a long time contributer and maintainer on various GNOME modules.

I'm a bit curious as to whether it wouldn't make sense to move the
infrastructure over to the GNOME/GTK+ infrastructure?

This will bring the project closer to the rest of the community, as
well as make it easier to get involved in the project if you are
already a GNOME/GTK+ contributor. As far as I know all of the
successful bindings are hosted on GNOME Subversion server, in GNOME
Bugzilla, release tarballs on the GNOME FTP etc.

I would personally be happy to assist in any way to make this happen
as well as try building on both Linux and Mac OS X (Intel and PPC).

Cheers and thanks to everyone who have brought the bindings to the
current level, your work is much appreciated.

Mikael Hallendal

> and to the "normal user" it will show, that ruby-gnome is still alive.
>>>    Windows, MacOSX, ...)
> much an expert in this, but i think that a _usefull_ testframework  
> IMHO that is not a special need. Cause SF does not make any backups  
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> ruby-gnome2-devel-en mailing list
> ruby-gnome2-devel-en@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-en

--
Imendio AB, http://www.imendio.com

Am Dienstag, den 11.03.2008, 23:43 +0100 schrieb Joachim Glauche:
> 
> I think what he meant with this is:
> - check out a specific svn version
> - put new version number on it
> - make a tarball out of it (=archive a new package)

For this is no need. For packages just put a tag onto the svn branch and
that was it.

Joachim Glauche wrote:
> Does it include precompiled binaries? The thing I don't have here is a 
> Windows machine. Anyone else would need to do binary packages for win32.
> 
> Best Regards,
>   Joachim Glauche

Well, this is too bad for me. I am a windows user but I don't have VC6 
compiler to build the binary.

Hi,

In <d5eb0925608bc8fc3ed7fe076bffce1f@ruby-forum.com>
  "Re: [ruby-gnome2-devel-en] Release manager" on Tue, 11 Mar 2008 
19:45:42 +0100,
  Joachim Glauche <ruby-forum-incoming@andreas-s.net> wrote:

> I would like to participate.

Thanks for your help!
I'll give you some rights on SF.net. Could you tell me your
SF.net account?

> How do you test all the bindings ? Are there any automated tests 
> available? Sure I can test it with all the applications I have and use, 
> but they surely will not test every feature.

No but I want to add some automated tests. Sample programs
will also help you.

> >   * You will archive a new Ruby-GNOME2 package.
> Does it include precompiled binaries? The thing I don't have here is a 
> Windows machine. Anyone else would need to do binary packages for win32.

It will be desired on Windows.


Thanks,
--
kou

Hi,

In <1205274719.3141.15.camel@datengrab>
  "Re: [ruby-gnome2-devel-en] Release manager" on Tue, 11 Mar 2008 
23:31:59 +0100,
  Detlef Reichl <detlef.reichl@gmx.org> wrote:

> > >   * You will archive a new Ruby-GNOME2 package.
> 
> IMHO that is not a special need. Cause SF does not make any backups (at
> least they tell so) someone has to make regularey backups from _all_
> data.

I just wanted to say about making .tar.gz, .zip, .exe and so
on.


Thanks,
--
kou

Hi,

In <7506E550-05E6-42C2-921F-E5ED12776BDA@imendio.com>
  "Re: [ruby-gnome2-devel-en] Release manager" on Tue, 11 Mar 2008 
23:44:25 +0100,
  Mikael Hallendal <micke@imendio.com> wrote:

> I'm a bit curious as to whether it wouldn't make sense to move the  
> infrastructure over to the GNOME/GTK+ infrastructure?
> 
> This will bring the project closer to the rest of the community, as  
> well as make it easier to get involved in the project if you are  
> already a GNOME/GTK+ contributor. As far as I know all of the  
> successful bindings are hosted on GNOME Subversion server, in GNOME  
> Bugzilla, release tarballs on the GNOME FTP etc.

It's OK for me. If other contributors prefer it, we will
move to there.

# But applying an account for GNOME infrastructure is a bit
# bother for me...

> I would personally be happy to assist in any way to make this happen  
> as well as try building on both Linux and Mac OS X (Intel and PPC).

It will be very helpful.


Thanks,
--
kou

On mer, 2008-03-12 at 22:50 +0900, Kouhei Sutou wrote:
> > well as make it easier to get involved in the project if you are  
> > already a GNOME/GTK+ contributor. As far as I know all of the  
> > successful bindings are hosted on GNOME Subversion server, in GNOME  
> > Bugzilla, release tarballs on the GNOME FTP etc.
> 
> It's OK for me. If other contributors prefer it, we will
> move to there.

I'm not really a contributor given that I don't even remember my last
commit, but I think it would be nice to get closer to GNOME, and it
would give visibility

> # But applying an account for GNOME infrastructure is a bit
> # bother for me...

It's supposed to be easier now
http://blogs.gnome.org/ovitters/2007/09/29/mango-gone-live/

12 mar 2008 kl. 14.50 skrev Kouhei Sutou:

Hi,

>> This will bring the project closer to the rest of the community, as
>> well as make it easier to get involved in the project if you are
>> already a GNOME/GTK+ contributor. As far as I know all of the
>> successful bindings are hosted on GNOME Subversion server, in GNOME
>> Bugzilla, release tarballs on the GNOME FTP etc.
>
> It's OK for me. If other contributors prefer it, we will
> move to there.

Wonderful, I got some pings yesterday in #gnome-ruby2 and on Jabber
from people who liked the idea.

> # But applying an account for GNOME infrastructure is a bit
> # bother for me...

I can help with getting accounts sorted out for people who need them.
And hopefully (as Pascal wrote in a reply), things are working better
these days.

Cheers,
   Mikael Hallendal

--
Imendio AB, http://www.imendio.com

Kouhei Sutou wrote:

> Thanks for your help!
> I'll give you some rights on SF.net. Could you tell me your
> SF.net account?

My account name is 'jglauche'

> It's OK for me. If other contributors prefer it, we will
> move to there.
fine by me.

>> How do you test all the bindings ? Are there any automated tests 
>> available? Sure I can test it with all the applications I have and use, 
>> but they surely will not test every feature.
> 
> No but I want to add some automated tests. Sample programs
> will also help you.
Sounds good. I have a bunch of programs which can be used for "reality" 
testing also. But a more extended automated test platform would be very 
very helpful.

Is there anyone who can help me on the win32 binaries?

Hi,

2008/3/12, Joachim Glauche <ruby-forum-incoming@andreas-s.net>:

>  > I'll give you some rights on SF.net. Could you tell me your
>  > SF.net account?
>
>
> My account name is 'jglauche'

I've added your account to the project members.

> > It's OK for me. If other contributors prefer it, we will
> > move to there.
> fine by me.

At least, the next release (soon?) will be done on SF.net.


Thanks,
--
kou

Kouhei Sutou wrote:

> At least, the next release (soon?) will be done on SF.net.

Is there any pending work in current trunk? (r2843)

If not, I can release the 0.17.0, at least the source-releases shortly. 
Seems to work fine for me.

Kouhei, will it be possible for you and the main dev team to keep News 
file in trunk with the most important/summarized news updated? I could 
parse all the Changelog files and put them into the news file, but the 
that'll gonna be huge amount of changes since last release.

Hi,

In <54d4f3f96725a1d526763e2b688d9c53@ruby-forum.com>
  "Re: [ruby-gnome2-devel-en] Release manager" on Wed, 12 Mar 2008 
22:04:28 +0100,
  Joachim Glauche <ruby-forum-incoming@andreas-s.net> wrote:

> Is there any pending work in current trunk? (r2843)

There is no pending work for the next release.
All works will be done after the next release.

> Kouhei, will it be possible for you and the main dev team to keep News 
> file in trunk with the most important/summarized news updated? I could 
> parse all the Changelog files and put them into the news file, but the 
> that'll gonna be huge amount of changes since last release.

Here are important changes that are remembered now:

  * Ruby/GLib: Improved main loop polling. I hope this
    changes will work well (no polling) on Windows too but I
    can't test it.

  * Ruby/GLib: Improved callback handling from non Ruby
    thread. I hope this changes will work well on Windows
    too but I can't test it.

    This changes breaks API. Sjoerd, you need to call
    rbgutil_start_callback_dispatch_thread() in your
    GStreamer bindings. Sorry.

 (* Ruby/GStreamer: Worked with GStreamer >= 0.10.x but doesn't
    completed yet.)

 (* Ruby-GNOME2 can be builded with ruby 1.9.0 but doesn't
    work well.)


And some important bug fixes and new features will be found
in ChangeLog. I hope that you include contributer names of
the next release in NEWS. It's very important.


Thanks,
--
kou

Kouhei Sutou wrote:

> And some important bug fixes and new features will be found
> in ChangeLog. I hope that you include contributer names of
> the next release in NEWS. It's very important.
Yes, no problem. Just if you do something big, write in what is done and 
the contributor name into NEWS file and commit it.

I think it's less work than searching all the Changelog files for big 
changes upon every release.


Those changes are all made by you or other contributors?

Am Freitag, den 14.03.2008, 22:28 +0900 schrieb Kouhei Sutou:

>  (* Ruby/GStreamer: Worked with GStreamer >= 0.10.x but doesn't
>     completed yet.)

Does this mean, that GStreamer is now a part of RubyGnome again? If so:
nice!

Cheers, detlef

Hi,

In <6be0505c0a4fe9de754c1bc0173a3d1e@ruby-forum.com>
  "Re: [ruby-gnome2-devel-en] Release manager" on Fri, 14 Mar 2008 
15:07:26 +0100,
  Joachim Glauche <ruby-forum-incoming@andreas-s.net> wrote:

> > And some important bug fixes and new features will be found
> > in ChangeLog. I hope that you include contributer names of
> > the next release in NEWS. It's very important.
> Yes, no problem. Just if you do something big, write in what is done and 
> the contributor name into NEWS file and commit it.

OK, the release manager. :)

> I think it's less work than searching all the Changelog files for big 
> changes upon every release.

I think so but I want you to search ChangeLog because I want
you to add contributer names even if their contribution is
very small. It may be small but contribution itself is very
big for us.

> Those changes are all made by you or other contributors?

Maybe me. If you find other contributor names in ChangeLog,
please add them to NEWS.


Thanks,
--
kou

Hi,

In <1205504139.13720.29.camel@datengrab>
  "Re: [ruby-gnome2-devel-en] Release manager" on Fri, 14 Mar 2008 
15:15:39 +0100,
  Detlef Reichl <detlef.reichl@gmx.org> wrote:

> >  (* Ruby/GStreamer: Worked with GStreamer >= 0.10.x but doesn't
> >     completed yet.)
> 
> Does this mean, that GStreamer is now a part of RubyGnome again? If so:
> nice!

It will be true but it may not be true in the next
release. Because it's not completed yet, the release manager
may decide that the next release doesn't include it.


Thanks,
--
kou

Hi,

In <1205330733.8213.23.camel@plop>
  "Re: [ruby-gnome2-devel-en] Release manager" on Wed, 12 Mar 2008 
15:05:33 +0100,
  Pascal Terjan <pterjan@linuxfr.org> wrote:

> > # But applying an account for GNOME infrastructure is a bit
> > # bother for me...
> 
> It's supposed to be easier now
> http://blogs.gnome.org/ovitters/2007/09/29/mango-gone-live/

I knew that. I want to use 'kou' for account name because
it's my account name that I always use. But I can't use
that. (Yes, this is a small problem.)


Thanks,
--
kou

Hi,

In <734B4413-2B8E-403A-8153-6CEF2F2A160C@imendio.com>
  "Re: [ruby-gnome2-devel-en] Release manager" on Wed, 12 Mar 2008 
15:08:01 +0100,
  Mikael Hallendal <micke@imendio.com> wrote:

> > move to there.
> 
> Wonderful, I got some pings yesterday in #gnome-ruby2 and on Jabber  
> from people who liked the idea.

Is there any auto-build support on the GNOME infrastructure?

> > # But applying an account for GNOME infrastructure is a bit
> > # bother for me...
> 
> I can help with getting accounts sorted out for people who need them.  
> And hopefully (as Pascal wrote in a reply), things are working better  
> these days.

Thanks.
If we decide to move to the GNOME infrastructure, could you
help the Ruby-GNOME2 subversion repository migration?


--
kou

Kouhei Sutou wrote:

>> Those changes are all made by you or other contributors?
> 
> Maybe me. If you find other contributor names in ChangeLog,
> please add them to NEWS.

Kouhei,

Please take a short look on updated NEWS file before I finally tag 
current trunk as 0.17.0.

I hope I didn't miss anything/anybody.

Thanks!

On Wed, Mar 19, 2008 at 03:47:43PM +0100, Joachim Glauche wrote:
> >> Those changes are all made by you or other contributors?
> > 
> > Maybe me. If you find other contributor names in ChangeLog,
> > please add them to NEWS.
> 
> Please take a short look on updated NEWS file before I finally tag 
> current trunk as 0.17.0.
> 
> I hope I didn't miss anything/anybody.

My 2 cents:
Since Ruby/GStreamer was dropped from the project in the 0.16.0 release,
I wouldn't mention the main change for it anymore.  It is confusing.
I would remove 15--17 too, since it is addressed to Sjoerd specifically 
;)
Rest seems fine.

Regards,
Paul

--
PhD Student @ Eindhoven                     | email: paul@luon.net
University of Technology, The Netherlands   | JID: paul@luon.net

Hi,

In <4565bff0edcf1a7f0105e6edfa734127@ruby-forum.com>
  "Re: [ruby-gnome2-devel-en] Release manager" on Wed, 19 Mar 2008 
15:47:43 +0100,
  Joachim Glauche <ruby-forum-incoming@andreas-s.net> wrote:

> >> Those changes are all made by you or other contributors?
> > 
> > Maybe me. If you find other contributor names in ChangeLog,
> > please add them to NEWS.
> 
> Please take a short look on updated NEWS file before I finally tag 
> current trunk as 0.17.0.
> 
> I hope I didn't miss anything/anybody.

I prefer to Masao's format like:

  * Ruby/GLib
      - Support GLib+-2.10 APIs. [Kouhei Sutou, Masao Mutoh]
      - Fix segfaults related GC with signal handlers. [Guillaume 
Cottenceau, K
ouhei Sutou]
      ...

  * Ruby/ATK
      - Support ATK-1.12 APIs. [Masao Mutoh]

  * ...

But it's OK for now. This is the first release for us. We
can improve our release process step by step.

# Supported version information may be useful.


I find a important change for convenience notation:

  glib/ChangeLog:
  2007-08-08  Kouhei Sutou  <kou@cozmixng.org>

          * src/rbgobj_enums.c: supported convenience GEnum and GFlags
          notation. e.g.:
            GLib::UTF8.normalize(utf8, GLib::NormalizeMode::NFD)
            ->
            GLib::UTF8.normalize(utf8, :nfd)

            key_file.load_from_data(data,
                                    GLib::KeyFile::KEEP_COMMENTS |
                                    GLib::KeyFile::KEEP_TRANSLATIONS)
            ->
            key_file.load_from_data(data, [:keep_contents, 
:keep_translations])


Thanks,
--
kou

Kouhei Sutou wrote:

>   * Ruby/GLib
>       - Support GLib+-2.10 APIs. [Kouhei Sutou, Masao Mutoh]
>       - Fix segfaults related GC with signal handlers. [Guillaume 
> Cottenceau, K
> ouhei Sutou]
>       ...
> 
>   * Ruby/ATK
>       - Support ATK-1.12 APIs. [Masao Mutoh]
> 
>   * ...

Yes, but I'm not the Maintainer and there are a lot of changes. I for 
myself cannot decide for each change which will make it to the NEWS 
file; for this I would require to know the changes in detail.

We can keep the old format for next releases. As I suggested, please 
update the NEWS file for changes in upcoming versions if you do big or 
noticeable changes, including contributors.

> # Supported version information may be useful.
Did anything change?

> I find a important change for convenience notation:
> 
>   glib/ChangeLog:
>   2007-08-08  Kouhei Sutou  <kou@cozmixng.org>
> 
>           * src/rbgobj_enums.c: supported convenience GEnum and GFlags
>           notation. e.g.:
>             GLib::UTF8.normalize(utf8, GLib::NormalizeMode::NFD)
>             ->
>             GLib::UTF8.normalize(utf8, :nfd)
> 
>             key_file.load_from_data(data,
>                                     GLib::KeyFile::KEEP_COMMENTS |
>                                     GLib::KeyFile::KEEP_TRANSLATIONS)
>             ->
>             key_file.load_from_data(data, [:keep_contents, 
> :keep_translations])

Ok, I'll add it.

>  Please take a short look on updated NEWS file before I finally tag
>  current trunk as 0.17.0.

Back in last summer, I began adding missing 2.12 GTK+ symbols. The
2.12 version of GTK+ was not released, so I used this form of macro:

#if GTK_CHECK_VERSION(2,11,0)

Because the rest of the bindings normally check for the stable version
(e.g. check for "2,10,0" for example), I think my 2,11,0 checks might
be changed to 2,12,0 for the sake of orthogonality - but I'm not
changing it for the moment, waiting for comments.

Also, the NEWS file doesn't mention the fact that rg2 now partially
supports new symbols in 2.12 (GtkRecentAction,  GtkTextBuffer,
GdkDisplay, GtkTreeViewColumn, GtkStock, GtkWidget, GtkScaleButton,
GtkTreeView, GtkVolumneButton,
GtkTooptop and GtkTextMark only). Is it intentional because the
support is only partial, or maybe just something forgotten?

Before tagging to 0.17.0, do you want to call for tests? It might be
less painful to fix bugs in trunk rather to do it both in trunk and in
the branch; as for myself, I have recently checked the SVN, and found
nothing wrong with it so far.

Finally, I think the personal message to Sjoerd has little to do in
the NEWS file, because that file is meant to be read by all developers
using rg2. It is too specific/personal for the NEWS file.

--
Guillaume Cottenceau - http://zarb.org/~gc/

Guillaume Cottenceau wrote:
> Also, the NEWS file doesn't mention the fact that rg2 now partially
> supports new symbols in 2.12 (GtkRecentAction,  GtkTextBuffer,
> GdkDisplay, GtkTreeViewColumn, GtkStock, GtkWidget, GtkScaleButton,
> GtkTreeView, GtkVolumneButton,
> GtkTooptop and GtkTextMark only). Is it intentional because the
> support is only partial, or maybe just something forgotten?

In my opinion, this should belong to the NEWS file (which is WIP of 
course). Because I guess this is not the only feature missing credit in 
the NEWS file, could you please add that and your ideas to the file?

> Before tagging to 0.17.0, do you want to call for tests? It might be
> less painful to fix bugs in trunk rather to do it both in trunk and in
> the branch; as for myself, I have recently checked the SVN, and found
> nothing wrong with it so far.

Everything works for me at in current trunk, but please do some tests 
too before we release 0.17.

If possible I need someone who can test it on the win32 platforms. It 
compiles on mingw, but I couldn't install on another windows machine 
yet.
I'll try again later, but working with Windows consumes much more time 
on many tasks.
We may consider to release windows binaries separately when this is 
blocking the release, which shouldn't wait more than 2 weeks from now 
(unless we find some mayor bugs meanwhile).

> Finally, I think the personal message to Sjoerd has little to do in
> the NEWS file, because that file is meant to be read by all developers
> using rg2. It is too specific/personal for the NEWS file.

Was just copy+pasted by me from post by Kouhei. I think this should be 
removed in news file too.

> The Ruby-GNOME2 project lacks human resources.

Hi there,

although I do not know C and thus will always be rather
limited in my ability to help, I will try my best to help
with the wiki (documentation) effort and similar.

Personally I use SVN checkouts of ruby-gnome and I am very
happy with them so far. I do compile gtk/glib/atk etc.. from
 source, which also means that sometimes things break here
(like glib-2.16.1 makes a few problems compared to 2.14.4
here for me) so my plattform is not very stable -
sometimes I break ruby-gnome too accidentally, especially
gtksourceview related. ( I <3 gtksourceview )

I think I would not be able to be a reliable maintainer due to
several reasons, but I try my best to help out others.

A Sidenote: Maybe if there are a handful of people interested
in a channel specifically aimed for ruby and gnome/gtk? for
ruby and qt/kde it exists on freenode called #kde-ruby
(But we have the much better specific ruby documentation,
thanks to the wiki and all the people who worked on it :-) )

Hi,

In <a568133042ae5943b6c9ad1ec8241e9a@ruby-forum.com>
  "Re: [ruby-gnome2-devel-en] Release manager" on Wed, 19 Mar 2008 
22:29:20 +0100,
  Marc Heiler <ruby-forum-incoming@andreas-s.net> wrote:

> > The Ruby-GNOME2 project lacks human resources.
> 
> although I do not know C and thus will always be rather
> limited in my ability to help, I will try my best to help
> with the wiki (documentation) effort and similar.

Great!
I'll send you an account for write access to the Wiki.

> Personally I use SVN checkouts of ruby-gnome and I am very
> happy with them so far. I do compile gtk/glib/atk etc.. from
>  source, which also means that sometimes things break here
> (like glib-2.16.1 makes a few problems compared to 2.14.4
> here for me) so my plattform is not very stable -
> sometimes I break ruby-gnome too accidentally, especially
> gtksourceview related. ( I <3 gtksourceview )

If you find some compile errors, please report them.

> I think I would not be able to be a reliable maintainer due to
> several reasons, but I try my best to help out others.

If you need write access to the Subversion repository, I'll
add you to the developers. If you want to work on
documentation in the Subversion repository (e.g. updating
NEWS, README and so on), you need write access.


Thanks,
--
kou

Hi,

In <20080320.063817.1071258630808802456.kou@cozmixng.org>
  "Re: [ruby-gnome2-devel-en] Release manager" on Thu, 20 Mar 2008 
06:38:17 +0900 (JST),
  Kouhei Sutou <kou@cozmixng.org> wrote:

>   Marc Heiler <ruby-forum-incoming@andreas-s.net> wrote:
> 
> > > The Ruby-GNOME2 project lacks human resources.
> > 
> > although I do not know C and thus will always be rather
> > limited in my ability to help, I will try my best to help
> > with the wiki (documentation) effort and similar.
> 
> Great!
> I'll send you an account for write access to the Wiki.

Marc, could you tell me your E-mail address?


Thanks,
--
kou

On Wed, Mar 19, 2008 at 10:29:20PM +0100, Marc Heiler wrote:
> A Sidenote: Maybe if there are a handful of people interested
> in a channel specifically aimed for ruby and gnome/gtk? for
> ruby and qt/kde it exists on freenode called #kde-ruby
> (But we have the much better specific ruby documentation,
> thanks to the wiki and all the people who worked on it :-) )

On GIMPNet/GNOMENet, there is the #ruby-gnome2 channel.
See also:
http://ruby-gnome2.sourceforge.jp/hiki.cgi?irc

Paul

--
PhD Student @ Eindhoven                     | email: paul@luon.net
University of Technology, The Netherlands   | JID: paul@luon.net

Hi,

In <c29a21c11d0164748618ea716ca1286a@ruby-forum.com>
  "Re: [ruby-gnome2-devel-en] Release manager" on Wed, 19 Mar 2008 
16:15:00 +0100,
  Joachim Glauche <ruby-forum-incoming@andreas-s.net> wrote:

> > # Supported version information may be useful.
> Did anything change?

For Ruby/Poppler, 0.6.2 was supported:

poppler/ChangeLog:
  2007-11-11  Kouhei Sutou  <kou@cozmixng.org>

          * README: updated supported poppler-glib version: 0.5.2 - 
0.6.2.

For Ruby/GTK+, Guillaume said about it. (The status page(*)
on the Wiki isn't updated yet.)

(*) http://ruby-gnome2.sourceforge.jp/hiki.cgi?Status+of+Ruby%2FGTK


Thanks,
--
kou

Hi,

In <dc3bf8580803191015n28afaedat46b89521c652870b@mail.gmail.com>
  "Re: [ruby-gnome2-devel-en] Release manager" on Wed, 19 Mar 2008 
18:15:32 +0100,
  "Guillaume Cottenceau" <gcottenc@gmail.com> wrote:

> Because the rest of the bindings normally check for the stable version
> (e.g. check for "2,10,0" for example), I think my 2,11,0 checks might
> be changed to 2,12,0 for the sake of orthogonality - but I'm not
> changing it for the moment, waiting for comments.

Please change.


Thanks,
--
kou

15 mar 2008 kl. 03.20 skrev Kouhei Sutou

Hi,

Sorry for slow reply, was traveling during the week.

>>>> This will bring the project closer to the rest of the community, as
>
> Is there any auto-build support on the GNOME infrastructure?

I'm not sure if there are but I can't recall I've seen that, it might
be possible to setup though.

>>> # But applying an account for GNOME infrastructure is a bit
>>> # bother for me...
>>
>> I can help with getting accounts sorted out for people who need them.
>> And hopefully (as Pascal wrote in a reply), things are working better
>> these days.
>
> Thanks.
> If we decide to move to the GNOME infrastructure, could you
> help the Ruby-GNOME2 subversion repository migration?

I can definitely help get the right people involved, I don't have the
admin rights to do the job myself though.

Cheers,
   Micke

--
Imendio AB, http://www.imendio.com

Hi,

In <F10EEC27-542D-4BDA-8C3D-9DC2B7F6001C@imendio.com>
  "Re: [ruby-gnome2-devel-en] Release manager" on Sat, 22 Mar 2008 
13:07:25 +0100,
  Mikael Hallendal <micke@imendio.com> wrote:

> Sorry for slow reply, was traveling during the week.

No problem.

> > Is there any auto-build support on the GNOME infrastructure?
> 
> I'm not sure if there are but I can't recall I've seen that, it might  
> be possible to setup though.

Ruby-GNOME2 supports some GTK+ versions. If we can check
building with all supported version, it will be very useful.

> > If we decide to move to the GNOME infrastructure, could you
> > help the Ruby-GNOME2 subversion repository migration?
> 
> I can definitely help get the right people involved, I don't have the  
> admin rights to do the job myself though.

OK. Thanks!

--
kou

On Fri, Mar 14, 2008 at 10:28:44PM +0900, Kouhei Sutou wrote:
>  (* Ruby/GStreamer: Worked with GStreamer >= 0.10.x but doesn't
>     completed yet.)

I just checked out the new ruby-gnome2 from SVN to see what my bindings 
needed
to change to work with them.. Only to discover that suddenly and 
completely
seperate from my ruby-gstreamer0.10 bindings the Ruby/GStreamer stuff 
has been
updated to 0.10...

This is a big WASTE of effort. It seems they have mostly redone the work 
i
already did a few years ago. Now i don't really care if other people 
waste
their time, but i don't like to waste my time on doing the same things 
as
others.

Having two seperate gstreamer 0.10 bindings is just ridicoulous and 
stupid. Not
only is it bad for users (2 bindings, which one should be used). It 
again
wastes developer effort (which we're already short on), and  the new 
updated
bindings are likely to repeat bugs that i've fixed a long time ago in 
mine. I
had a quick look in the source and i can easily point out various issues 
that i
fixed a long time ago.

IMHO we should get the two efforts merged ASAP (There should be only 
ever have
been one effort in the first place, but oh well).. What was the 
rationale of
doings this anyways, i'm pretty sure people know about my bindings. And 
i'd hope
the ruby-gnome2 team doesn't have NIH syndrome.

Now i've initially done my bindings outside of the main tree because of 
various
reasons discussed a long long time ago. The main reason for that still 
exists,
i think it's very bad from a release management pov. that all the 
modules are
tied together. Releasing everything as seperate lean packages has the 
advantage
of making releases much easier to do and much less effort for 
distributions.
Unless that's changed my opinion will stay the same: I think that it is 
in
the gstreamer bindings best interest to keep seperate from the main 
bunch.

If we can change to a more sane releases and release everything as
seperate package, i'm happy to merge my bindings back into the main 
repository.
In which case i guess i'll just have to live with the sf's horrible 
bugtracking
system (unless we move to gnome, hint hint). If not, then oh well, 
that's live.
but we should stop wasting eachothers time by doing the same work and 
find some
middleground to get stuff merged.

Very much unamused,
  Sjoerd
--
The function of the expert is not to be more right than other people,
but to be wrong for more sophisticated reasons.
    -- Dr. David Butler, British psephologist

Hi,

In <20080325115712.GA31107@spring.luon.net>
  "Re: [ruby-gnome2-devel-en] Release manager" on Tue, 25 Mar 2008 
12:57:12 +0100,
  Sjoerd Simons <sjoerd@luon.net> wrote:

> IMHO we should get the two efforts merged ASAP (There should be only ever have
> been one effort in the first place, but oh well).. What was the rationale of
> doings this anyways, i'm pretty sure people know about my bindings. And i'd hope
> the ruby-gnome2 team doesn't have NIH syndrome.

NIH syndrome?

I tried to contribute your bindings (not the bindings in the
Ruby-GNOME2 repository) and submitted a patch two years
ago. But the patch was derelict until two days ago. So I
understood your bindings are not maintained. This is the
reason why I started to updated Ruby/GStreamer.


> If we can change to a more sane releases and release everything as
> seperate package, i'm happy to merge my bindings back into the main repository.

If you want to release it as a separate package, you can
do. But Ruby/GStreamer may depend on unreleased Ruby/GLib.


Thanks,
--
kou

On Tue, Mar 25, 2008 at 11:17:45PM +0900, Kouhei Sutou wrote:
> > hope the ruby-gnome2 team doesn't have NIH syndrome.
> 
> NIH syndrome?

> I tried to contribute your bindings (not the bindings in the
> Ruby-GNOME2 repository) and submitted a patch two years
> ago. But the patch was derelict until two days ago. So I
> understood your bindings are not maintained. This is the
> reason why I started to updated Ruby/GStreamer.

I haven't had a lot of time for them that's true and i never made a lot 
of time
because there weren't big issues with them. Otoh still you could have 
asked me
about my plans first before starting a new effort (i would have been 
very happy
to give you svn access). And even that is not so bad, but you really 
should
have pulled my bindings into the repository instead of ignoring 
everything i
already did. And thus set yourself up to hit the same issues that are 
already
fixed in my bindings. I can already tell you that the in the current 
state
Ruby/Gstreamer will get deadlocks and potentially crashes if used for 
anything
but a non-trivial program.

ruby-gstreamer0.10 might be undermaintained, but at least it's a stable 
base to
build upon.

> > If we can change to a more sane releases and release everything as seperate
> > package, i'm happy to merge my bindings back into the main repository.
>
> If you want to release it as a separate package, you can do.

I'm interested in what your ideas are here. Does this mean you agree 
with not
including Ruby/Gstreamer in ruby-gnome2 release but have it go seperate. 
Or do
include it in the big ruby-gnome2 release, but also allow it to seperate
releases inbetween ?

> But Ruby/GStreamer may depend on unreleased Ruby/GLib.

It shouldn't be a big problem to have Ruby/Gstreamer and/or 
ruby-gstreamer0.10
always working with the last release version of Ruby/GLib...

  Sjoerd
--
The biggest difference between time and space is that you can't reuse 
time.
    -- Merrick Furst

Hi,

In <20080325150626.GA7078@spring.luon.net>
  "Re: [ruby-gnome2-devel-en] Release manager" on Tue, 25 Mar 2008 
16:06:26 +0100,
  Sjoerd Simons <sjoerd@luon.net> wrote:

> have pulled my bindings into the repository instead of ignoring everything i
> already did.

Your bindings have several problems to use in the
Ruby-GNOME2 Project Team: Non-consistent coding style, low
Ruby/GLib integration (e.g. rbgst_new_gstobject), out of
Ruby-GNOME2 Project's naming convention and so on.

>              And thus set yourself up to hit the same issues that are already
> fixed in my bindings. I can already tell you that the in the current state
> Ruby/Gstreamer will get deadlocks and potentially crashes if used for anything
> but a non-trivial program.

Please tell us them.

And please tell us a feature list that your bindings has
but ours doesn't have.


> > > If we can change to a more sane releases and release everything as seperate
> > > package, i'm happy to merge my bindings back into the main repository.
> >
> > If you want to release it as a separate package, you can do.
> 
> I'm interested in what your ideas are here. Does this mean you agree with not
> including Ruby/Gstreamer in ruby-gnome2 release but have it go seperate. Or do
> include it in the big ruby-gnome2 release, but also allow it to seperate
> releases inbetween ?

I prefer to the later if Joachim says OK.

Ruby/GStreamer's version number will be like the followings:

  * 0.17.0: with Ruby-GNOME2 0.17.0 release
  * 0.17.1: separated release. It will depend on Ruby/GLib 0.17.0.
  * 0.17.2: separated release. It will depend on Ruby/GLib 0.17.0.
  * ...
  * 0.18.0: with Ruby-GNOME2 0.18.0 release
  * 0.18.1: separated release. It will depend on Ruby/GLib 0.18.0.
  * 0.18.2: separated release. It will depend on Ruby/GLib 0.18.0.
  * ...


Thanks,
--
kou

Kouhei Sutou wrote:
>> I'm interested in what your ideas are here. Does this mean you agree with not
>> including Ruby/Gstreamer in ruby-gnome2 release but have it go seperate. Or do
>> include it in the big ruby-gnome2 release, but also allow it to seperate
>> releases inbetween ?
> 
> I prefer to the later if Joachim says OK.

We can pack the gstreamer from current trunk into the release for now. 
It's experimental, not stable.

Which version you chose to officially support is up to Kouhei. For 
releasing with the package it need to be maintained and should become 
complete and stable in near future.

On Wed, Mar 26, 2008 at 08:21:04PM +0900, Kouhei Sutou wrote:
> Ruby-GNOME2 Project Team: Non-consistent coding style,
It's moving over to my own coding style, but that's easy to change back 
to the
``ruby-gnome2'' coding style as needed. Is there a document describing 
what
this style exactly is ? (Exept for the emacs style file)

> low Ruby/GLib integration (e.g. rbgst_new_gstobject)

Hmm, exactly the same function is in your gstreamer bindings and afaik 
stems
from the original 0.8 bindings. I don't see why this means low 
integration.

> Ruby-GNOME2 Project's naming convention and so on.

Because of the gst010 name or ? That was basically there to allow 
parallel
installability of the 0.8 and 0.10 bindings.

It seems that most of these things are style issues though and not 
fundamental
issues with the implemtation.

> > And thus set yourself up to hit the same issues that are
> > already fixed in my bindings. I can already tell you that the
> > in the current state  Ruby/Gstreamer will get deadlocks and potentially
> > crashes if used for anything but a non-trivial program.
> Please tell us them.

I didn't do a full comparison but some of the things i noticed:

* The bin_add doesn't take into account that the bin takes over 
ownership if
  GstObjects are floating.
* You expose gst_object_sink to the ruby layers, which your really not
  supposed too. As soon as you wrap an GstObject you should take 
ownership and
  sink any floating object (which also solves the previous issue). And 
crashes
  with playbin which basically behaves like a bin.
* You don't cope with the fact that state changes to a ``lower'' state 
are
  synchronous (the call will block), but to change state several ruby 
callbacks
  might be called. Which won't work as your in a blocking 
gst_element_set_state
  call. Hence your program will deadlock.

And i'm sure there will be more if i go in for a closer look.

> And please tell us a feature list that your bindings has
> but ours doesn't have.

Actually tested and working in non-trivial programs is the main feature.
Gstreamer is somewhat more complex then most other things (mostly 
because its
heavy use of threads and the way ruby (doesn't) handle them), you can't 
naively
bind it and expect things to work.

> 
>   * 0.18.2: separated release. It will depend on Ruby/GLib 0.18.0.
>   * ...

I think that makes sense. What i'd like to see if we do things this way. 
Is
that say 0.17.0 is both released as one big tarball and a set of smaller 
ones.
For distributions (like say Debian) it would be great to have one source
tarball per component instead of the big blob with everything. Let's see 
what
Joachim thinks about this all :)

I'll see if i can get a few hours this weekend to create a set of 
patches to
merge my binding into yours. I still think you've wasted a lot of effort 
by
doing things this way, but it's more important to have one good solid 
set of
gstreamer bindings then two different ones just because the maintainers 
can't
work out their differences :)

For now, please hold the Ruby-Gnome2 0.17.0 release (with gstreamer) 
untill
these issues are resolved. Or release 0.17.0 without gstreamer and have 
a
seperate gstreamer 0.17.1 release later on. I don't think it's 
benificial for
anyone to have a release of Ruby/Gstreamer in its current state.

  Sjoerd
--
"I gained nothing at all from Supreme Enlightenment, and for that very
reason it is called Supreme Enlightenment."
    -- Gotama Buddha

Hi,

Am Mittwoch, den 26.03.2008, 20:21 +0900 schrieb Kouhei Sutou:

> 
IMHO thats not usefull, cause there is no way for bugfix releases (wich
we sould do in the future). The Ruby-GNOME version numbering should go
up to four numbers and for GStreamer inbetween releases the nano Version
sould be used. In this way we keep the numbering consistent.

* 0.17.0.0: with Ruby-GNOME2 0.17.0.0 release
* 0.17.0.1: separated release. It will depend on Ruby/GLib 0.17.0.0
* 0.17.0.2: separated release. It will depend on Ruby/GLib 0.17.0.0
* 0.17.1.0: Ruby-GNOME bugfix release. It will depend on Ruby/GLib
0.17.1.0
* 0.17.1.1: separated release. It will depend on Ruby/GLib 0.17.1.0


Cheers, detlef


Sjoerd Simons wrote:
>>   * 0.18.2: separated release. It will depend on Ruby/GLib 0.18.0.
>>   * ...
> 
> I think that makes sense. What i'd like to see if we do things this way. 
> Is
> that say 0.17.0 is both released as one big tarball and a set of smaller 
> ones.
> For distributions (like say Debian) it would be great to have one source
> tarball per component instead of the big blob with everything. Let's see 
> what
> Joachim thinks about this all :)

Write a script which does something like that for debian packages if you 
want. But releasing every single component as source tarball doesn't 
make any sense. Installing Ruby-Gnome would be like "sorry, you need to 
download this tarball in order to continue" all the time.

What could be done is to separate core packages and additional packages. 
But not 24 packages.

> For now, please hold the Ruby-Gnome2 0.17.0 release (with gstreamer) 
> untill
> these issues are resolved. Or release 0.17.0 without gstreamer and have 
> a
> seperate gstreamer 0.17.1 release later on. I don't think it's 
> benificial for
> anyone to have a release of Ruby/Gstreamer in its current state.

I really would like to release 0.17 soon. But I'll wait to make my 
decision if and which version to release until you guys finally come to 
a conclusion which code base to work on with.
Please don't let this take too long.

Thanks,
  Joachim

Hi,

In <20080326121914.GA8718@spring.luon.net>
  "Re: [ruby-gnome2-devel-en] Release manager" on Wed, 26 Mar 2008 
13:19:14 +0100,
  Sjoerd Simons <sjoerd@luon.net> wrote:

> > Your bindings have several problems to use in the
> > Ruby-GNOME2 Project Team: Non-consistent coding style,
> 
> It's moving over to my own coding style, but that's easy to change back to the
> ``ruby-gnome2'' coding style as needed. Is there a document describing what
> this style exactly is ? (Exept for the emacs style file)

If you don't want to see
http://svn.ruby-lang.org/repos/ruby/trunk/misc/ruby-style.el,
see other C sources in Ruby-GNOME2 Project.

> > low Ruby/GLib integration (e.g. rbgst_new_gstobject)
> 
> Hmm, exactly the same function is in your gstreamer bindings and afaik stems
> from the original 0.8 bindings. I don't see why this means low integration.

We should use GOBJ2RVAL.

I use it just for now because I'm working step by step. It
will be removed in the feature. But your bindings completely
use it. It will not be removed from your bindings in the
feature.

> > Ruby-GNOME2 Project's naming convention and so on.
> 
> Because of the gst010 name or ? That was basically there to allow parallel
> installability of the 0.8 and 0.10 bindings.

e.g.: RGST_* macro names for converting to Ruby object from
GStreamer object. We should use XXX2YYY name for those macro.

The origin of naming conversion is Ruby/GStreamer for
GStreamer 0.8. We should fix it in the feature.

> It seems that most of these things are style issues though and not fundamental
> issues with the implemtation.

No. It's important because WE are working TOGETHER.

> * The bin_add doesn't take into account that the bin takes over ownership if
>   GstObjects are floating.
> * You expose gst_object_sink to the ruby layers, which your really not
>   supposed too. As soon as you wrap an GstObject you should take ownership and
>   sink any floating object (which also solves the previous issue). And crashes
>   with playbin which basically behaves like a bin.

OK. They will be fixed.

> * You don't cope with the fact that state changes to a ``lower'' state are
>   synchronous (the call will block), but to change state several ruby callbacks
>   might be called. Which won't work as your in a blocking gst_element_set_state
>   call. Hence your program will deadlock.

Do you have a test case?


Thanks,
--
kou

On Wed, Mar 26, 2008 at 10:14:17PM +0900, Kouhei Sutou wrote:
> > >   "Re: [ruby-gnome2-devel-en] Release manager" on Tue, 25 Mar 2008
> > what this style exactly is ? (Exept for the emacs style file)
> 
> If you don't want to see
> http://svn.ruby-lang.org/repos/ruby/trunk/misc/ruby-style.el,

I did see it. But i'm not an emacs user and it's not so easy to figure 
out what
it means if you don't speak emacs/lisp :)

> see other C sources in Ruby-GNOME2 Project.

Ok. Reverse engineering coding style is always a big nasty though :)

> > > low Ruby/GLib integration (e.g. rbgst_new_gstobject)
> > 
> > Hmm, exactly the same function is in your gstreamer bindings and afaik stems
> > from the original 0.8 bindings. I don't see why this means low integration.
> 
> We should use GOBJ2RVAL.

Hmm, well GstObjects need a bit of special handling. See the points 
about
floating i made earlier. If we can get GOBJ2RVAL to support sinking 
objects
where needed then that could work.

I looked over at the python bindings a bit and their gobject bindings 
allow one
to register sink_handlers per object type. (As both GTK objects and 
GstObjects
have their own _sink methods). Currently the Ruby Gtk bindings do sink 
stuff on
their own too, so maybe that could be synced.

> I use it just for now because I'm working step by step. It
> will be removed in the feature. But your bindings completely
> use it. It will not be removed from your bindings in the
> feature.

Well just as much as yours and nothing that can't be changed in either 
:)
Basically i'm just wondering why you took the old 0.8 bindings as a 
starting
point instead of my 0.10 ones.. But we don't have to discuss that 
further if
you don't want too.

> 
> > It seems that most of these things are style issues though and not
> > fundamental issues with the implemtation.
> 
> No. It's important because WE are working TOGETHER.

Exactly. Which is what i've been saying all along. And why i mentioned 
in my
previous mail that i'll spent some time next weekend to create a 
patchset to
merge the two.

> > * The bin_add doesn't take into account that the bin takes over ownership if
> >   GstObjects are floating.
> > * You expose gst_object_sink to the ruby layers, which your really not
> >   supposed too. As soon as you wrap an GstObject you should take ownership
> >   and sink any floating object (which also solves the previous issue). And
> >   crashes
> >   with playbin which basically behaves like a bin.
> 
> OK. They will be fixed.

Nice. I'd still recommend looking at how my bindings cope with these 
things
though :)

> > * You don't cope with the fact that state changes to a ``lower'' state are
> >   synchronous (the call will block), but to change state several ruby
> >   callbacks  might be called. Which won't work as your in a blocking
> >   gst_element_set_state call. Hence your program will deadlock.
>
> Do you have a test case?

Hmm. Not a simple one at this point. Probably the easiest way to do this 
is to
connect to the handoff signal of identity element and then switch the 
pipeline
back and forward to playing continously. I can't come up with one from 
the
top of my head that will hit this case 100%.

Again, have a look at my bindings for a way to fix this or just wait a 
bit for
the merging patchset.

  Sjoerd
--
Given a choice between grief and nothing, I'd choose grief.
    -- William Faulkner

Hi,

In <20080326134707.GB11138@spring.luon.net>
  "Re: [ruby-gnome2-devel-en] Release manager" on Wed, 26 Mar 2008 
14:47:07 +0100,
  Sjoerd Simons <sjoerd@luon.net> wrote:

> > We should use GOBJ2RVAL.
> 
> Hmm, well GstObjects need a bit of special handling. See the points about
> floating i made earlier. If we can get GOBJ2RVAL to support sinking objects
> where needed then that could work.

It can be done in our bindings. I hope you look our bindings
before you say "look my bindings, look my bindings, ...".

Index: test/test_object.rb
===================================================================
--- test/test_object.rb  (revision 2869)
+++ test/test_object.rb  (working copy)
@@ -1,13 +1,6 @@
 class TestObject < Test::Unit::TestCase
   include GstTestUtils

-  def test_floating
-    sink = create_element("fakesink")
-    assert(sink.floating?)
-    sink.sink
-    assert(!sink.floating?)
-  end
-
   def test_name
     sink = create_element("fakesink", "my-fakesink")
     assert_equal("my-fakesink", sink.name)
Index: src/rbgst-object.c
===================================================================
--- src/rbgst-object.c  (revision 2869)
+++ src/rbgst-object.c  (working copy)
@@ -24,21 +24,33 @@

 #define SELF(self) (RVAL2GST_OBJ(self))

+extern VALUE rbgobj_get_value_from_gobject(GObject* gobj, gboolean 
alloc);
+
+static RGConvertTable table = {0};
+
 /* Class: Gst::Object
  * Basis for the GST object hierarchy.
  */

-/*
- * Method: floating?
- *
- * Checks if the Gst::Object::FLAG_FLOATING flag is set on the object.
- *
- * Returns: true if the flag is set, false otherwise.
- */
 static VALUE
-object_is_floating(VALUE self)
+rbgst_object_instance2robj(gpointer instance)
 {
-    return CBOOL2RVAL(GST_OBJECT_IS_FLOATING(SELF(self)));
+    VALUE object;
+
+    object = rbgobj_get_value_from_gobject(instance, FALSE);
+    if (!NIL_P(object))
+  return object;
+
+    object = rbgobj_get_value_from_gobject(instance, TRUE);
+    if (NIL_P(object))
+  return object;
+
+    if (GST_OBJECT_IS_FLOATING(instance)) {
+  gst_object_ref(instance);
+  gst_object_sink(instance);
+    }
+
+    return object;
 }

 static VALUE
@@ -47,23 +59,19 @@
     return CBOOL2RVAL(gst_object_set_name(SELF(self), 
RVAL2CSTR(name)));
 }

-static VALUE
-object_sink(VALUE self)
-{
-    gst_object_sink(SELF(self));
-    return Qnil;
-}
-
 void
 Init_gst_object(void)
 {
     VALUE cGstObject;

+    table.type = GST_TYPE_OBJECT;
+    table.instance2robj = rbgst_object_instance2robj;
+
+    RG_DEF_CONVERSION(&table);
+
     cGstObject = G_DEF_CLASS(GST_TYPE_OBJECT, "Object", mGst);

-    rb_define_method(cGstObject, "floating?", object_is_floating,0);
     rb_define_method(cGstObject, "set_name", object_set_name, 1);
-    rb_define_method(cGstObject, "sink", object_sink, 0);

     G_DEF_SETTERS(cGstObject);

> > I use it just for now because I'm working step by step. It
> > will be removed in the feature. But your bindings completely
> > use it. It will not be removed from your bindings in the
> > feature.
> 
> Well just as much as yours and nothing that can't be changed in either :)

Did you look ours? Ours use GOBJ2RVAL except for we didn't
update. Ours doesn't need to change it because we doesn't
need it.

> Basically i'm just wondering why you took the old 0.8 bindings as a starting
> point instead of my 0.10 ones.. But we don't have to discuss that further if
> you don't want too.

I mentioned that yours have several problems. They are
serious implement design problems for us.

> Nice. I'd still recommend looking at how my bindings cope with these things
> though :)

BTW, do you have a test case for the problem? We can't
commit our fix until we confirm the problem and our fix the
problem.

> top of my head that will hit this case 100%.
As I mentioned above, we can't commit our fix until we
confirm the problem and our fix the problem.

> Again, have a look at my bindings for a way to fix this or just wait a bit for
> the merging patchset.

I hope that you submit test cases with the patchset.


Thanks,
--
kou

Kouhei Sutou wrote:
> Hi,
> We want a release manager who will do the following work:
> 
>   * You will try to build on supported platform that will be
>     decided by you.
>     (e.g. ruby >= 1.8.x, GTK+ >= 2.x.x, Linux, FreeBSD,
>     Windows, MacOSX, ...)
> --
> kou

Which compiler the future Ruby-Gnome2 will use? VC6 or MinGW. Luis 
Lavena is working on the Ruby OCI using MinGW. Although there are still 
some issue on it but it looks promising. So, will the Ruby-Gnome2 will 
provide an installer for windows build with MinGW? I prefer for the 
MinGW solution because it is hard to get VC6 compiler now.

Is there any release manager for windows? Base on the reply, seems like 
nobody have windows box to work on it.

Regards,
Shin Guey

Shin guey Wong wrote:

> Which compiler the future Ruby-Gnome2 will use? VC6 or MinGW. 
I would prefer MinGW. I see no reason to use an outdated compiler.

> Is there any release manager for windows? Base on the reply, seems like 
> nobody have windows box to work on it.

Well basically I've a win32 virtual machine. But it's not running well 
and it's hard to use for me. I didn't get the bindings working on 
another windows machine, yet.

If you want to participate as release manager for windows binaries, 
you're welcome!

Joachim Glauche

Joachim Glauche wrote:
> Shin guey Wong wrote:
> 
>> Which compiler the future Ruby-Gnome2 will use? VC6 or MinGW. 
> I would prefer MinGW. I see no reason to use an outdated compiler.
> 
>> Is there any release manager for windows? Base on the reply, seems like 
>> nobody have windows box to work on it.
> 
> Well basically I've a win32 virtual machine. But it's not running well 
> and it's hard to use for me. I didn't get the bindings working on 
> another windows machine, yet.
> 
> If you want to participate as release manager for windows binaries, 
> you're welcome!
> 
> Joachim Glauche

I am still new to ruby-gnome now. I just compiled the MinGW ruby version 
from Luis Lavena. It is still not really complete yet. Some extension 
doesn't exist/compile like the curse ext, dbm(not sure what is this), 
tcl binding. The readline also doesn't pass the ruby test. I haven't 
tried the entire feature, it is usable in the normal irb mode with 
readline though.

I am trying to compile the ruby-gnome first(the old version downloaded 
from the source forge website, not the trunk src). I still having some 
problem on compiling the ruby gnome now, may be I don't have some 
require library. Still working on it now. (the GLADE for Windows website 
is down..at least I can't download the gtk-dev package from it. I am 
trying to download 1 from teh GTK+ website now)

If I able to compile on windows, I can help to release and test the 
windows binaries.

Regards,
Shin Guey

Shin guey Wong wrote:

> I am trying to compile the ruby-gnome first(the old version downloaded 
> from the source forge website, not the trunk src). I still having some 
> problem on compiling the ruby gnome now, may be I don't have some 
> require library. 
Some modules are not working on win32 environments since.

I would suggest to start with the current trunk because there are many 
changes since 0.16.0.

This guide may be helpful:
http://ruby-gnome2.sourceforge.jp/hiki.cgi?compile_mingw

> Still working on it now. (the GLADE for Windows website 
> is down..at least I can't download the gtk-dev package from it. I am 
> trying to download 1 from teh GTK+ website now)

Yes the link is dead. I'll fix the wiki later.
You can download it here:
http://wingtk.sourceforge.net/

Joachim Glauche wrote:
> This guide may be helpful:
> http://ruby-gnome2.sourceforge.jp/hiki.cgi?compile_mingw
>
> Yes the link is dead. I'll fix the wiki later.
> You can download it here:
> http://wingtk.sourceforge.net/

I am follow the wiki guide to compile the src now. The wingtk seems very 
outdated. I downloaded 1 from the gtk+ website (gtk+-2.12.9-bundle.zip) 
But I failed to compile Glib in ruby-gnome2-all-0.16.0 src.

I will try to download the latest src from the trunk and compile again 
tonight. May be the ruby binding doesn't match the gtk+ version 2.12.9

Regards,
Shin Guey

Here the error message:
(* I take look at the line 292, 293 & 294, there is nothing wrong with 
that so I guess it cannot get the constant or macro in that line).

make[1]: Entering directory 
`/c/Devel/installer3/sandbox/ruby-gnome2-all-0.16.0/glib/src'
gcc -I. -I. 
-Ic:/Devel/installer3/sandbox/ruby_mingw/lib/ruby/1.8/i386-mingw32 -I. 
-DHAVE_RB_DEFINE_ALLOC_FUNC -DHAV