Greg Ercolano wrote: > Fabien Costantini wrote: >> Albrecht wrote: >>>> Solution #1 (the documentation is correct, the code is wrong) [..] >>>> >>>> Solution #2 (the code is correct, the documentation is wrong) [..] >>>> >>>> Solution #3... A mix of both? >> Or solution #4 [deprecate fl_rect() and make new functions fl_fast_rect() + >> fl_draw_rect()] > > I'd be -1 on deprecating fl_rect() and friends.. it's a good API name > and implementation, and those calls are used a lot by existing > widget libraries.. would hate to see it obsoleted.
Seconded. Too much code out there is using it at is. We must not change it. > My opinion is leave fl_rect() alone, and just document its intended use > for 1-pixel widget drawing only, and fl_line_style() may yield certain > unpredictable results. I added some new comments to the mentioned STR #2108 (please see there). After all I think that we should correct the documentation to tell what the functions really do (they use the given line style and work as other line drawing functions). And I think that the results are not as unpredictable as I thought some hours ago. Thus my preferred solution is #2 (the docs are wrong). > I suppose if a convenience function is needed to be compatible with > line styles, then add a new API function, eg. fl_rect_line(), that > could do the four fl_line() calls. Adding one additional options argument (a bit mask) for alignment, anti-aliasing, clipping, and maybe more would do it. Maybe ;-) . The default would be the current behavior. > I don't imagine fl_rectf() (filled rectangle) needs anything new, > as it doesn't deal with lines or borders IIRC. Yes, I think that's correct. Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
