ruby-fltk-devel — ruby-fltk-devel

[ruby-fltk-devel] Road map

[Kevin S. <kev...@ya...>]

I think it's important that we release an initial package
as quickly as possible. FOX has some momentum, but many
people are still looking for a good GUI package.

It doesn't have to be complete. I think if we have 50% of
Window, Widget, and Button, and 90% of the drawing methods,
that would make a good first release. If we have other
stuff in, that's even better.

We need to have a little bit of documentation, and samples
showing how everything works. I think I can write those.
The first release can be Linux-only.

Where should I check in the samples, documentation, etc?
Should they go in cvs in a subproject under ruby-fltk, or
should they each go in their own top-level project?

Can you think of anything else we need to do?

Kevin

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

Re: [ruby-fltk-devel] fltk.so?

[Takaaki T. <tt...@ja...>]

At Sun, 26 Aug 2001 20:33:06 -0700 (PDT),
Kevin Smith wrote:
> > As fltk.so usually installed in the ruby's directory like
> > /usr/local/lib/ruby/1.6/i686-linux/fltk.so, I think the
> > administrator can find it is a ruby's library.
> > 
> > Yes, we can create a `fltk.rb' with `fltk.so'. If we load
> > the `fltk.so' from `fltk.rb', we can write:
> > 
> >   require "fltk.o"
> 
> Hmmm. I guess that's ok, as long as it works under Windows
> and Mac as well as Linux. Why do you prefer this over
> fltk.rb and rubyfltk.so?

Yes, this should work on any plathome.
But now I don't deprecate your opinion.
let's use the name 'rubyfltk.so'.
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] fltk.so?

[Kevin S. <kev...@ya...>]

--- Takaaki Tateishi <tt...@ja...> wrote:
> As fltk.so usually installed in the ruby's directory like
> /usr/local/lib/ruby/1.6/i686-linux/fltk.so, I think the
> administrator can find it is a ruby's library.
> 
> Yes, we can create a `fltk.rb' with `fltk.so'. If we load
> the `fltk.so' from `fltk.rb', we can write:
> 
>   require "fltk.o"

Hmmm. I guess that's ok, as long as it works under Windows
and Mac as well as Linux. Why do you prefer this over
fltk.rb and rubyfltk.so?

> Ruby/Gtk and Ruby/Qt make `gtk.so' and `qt.so', but I've
> never  heard any problem about these libraries.

I didn't like the naming of Ruby/Gtk. In that case, on
Windows, you had the Gtk dlls, and then the Ruby/Gtk dlls,
and it was somewhat confusing.

I'm not sure they are correct, either. Perhaps we should
ask the Ruby mailing list which would be better?

Kevin

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [ruby-fltk-devel] renaming

[Kevin S. <kev...@ya...>]

> DEF_RBFL_CLASS -> RBFL_CLASS
> DEF_XXXX       -> FN_XXX
> ADD_XXXX       -> DEF_XXXX

Perfect.

Kevin

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

[ruby-fltk-devel] renaming

[Takaaki T. <tt...@ja...>]

Hello,

I inform you that I renamed macros as follows:

DEF_RBFL_CLASS -> RBFL_CLASS
DEF_XXXX       -> FN_XXX
ADD_XXXX       -> DEF_XXXX
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] fltk.so?

[Takaaki T. <tt...@ja...>]

At Sat, 25 Aug 2001 08:06:35 -0700 (PDT),
Kevin Smith wrote:
> Right now, we have fltk.so. For a system administrator,
> they would have no way to know that this is related to
> ruby. Also, there are some extensions to ruby-fltk that I
> would like to write in ruby itself (like a GraphicContext
> class).

As fltk.so usually installed in the ruby's directory like
/usr/local/lib/ruby/1.6/i686-linux/fltk.so, I think the
administrator can find it is a ruby's library.

> So, can we create a little fltk.rb (that just has require
> 'rubyfltk'), and then rename the main library to
> rubyfltk.so?

Yes, we can create a `fltk.rb' with `fltk.so'. If we load
the `fltk.so' from `fltk.rb', we can write:

  require "fltk.o"

Ruby/Gtk and Ruby/Qt make `gtk.so' and `qt.so', but I've never
heard any problem about these libraries.
So I think we had better create `fltk.so'.
-- 
Takaaki Tateishi <tt...@ja...>

[ruby-fltk-devel] fltk.so?

[Kevin S. <kev...@ya...>]

I think I mentioned this earlier, but I wanted to know what
you think about it.

Right now, we have fltk.so. For a system administrator,
they would have no way to know that this is related to
ruby. Also, there are some extensions to ruby-fltk that I
would like to write in ruby itself (like a GraphicContext
class).

So, can we create a little fltk.rb (that just has require
'rubyfltk'), and then rename the main library to
rubyfltk.so?

Kevin

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

[ruby-fltk-devel] adding some macros

[Takaaki T. <tt...@ja...>]

I added the following macro definitions in flwidget.h:

DEFINE_RBFLWIDGET_S_NEW(CXXClass,func)
DEFINE_RBFLSUBWIDGET_CALL_SUPER_HANDLE(CXXSuperClass,func)
DEFINE_RBFLSUBWIDGET_CALL_SUPER_DRAW(CXXSuperClass,func)

and I renamed FLSUBWIDGET_CALLER with RBFLSUBWIDGET_CALLER.

I will begin to make widgets which inherits from Fl_Group or
implement Fltk's constants such as FL_SHOW which is shown in
FL/Enumeration.H.

Regards,
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Takaaki T. <tt...@ja...>]

At Mon, 20 Aug 2001 12:43:07 +0900,
> Ok, I remove old sources from the cvs repository and
> add new sources.

done.
and I added the method `_handle' and `_draw' to each FLSubXxx
class so that we can call the draw() and handle() of the super
class like Fl_Window::draw().
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Takaaki T. <tt...@ja...>]

At Sun, 19 Aug 2001 14:04:05 -0700,
Kevin Smith <kev...@ho...> wrote:
> I've uploaded a diagram at:
> http://www.qualitycode.com/parallel.html

I see,
FLSubWindow inherits from FLWindow which has the connection
to the Fl_Window via RBFLData,
and FLSubWindow has the connection to the RBFLSubWindow which
is inherits from Fl_Window.
You think that this is similar to the multiple inheritance,
aren't you? If so, now I can understand your sense.

If FLWindow has the connection to the RBFLWindow(= RBFLSubWindow)
which inherits from the Fl_Window and FLWidget has the connection
to the RBFLWidget, we can not cast the `RBFLData.widget' from
RBFLWindow to RBFLWidget. it is because of RBFLWindow doesn't
inherit from RBFLWidget.
This is the reason why I adopt such design.

> By the way, I haven't figured out how and where I might upload these
> documents to sourceforge, rather than having to host them on my web page.
> Can you tell me how to upload them there?

We can upload using `scp', and also login to the host
`ruby-fltk.sourceforge.net'. Please login to the host,
and change the current directory to:

  /home/groups/r/ru/ruby-fltk/htdocs

now you can see some documents which are also shown at
`http://ruby-fltk.sourceforge.net/'.

If you'd like to put the document `foo.html' into the
directory `/home/groups/r/ru/ruby-fltk/htdocs', you
must run the following commend:

  scp foo.html ruby-fltk.sourceforge.net:/home/groups/r/ru/ruby-fltk/htdocs/

Here are some documents which will help you:
https://sourceforge.net/docman/display_doc.php?docid=774&group_id=1
https://sourceforge.net/project/admin/?group_id=33685

> And, as I said before, if this complex structure is required, we can do it.
> But I would prefer a simpler approach if the simpler approach will work.

Ok, I remove old sources from the cvs repository and
add new sources.
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Kevin S. <kev...@ho...>]

On Mon, 20 Aug 2001, Takaaki Tateishi wrote:
> Maybe I misunderstood `parallel inheritance'.
> 
> Xxxx ---> SubXxxx
>  |
>  V
> Yyyy ---> SubYyyy
> 
> Is the above a parallel inheritance?
> It is not `multiple inheritance'. Is it right?

The above is not multiple inheritance, but the design you presented does
have some similaries to MI. I've uploaded a diagram at:
http://www.qualitycode.com/parallel.html

By the way, I haven't figured out how and where I might upload these
documents to sourceforge, rather than having to host them on my web page.
Can you tell me how to upload them there?

And, as I said before, if this complex structure is required, we can do it.
But I would prefer a simpler approach if the simpler approach will work.

Kevin

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Takaaki T. <tt...@ja...>]

At Sun, 19 Aug 2001 09:38:42 -0700,
Kevin Smith <kev...@ho...> wrote:
> It seems quite complex to me, and I like simple things. If there is a
> compelling reason to have the parallel inheritance, then this seems like it
> might be a good way to do it. But I haven't found any features yet that
> require it.

Maybe I misunderstood `parallel inheritance'.

Xxxx ---> SubXxxx
 |
 V
Yyyy ---> SubYyyy

Is the above a parallel inheritance?
It is not `multiple inheritance'. Is it right?

I show you the reason later, since it's kinda
difficult for me to explain it in english.

> The only feature missing from this design seems to be the ability for a
> client to override draw( ) and invoke the original version. I haven't
> thought about it, but I assume this would be possible to add.

Yes, I forgot to implement the method invoking the draw() of
the super class. I found this problem a few hour ago.
now I'm sure it is possible.
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Kevin S. <kev...@ho...>]

On Sun, 19 Aug 2001, Takaaki Tateishi wrote:
> I wrote http://ruby-fltk.sourceforge.net/design.html.
> though it's not completed, I hope it help you to look at the code.

Yes, it was helpful. I had figured out most of the code, but the document
confirmed what I thought, and helped me understand some of the corners.

It seems quite complex to me, and I like simple things. If there is a
compelling reason to have the parallel inheritance, then this seems like it
might be a good way to do it. But I haven't found any features yet that
require it.

The only feature missing from this design seems to be the ability for a
client to override draw( ) and invoke the original version. I haven't
thought about it, but I assume this would be possible to add.

I'm interested to hear what you think of my design, so we can start to move
the actual coding along quickly. It seems like there is some real interest
in the Ruby community right now for a simple toolkit, and I would like FLTK
to be one of the options.

Kevin

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Takaaki T. <tt...@ja...>]

At Sat, 18 Aug 2001 18:01:40 -0700,
Kevin Smith <kev...@ho...> wrote:
> > now I find out the nice implementation for me. it is including both of
> > your idea and my idea. I've put the sample implementation. download the
> > following archive and refer it.
> 
> That's funny that our ideas crossed paths! I'm starting to look at your
> code now.

I wrote http://ruby-fltk.sourceforge.net/design.html.
though it's not completed, I hope it help you to look at the code.
-- 
Takaaki Tateishi <tt...@ja...>

[ruby-fltk-devel] Results of my experiments

[Kevin S. <kev...@ho...>]

I have posted a new document describing the results of my experiments:
http://www.qualitycode.com/newrbfl.html

Hopefully, it clearly explains what I have found, and what I am proposing.
I have changed my mind on several issues. Working with actual client code
helped me understand it much better.

I eagerly await whatever comments you may have on this.

Kevin

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Takaaki T. <tt...@ja...>]

At Fri, 17 Aug 2001 20:35:57 -0700,
Kevin Smith <kev...@ho...> wrote:
> > - it is not recommended that ruby object is owned by the `RBFLXxxx'.
> 
> I still don't understand this.

this is not my recommendation.
I adopted this technique to the sample
implementation which is described below.

> I agree, but we can automate this using macros, templates, or our own
> preprocessor (something like SWIG, I guess). By the way, did you consider
> SWIG? Have you tried it on any projects? I haven't, and I'm still trying to
> figure out if it would help us or not.

I will not use any pre-processor like SWIG.
and don't know the details of SWIG well.

> > but I want to think about this issue for a few days, since I
> > think that it is the most important point of Ruby/Fltk.
> > and I will try to find another design improving your idea.
> 
> Great. I'll be experimenting this weekend, which will really help me
> understand how to improve my ideas, too.

now I find out the nice implementation for me. it is including both of
your idea and my idea. I've put the sample implementation. download the
following archive and refer it.

http://ruby-fltk.sourceforge.net/archive/ruby-fltk-new.tar.gz

in this implementation, we create the subclass RBFLSubXxxx for each
Fl_Xxxx. and in the ruby layer, we will have the class FLXxxx and
FLSubXxxx for the C++ class Fl_Xxxx and RBFLSubXxxx.
there are sample two script in the archive. one is for Fl_Xxxx and
the other shows how to handle the event.
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Kevin S. <kev...@ho...>]

On Sat, 18 Aug 2001, Takaaki Tateishi wrote:
> the method `func_a' of the class RA is used since there is no
> such method in the RB. so the function `rb_a_func_a()' is called.
> the value of `self' represent the `b'. we can obtain the `data' as
> the object instantiated from the class A using Data_Get_Struct(),
> but `data' is the object instantiated from the class B. something
> like the cast is done here.
> 
> of course, this is depend on the implementation. the advantage is
> that we don't need to implement all methods for each subclass.

Ok. I understand this perfectly now.

> - we'd like to avoid the multiple inheritance.

Yes.

> - it is not recommended that ruby object is owned by the `RBFLXxxx'.

I still don't understand this. If you write a C program that links with the
ruby library, then C code will own all the ruby objects. Is there a
difference with C++ here?

> - (I don't want to write all methods for each class.)

I agree, but we can automate this using macros, templates, or our own
preprocessor (something like SWIG, I guess). By the way, did you consider
SWIG? Have you tried it on any projects? I haven't, and I'm still trying to
figure out if it would help us or not.

Hashes would be ok, too, if we keep it simple. I'll think about that angle.
I think simplicity is one of the most important attributes of any project.

> but I want to think about this issue for a few days, since I
> think that it is the most important point of Ruby/Fltk.
> and I will try to find another design improving your idea.

Great. I'll be experimenting this weekend, which will really help me
understand how to improve my ideas, too.

Kevin

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Takaaki T. <tt...@ja...>]

At Fri, 17 Aug 2001 16:58:35 -0700,
Kevin Smith <kev...@ho...> wrote:
> > I've tried to implement the above class, but some problems are found.
> > if we implement classes RBFL_Xxxx and RBFL_Yyyy, RBFL_Yyyy is a subclass
> > of the class RBFL_Xxxx, we obtain the following class hierarchy.
> > 
> > Fl_Xxxxx -------> RBFL_Xxxxx
> >    |
> >    |
> >    V
> > Fl_Yyyyy -------> RBFL_Yyyyy
> 
> That seems fine, as long as we don't need RBFL_Yyyyy to inherit from
> RBLF_Xxxxx. I thought about this some, and couldn't think of a reason we
> needed it. 

in current implementation, when we call the ruby method `do_callback'
of the class `Fltk::Adjuster', `do_callback()' of the C++ class
`RBFLWidget' is used. so the ruby inheritance is closely coupled with
C++ inheritance.
I will show you the simple example of this mechinism. now we assume
that there are two C++ classes A and B, we make Ruby wrapper classes
RA and RB, and use C symbols `rb_cRA' and `rb_cRB' for ruby classes
`RA' and `RB' respectively. A and B is like:

class A {
  A(){ ... };
  func_a(){ ... };
};

class B : public A {
  B(): A(){ ... };
  func_b(){ ... };
};

we can create the ruby classes like this:

rb_cRA = rb_define_class("RA", rb_cObject);
rb_define_sigleton_method(rb_cRA, "new", rb_a_new, 0);
rb_define_method(rb_cRA, "func_a", rb_a_func_a, 0);

rb_cRB = rb_define_class("RB", rb_cRA);
rb_define_sigleton_method(rb_cRB, "new", rb_b_new, 0);
rb_define_method(rb_cRB, "func_b", rb_b_func_b, 0);

where `rb_a_new()', `rb_b_new()', `rb_a_func_a()' and `rb_b_func_b()'
are defined like:

VALUE rb_a_new(VALUE klass)
{
  A *data = new A();
  return Data_Wrap_Struct(klass, .... ,data);
};

VALUE rb_b_new(VALUE klass)
{
  B *data = new B();
  return Data_Wrap_Struct(klass, ...., data);
};

VALUE rb_a_func_a(VALUE self)
{
  A *data;

  Data_Get_Struct(self, A, data);
  data->func_a();
  return Qnil;
};

VALUE rb_b_func_b(VALUE self)
{
  B *data;

  Data_Get_Struct(self, B, data);
  data->func_b();
  return Qnil;
};  

and if we run the following ruby code:

  b = RB.new
  b.func_a()

the method `func_a' of the class RA is used since there is no
such method in the RB. so the function `rb_a_func_a()' is called.
the value of `self' represent the `b'. we can obtain the `data' as
the object instantiated from the class A using Data_Get_Struct(),
but `data' is the object instantiated from the class B. something
like the cast is done here.

of course, this is depend on the implementation. the advantage is
that we don't need to implement all methods for each subclass.

> Do we need our wrappers to inherit from each other? If not, I'd prefer to
> avoid having parallel hierarchies.

I'm very interested in your idea, but I'd like to use the mapping
from C++ object to Ruby object using something like Hash again
from the following reasons.
- we'd like to avoid the multiple inheritance.
- it is not recommended that ruby object is owned by the `RBFLXxxx'.
- (I don't want to write all methods for each class.)

but I want to think about this issue for a few days, since I
think that it is the most important point of Ruby/Fltk.
and I will try to find another design improving your idea.
-- 
Takaaki Tateishi <tt...@ja...>

[ruby-fltk-devel] FLTK release schedule

[Kevin S. <kev...@ho...>]

I asked the FLTK folks what their update schedule  looks like, and how
major the changes are going to be in 2.0. Here's an answer:

On Fri, 17 Aug 2001, Michael Sweet wrote:
> There are some pretty significant changes to things like the menu and
> browser based widgets, and of course the style stuff.  The header
> files are under a new directory as well (fltk/Fl_Foo.h instead of
> FL/Fl_Foo.H) to make life a bit easier for mixed 1.x/2.x development.
> 
> There will be an intermediate 1.1 release (beta going out soon) that
> is accessible via CVS using the "v1_1" branch.  It incorporates some
> of the 2.0 widgets and features, without the style/scheme/theme
> and menu/browser changes.  This makes it 100% source compatible with
> FLTK 1.0.x while providing the benefits of 2.0 (which is still in
> alpha state)

So it looks like we should continue to target FLTK 1.x for a while longer.

Kevin 

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Kevin S. <kev...@ho...>]

On Sat, 18 Aug 2001, Takaaki Tateishi wrote:
> I've tried to implement the above class, but some problems are found.
> if we implement classes RBFL_Xxxx and RBFL_Yyyy, RBFL_Yyyy is a subclass
> of the class RBFL_Xxxx, we obtain the following class hierarchy.
> 
> Fl_Xxxxx -------> RBFL_Xxxxx
>    |
>    |
>    V
> Fl_Yyyyy -------> RBFL_Yyyyy

That seems fine, as long as we don't need RBFL_Yyyyy to inherit from
RBLF_Xxxxx. I thought about this some, and couldn't think of a reason we
needed it. 

> class RBFl_Yyyy : public Fl_Yyyy, public RBFl_Xxxx {
>   ...
> }

Do we need our wrappers to inherit from each other? If not, I'd prefer to
avoid having parallel hierarchies.

> I prefer short name. how about `RBFLXxx'?

Sounds good to me.

Kevin

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Takaaki T. <tt...@ja...>]

At Fri, 17 Aug 2001 08:46:02 -0700,
Kevin Smith <kev...@ho...> wrote:
> > class RBFl_Xxxx : Fl_Xxxx {
> > public:
> >   VALUE rb_object;
> >   ....
> > }
> 
> Exactly.

I've tried to implement the above class, but some problems are found.
if we implement classes RBFL_Xxxx and RBFL_Yyyy, RBFL_Yyyy is a subclass
of the class RBFL_Xxxx, we obtain the following class hierarchy.

Fl_Xxxxx -------> RBFL_Xxxxx
   |
   |
   V
Fl_Yyyyy -------> RBFL_Yyyyy

if ruby classes `Fltk::Xxxx' and `Fltk::Yyyy' wrap the C++ classes
`RBFL_Xxxx' and `RBFL_Yyyy' respectively, the C++ class hierarchy
is different from the Ruby class hierarchy.
I think we had better write the class like this:

class RBFl_Xxxx : Fl_Xxxx {
public:
  VALUE rb_object;
  ....
}

class RBFl_Yyyy : public Fl_Yyyy, public RBFl_Xxxx {
  ...
}

class RBFl_Zzzz : public Fl_Zzzz, public RBFl_Yyyy {
  ...
}

> > and making the structure for the Ruby class,
> > 
> > struct rb_fl_data {
> >   RBFl_Xxxxx *widget;
> > }
> 
> I'm not sure what we would store in *widget.

Sorry, I mistook here. please forget that code.

> One other note: I'm not really happy with RBFl_ as a prefix. I would much
> prefer one of the following, as they seem more consistent:
> 1. RBFL_Xxx
> 2. RubyFltkXxx

I use `RBFl_', since the Fltk uses `Fl_'.
I prefer short name. how about `RBFLXxx'?
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Takaaki T. <tt...@ja...>]

At Fri, 17 Aug 2001 08:46:02 -0700,
Kevin Smith <kev...@ho...> wrote:
> > class RBFl_Xxxx : Fl_Xxxx {
> > public:
> >   VALUE rb_object;
> >   ....
> > }
> 
> Exactly.

I've tried to implement the above class, but some problems are found.
if we implement classes RBFL_Xxxx and RBFL_Yyyy, RBFL_Yyyy is a subclass
of the class RBFL_Xxxx, we obtain the following class hierarchy.

Fl_Xxxxx -------> RBFL_Xxxxx
   |
   |
   V
Fl_Yyyyy -------> RBFL_Yyyyy

if ruby classes `Fltk::Xxxx' and `Fltk::Yyyy' wrap the C++ classes
`RBFL_Xxxx' and `RBFL_Yyyy' respectively, the C++ class hierarchy
is different from the Ruby class hierarchy.
I think we had better write the class like this:

class RBFl_Xxxx : Fl_Xxxx {
public:
  VALUE rb_object;
  ....
}

class RBFl_Yyyy : public Fl_Yyyy, public RBFl_Xxxx {
  ...
}

class RBFl_Zzzz : public Fl_Zzzz, public RBFl_Yyyy {
  ...
}

> > and making the structure for the Ruby class,
> > 
> > struct rb_fl_data {
> >   RBFl_Xxxxx *widget;
> > }
> 
> I'm not sure what we would store in *widget.

Sorry, I mistake here. please forget that code.

> One other note: I'm not really happy with RBFl_ as a prefix. I would much
> prefer one of the following, as they seem more consistent:
> 1. RBFL_Xxx
> 2. RubyFltkXxx

I use `RBFl_', since the Fltk uses `Fl_'.
I prefer short name. how about `RBFLXxx'?
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Kevin S. <kev...@ho...>]

On Fri, 17 Aug 2001, Takaaki Tateishi wrote:
> I see. you think about making the class like:
> 
> class RBFl_Xxxx : Fl_Xxxx {
> public:
>   VALUE rb_object;
>   ....
> }

Exactly.

> and making the structure for the Ruby class,
> 
> struct rb_fl_data {
>   RBFl_Xxxxx *widget;
> }

I'm not sure what we would store in *widget. RBFI_Xxxx already contains a
pointer to the C++ object (this). Unless you mean to store the passed
callback data here, but I would store that as a void* or long.

> > We could also store callback data there. But as I mentioned, I think
> > there's value in keeping the C++ code to a minimum, and doing as much
> as we
> > can in ruby.
> 
> I think it is also possible. but I heard that it is not recommended
> that VALUE data is owned by the structure like `rb_fl_data' and class
> `RBFl_Xxxx'.
> if we adopt such mechanism, we would carefully deal with the both of
> the ruby object and C++ object.
> I will ask some ruby developers this issues.

That's good. I'm still learning about how ruby manages memory. But I'm
still not sure that the rb_fl_data struct need to own anything. Also, is
there a difference between keeping a copy of a VALUE and being the one who
allocates it? In ruby, I don't think there really is, but I'm not sure.

One other note: I'm not really happy with RBFl_ as a prefix. I would much
prefer one of the following, as they seem more consistent:
1. RBFL_Xxx
2. RubyFltkXxx

Personally, I dislike underscores, but I realize they're the standard in
both ruby AND in FLTK. So I like #2, but probably #1 would be better.

Kevin

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Takaaki T. <tt...@ja...>]

At Thu, 16 Aug 2001 23:47:48 -0700,
> No, wait. I just remembered that we're thinking of creating our own wrapper
> class for each FLTK C++ class. We can add a local member variable there
> that contains the ruby object. No hash table needed, and simpler memory
> management.

I see. you think about making the class like:

class RBFl_Xxxx : Fl_Xxxx {
public:
  VALUE rb_object;
  ....
}

and making the structure for the Ruby class,

struct rb_fl_data {
  RBFl_Xxxxx *widget;
}

and we can create ruby objects using Data_Make_Struct macro like:

struct rb_fl_data *data;
VALUE rb_cFl_Xxxxx = rb_define_class("ClassName");
VALUE obj = Data_Make_Struct(rb_cFl_Xxxx, ...., data);
data->widget = new RBFl_Xxxxx(....);
data->widget->rb_object = obj;

now we can obtain the ruby object `obj'.
Is this right?

> We could also store callback data there. But as I mentioned, I think
> there's value in keeping the C++ code to a minimum, and doing as much as we
> can in ruby.

I think it is also possible. but I heard that it is not recommended
that VALUE data is owned by the structure like `rb_fl_data' and class
`RBFl_Xxxx'.
if we adopt such mechanism, we would carefully deal with the both of
the ruby object and C++ object.
I will ask some ruby developers this issues.
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] Mapping C++ objects to Ruby objects

[Kevin S. <kev...@ho...>]

> So, it looks like we should have our own map, probably in the form of a
> ruby hash created in C++, and updated each time we create or delete an
> object. I think it would make sense to use the C++ pointer as the key,
> and
> the ruby object VALUE as the value. This way, we can store the callback
> data item in the ruby part of our object, along with any similar data we
> need in the future.

No, wait. I just remembered that we're thinking of creating our own wrapper
class for each FLTK C++ class. We can add a local member variable there
that contains the ruby object. No hash table needed, and simpler memory
management.

We could also store callback data there. But as I mentioned, I think
there's value in keeping the C++ code to a minimum, and doing as much as we
can in ruby.

Kevin