Extending GTK+ Classes in Ruby (revisited)

Hi,

I’m trying to figure out if it’s possible to create a custom cell
renderer using a Ruby class. Digging through the source, I found the
type_register example, and that does allow me to provide default
handlers for the editing signals, but in order to do my custom renderer,
I need to override some of the methods in the base class.

According to examples I’ve found, you can do this sort of thing with the
Python bindings, but I don’t see how you can do it from the Ruby ones.
I saw the following thread on the mailing list back in 2003
(http://sourceforge.net/mailarchive/message.php?msg_id=20030912092726.GA2014%40intersect-uk.co.uk))
as well as (
http://sourceforge.net/mailarchive/message.php?msg_id=14e8de370603312339ne957094y5a45753e65e419e8%40mail.gmail.com).
I’ve also been looking through how it’s implemented in the C source, but
I haven’t used C GLib/GTK+ in years, and I’ve never done anything other
than read about extending Ruby in C apart for adding a missing method to
the Ruby goocanvas bindings (patch to follow at some stage).

Does anyone have any idea how item #1 in the 2003 email message can be
accomplished? I really don’t want to have to write my custom cell
renderer in C, then wrap it in Ruby just so I can render one set of
cells in one table which represents about .000001 of the functionality
of what I’m trying to write.

I’m sure that solving this problem would also be very useful to the
general community for cell renderers and view models (which are the main
reasons you’d need to do something more sophisticated than the signal
handling already there).

In the old threads, the problem of GLib interfaces vs. Ruby was also
raised. However, I’d think there should be an easy solution for this.
Something like the following seems to be a good trade-off:

class MyRenderer < Gtk::CellRenderer
type_register
implements_interface(Gtk::foo)
implements_interface(Gtk::bar)


end

or, you could do something like

class MyRenderer < Gtk::CellRenderer

register the type (type_register) and all implemented GLib

inteterfaces
register_glib_type([… optional interfaces …])


end

As I said, not having done much with either GLib/GTK+ in C or Ruby
extensions, I’m not sure how to actually make this happen, but it seems
like there ought to be a way to do it since you can already add custom
signals, properties and register the type. Even if it was via closures
(which, based on the names used, is how it seems to be implemented in
Python), it’d still be better than what exists today: if you don’t have
a signal you can override, you’re SOL.

Surely there’s some way to automatically add these redirects to the
existing bindings. Unfortunately, I’m not sure where to begin, and I’m
also under time pressure to get something working with my application.
I guess this means defining my custom GLib classes in C and then
wrapping them back to Ruby. :frowning:

Thanks in advance for any ideas/assistance.

Cheers,

ast

P.S. Some other references (I’m sure you’ve seen most of these already):

http://library.gnome.org/devel/gobject/unstable/
http://live.gnome.org/PyGTK/WhatsNew28
http://www.sicem.biz/personal/lgs/docs/gobject-python/gobject-tutorial.html

Andrew S. Townley [email protected]
http://atownley.org

hi,
i don’t know the answer to your problem, but i’m also interested in the
solution.
what kind of renderer would you like to implement?
do you need something more sophisticated that cannot be accomplished
with
http://ruby-gnome2.sourceforge.jp/hiki.cgi?Gtk%3A%3ACellLayout#set_cell_data_func
?

regards
balint

Hi Balint,

Yep. I need a multi-line text editor embedded in a cell. I found this
one (done in Python), so I know it’s possible:

http://www.daa.com.au/pipermail/pygtk/2005-April/009990.html

However, it has some issues (other than being in Python). I hacked it
to make it kinda work, just to see how complete it was. It still has
some other functionality that would be required in a polished
application. I’m pretty sure I can do the rest, but I can’t get to the
get_size and render methods from Ruby.

I did write a version of an editible table cell (single line) using pure
Python years ago before the GtkTreeView & friends existed (basically a
crude version of what’s there today). It took a while to get the
placement right (along with some guesses in the end), but it did end up
working quite well. At least this time, the right hooks seem to be
there, so it should be easier/cleaner to do–provided you can get to
them from Ruby.

On the upside, I was thinking that I could provide a C + Ruby binding
for such a critter to the community if I got it working (because I think
this should be core functionality in GTK+). The current implementation
doesn’t pay attention to things like yalign during editing if you have a
long row (I want valign=top), but the default CellEditorText
implementation always locates the GtkEdit in the middle of the cell
space. It seems a little half-baked, but I really need something
equivalent to the type of cell editing support you’d find in Excel or OO
Calc for what I’m doing (and no, it isn’t another spreadsheet! :)).

I haven’t written any C code in about 7 years, but I did play around
with trying to port the old asclock applet to the new version of Gnome
at the time, so I have messed around a little with the GLib/GTK+ type
system and its approach to OOP. Still, it’s a distraction I
don’t/didn’t need, but I do need the functionality from a user
experience point of view.

Thanks for trying to help.

Cheers,

ast

On Tue, 2008-09-09 at 16:17 +0300, Dobai-Pataky Bálint wrote:

balint

According to examples I’ve found, you can do this sort of thing with the
I’m sure that solving this problem would also be very useful to the
implements_interface(Gtk::foo)

ast
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ ruby-gnome2-devel-en mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ruby-gnome2-devel-en

Andrew S. Townley [email protected]
http://atownley.org

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs