ruby-fltk-devel

[ruby-fltk-devel] Browser support

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

For now, I have committed a version of Browser that only
allows you to add strings, without data values. It works
fine, but later we will need to add that feature.

I also deleted Context from fltk.rb, by the way.

Kevin

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

Re: [ruby-fltk-devel] Browser support

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

At Mon, 3 Sep 2001 12:52:33 -0700 (PDT),
Kevin Smith wrote:
> allows you to add strings, without data values. It works

To use data values we may use Marshal.dump and load. I think we
can deal with most of objects as the string without considering
GC problem.
In this case, It is a disadvantage that Proc, Thread and IO
objects can't be serialized.
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] Browser support

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

--- Takaaki Tateishi <tt...@ja...> wrote:
> To use data values we may use Marshal.dump and load. I
> think we can deal with most of objects as the string
without
> considering GC problem.
> In this case, It is a disadvantage that Proc, Thread and
> IO objects can't be serialized.

Interesting approach. Do you think this is better than just
passing a VALUE and keeping a copy for ourselves? What are
the advantages?

Kevin


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

Re: [ruby-fltk-devel] Browser support

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

At Mon, 3 Sep 2001 21:00:17 -0700 (PDT),
Kevin Smith wrote:
> > In this case, It is a disadvantage that Proc, Thread and
> > IO objects can't be serialized.
> 
> Interesting approach. Do you think this is better than just
> passing a VALUE and keeping a copy for ourselves? What are
> the advantages?

If we keep a copy of VALUE, we would have the difficulties of
the object chain and memory management. I'd like to avoid these
difficulties. So I suggested serializing the object.
If we deal with serialized object, we can pay attention to only
string object, and we don't need to consider those difficulties.
This is the advantage.

But we can't use this approach to implement the callback functions.
It is because we must deal with Proc object after all.
Though I suggested that we pass the Array object to the user data
of the callback function, that suggestion has same difficulties.
For example, how do we mark the Array object. One solution is your
idea that we store those Array objects somewhere. Now I don't know
how/when do we remove those objects from the store.
But I will adopt this approach to implement callbacks.
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] Browser support

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

At Tue, 04 Sep 2001 15:02:19 +0900,
> > Interesting approach. Do you think this is better than just
> > passing a VALUE and keeping a copy for ourselves? What are
> > the advantages?
> 
> If we keep a copy of VALUE, we would have the difficulties of
> the object chain and memory management. I'd like to avoid these
> difficulties. So I suggested serializing the object.
> If we deal with serialized object, we can pay attention to only
> string object, and we don't need to consider those difficulties.
> This is the advantage.

Now I've added some module functions such as Fl::add_fd, Fl::add_timeout,
Fl::add_idle and Fl::add_handlers. In this approach, Fltk module has
constants FDMap, Callbacks and Handlers to keep Proc objects and user data.

# test scripts handler.rb and timeout.rb are also added.

In the case of Browser#add, we prepare the instance variable @items
which is an Array object and call Fl_Browser::add() with the string
and the data, and then we keep added data using @items without copying.
I will try to realize this idea, if you don't mind.
-- 
Takaaki Tateishi <tt...@ja...>

Re: [ruby-fltk-devel] Browser support

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

--- Takaaki Tateishi <tt...@ja...> wrote:
> Now I've added some module functions such as Fl::add_fd,
> Fl::add_timeout,
> Fl::add_idle and Fl::add_handlers. In this approach, Fltk
> module has
> constants FDMap, Callbacks and Handlers to keep Proc
> objects and user data.

Sounds great.

> In the case of Browser#add, we prepare the instance
> variable @items
> which is an Array object and call Fl_Browser::add() with
> the string
> and the data, and then we keep added data using @items
> without copying.
> I will try to realize this idea, if you don't mind.

I think that sounds good, although I don't fully understand
it.

Are you saying that we will never pass 'data' into FLTK?
That we will just keep it in our code, so when the user
wants their data we can give it to them without asking
FLTK?

I think Menu_ has a similar situation, so you might also
look at it for ideas.

Kevin

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

Re: [ruby-fltk-devel] Browser support

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

At Tue, 4 Sep 2001 08:40:48 -0700 (PDT),
Kevin Smith wrote:
> Are you saying that we will never pass 'data' into FLTK?

No, I will pass the the data into both of add() and @items.

> That we will just keep it in our code, so when the user
> wants their data we can give it to them without asking
> FLTK?

I don't think so, but it is possible.
-- 
Takaaki Tateishi <tt...@ja...>