On 13.03.2012 06:28, Greg Ercolano wrote:
> On 03/12/12 20:30, J. Liles wrote:
>> However, when I dig into the FLTK code to look for a place to
>> install this permanently, I find a bizarre mess of #if defined(USE_X11)
>> type junk. What is the point of having different classes that inherit
>> from Fl_Graphics_Driver if you're just going to implement everything
>> in the base class using conditional compilation?
>
>       I believe what you're seeing is the process of
>       a dramatic code change that occurred in 1.3.0
>       where the graphics abstraction was first introduced.
>
>       Answering for Manolo, who I think took on quite a bit
>       of the heavy lifting of implementing the new abstraction
>       layer, I take it this was planned as a two step process:
>
>               1) Take the old style code where each drawing
>                  operation has its own .cxx file (fl_rect.cxx,
>                  fl_vertex.cxx, etc) and add the abstraction classes
>                  around that, leaving the code in the same files.
>
>                  This way any problems introduced during the change
>                  could be quickly fixed by other devs not yet up to
>                  speed on the abstraction transition.
>
>               2) Once a few maintenance releases go by to debug the
>                  abstraction arrangement where the code can stabilize,
>                  the code would be combined into the new 'per platform'
>                  Fl_Xxx_Graphics_Driver class files
>
>       So what you're seeing is not a so much a messy design,
>       but rather a careful code transition due to a major change.
>
>       Now I know Manolo put a lot of effort into all this,
>       so please give the devs a break; 1.3.0 had some enormous
>       code changes; the entire text system transitioned to utf8,
>       mac transitioned from Carbon to Quartz, printer abstraction
>       and graphics abstraction was added for all drawing, and
>       doxygen-ification of all the docs and comments.
>
>       We support a lot of platforms and compilers, so there is
>       a bit of legacy under the hood that is still being cleaned up.
>
>       It's good that you point this out though, but patience please;
>       we're a small dev team.
>
>       So I'd expect you'll see a cleanup of this stuff over the next
>       few maintenance releases.
>
>       For now, I think anyone looking to implement a new
>       graphics layer will have to be aware of the history of the
>       code in its old and new state while we go through the
>       transition.

Well put !

Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to