On 6/7/21 11:41 PM Greg Ercolano wrote:
On 6/7/21 2:26 PM, Bill Spitzak wrote:
What I meant for Device was to replace it with
code like this:
#if X11
#include <X11code.C>
#elif Windows
#include <Windowscode.C>
I had used that technique in the native file chooser,
but it was changed.
That technique was generally recommended IIRC in an
old O'Reilly book
on multiple platform code management I've had for decades
now.
And that's exactly the point. It's decades old!
This type of code is not at all scalable (by platform). You can see
this in our old (1.3) code that has exactly that, with the (above
missing) #else case. It was usually something like:
#ifdef _WIN32 // Windows
...
#elif defined(__APPLE__) // macOS
...
#else // X11
...
#endif
which *implied* that the #else case is Unix/Linux/X11. This also
precluded (basically) using X11 on macOS (which is definitely
possible). Whenever you add another device/platform/driver/backend
(call it as you like) you need to add yet another #elif case at
*uncountable* places. That's the nightmare we got rid of by moving
to the "driver" structure.
This driver structure is unlimited extensible by adding "just
another class" with selected virtual methods that need to be
overridden (sharing the code of not overridden methods). This is the
ideal case. You can see it in the drawing code of the Wayland
graphics driver which reuses existing Cairo driver code.
In practice, I admit, this is not as easy as it sounds. It tends to
"copy and paste" code from one driver to another one, fix the "few
statements" that need to be replaced, and then you end up with lots
of duplicated code that needs to be maintained (mainly in the system
specific parts). That's bad and not intended. The "correct" way
needs a finer granularity of functions (virtual methods) and a good
design. This is harder to achieve but possible (and that's why I
asked Manolo about the current status of his edits and his plans for
completion).
Example: We have three totally different ways to implement timer
related code: Unix/Linux (Posix), Windows, and macOS. This led to
incompatibilities (macOS) and lack of accuracy (Windows). I don't
want to write about more details here, but I believe that a better
implementation would be doable in platform-agnostic code with only
minor system specific functions (here: virtual driver methods).
Copying the Linux/Unix/Posix code to "Wayland drivers" (which has
been done during the development) is NOT the final solution
(hopefully). That's only one example...
