Re: [Fxruby-users] API documentation

[Hugh S. S. E. E. <hg...@dm...>]

On Tue, 2 Sep 2003, ly...@kn... wrote:

>
> > I still seem to be seeing the old one (09-Jun-2003), have refreshed
> > my browser (Firebird) twice.
>
> Very strange. I just went back to check the files page at SourceForge:
>
>     http://sourceforge.net/project/showfiles.php?group_id=20243

Oh, I'm coming in from FXRuby.org/doc/api ...
>
> and mine is definitely showing the "20030901" snapshot.
>
> > I notice that FXGLViewer starts with :
> > "Canvas, an area drawn by another object" ...
>
> Obviously, this is an example of cut and paste gone bad. I just checked the
> FOX header files and the same comment appears in FXGLViewer.h (the C++
> include file for the FXGLViewer class).
>
> > ... which would seem to contradict
> > http://www.fxruby.org/doc/opengl.html
> > which says that FXCanvas must point at an FXGLVisual in order to
> > work because the canvas provides no state.
> >
> > This seems to ba a "false" clue as to how to make the scribble
        [....]
> > this non-orthogonal approach, but it seems disappointing, to me.
>
> It is true that both FXGLCanvas and its subclass, FXGLViewer, must have a
> reference to an FXGLVisual which describes their capabilities (e.g. the
        [...]
> FXGLCanvas widget is very much like the (non-OpenGL) FXCanvas widget in the
> sense that it doesn't "remember" what has been drawn into it.

Yes.
>
> Now, FXGLViewer is a different story. You can assign a "scene" to an
> FXGLViewer, and whenever the FXGLViewer needs to repaint itself, it uses the
> state information in that scene. The scene is a reference to an FXGLObject
> (or one its subclasses, almost always an FXGLGroup).

That's roughly what I was thinking. Thank you.
>
> What FOX/FXRuby does *not* have (although it would be nice) is a 2-D
> equivalent to the FXGLViewer. That is, there is no 2-D, non-OpenGL type
> widget that can automatically redraw itself based on some scene or model

That's what I was thinking when I commented about non-orthogonality.

> object. Tk's Canvas is such a widget and might be a good model for someone
> interested in developing such a widget.
>

This seems to be the sort of essential functiaonality that deserves
encapsulation in some kind of object.  Fox has a good set of widgets
with things like dials that Tk doesn't have, etc, but in trying to
move from Tk to Fox I have been finding the learning curve very
steep.  It seemed easier to get going with Tk.  So how can I change
this from just a whinge :-) to constructive criticism?  Well, I'm
new to fox so lots of this may be invalid, but I think that Fox
would benefit from having:

 * A 2-d object that holds graphic state, as mentioned above.
 * A simple means to operate controls programmatically, to aid test
   driven design.  I'd suggest something like FXPseudoMouse and
   FXPseudoKeyboard for starters, which can be pointed at an
   FXObject and will manage the sending of events to it.
 * More documentation with examples is needed, but this is ongoing
   anyway, and will happen in due course.  I think a map, graphical
   if necessary, of the widget hierarchy would be really useful,
   like Rdoc's middle pane but tree structured...? There are some of
   these on the web, but I can't seem to see the motorways/freeways
   for all the minor roads and cul-de-sacs that show up on the maps.
 * I'm not entirely sure why FXTreeItems are not just FXTreeLists,
   in the way that Trees are normally defined in computer science.

Do these comments seem valid, or are they the equivalent of saying
"If I write
#define { BEGIN
#define } END
I can make C code more like the Pascal I've grown to love" :-), (i.e.
tactless and rather stupid in the hindsight I don't have yet)?

Thank you for your continued help on this path,
        Hugh