Hal E. Fulton wrote:
> ----- Original Message ----- 
> From: "Lyle Johnson" <lyle / users.sourceforge.net>
> Newsgroups: comp.lang.ruby
> To: "ruby-talk ML" <ruby-talk / ruby-lang.org>
> Sent: Monday, July 29, 2002 8:54 AM
> Subject: Re: Moving from TK to Fox.
> 
> 
> [snip from Hugh Sasse]
> 
>> > If these reflect aspects of the C++ API, may I suggest that you either
>> > document their purpose in the Ruby API, or allow them to be assimilated
>> > into soemthing more Rubyesque, because at the moment we have calls to
>> > application.new, application.init and application.create.
>> 
>> OK, I'll consider some ways to simplify the startup code.
> 
> Interesting idea, Lyle. I wasn't sure
> how "set in stone" the Ruby API was. I
> know that many parts aren't, but some
> might be.

The API is not set in stone, but there are at least two constraints for 
me to consider when making changes.

One constraint is that there are certain things that must be done to 
satisfy the underlying FOX library. To use Hugh's case as an example, we 
*must* construct an application (FXApp) instance; we *must* call 
FXApp#init (which is different from Ruby's initialize method) on that 
instance and pass in a (possible empty) array of command line arguments; 
and we *must* call FXApp#create to create the various server-side 
resources (e.g. icons, fonts and windows).

Now, having said that, there's no reason why we couldn't hide some of 
these nasty details away somewhere so that the FXRuby application 
programmer is burdened with them. The scheme for connecting widget 
events directly to Ruby procs (using the "connect" instance method) is 
implemented entirely in Ruby code, layered on top of the real way you 
have to do this in FOX. I did not change how FOX does things under the 
hood, with its message maps and so forth, but I did make it more 
accessible to Ruby programmers.

Another equally important constraint is to avoid making incompatible, 
code-breaking changes to the API, and so the APIs that Hugh referred to 
won't actually go away. That is, code that calls FXApp#init directly or 
whatever should still continue to work. But I don't think that will be 
too difficult to manage. To refer back to the previous example, people 
can still write code to FXRuby's original event-handling API (as 
described in "The Ruby Way" and "Ruby Developer's Guide") even though 
the new API is decidedly more "Rubyesque".

> Lyle: Let's discuss this sometime, either
> on or off the mailing list. I like Fox, 
> but I sometimes find pieces of the API
> cumbersome (as Hugh does).

Yes, any comments and suggestions are welcome (either through the 
mailing list, newsgroup or private e-mails). Please note that I'm not 
really interested in discussing *wholesale* changes to the API, along 
the lines of some other current threads (i.e. "Rouge" and friends). 
However, if others in the Ruby community want to use FOX/FXRuby as a 
springboard for implementing such new APIs, that's great, and I wish 
them success. And of course, I reserve the right to steal any of their 
good ideas for FXRuby if I so choose ;)