bug#35468: [PATCH] Refactor draw_glyph_string on X and w32

[Alex Gramiak <agrambot@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex Gramiak <agrambot@gmail.com>
>> Date: Sat, 27 Apr 2019 19:29:30 -0600
>> 
>> This merges x_draw_glyph_string and w32_draw_glyph_string together to
>> remove duplicated code.
>> 
>> I wanted to do it for NS as well, but it seems just a bit too different
>> to make it easily work.
>
> If we don't include NS in this, we won't actually gain enough to
> justify the reshuffle.

I still think that removing duplication between 2 out of 3 is worth it
considering the size of the removal, but I started to do this because
I'm working on a new backend (GTK without depending on X) that would
benefit from this refactoring.

> What prevented you from including NS, it looks to me the code is very
> similar?

Mostly the differences in clipping behaviour that seemed just slightly
incompatible with the way gui_draw_glyphs_string does it. I'll look at
it a bit harder.

It also doesn't have the two sections (the s->prev and s->next
conditionals) at the end, which I'm not sure is a bug or unnecessary
there. Those could just be surrounded by a (!FRAME_NS_P (s->f))
conditional though.

>> +struct draw_glyph_string_interface
>
> I'd prefer draw_glyphs_interface, it's shorter.  And given the
> comments below, maybe the name should be gui_interface.

draw_glyphs_interface doesn't seem bad, as long as glyph strings are the
only types of glyphs that are drawn (otherwise draw_glyphs would be too
broad).

I think gui_interface is too broad of a description, since many of the
terminal hooks and frame parameter handlers (setting GUI window
properties, accessing color structures, setting WM hints, etc.) could
also be considered as belonging to a GUI interface. Perhaps
gui_drawing_interface or graphical_drawing_interface?

> The result of this refactoring should be more low-level and more
> primitive interfaces, and they should each one make sense, not be
> ad-hoc.  It means the job becomes more complex, and you will probably
> need to ask questions regarding the GUI systems you are less familiar
> with.  But the result will IMO much better and future-proof.

I'll see what I can do.