Menu
▾
▴
ruby-fltk-devel — ruby-fltk-devel
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(31) |
Sep
(85) |
Oct
|
Nov
(10) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(10) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Kevin S. <kev...@ya...> - 2001-09-01 16:54:44
|
--- Takaaki Tateishi <tt...@ja...> wrote: > How about adding another singleton method something like > `Window.toplevel', `Window.new2' or `Window.create' for > creating the "top-level" window? I thought of that, but EVERY app will have a toplevel window, but only a few apps will have child windows. So I think the default (if there is one) should be toplevel. The other way would be to disable new and require users to choose Window.toplevel or Window.child. I don't like the name 'child' here, because it is not clear that you are creating a child--it sounds like you might be getting the child of a window. Maybe Window.popup would work. So, I see three options, and any are ok with me: 1. Window.new normally creates a toplevel, but if you pass an extra Fltk::CHILD_WINDOW at the beginning, it creates a child. 2. Window.new creates a toplevel, and Window.popup creates a child. 3. Window.new is disabled, Window.toplevel creates a toplevel, and Window.popup creates a child. I think I like #2 the best, because people looking at the C++ FLTK docs who just want a simple window will expect it to work. Kevin __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com |
|
From: Kevin S. <kev...@ya...> - 2001-09-01 16:49:30
|
--- Takaaki Tateishi <tt...@ja...> wrote: > I see. I didn't refer RBFL_CALLERS. > You added resize and call_parent_resize to RBFL_CALLERS > aren't you? Exactly. Kevin __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 15:06:10
|
At Sat, 1 Sep 2001 07:28:19 -0700 (PDT), Kevin Smith wrote: > Resize is identical to handle and draw. We need to offer it > to Ruby objects, because people might override it. And we > need to give the ability to call the original version, and > the default behavior should be to just call the original > version. I see. I didn't refer RBFL_CALLERS. You added resize and call_parent_resize to RBFL_CALLERS aren't you? Thanks, -- Takaaki Tateishi <tt...@ja...> |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 14:47:24
|
At Sat, 1 Sep 2001 07:15:24 -0700 (PDT), > I'm not happy that FLTK uses the constructor signature to > decide between child and top-level windows. I didn't know this fact. > I've thought of many possibilities, but I don't really like > any of them. I think tmy favorite so far is: .. > Assume that any Window will be top-level. If someone wants > to create a child window, require them to insert the RBFL > constant Fltk::CHILDWINDOW as the first parameter to new. > So new would now take zero to six parameters. How about adding another singleton method something like `Window.toplevel', `Window.new2' or `Window.create' for creating the "top-level" window? -- Takaaki Tateishi <tt...@ja...> |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 14:37:37
|
At Sat, 1 Sep 2001 07:05:31 -0700 (PDT), Kevin Smith wrote: > I just committed a change to Window that allows this to > work: It's great! > I have only changed this for Window, but I think we should > make a similar change for Widget. I agree. -- Takaaki Tateishi <tt...@ja...> |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 14:20:33
|
At Sat, 1 Sep 2001 06:08:31 -0700 (PDT), Kevin Smith wrote: > I added resize, and because it is also virtual, I made it > like draw and handle. So now I have bundled all three > virtual methods into macros: WIDGET_FNS (which contains > FN_DRAW, FN_HANDLE, and FN_RESIZE), and DEF_WIDGET_METHODS > (which contains DEF_METHOD for each of them). I agree with you on WIDGET_FNS. But I can't understand why resize must be redefined in subclasses. In the case of handle and draw, they caused the infinite recursion. -- Takaaki Tateishi <tt...@ja...> |
|
From: Kevin S. <kev...@ya...> - 2001-09-01 14:15:25
|
I'm not happy that FLTK uses the constructor signature to decide between child and top-level windows. I think we should do something different, to allow you to create a top-level window at a certain position, and to avoid specifying the position of a child window. For now, as a result of my work on new and initialize, it is impossible to create a child window. If we can't agree on a solution, I can restore the ability to choose top-level or child based on whether or not you pass x and y. I've thought of many possibilities, but I don't really like any of them. I think tmy favorite so far is: Assume that any Window will be top-level. If someone wants to create a child window, require them to insert the RBFL constant Fltk::CHILDWINDOW as the first parameter to new. So new would now take zero to six parameters. How does this sound? Kevin __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com |
|
From: Kevin S. <kev...@ya...> - 2001-09-01 14:05:34
|
I just committed a change to Window that allows this to work: ### require 'fltk' class MyWindow < Fltk::Window def initialize super(400, 200, 'Main Window Class') end end w = MyWindow.new w.show Fltk::run ### Now, the 'new' function always calls new Fl_Window(0,0), regardless of the args that were passed in. I have added a default 'initialize' method that actually uses the args to call size, resize, and/or label as needed. I have only changed this for Window, but I think we should make a similar change for Widget. Kevin __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 10:53:26
|
I've implemented most of widgets with `new', `handle' and `draw' methods except Fl_Free. Now you can create samples using a lot of widgets. If you find minor bugs, fix without my agreement, or show me them. I appreciate you to add some methods to each class. Regards, -- Takaaki Tateishi <tt...@ja...> |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 08:33:45
|
At Fri, 31 Aug 2001 11:25:31 -0700 (PDT), Kevin Smith wrote: > naming standards there are. The Windows version of Ruby > uses these names: > .../doc/ > .../samples/ I've created `doc' and `sample'. and there are two directories `ja' and `en' inside `doc'. > versions. Should we use text format, html, or some of each? Both are ok. -- Takaaki Tateishi <tt...@ja...> |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 08:22:01
|
At Fri, 31 Aug 2001 18:18:10 -0700 (PDT), Kevin Smith wrote: > I would like to allow the following constructors for every > widget: now I've added those. > Note also that FLTK's Fl_Window behaves differently > depending on whether you construct it with x and y or > without. I define the macro FN_S_NEW_WIN and RBFL_CLASS_WIN for this purpose. -- Takaaki Tateishi <tt...@ja...> |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 07:10:09
|
At Sat, 01 Sep 2001 14:49:05 +0900, > By the way, can we define FN_DRAW using FN_CALL_RENAME? > For example: > #define FN_DRAW(klass) FN_CALL_RENAME(klass,draw,call_parent_draw) now I've added the above macro, and add handle and draw methods to each class. -- Takaaki Tateishi <tt...@ja...> |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 05:04:30
|
At Fri, 31 Aug 2001 20:32:21 -0700 (PDT), Kevin Smith wrote: > class's draw instead. Right now, it is calling > Fl_Widget::draw. But if the widget is actually an > Fl_Window, we still call Fl_Widget::draw because we specify > that class. All subclasses end up calling Fl_Widget::draw. I think this problem would be caused when calling handle(). So I removed `virtual' from the definition of handle() in the class RBFLXxxxx which described in fltk.h. This modified version of rubyfltk seems to be working fine. I wander this solution is effective for draw() and handle(). How do you think about my opinion? -- Takaaki Tateishi <tt...@ja...> |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 04:13:24
|
At Sat, 01 Sep 2001 10:56:40 +0900, > Kevin Smith wrote: > > I would like to remove the FL and FL_. Is that ok with you? > > Yes, it's ok. > I will try to remove the prefix, and rename > the `enum' with `flenum'. done. -- Takaaki Tateishi <tt...@ja...> |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 03:40:47
|
At Fri, 31 Aug 2001 20:32:21 -0700 (PDT), Kevin Smith wrote: > Right now, child widgets inside a window do not get drawn. > I think I understand the problem, and the solution. I'll > fix it, but I wanted to let you know what I'm doing. I can understand the problem. please do cvs commit. -- Takaaki Tateishi <tt...@ja...> |
|
From: Kevin S. <kev...@ya...> - 2001-09-01 03:32:22
|
Right now, child widgets inside a window do not get drawn.
I think I understand the problem, and the solution. I'll
fix it, but I wanted to let you know what I'm doing.
The problem is that right now, when FLTK calls draw, it
goes to the virtual method in our RBFL class. That calls
the Ruby draw method, which (by default) calls the Ruby
call_parent_draw method. That casts the C++ pointer to
RBFLWidget, and calls call_parent_draw.
Now, inside there, it can't just call draw, because that
would cause infinite recursion. It needs to call the FLTK
class's draw instead. Right now, it is calling
Fl_Widget::draw. But if the widget is actually an
Fl_Window, we still call Fl_Widget::draw because we specify
that class. All subclasses end up calling Fl_Widget::draw.
I think the chain instead should be: FLTK calls draw, which
is our RBFL virtual method. It should call the Ruby draw
method. But by default, the Ruby draw method should simply
call its own RBFL call_parent_draw method, which will call
the correct FTLK draw.
To do this, I will create a macro FN_CALL_RENAME, which
will allow us to map a Ruby method ("draw") to a different
RBFL method ("call_parent_draw"). Since every Ruby draw
method has to call its own RBFL call_parent_draw, every
class will have to have:
static FN_CALL_RENAME(Window, draw, call_parent_draw);
and
DEF_METHOD(Window, draw, 0);
We can then get rid of the rb_flwidget_draw and
rb_flwidget_call_parent_draw methods in flwidget.cc.
I should be able to do this right now, and check it in
within an hour or so.
Kevin
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
|
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 02:10:39
|
At Fri, 31 Aug 2001 18:08:47 -0700 (PDT), Kevin Smith wrote: > You know more about Ruby memory management, so I don't want > to make a change like this myself yet. now I'm working for this problem. > I don't know why your window.rb sample works fine. If you put the following code before Fltk.run, the sample program will die. ... $win = nil GC.start Fltk.run -- Takaaki Tateishi <tt...@ja...> |
|
From: Takaaki T. <tt...@ja...> - 2001-09-01 01:55:38
|
At Fri, 31 Aug 2001 18:01:07 -0700 (PDT), Kevin Smith wrote: > I would like to remove the FL and FL_. Is that ok with you? Yes, it's ok. I will try to remove the prefix, and rename the `enum' with `flenum'. -- Takaaki Tateishi <tt...@ja...> |
|
From: Kevin S. <kev...@ya...> - 2001-09-01 01:18:10
|
I would like to allow the following constructors for every widget: new() new(label) new(width,height) new(width,height,label) new(x,y,width,height) new(x,y,width,height,label) The defaults for x, y, width, and height would be zero. They can always be changed later with calls to size, position, and resize. By the way, resize is virtual. I think that's fine with our system, but it is one of the few virtual methods so I wanted to point it out. Note also that FLTK's Fl_Window behaves differently depending on whether you construct it with x and y or without. Child windows get x and y, but to create a main window you only pass width and height. This affects 'parent', 'visible', and perhaps other aspects. Kevin __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com |
|
From: Kevin S. <kev...@ya...> - 2001-09-01 01:13:07
|
Here's my little program: ### require 'fltk' class MyWindow < Fltk::FLWindow def initialize super(0, 0, 400, 200, 'Hello Ruby-FLTK!') end end w = MyWindow.new w.show Fltk::run ### When I run it, it complains that I'm passing the wrong number of arguments to 'new' (0 for 4). I suspect we need to do something different in C++, but I don't know what. My prototype worked, but it was quite different so I don't know where to begin. Kevin __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com |
|
From: Kevin S. <kev...@ya...> - 2001-09-01 01:08:47
|
This little program gets a segfault when I exit:
###
require 'fltk'
Fltk::FLWindow.new(0, 0, 400, 200, 'Hello Ruby-FLTK!').show
Fltk::run
###
I wonder if it might be because FLTK doesn't make a copy of
the label string? In my prototype, I coded for this (even
though I didn't actually see a problem). Here's my label()
method in the C++ class that wrapped each FLTK class:
void label(const char* p) { \
const char* pOld = Fl_##klass::label(); \
free((char*)pOld); \
char* pNew = strdup(p); \
Fl_##klass::label(pNew);} \
const char* label() { printf("Getting\n"); \
return Fl_##klass::label();} \
I never passed a label to the actual FLTK widget
constructor. I would always call label() after the actual
construction, so it would go through this code.
You know more about Ruby memory management, so I don't want
to make a change like this myself yet.
I don't know why your window.rb sample works fine.
Kevin
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
|
|
From: Kevin S. <kev...@ya...> - 2001-09-01 01:01:08
|
I had assumed that since the classes, functions, and constants were all within the Fltk module, we could leave the FL off all of them. I just noticed that it's still FLWindow and FL_MAJOR_VERSION. I would like to remove the FL and FL_. Is that ok with you? Also, I just noticed that most of the source files start with fl, but enum does not. Would it be difficult to make it flenum to be consistent? Kevin __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com |
|
From: Kevin S. <kev...@ya...> - 2001-08-31 18:25:33
|
--- Takaaki Tateishi <tt...@ja...> wrote: > I think we had better put everything in top-level project > under the ruby-fltk cvs repository for a start. Ok. So I should create subdirectories. I don't know what naming standards there are. The Windows version of Ruby uses these names: .../doc/ .../samples/ Inside /doc we would have both English and Japanese versions. Should we use text format, html, or some of each? Kevin __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com |
|
From: Takaaki T. <tt...@ja...> - 2001-08-31 17:38:29
|
At Thu, 30 Aug 2001 18:13:39 -0700 (PDT), Kevin Smith wrote: > 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. I agree, and I appreciate you to write documentations and samples. > 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? now I think that we keep everything in the cvs repository `ruby-fltk'. In the near future, if they will get large, let's separate them from the source. How do you think about this? -- Takaaki Tateishi <tt...@ja...> |
|
From: Takaaki T. <tt...@ja...> - 2001-08-31 14:11:03
|
At Thu, 30 Aug 2001 18:13:39 -0700 (PDT), Kevin Smith wrote: > 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. I agree. > 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. I appreciate you to write those. I will also try to japanese one, if I will take time for them. > 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? I think we had better put everything in top-level project under the ruby-fltk cvs repository for a start. In the near future, if we will get a lot of works, let's separate something like documentation from the main package. -- Takaaki Tateishi <tt...@ja...> |
2 messages has been excluded from this view by a project administrator.
