RE: [gtkmm] Comments on tutorial

[RMM <morelli cs utah edu>]

On Wed, 2003-11-19 at 01:15, Murray Cumming Comneon com wrote:
> > comment in the declaration of CustomDrawingArea:
> >
> >   //TODO: Why do we store m_width and m_height?  murrayc
> >
> > which makes no sense in its context.  I assume this code was already
> fixed,  or it was copied from somewhere where it might 
> > have made sense.
> 
> Yes.
> 
> > Second,  the main method contains the unexplained line:
> >
> > Gtk::Main main_runner(argc, argv);
> 
> It's a very basic gtkmm technique, explaind in the "Basics" chapter:
> http://www.gtkmm.org/gtkmm2/docs/tutorial/html/ch03.html#id2807900
> 
> > Looking back over previous chapters,  I see the line
> >
> > Gtk::Main kit(argc, argv);
> >
> > in the corresponding place,  which is explained in the beginning of the 
> > tutorial.  I notice that the author of chapter 14 (M'Sadoquesis) is
> different from the author of the previous chapters,  
> > which may help 
> > explain this.  Someone needs to advise the author of chapter 14 to get in
> line with the previous chapters.
> 
> I don't see the problem. It's just a variable name that's different. You can
> write
> Gtk::Main soylentgreen(argc, argv);
> if you like. It won't make any difference.

It won't make any difference to the compiler,  but if there's no reason
to call the variable soylentgreen,  it's going to confuse a human
reading the code.  It's admittedly a minor point,  but I don't think
it's a good idea in a tutorial to call something "kit" for 13 chapters
and then start calling it "main_runner" for no particular reason.
In fact,  perhaps this is a place where a general convention might make 
sense,  since I assume almost every gtkmm program needs such a variable.

> > Another thing that surprised me was that there was no interactive 
> > example in the chapter,  such as a drawing application,  or at least
> something that responds to a mouse click or anything.  I > think of that as
> a sort of hello world for canvas type widgets.
> 
> That might be nice. You might look at the "Monster Masher" game and, after
> you have learnt how, provide an extra example, or add to one of the
> examples. Patches are welcome.

Well,  a game would be nice as a mega-example,  if it illustrates a lot
of points at once.  I had in mind something simple,  like painting a 
small circle at a point where you double click the mouse.  A 
bigger example would be a simple "object-oriented" paint program that
draws movable rectangles and ellipses.

> Note that libgnomecanvamm or foocanvasmm might be more suitable for you.
> 
> > Instead of dealing with normal interactive events like mouse events, the
> example programs are all built around around 
> > responding to the expose event (in on_expose_event).  Why?  On first
> impression,  this strikes me as rather strange.
> 
> That's a fundamental part of using a Drawing Area, as mentioned in the first
> paragraph of the chapter:
> http://www.gtkmm.org/gtkmm2/docs/tutorial/html/ch14.html
> 
> Maybe it should be made even clearer though.

What it says is clear enough.  It's probably me who's not being clear.
It just seems to me that the emphasis is in the wrong place and the 
examples are slightly artificial.  I would expect on_expose_event to
be as minimal as possible,  just invoke some paint routines that paint 
something determined by some stored state.  It shouldn't have details 
in it.  And painting in general has to be separate from on_expose_event
anyway,  because normally you'll be painting in response to some kind
of interaction,  like mouse clicks,  so you won't be getting expose
events.

> Murray Cumming
> www.murrayc.com
> murrayc usa net
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>