Re: Merging x*, w32* and mac* sources (was Re: table.el)

[Jason Rumney]

address@hidden (Kim F. Storm) writes:

> I don't see why we cannot combine all of these methods to achieve as much
> code sharing as possible (and desireable).
> 
> 1) Try to emulate X* functions directly whenever that is possible,
> 
> 2) put a small wrapper around the X* functions (e.g. supplying additional
>    arguments) if that makes it possible to emulate the "wrapped" function, 

One possible way to decide between these could be to look at what GTK
does. If a GTK port would do it differently than current X code, use
a higher level of abstraction (2), if GTK would use the X functions
(or something virtually identical), then macros/functions that emulate
the X function are probably feasible for all platforms.


> 3a) for larger functions, find common and non-common sub-functions and
>    make it easy to write emulations for the non-common parts, e.g.
>    (supposing we use the x* files as the base version, whereas the w32 and
>     mac files supply stub functions):
> 
>         x_some_func(f, g)
>         {
>                 // common code
>                 ...
> 
>                 // non-common code
>         #ifndef HAVE_X_WINDOWS
>                 stub_some_func(f, ...)
>         #else
>                 // the X-version of the code is here
>         #endif
> 
>                 // more common code
>                 ...
>         }
> 
> 3b) or if we separate the functions into com* and x/w32/mac files:
>    (where the x files will also supply the stub function):
> 
>         x_some_func(f, g)
>         {
>                 // common code
>                 ...
> 
>                 // non-common code
>                 stub_some_func(f, ...)
> 
>                 // more common code
>                 ...
>         }

I think it depends how much code is involved. If all platforms only
differ by one or two lines, then we might as well use #ifdef blocks
and inline the code for all platforms. If Windows/Mac need a lot of
code to implement what can be done in X using a single system call,
then use 3a. If all platforms need substantially different code to do
the same job, then use 3b.

> BTW, I noticed that the w32_output structure has a small (almost
> dummy) x_output structure at the start to allow a few generic
> occurrences of f->output_data.x->...

This was a byproduct of merging w32faces.c and xfaces.c about a year
ago. I intended to put more of w32_output in the x_output structure,
but all that was needed for xfaces.c was what is in there now.

> Actually, it could probably just be the normal x_output structure
> with the last part conditioned by HAVE_X_WINDOWS.

Yes. It may mean reordering x_output (which is why I didn't go ahead
and do it at the time, because the pretest was about to start).


-- 
Jason Rumney