Am 20.03.2010 11:33, imacarthur wrote:
>
> On 20 Mar 2010, at 9:07, manolo gouy wrote:
>>>
>>> Documentation of fl_draw() etc.: Meanwhile I came to the conclusion
>>> that I like to see all drawing methods in the Fl_Device class
>>> context. Maybe it would be a good idea just to add
>>>
>>> \see Fl_Device::draw()
>>>
>>> or similar to the old (and now undocumented) fl_draw() etc. functions.
>>> Then we could add a back-link or note that the draw() etc. methods are
>>> called by the corresponding fl_draw() etc. function.
>>>
>>> What do you think about that?
>>>
>>> Albrecht
>>
>> Do you mean that FLTK end users should now preferentially use, e.g;,
>> fl_device->draw("xxx", x, y);
>> instead of
>> fl_draw("xxx", x, y);
>> ?
>>
>> This is an interesting suggestion, but it would be a major change
>> to be carefully discussed.
>
> I assumed that Albrecht was only referring to the docs...
> I don't think I'd be all that keen on "changing" all my code.
That's correct. Nobody should need to change code. Only the docs
would look like this:
----
fl_draw(char *text, int x, int y)
Draws text ... (only "brief" description line).
\see Fl_Device::draw(char *,int,int);
----
Fl_Device::draw(char *text, int x, int y)
Draws text ... ("brief" description line).
\note This method is called by fl_draw(char *,int,int). Don't
call it directly, except from other devices' drawing methods.
\see fl_draw(char *,int,int) [optional, see ref. above]
Description ...
----
So or similar. Reasoning:
The main documentation would stay where most of the code is. In the
future this might change slightly because we will need to split the
device drawing code in different files for different platforms, but
IMHO still most of the drawing code and the docs could stay in the
base Fl_Device class. Deviations and additions would then have to
be documented in the derived classes (Fl_GDI_Display etc.).
We should make the mechanics of drawing by different Fl_*_Device
classes public anyway, so that there is a clear interface how to
add other devices (e.g. frame buffer).
Drawback: it could be confusing to have to switch from fl_draw()
to Fl_Device::draw() in the docs to find something, but once you
know how it is designed, this would probably be "normal".
Note: this is only "thinking loud", I don't know if it is feasible.
Please comment.
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
