FLTK logo

Re: [fltk.coredev] Please vote: add a Wayland platform to FLTK

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: Please vote: add a Wayland platform to FLTK Albrecht Schlosser Jan 11, 2022  
 
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.
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'.