|
|
On 4/29/21 9:16 PM Manolo wrote:
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.
Okay, understood and accepted. The static method avoids making the
driver() method public and that's good.
So please ignore that part for further discussion.
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 ...
Sure.
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.
Okay, but this has nothing to do with my second question to introduce
the methods (1) and (2) above.
Please look back at my suggestion (1). That point has nothing to do with
internal driver classes.
You could also take it as a general RFE. We have fl_read_image() but
this returns only a data array. The proposed function would return an
Fl_RGB_Image.
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.
Fl_Gl_Window /is/ derived from Fl_Window anyway. So you can define
virtual Fl_RGB_Image * Fl_Window::capture_rectangle(x, y, w, h);
and redefine/reimplement it in class Fl_Gl_Window. This can even be done
if the implementation of Fl_Window::capture_rectangle() is in lib fltk
and Fl_Gl_Window::capture_rectangle() is in libfltk_gl.
This method /could/ also be public, there's no reason not to let users
use this.
So let me rephrase my suggestion. What about adding
virtual Fl_RGB_Image * Fl_Window::capture_rectangle(x, y, w, h);
to the public API in addition to fl_read_image() ?
My view is that this division in two orthogonal hierarchies ...
Again, the proposal above has nothing to do with the internal
implementation of drivers. It's just an implementation of virtual
functions in derived classes Fl_Window and Fl_Gl_Window, resp.. The
final implementation in either class would presumably use the
Fl_Window_Driver and Fl_Gl_Window_Driver internally, but that's the case
anyway. (As you say, this is orthogonal to the widget hierarchy.)
PS: I'm not sure whether proposal (2) is as useful as (1), so let's not
talk about (2) for now. I need to look into more details first.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/f1726969-091b-bb40-bdd0-567c1db16553%40online.de.
[ Direct Link to Message ] | |
|
| |