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.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
