On Thursday, April 29, 2021 at 12:36:59 PM UTC+2 Albrecht Schlosser wrote:
Here I'm wondering if it's "a good idea" to add that static method
to return the driver.
With that, we have similar ways to access to Fl_Window_Driver and Fl_Gl_Window_Driver objects
of the form
static Fl_XX_Driver *Fl_XX_Driver::driver(Fl_XX *object)
These methods are not part of the public API, because they are in the drivers, and the driver member
of each class remains private. It would be possible to make the driver member public, but they would become
visible to the public API.
My second question is if we really need '
capture_gl_rectangle()'
rather than having a '
virtual capture_rectangle()' method
that automatically does "the right thing"?
What about using the Fl_Window object to do the stuff we need to do,
maybe with functions like these:
(1) virtual Fl_RGB_Image * Fl_Window::capture_rectangle(x, y, w, h);
This method would have (virtual) reimplementations in all subclasses and work with Fl_Gl_Window as well.
(2) virtual Fl_Window::draw_overlay();
This method would do nothing for normal windows but would have
(virtual) reimplementations in all subclasses that need it. Maybe it
could only be defined for classes that require it (not in the base
Fl_Window class).
The current situation is that we have hierarchies of classes and derived classes with virtual methods whose code is
platform-independent. Virtual methods allow for example to implement the resize operation adequately for widgets, groups, and windows.
Orthogonal to that, we have hierarchies of driver classes with derived classes for each supported platform. These methods
contain all the platform-specific code present in FLTK.
That situation is visible with the widget tree to which 2 driver trees are connected, those rooted at Fl_Window_Driver and at Fl_Gl_Window_driver.
It's visible also in the tree rooted at Fl_Surface_Device, connected to trees rooted at Fl_Image_Surface_Driver and at Fl_Copy_Surface_Driver.
With Fl_Gl_Window objects, there's an additional strong constraint that all GL-related code must be in libfltk_gl whereas libfltk
cannot use any member function of class Fl_Gl_Window. I'm not sure a single Fl_Window class with derived classes both for special
windows and for all platforms can accomodate that constraint.
My view is that this division in two orthogonal hierarchies is easily understandable and allows to hide completely all platform-specific
aspects from the FLTK public API. For sure that is the solution to which we, Matthias and I, arrived when we decided to convert FLTK
to the driver model. Others may exist, but this one does work, and has proven able to accomodate new platforms (e.g., Android)
without any change to the platform-independent code base.
