ruby-gnome-devel-en — Ruby-GNOME developer's Mailing List in English.

Re: [ruby-gnome2-devel-en] Re: [ruby-gnome-devel-en] Ruby/GNOME2 suggestions

[Paul v. T. <pa...@lu...>]

On Tue, Sep 13, 2005 at 09:49:21PM +0200, Laurent Sansonetti wrote:
> > > * Some inspects of Gst::Pads are shown as #<#<Class:0x.....>>.
> > 
> 
> This is a bug :)  Please report it with a sample piece of code, so I can fix it.

Attached is the avtest script (written by Sjoerd Simons).  This script
uses the new (and cool) decodebin and shows the two problems we have
with it:

1. The problem mentioned above.: strange to_s results of some pads.
2. If your stack is limited (which is normal, see ulimit -s ), it
   crashes (stack level too deep).

It's not exactly an example script, but once cleaned up (I know it's
messy now) it's a nice media player example.

Usage: avtest <any media file>

> Thanks for the feedback!  I will implement that for the next release.

Thank you as well!

Paul

-- 
Student @ Eindhoven                         | email: pa...@lu...
University of Technology, The Netherlands   | JID: pa...@lu...
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181

Re: [ruby-gnome2-devel-en] Re: [ruby-gnome-devel-en] Ruby/GNOME2 suggestions

[Laurent S. <lau...@gm...>]

Hi Paul & Masao,

On 8/27/05, Masao Mutoh <mu...@hi...> wrote:
> > GStreamer
>=20
> I hope Laurent reply GStreamer's comments below.
>=20
> > * Add alias '>>' to Gst::Pad#link for symmetry with Gst::Element#link.
> >   (This might pose a problem though, because it is not chainable.)

Good idea.

> > * Add alias [](pad) to Gst::Element#get_pad(pad)

Not a good idea because Gst::Bin#[] already exists, and Gst::Bin
inherits from Gst::Element.

> > * Alias Gst::Bin#each_element to Gst::Bin#each.

Good idea.

> > * Add Gst::Element.to_s.

I do not see any descriptive function in the GstElement API to use.=20
If we create such a method what should we return?

> > * Gst::Caps#get_structure but no Gst::Caps#structure

I do not see the point there.  We already have
Gst::Caps#get_structure.  We can not replace it with
Gst::Caps#structure because it takes a parameter, then it violates the
naming rules.

> > * Some inspects of Gst::Pads are shown as #<#<Class:0x.....>>.
>=20

This is a bug :)  Please report it with a sample piece of code, so I can fi=
x it.

Thanks for the feedback!  I will implement that for the next release.

Laurent

Re: [ruby-gnome-devel-en] Ruby/GNOME2 suggestions

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

Hi,

This ML is for Ruby-GNOME, not Ruby-GNOME2,

Join Ruby-GNOME2 develper mailinglist
(ruby-gnome2-devel-en), please.

#This message is CCed to ruby-gnome2-devel-en.

See:
http://sourceforge.net/mail/?group_id=53614


On Fri, 26 Aug 2005 19:32:28 +0200
Paul van Tilburg <pa...@lu...> wrote:

> Hi,
> 
> Having been able to use Ruby/GNOME2 for my job, and because of this I &
> a colleague ran into some issues and got some ideas.  We wrote them down
> and I would like to post them here for discussion, discarding or TODO
> purposes.
> 
> Gdk
> * Let Gdk::Event<type>.new defer to Gdk::Event.new(<type>) with the right type
>   (e.g. Gdk::EventExpose.new -> Gtk::Event.new(Gdk::Event::Type::EXPOSE))
>   It isn't very Rubyish now, you have to do for example:
>   Gdk::EventExpose.new(Gdk::Event::Type::EXPOSE)

You can omit ::Type:: here.

Gdk::EventExpose.new(Gdk::Event::EXPOSE)

How about the events which has plural type like below?
Gdk::EventButton.new(Gdk::Event::BUTTON_PRESS)
Gdk::EventButton.new(Gdk::Event::BUTTON_PRESS1)
Gdk::EventButton.new(Gdk::Event::BUTTON_PRESS2)

> Glib2
> * GLib::IOChannel#shutdown is missing, but IOChannel#close (that has
>   been deprecated) is available.

GLib::IOChannel#close is a wrapper of g_io_channel_shutdown(), not g_io_channel_close().

GLib::IOChannel changes the APIs to follow IO, File of Ruby standard library.
# Sorry for lack of API documents.


> Gtk2
> * Add alias '[]' for Gtk::UIManager#get_widget.

Good idea. I'll add it.

> * Add alias 'size_request=' for Gtk::Widget#set_size_request for
>   symmetry.

Gtk::Widget#set_size_request(width, height) has 2 parameter.
We use "=" parameter which method has A parameter. 
This is one of ruby-gnome2 API rule.

> * Gtk::Dialog#run doesn't call it's own destroy when a block was a
>   provided.  I would've suspected it to be analogous with File.open
>   (if block given, file is closed afterwords automatically, if not,
>   you have to do it yourself)

Sure. This is a bug. I'll fix it.

> * Can't the TreeModel include Enumerable? This would make it much
>   more Rubyish.

Gtk::TreeModel? Hmm. I can't understand your idea. 
I want to know what you use them. 
Could you tell us the details with a simple sample(but executable) ? 

> * Raise an error for Gtk::UIManager when trying to merge /foo/bar when
>   /foo does not exist (this might be a Gtk issue though).

Agreed. I'll fix it.
#you mention Gtk::UIManager#get_widget, doesn't you?

> * Trying to retrieve the ID of a Gtk::Plug when Gtk.init has not been
>   called leads to a segfault, try: Gtk::Plug.new.id.
>   Note that in many more occasions I have encountered that forgetting a
>   Gtk.init leads to a segfault.

It's well know issue. But I don't have good idea to avoid it.
 
> GStreamer

I hope Laurent reply GStreamer's comments below.

> * Add alias '>>' to Gst::Pad#link for symmetry with Gst::Element#link.
>   (This might pose a problem though, because it is not chainable.)
> * Add alias [](pad) to Gst::Element#get_pad(pad)
> * Alias Gst::Bin#each_element to Gst::Bin#each.
> * Add Gst::Element.to_s.
> * Gst::Caps#get_structure but no Gst::Caps#structure
> * Some inspects of Gst::Pads are shown as #<#<Class:0x.....>>.
 
> It's a pity our time (for the job) was up, I would really have liked to
> contribute some stuff, but I am really too busy with a dozen of other
> things.
> I hope these ideas/suggestions are helpful for the future, if not it's
> no bother.  :)

You're welcome ;).

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

[ruby-gnome-devel-en] Ruby/GNOME2 suggestions

[Paul v. T. <pa...@lu...>]

Hi,

Having been able to use Ruby/GNOME2 for my job, and because of this I &
a colleague ran into some issues and got some ideas.  We wrote them down
and I would like to post them here for discussion, discarding or TODO
purposes.

Gdk
* Let Gdk::Event<type>.new defer to Gdk::Event.new(<type>) with the right type
  (e.g. Gdk::EventExpose.new -> Gtk::Event.new(Gdk::Event::Type::EXPOSE))
  It isn't very Rubyish now, you have to do for example:
  Gdk::EventExpose.new(Gdk::Event::Type::EXPOSE)

Glib2
* GLib::IOChannel#shutdown is missing, but IOChannel#close (that has
  been deprecated) is available.

Gtk2
* Add alias '[]' for Gtk::UIManager#get_widget.
* Add alias 'size_request=' for Gtk::Widget#set_size_request for
  symmetry.
* Gtk::Dialog#run doesn't call it's own destroy when a block was a
  provided.  I would've suspected it to be analogous with File.open
  (if block given, file is closed afterwords automatically, if not,
  you have to do it yourself)
* Can't the TreeModel include Enumerable? This would make it much
  more Rubyish.
* Raise an error for Gtk::UIManager when trying to merge /foo/bar when
  /foo does not exist (this might be a Gtk issue though).
* Trying to retrieve the ID of a Gtk::Plug when Gtk.init has not been
  called leads to a segfault, try: Gtk::Plug.new.id.
  Note that in many more occasions I have encountered that forgetting a
  Gtk.init leads to a segfault.

GStreamer
* Add alias '>>' to Gst::Pad#link for symmetry with Gst::Element#link.
  (This might pose a problem though, because it is not chainable.)
* Add alias [](pad) to Gst::Element#get_pad(pad)
* Alias Gst::Bin#each_element to Gst::Bin#each.
* Add Gst::Element.to_s.
* Gst::Caps#get_structure but no Gst::Caps#structure
* Some inspects of Gst::Pads are shown as #<#<Class:0x.....>>.

It's a pity our time (for the job) was up, I would really have liked to
contribute some stuff, but I am really too busy with a dozen of other
things.
I hope these ideas/suggestions are helpful for the future, if not it's
no bother.  :)

Thanks for the great bindings,

Paul

-- 
Student @ Eindhoven                         | email: pa...@lu...
University of Technology, The Netherlands   | JID: pa...@lu...
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181

[ruby-gnome-devel-en] Objects that doesn't destroy?

[DaVinci <da...@es...>]

 Hello all.

 I think I have a problem with ruby-gtk2 and objects that does not
 destroy, like Gtk::TextBuffer or Gtk::ListStore.

 Example: Imagine I have this class:

-------------------------------------------
class Texto < Gtk::ScrolledWindow
	def initialize
		super()
		@view = Gtk.TextView.new
		@buffer = @view.buffer
		add(@view)
	end
end
-------------------------------------------

 This class go inside a Window, and when I destroy window, all widgets
 are destroyed. But @buffer points to a Gtk::TextBuffer object, that it
 is not widget and it is not destroyed (or so I think after using a
 rutine that shows me which objects in ObjectSpace are destroyed or
 not).

 I have tried destroying @buffer adding next code in initialize:

 	@view.signal_connect('destroy') do
		@buffer.destroy
	end

 But with this code, I get a segment fault ([BUG]) when I try to destroy
 window.

 My question is: Is it necessary to destroy buffer or is it destroyed
 automatically by ruby garbage collection?

 I see same behaviour with classes relatives to Gtk::TreeView, like
 Gtk::ListStore, Gtk::TreeSelection, etc...

 Please, Help!!

 Oh, and happy christmas :)

							David

P.D: I have too problems sending messages to the list, so I use ruby
news group to inform of ruby-gnome2 more than I'd like. Sorry for
inconvenience.

Re: [ruby-gnome-devel-en] Objects that doesn't destroy?

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

Hi David,

Here is a mailing list for Ruby-GNOME(1) not Ruby-GNOME2.
Don't send questions for Ruby-GNOME2 here.

And I've already replied same message which you posted here 
at "2004-12-24 21:41".

See:
http://sourceforge.net/mailarchive/forum.php?thread_id=6221350&forum_id=9442

On Fri, 31 Dec 2004 11:33:11 +0100
DaVinci <da...@es...> wrote:

>  Hello all.
> 
>  I think I have a problem with ruby-gtk2 and objects that does not
>  destroy, like Gtk::TextBuffer or Gtk::ListStore.
> 
>  Example: Imagine I have this class:
> 
> -------------------------------------------
> class Texto < Gtk::ScrolledWindow
> 	def initialize
> 		super()
> 		@view = Gtk.TextView.new
> 		@buffer = @view.buffer
> 		add(@view)
> 	end
> end
> -------------------------------------------
> 
>  This class go inside a Window, and when I destroy window, all widgets
>  are destroyed. But @buffer points to a Gtk::TextBuffer object, that it
>  is not widget and it is not destroyed (or so I think after using a
>  rutine that shows me which objects in ObjectSpace are destroyed or
>  not).
> 
>  I have tried destroying @buffer adding next code in initialize:
> 
>  	@view.signal_connect('destroy') do
> 		@buffer.destroy
> 	end
> 
>  But with this code, I get a segment fault ([BUG]) when I try to destroy
>  window.
> 
>  My question is: Is it necessary to destroy buffer or is it destroyed
>  automatically by ruby garbage collection?
> 
>  I see same behaviour with classes relatives to Gtk::TreeView, like
>  Gtk::ListStore, Gtk::TreeSelection, etc...
> 
>  Please, Help!!
> 
>  Oh, and happy christmas :)
> 
> 							David
> 
> P.D: I have too problems sending messages to the list, so I use ruby
> news group to inform of ruby-gnome2 more than I'd like. Sorry for
> inconvenience.
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> ruby-gnome-devel-en mailing list
> rub...@li...
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome-devel-en
> 

[ruby-gnome-devel-en] Objects that doesn't destroy?

[DaVinci <da...@es...>]

 Hello all.

 I think I have a problem with ruby-gtk2 and objects that does not
 destroy, like Gtk::TextBuffer or Gtk::ListStore.

 Example: Imagine I have this class:

-------------------------------------------
class Texto < Gtk::ScrolledWindow
	def initialize
		super()
		@view = Gtk.TextView.new
		@buffer = @view.buffer
		add(@view)
	end
end
-------------------------------------------

 This class go inside a Window, and when I destroy window, all widgets
 are destroyed. But @buffer points to a Gtk::TextBuffer object, that it
 is not widget and it is not destroyed (or so I think after using a
 rutine that shows me which objects in ObjectSpace are destroyed or
 not).

 I have tried destroying @buffer adding next code in initialize:

 	@view.signal_connect('destroy') do
		@buffer.destroy
	end

 But with this code, I get a segment fault ([BUG]) when I try to destroy
 window.

 My question is: Is it necessary to destroy buffer or is it destroyed
 automatically by ruby garbage collection?

 I see same behaviour with classes relatives to Gtk::TreeView, like
 Gtk::ListStore, Gtk::TreeSelection, etc...

 Please, Help!!

 Oh, and happy christmas :)

							David

P.D: I have too problems sending messages to the list, so I use ruby
news group to inform of ruby-gnome2 more than I'd like. Sorry for
inconvenience.

[ruby-gnome-devel-en] Objects that doesn't destroy

[DaVinci <bom...@wa...>]

 Hello all.

 I think I have a problem with ruby-gtk2 and objects that does not
 destroy, like Gtk::TextBuffer or Gtk::ListStore.

 Example: Imagine I have this class:

-------------------------------------------
class Texto < Gtk::ScrolledWindow
	def initialize
		super()
		@view = Gtk.TextView.new
		@buffer = @view.buffer
		add(@view)
	end
end
-------------------------------------------

 This class go inside a Window, and when I destroy window, all widgets
 are destroyed. But @buffer points to a Gtk::TextBuffer object, that it
 is not widget and it is not destroyed (or so I think after using a
 rutine that shows me which objects in ObjectSpace are destroyed or
 not).

 I have tried destroying @buffer adding next code in initialize:

 	@view.signal_connect('destroy') do
		@buffer.destroy
	end

 But with this code, I get a segment fault ([BUG]) when I try to destroy
 window.

 My question is: Is it necessary to destroy buffer or is it destroyed
 automatically by ruby garbage collection?

 I see same behaviour with classes relatives to Gtk::TreeView, like
 Gtk::ListStore, Gtk::TreeSelection, etc...

 Please, Help!!

 Oh, and happy christmas :)

							David

Re: [ruby-gnome-devel-en] Objects that doesn't destroy

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

Hi,

BTW, this mailing list is for Ruby-GNOME(1).
Don't send questions about Ruby-GNOME2 here, please.

On Sat, 25 Dec 2004 00:13:44 +0900
Masao Mutoh <mu...@hi...> wrote:

> Hi,
> 
> On Fri, 24 Dec 2004 13:44:28 +0100
> DaVinci <da...@es...> wrote:
> 
> >  Hello all.
> > 
> >  I think I have a problem with ruby-gtk2 and objects that does not
> >  destroy, like Gtk::TextBuffer or Gtk::ListStore.
> 
> Do you mean "destroy" as Gtk::Object#destroy ?
> If so, both of Gtk::TextBuffer and Gtk::ListStore don't have such method,
> because they are not subclasses of Gtk::Object but GLib::Object.
> 
> >  My question is: Is it necessary to destroy buffer or is it destroyed
> >  automatically by ruby garbage collection?
> 
> It sould be so.
>  
> -- 
> .:% Masao Mutoh<mu...@hi...>
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> ruby-gnome-devel-en mailing list
> rub...@li...
> https://lists.sourceforge.net/lists/listinfo/ruby-gnome-devel-en
> 


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

Re: [ruby-gnome-devel-en] Objects that doesn't destroy

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

Hi,

On Fri, 24 Dec 2004 13:44:28 +0100
DaVinci <da...@es...> wrote:

>  Hello all.
> 
>  I think I have a problem with ruby-gtk2 and objects that does not
>  destroy, like Gtk::TextBuffer or Gtk::ListStore.

Do you mean "destroy" as Gtk::Object#destroy ?
If so, both of Gtk::TextBuffer and Gtk::ListStore don't have such method,
because they are not subclasses of Gtk::Object but GLib::Object.

>  My question is: Is it necessary to destroy buffer or is it destroyed
>  automatically by ruby garbage collection?

It sould be so.
 
-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome-devel-en] Objects that doesn't destroy

[DaVinci <da...@es...>]

 Hello all.

 I think I have a problem with ruby-gtk2 and objects that does not
 destroy, like Gtk::TextBuffer or Gtk::ListStore.

 Example: Imagine I have this class:

-------------------------------------------
class Texto < Gtk::ScrolledWindow
	def initialize
		super()
		@view = Gtk.TextView.new
		@buffer = @view.buffer
		add(@view)
	end
end
-------------------------------------------

 This class go inside a Window, and when I destroy window, all widgets
 are destroyed. But @buffer points to a Gtk::TextBuffer object, that it
 is not widget and it is not destroyed (or so I think after using a
 rutine that shows me which objects in ObjectSpace are destroyed or
 not).

 I have tried destroying @buffer adding next code in initialize:

 	@view.signal_connect('destroy') do
		@buffer.destroy
	end

 But with this code, I get a segment fault ([BUG]) when I try to destroy
 window.

 My question is: Is it necessary to destroy buffer or is it destroyed
 automatically by ruby garbage collection?

 I see same behaviour with classes relatives to Gtk::TreeView, like
 Gtk::ListStore, Gtk::TreeSelection, etc...

 Please, Help!!

 Oh, and happy christmas :)

							David

[ruby-gnome-devel-en] Debian packages

[Dafydd H. <da...@pa...>]

Hello,

I have begun packaging ruby-gnome2 for Debian. The packages I have made
so far are available at

	http://muse.19inch.net/~daf/debian/

There are a couple of bindings that aren't built currently:

 - the libgda binding requires libgda code that is still in CVS and so
   can't be built
 - the gtkglext binding requires the OpenGL binding, which hasn't been
   packaged yet

The libgda problem should be solved as soon as 1.0.2 is released, and
the gtkglext problem should be solved as soon as the OpenGL binding is
packaged.

I've also done some work packaging rbbr, but the package isn't finished
yet.

-- 
Dafydd

[ruby-gnome-devel-en] Ruby-GNOME developer's Mailing List is now available!

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

Hi, 

I'm new maintainer of Ruby-GNOME.

This ML is for Ruby-GNOME developer.
If you are interested in development of 
Ruby-GNOME, join this ML!

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