[email protected] wrote:
> Author: matt
> Date: 2009-04-18 11:52:59 -0700 (Sat, 18 Apr 2009)
> New Revision: 6770
> Log:
> Updated doxygen docs for Fl_Input_ to get a greater insight into the code.
> I'll try to get full Unicode support in soon. The current code uses some
> interesting solutions ;-).
>
> Modified:
> branches/branch-1.3/CHANGES
> branches/branch-1.3/FL/Fl.H
...
I'm wondering, why you did the following changes (adding "\c") at
places where doxygen does its own link highlighting.
IMHO we should *not* add \c to links that are recognized by doxygen
automatically. Otherwise we'd have to do this everywhere, and that's
not the idea of using doxygen. (And personally I think that it looks
worse than before).
> Modified: branches/branch-1.3/FL/Fl.H
> ===================================================================
> --- branches/branch-1.3/FL/Fl.H 2009-04-18 11:51:32 UTC (rev 6769)
> +++ branches/branch-1.3/FL/Fl.H 2009-04-18 18:52:59 UTC (rev 6770)
> @@ -852,29 +852,29 @@
>
> These functions support deletion of widgets inside callbacks.
>
> - Fl::delete_widget() should be called when deleting widgets
> - or complete widget trees (Fl_Group, Fl_Window, ...) inside
> + \c Fl::delete_widget() should be called when deleting widgets
> + or complete widget trees (\c Fl_Group, \c Fl_Window, ...) inside
> callbacks.
>
> The other functions are intended for internal use. The preferred
> - way to use them is by using the helper class Fl_Widget_Tracker.
> + way to use them is by using the helper class \c Fl_Widget_Tracker.
>
> The following is to show how it works ...
>
> There are three groups of related methods:
>
> -# scheduled widget deletion
> - - Fl::delete_widget() schedules widgets for deletion
> - - Fl::do_widget_deletion() deletes all scheduled widgets
> + - \c Fl::delete_widget() schedules widgets for deletion
> + - \c Fl::do_widget_deletion() deletes all scheduled widgets
> -# widget watch list ("smart pointers")
> - - Fl::watch_widget_pointer() adds a widget pointer to the watch list
> - - Fl::release_widget_pointer() removes a widget pointer from the watch
> list
> - - Fl::clear_widget_pointer() clears a widget pointer \e in the watch
> list
> + - \c Fl::watch_widget_pointer() adds a widget pointer to the watch list
> + - \c Fl::release_widget_pointer() removes a widget pointer from the
> watch list
> + - \c Fl::clear_widget_pointer() clears a widget pointer \e in the watch
> list
> -# the class Fl_Widget_Tracker:
> - - the constructor calls Fl::watch_widget_pointer()
> - - the destructor calls Fl::release_widget_pointer()
> + - the constructor calls \c Fl::watch_widget_pointer()
> + - the destructor calls \c Fl::release_widget_pointer()
> - the access methods can be used to test, if a widget has been deleted
> - \see Fl_Widget_Tracker.
> + \see \c Fl_Widget_Tracker.
>
> @{ */
> // Widget deletion:
> @@ -937,11 +937,11 @@
> /**
> This class should be used to control safe widget deletion.
>
> - You can use an Fl_Widget_Tracker object to watch another widget, if you
> + You can use an \c Fl_Widget_Tracker object to watch another widget, if you
> need to know, if this widget has been deleted during a callback.
>
> This simplifies the use of the "safe widget deletion" methods
> - Fl::watch_widget_pointer() and Fl::release_widget_pointer() and
> + \c Fl::watch_widget_pointer() and \c Fl::release_widget_pointer() and
> makes their use more reliable, because the destructor autmatically
> releases the widget pointer from the widget watch list.
>
> @@ -950,7 +950,7 @@
> scope is left. This ensures that no stale widget pointers are
> left in the widget watch list (see example below).
>
> - You can also create Fl_Widget_Tracker objects with \e \b new, but then it
> + You can also create \c Fl_Widget_Tracker objects with \c new, but then it
> is your responsibility to delete the object (and thus remove the
> widget pointer from the watch list) when it is not needed any more.
Most of the following changes are IMHO okay:
> /**
> - returns a pointer to the watched widget.
> + Returns a pointer to the watched widget.
>
> - This pointer is NULL, if the widget has been deleted.
> + This pointer is \c NULL, if the widget has been deleted.
> */
> Fl_Widget *widget() {return wp_;}
>
> /**
> - returns 1, if the watched widget has been deleted.
> + Returns 1, if the watched widget has been deleted.
>
> This is a convenience method. You can also use something like
>
> - if (wp.widget() == 0) // ...
> + <tt> if (wp.widget() == 0) // ...</tt>
>
> - where \e \b wp is an Fl_Widget_Tracker object.
> + where \p wp is an \c Fl_Widget_Tracker object.
> */
> int deleted() {return wp_ == 0;}
>
> /**
> - returns 1, if the watched widget exists (has not been deleted).
> + Returns 1, if the watched widget exists (has not been deleted).
>
> This is a convenience method. You can also use something like
>
> - if (wp.widget() != 0) // ...
> + <tt> if (wp.widget() != 0) // ...</tt>
>
> - where \e \b wp is an Fl_Widget_Tracker object.
> + where \p wp is an \c Fl_Widget_Tracker object.
Note: \p is equivalent to \c, so this should be:
> + where \c wp is an Fl_Widget_Tracker object.
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
