FLTK logo

Re: [fltk.coredev] Re: [master] 9df287b - Cleaner access to Fl_Gl_Window_Driver objects.

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Re: [master] 9df287b - Cleaner access to Fl_Gl_Window_Driver objects. Albrecht Schlosser Apr 29, 2021  
 
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 ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.