| |
| |
On 3/22/22 18:26 Bill Spitzak wrote:
I see no reason you cannot use global variables
instead of function calls for these pointers.
Yes, generally you can use global variables but those used today
(one name for all platforms) can't be used further because different
platforms require different types. As long as you had only one
platform active in the build at any time this was no problem
(although it made things sometime very complicated).
I've also seen too often that global variables exposed to user ode
make later changes almost impossible. The existing global variables
(e.g. fl_display) are also user-writable IIRC. All these points are
reasons to use accessor functions instead.
The variables are there entirely so that other
platform-specific code can use them. You should be able to
rename them because all the users of them can change the names
as well.
Yes, we can do this. But if we rename them in one step backwards
compatibility is gone. We'd have to keep at least both variable
names for some time. Exporting accessor functions to these variables
makes sure we have full control (read-only) and we can change the
function later if required.
I would very very much like to get rid of this idea that
the platform is supported by virtual functions, and return to
a state where it is controlled by ifdefs which can change how
fltk functions are implemented, either by using completely
diffferent versions of the functions, or ifdefs inside their
internals, which is a very useful feature we lost with this
virtual function idea. In particluar it would allow x-only,
wayland-only, and the hybrid version to use the same source
code.
No, it wouldn't. In the classic style you have only one platform
enabled during compilation. In the future (with a "hybrid" FLTK lib)
we'd have more than one platform concurrently. #if ... #elif ...
#elif ... #endif does no longer work. We would have to use #if
platform-1 (code1) #endif, #if platform-2 (code2) #endif and both
platform-1 and platform-2 expressions (e.g. X11 and Wayland) could
be active at the same time.
That said, and as I already wrote before: we made a conscious
decision to go away from the #ifdef ... style and use the current
driver model. This is not going to be reverted. I'm sorry to say
that to you, Bill, but that's a fact. One of the main persons in
this decision process was Matthias, and the decision was mainly
driven by the fact that the old style wouldn't scale to more
platforms (we had three at that time).
Meanwhile we removed some experimental platforms (SDL, Pico,
Android) and added Wayland. Note that the removal of the
experimental platforms was done in minutes, mainly by removing
entire directories and editing the two platform specific header
files. It would likely have taken days to remove platform specific
code from the old-style #ifdef structure by editing all necessary
files. This is modularity that helps to maintain the library. The
inverse process to add Wayland was mostly done by adding the Wayland
specific driver directories with their own virtual driver methods.
The only code that was required to support it was a design decision
to split the driver base so we had another Fl_Unix_Driver but that's
another point.
In addition it is absolutely required that the X11 version
be changed to use Cairo rendering.
This is work in progress and will be done.
PS: Bill, please don't top-post here. It's hard to keep the context.
On
Tue, Mar 22, 2022 at 8:14 AM Albrecht Schlosser <AlbrechtS.fltk@online.de>
wrote:
On 3/22/22 15:42 Manolo wrote:
Le lundi 21 mars 2022 à 20:31:53
UTC+1, Albrecht Schlosser a écrit :
…
What to do in FLTK 1.4?
In FLTK 1.4.0 with Wayland support we must ensure
that the "Operating System Issues" are documented in
a clean and future proof way and that typedefs and
globals are not shared between X11 and Wayland
modes. Rather than using the globals fl_display etc.
we should define functions to access the platform
specific variables and objects as required (see
suggestion above).
Note that we *MUST* IMHO do this before FLTK 1.4.0
gets released because we couldn't easily go back
once it is documented and published.
Defining new, similar functions for the X11 and
other platforms would be optional in FLTK 1.4.0 but
could be done as well. The "old interface" with
typedefs and globals would be deprecated (for legacy
applications) and new applications or those that
want to be "hybrid" as well and still use platform
specific code would have to use the "new interface".
So far my thoughts but this is probably far from
complete. It should be a beginning...
Comments and suggestions appreciated.
I appreciate very much this input on this topic
because I see it's very important and also complex to
solve.
I will look into these proposals and try to
implement the beginning for 1.4.0
Thanks for doing this, but please keep in mind that my
suggestions are so far only thoughts and theoretical. We'll
need to find out if this theory works and then find a
migration path for future versions.
I'll try to look into it further to see if I can improve my
ideas, but please go ahead, you may know better than I what
to do.
--
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/c4e4f9ab-474c-586c-8d79-f1731e000deb%40online.de.
[ Direct Link to Message ] | |
|
| |
