The fact the issue arose in fltk.discussion is proof that the
reference to the "current path" present in the function's
one-line description is not enough. I would suggest to slightly
rephrase the first two sentences of the added text as follows to
connect it to the "current path":
Unlike the integer-coordinate \c fl_arc(x,y,w,h,a1,a2)
overload, this function requires a current path, that is,
it must be bracketed by matching fl_begin_*() and
fl_end_*() calls.
Sounds good to me; shorter is better.
On 8/29/26 08:35, 'Albrecht Schlosser'
via fltk.coredev wrote:
I'm generally fine with the suggested
changes, and I would also add what Manolo proposed to clarify it
even more.
Yep, agreed..
However, I'm not sure if "Valid path types are \c points, \c line,
\c loop, \c polygon, and \c complex_polygon" is correct in this
context. Can all these path types be combined with arcs ? I'm
leaving this open for now.
Pretty sure that's the case. I just wasn't sure if there were
other cases; I don't know much about "paths" in this context, but I
assume it's like opengl meshes and such.
Another point for better documentation
experience (doxygen related): I would change
"Unlike the integer-coordinate \c
fl_arc(x,y,w,h,a1,a2) overload"
to
"Unlike the integer-coordinate
fl_arc(int, int, int, int, double, double) overload".
Ya, I started with that fl_arc(int, int,
int, int, double, double) because it makes an accurate
link, but it seemed so long as to be confusing; easy for someone to
miss that one extra 'int'.. also that many unnamed types would
visually overwhelm the average reader, and adding actual names would
just make it even longer.
I figure the first few paragraphs of docs for a function/method
shouldn't get too far into the weeds right away.
I was wondering if there was a way to make a \ref so that I
could just say "fl_arc()" and the ref would point it at the right
actual function docs, just for brevety.
Anyway, curious if a \ref (or whatever it's called) might be a
better solution to avoid the int,int,int,int..
Furthermore, the given example is
superfluous, because there are already examples below the image.
Ya, again, I did that for clarity, because I think people might
not read below the diagram where the examples are. I know I missed
it just trying to quick review to answer that discussion, and I
stopped at the diagram because I knew that stuff, and didn't look
below it.
I guess I could move the examples up above the diagram, to
avoid the redundancy.
I'm not a friend of duplicating the same
information "everywhere". [regarding the "drawing with fltk"duplication]
Yeah, I'm not either, but I figure that's a rewrite of the
entire "drawing with fltk" section, a bigger issue.
I assume it's that way to make the intro into drawing easier
to understand, so the user doesn't have to jump around in the
docs. (One annoying thing about doxygen is if you click on a
link to another doc, then try to return to where you were with
the browser's Back button, you don't always end up where you
were..! I find I have to middle-click to open new tabs so I
don't loose my place)
To redo the doxygen docs, perhaps there's an \include
technique of some kind so the docs from elsewhere get pulled in to
that same location, avoiding duplicate docs.
Comments are owned by the poster. All other content is copyright 1998-2026 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.
