wxruby-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Wxruby-dev] Summary of naming problems


From: Richard Kilmer
Subject: Re: [Wxruby-dev] Summary of naming problems
Date: Sun, 22 Jun 2003 23:16:52 -0400


On Sunday, June 22, 2003, at 09:20  PM, Curt Hibbs wrote:

Kevin Smith wrote:

[snip]

But this means that if they grab a wxWindows book off the shelf, or if
they are trying to use a wxPython program as a sample, they will always
have to perform the mental translation themselves.

When working with the RubyGTK library, I really appreciated being able
to use any of the C documents out on the web.

After thinking about all the previous comments, I've come to agree with
this. For now, its enough work just to write the code, and it would be
better not to simultaneously make the documentation and issue as well.

Change my vote to sick as close as possible to the existing wxWindows
documentation.

I would really like Wx to become the standard graphical library for Ruby because of its cross-platform reach and native widget approach. When you code a lot of Ruby and then run into a CamelCase library just feels odd, and I think that if Wx becomes the standard graphical library...that will be an issue. I am just trying to look at this in the long run. If we say "let's stick with the Wx API for now" that will likely be the API.

And, although there are lots of python examples of Wx apps out there, there are no printed books.

This is the closest effort: http://www.wxwindows.org/wxbook.htm

And its not been accepted by a publisher, and its goal is to be a C++ book.

The C++ documentation from the Wx site is the main class/method docs...these same latex files would be the files ported for wxruby



Maybe the best answer is to provide GetPosition and get_position (and
perhaps getPosition), as aliases of each other.

I wouldn't do this, at least not yet. Just do the simple straight-forward
approach. Later, when someone is really motivated, they can create a
rubyesque wrapper along with documentation for it.

I believe that the documentation could be converted more simply than the code...the method parameters are different in WxRuby vs. C++ anyway, so the documentation is going to have to be updated to some degree. In the little utility I wrote to parse the latex and emit the method names for you, it was not all that much of a stretch to think of having it rewrite the documentation with the parsed/rewritten methods/classes/constants.

I will put this another way. I will (in my copious free time ;-) "port" the documentation if that will help





reply via email to

[Prev in Thread] Current Thread [Next in Thread]