Re: [Fxruby-users] [ANN] Updated API Documentation

[Lyle J. <jl...@cf...>]

Hugh Sasse Staff Elec Eng wrote:

> Yes, this is really nice.  Concise and informative.  Also it may
> help to add information about what happens when block_given?() is
> true or false.  Does this affect the return value for <a method>?....

OK, just made a note of this. But to answer the question, no, the return 
value of FXClass.new is always a reference to the new instance, and is 
not affected by the presence or absence of a block.

> Links to examples that are shipped with FXRuby might be good.  You
> have a few that rely on the FXCanvas for example, but I found
> reading the code too confusing to learn from, and the API
> documentation is rather obscure about how to draw on a canvas.  It
> seems, from looking at the draw methods, that you don't draw on an
> FXCanvas, you draw on an FXDC.  [cf "How do you get down from an
> elephant?"]  The media independence is good, but for someone coming
> from Tk this is odd :-)  So how to connect this related semantic
> information?  Maybe have a "See also:" item at the end?  "Keywords"?
> "CategoryCategories" as per Wiki?  Interesting problem....

Your point is well taken. A lot of the more interesting information 
about classes like FXDC is not their API in isolation, but rather how 
they plug into the surrounding framework and interact with other classes 
(like FXCanvas). At the least, I should be able to link to other classes 
and methods that RDoc knows about (i.e. a "see also" approach). Not sure 
what facilities, if any, RDoc provides for a more general solution to 
the challenge of cross-referencing related ideas.

By the way, thanks for making me look up the answer to the riddle. I 
will let others google for the answer as I did ;)

> I find myself wondering if this flexibility should be exposed
> to every programmer, or whether a simpler wrapper might be useful
> for the neophyte or the writer of the quick, throwaway bit of code.

Which flexibility are you talking about? Attaching a device context (DC) 
to a canvas before you can draw into it?

> Drifting off topic a bit: Thinking about the different ways people
> look at code, and changing viewpoint dynamically, I wondered about
> the difficulties of creating FXRdoc, a graphical explorer of code
> which allows one to see trees of classes, expose all the constants a
> class inherits at once, or just its own, toggle showing of method
> code, .....

Have you seen the class browser from FreeRIDE? It doesn't work exactly 
as you described, but it's a pretty nifty tool for working with Ruby 
code. It could perhaps be extended to do some of the kinds of the things 
you're describing.