| |
| |
The problem with the old code was that the "base" was the X11 version and everything else was ifdefs alternatives. The fltk2.0 code rearranged this so that "#if X11" worked and thus the X11 code could be put into it's own files where you don't have to see it if working on another platform, and also the attempts to make other platforms look like X11 (like #define things to XWindow, etc) were removed.
You are correct that another fix was to not try to merge different implementations excessively. But I do like that it can be done occasionally. I don't like having the lower-level functions exist because nothing is stopping client code from calling them directly and then we are stuck with the implementation.
On 1/11/22 11:58 PM Bill Spitzak wrote:
> I think we need to seriously fix this misuse of virtual functions.
What you consider a misuse has been a design decision many years ago
(but after your active participation). The advantage is to be open for
an unlimited number of "platforms" which turned out to be no longer
maintainable with the old three-platform #ifdef stuff.
I've just today compared new code with the old #ifdef code of 1.3.x -
although the new code is sometimes more difficult to understand the old
code was horrible to read for me. All that grown platform specific stuff
(handling of platform specific config directories) was way too
complicated - for only three platforms! Android is under development and
there's now Wayland, we have preparations for SDL(2), and the exotic
'pico' drivers. All in one code base would not be maintainable.
But we do know that the new strategy comes with a price we have to pay...
> As you note, this often requires it to compile code that will never be
> used, and may not compile on a given platform.
Normally this is not a problem because the drivers for each platform are
only compiled on the respective platforms. As Manolo mentioned, this new
split of Wayland from the common base used in parts for Unix/Linux and
macOS is much more complicated to do it right.
> The other problem is it pretty much links in *everything* to the vtab
> table so fltk ends up as a monolithic library.
All unused driver code is not compiled at all, such classes are not
known to the compiler and that makes it not link in *everything* to the
vtab table.
> It also requires any differences to be split at the function level,
> rather than just putting #if around some statements which could
> greatly reduce the size of the differences.
I agree, that's a valid point. But there's another option: splitting the
code in simpler functions where only the mostly very short platform
specific parts are splitted off. This has not always been done optimally
yet so that one can find (too) large parts of copied code in different
platform drivers. Admittedly, this is a problem we have now, but this is
IMHO not the design but just not (yet) optimal work in some parts. But
this can be improved.
--
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/2a603665-1949-fd4b-e61f-c261c6b430d7%40online.de.
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/CAL-8oAjCzceu6xW4Cpb7rzt1d6Rwo%2B4jLZ7zD5YdwJf6E2HB-g%40mail.gmail.com.
[ Direct Link to Message ] | |
|
| |
