RFC: why is Fl_Window::flush() protected?

[Albrecht Schlosser]

Fl_Window::flush() is virtual and protected.

In all derived window classes flush() is virtual and public.

I don't see a reason why this is so, maybe it's by accident? I verified that the situation is the same in FLTK 1.3.x.

RFC: Should we make Fl_Window::flush() public?

No one complained but it looks neither required nor intended that it's protected.

Details:

This minimal (complete) example program shows the issue:

#include <FL/Fl_Double_Window.H>

int main(int argc, char **argv) {

auto window = new Fl_Window(340, 180);

window->end();

window->show(argc, argv);

window->flush();

return Fl::run();

}

Error message from `fltk-config --compile`:

test/hello.cxx: In function ‘int main(int, char**)’:
test/hello.cxx:22:16: error: ‘virtual void Fl_Window::flush()’ is protected within this context
   22 |   window->flush();
      |   ~~~~~~~~~~~~~^~
In file included from [...]/FL/Fl_Double_Window.H:23,
                 from test/hello.cxx:17:
[...]/FL/Fl_Window.H:102:16: note: declared protected here
  102 |   virtual void flush();
      |                ^~~~~

"Solution":

Replace 'new Fl_Window(340, 180);' with 'new Fl_Double_Window(340, 180);' or any other Fl_*_Window class and it works.

This doesn't look like intended. Since Fl_Window::flush() "makes the window current" I don't see a reason not to make it public.

Docs say: "Forces the window to be drawn, this window is also made current and calls draw(). "

[melcher....@googlemail.com]

+1

[Manolo]

I think the logic to have Fl_Window::flush() protected is that it's not useful for the library user

who can use public function Fl::flush().

In my view, the error is that its overridden variants in derived classes are public.
They should all be protected.

I notice that if these overridden members in derived classes are made protected,

libfltk and all test programs build with no error.

But we have to keep API compatibility.
So my vote is: don't change anything.

Le lundi 21 octobre 2024 à 20:30:21 UTC+2, melcher....@googlemail.com a écrit :

+1

[Albrecht Schlosser]

On 10/21/24 21:20 Manolo wrote:

I think the logic to have Fl_Window::flush() protected is that it's not useful for the library user

who can use public function Fl::flush().

Sorry, this argument doesn't make sense to me. The user who wants to "flush" one window would be forced to "flush" all windows.

Also, since the method is protected users can derive their own class and call MyWindow::flush() anyway.

In my view, the error is that its overridden variants in derived classes are public.
They should all be protected.

I can follow this argument. If it was intended that Fl_Window::flush() is protected - for whatever reason - then all the other subclasses should likely also be protected.

I would have appreciated if Bill could have shed some light on the reasoning why it was protected in the first place. Bill, are you reading?

I notice that if these overridden members in derived classes are made protected,

libfltk and all test programs build with no error.

Interesting, but irrelevant, because ...

[But] we have to keep API compatibility.

That's true. We can't reduce accessibility but we can open it, hence we could allow public access to Fl_Window::flush() in 1.4.

So my vote is: don't change anything.

Le lundi 21 octobre 2024 à 20:30:21 UTC+2, melcher....@googlemail.com a écrit :

+1

I prefer consistency, and therefore my vote is +1 to make Fl_Window::flush() public in FLTK 1.4 - unless I see more arguments for not doing it.

Current status: we have enough (3) votes (Matthias, Manolo, and me) and the net result is +1 to make Fl_Window::flush() public.

Any more comments?

[Manolo]

Le mardi 22 octobre 2024 à 13:54:56 UTC+2, Albrecht-S a écrit :

On 10/21/24 21:20 Manolo wrote:

I think the logic to have Fl_Window::flush() protected is that it's not useful for the library user

who can use public function Fl::flush().

Sorry, this argument doesn't make sense to me. The user who wants to "flush" one window would be forced to "flush" all windows.

……

 

I prefer consistency, and therefore my vote is +1 to make Fl_Window::flush() public in FLTK 1.4 - unless I see more arguments for not doing it.

Here is one argument: Fl::flush() does more than running Fl_Window::flush() on all dirty windows,

it also calls Fl_Screen_Driver::flush() which does platform-specific things such as XFlush(fl_display) under X11

and GdiFlush() under Windows. Calling just Fl_Window::flush() may not have any visible effect on the display.
And flushing the display only in Fl::flush() may be an optimization to eliminate redundant flush operations.

I'm not opposed at all to making Fl_Window::flush() public, but I believe it may be a false good idea.

[Bill Spitzak]

I think the intention was that only Fl::flush would be used by programs. I would make sure that the individual call works and does not rely on code that Fl::flush does. I believe on X and possibly all systems this will in effect flush some subset of the windows, not only the one that is called.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/c2a7b03b-5d27-4b90-b027-88e0d32172dfn%40googlegroups.com.

[Albrecht Schlosser]

On 10/22/24 18:25 Bill Spitzak wrote:

I think the intention was that only Fl::flush would be used by programs. I would make sure that the individual call works and does not rely on code that Fl::flush does. I believe on X and possibly all systems this will in effect flush some subset of the windows, not only the one that is called.

Thanks, Bill.

[Ciro Miranda (CiroInGiro)]

I think it is better to avoid a malfunction of Fl_Window with an override of Fl_Window::flush because if it malfunctions it will crash the whole application and not just the derived widgets.