fxruby-users

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

Re: [Fxruby-users] API documentation

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

Hugh Sasse Staff Elec Eng wrote:

> OK, then is is worth raising these issues with Jeroen?  Bearing in
> mind comments below, of course.

I'm not sure how to answer the question. While not presuming to speak 
for Jeroen, I think he'd probably agree with you that (for example) a 
2-D canvas object would be a nice thing to have. To put things in 
perspective, there's a survey running at the FOX Community Wiki site:

     http://www.fifthplanet.net/cgi-bin/wiki.pl

that indicates many additional things that people would like to see for 
FOX (including, as you mentioned, better documentation).

So I think it's worthwhile to raise these points, if for no other reason 
to add your voice to the chorus asking for feature X or Y. At the same 
time, it is important to understand that, for the most part, Jeroen is 
primarily going to work on things that are interesting to him.

Re: [Fxruby-users] API documentation

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

On Thu, 4 Sep 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > OK, then is is worth raising these issues with Jeroen?  Bearing in
> > mind comments below, of course.
>
> I'm not sure how to answer the question. While not presuming to speak

Your answer gave me what I wanted.  The ideas have some value, and
he is likely to be receptive.  (It might have been that he were so
snowed under he wouldn't want ANY suggestions till 2005! :-), so
you've given me useful input here.) Thank you

        Hugh

Re: [Fxruby-users] API documentation

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

On Tue, 2 Sep 2003, Hugh Sasse Staff Elec Eng actually wrote:

> Do these comments seem valid, or are they the equivalent of saying
> "If I write
> #define { BEGIN
> #define } END

MY GOODNESS!!  I've only been programming in C for...what?...16
years!?  How the photon did I write that backwards?   Maybe I should
stop trying to get 25 hours out of each day!  Or I should learn
FORTH.

> 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)?

        Hugh.

Re: [Fxruby-users] API documentation

[Lyle J. <ly...@kn...>]

Hugh Sasse Staff Elec Eng wrote:

>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.
>
Agreed.

> * 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.
>
Sure, this sounds like an interesting approach to the problem.

> * 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 think RDoc has an option for generating inheritance diagrams as part 
of its output. Let me investigate that and see how well it works in 
practice...

> * I'm not entirely sure why FXTreeItems are not just FXTreeLists,
>   in the way that Trees are normally defined in computer science.
>
Yes, we've discussed this previously on the list. I do not know all of 
the factors that went into this design decision by Jeroen, but it's 
unlikely to change at this point.

>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)?
>
Of course your comments are valid! But it's important to note that like 
so many open source software projects, FXRuby is something that I work 
on in my spare time, for free. So, for example, I can get motivated to 
write more documentation because I understand that this activity has the 
potential to save me time later. That is, if I answer the question in a 
tutorial or in improved API documentation, that's one less question for 
someone to ask down the road ;)

On the other hand, I don't have any personal need for a Canvas-like 
widget. If I did, I probably would have developed one by now. For that 
matter, if it were something I could knock out in an afternoon or two, I 
might go ahead and do it out of the kindness of my heart; but I have the 
feeling it's a more substantial development effort than that ;) If 
someone were to take this project on themselves, I would do my best to 
support them and, if it were their wish, incorporate it into the 
standard FXRuby library at some point.

Re: [Fxruby-users] API documentation

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

On Tue, 2 Sep 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > * A simple means to operate controls programmatically, to aid test
> >   [...] like FXPseudoMouse and FXPseudoKeyboard [...]
> >
> Sure, this sounds like an interesting approach to the problem.
>
thanks.

> > * More documentation with examples is needed, but this is ongoing
> >   anyway, and will happen in due course.  I think a map, graphical
        [...]
> >
> I think RDoc has an option for generating inheritance diagrams as part
> of its output. Let me investigate that and see how well it works in
> practice...

I don't have graphviz, and don't like the licencing [way off topic]
and would like to re-implement it with SVG, but haven't got my head
around rdoc internals yet...
>
> > * I'm not entirely sure why FXTreeItems are not just FXTreeLists,
> >   in the way that Trees are normally defined in computer science.
> >
> Yes, we've discussed this previously on the list. I do not know all of
> the factors that went into this design decision by Jeroen, but it's
> unlikely to change at this point.

I'll maybe ask, because understanding, well, probably "teleology" is
the right word here, can aid in seeing the whole picture.
>
> >Do these comments seem valid, or are they the equivalent of saying
> >["]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)?
> >
> Of course your comments are valid! But it's important to note that like

OK, then is is worth raising these issues with Jeroen?  Bearing in
mind comments below, of course.

> so many open source software projects, FXRuby is something that I work
> on in my spare time, for free. So, for example, I can get motivated to

Absolutely: there is no obligation for anyone to shape the world to
suit me. I think these things might possibly be worthwhile enough to
help other people, help the uptake of FOX, and thus help bring
"hands to the pump" as far as supporting the code base goes. But
that is hypothesis/speculation!

> write more documentation because I understand that this activity has the
> potential to save me time later. That is, if I answer the question in a
        [...]

Yes, also why when I make notes about things I put them on the web.
I probably use them more than other people!
>
> On the other hand, I don't have any personal need for a Canvas-like
> widget. If I did, I probably would have developed one by now. For that

Agreed. And if I knew enough about the internals and had time I
gladly contribute.

> feeling it's a more substantial development effort than that ;) If

Yes, but I suspect that some FOX "black belts" may find this easier
than either of us to do.  This is really what my question of
validity is about: is it worth suggesting these features? Sometimes
outsiders can't contribute much that is material, but the fresh
viewpoint alone can throw up something useful. Hence lateral
thinking.  Once my mind is shaped by Fox I won't be able to do that,
so this discomfort may be worth something in itself.

> someone were to take this project on themselves, I would do my best to
> support them and, if it were their wish, incorporate it into the
> standard FXRuby library at some point.
>

        Thank you,
        Hugh