Opal backend: make functional again

[pkgdemon]

Summary

The opal backend in libs-back has been non-functional for years.
This PR is the minimum set of changes to make it usable again.
All changes are confined to Source/opal/ plus one declaration in
Headers/opal/OpalSurface.h.

This does require my other PR to be merged:

gnustep/libs-opal#16

What's fixed

• Surface attachment. OpalSurface no longer calls
  OPX11ContextCreate before the X window is mapped (which produced
  a non-drawing context). A new lazy -ensureX11Context creates the
  X11 context on first expose; the accessor calls it so every
  OpalGState.m consumer is covered without per-site edits. Resize
  is handled for free since XGServer recreates the surface.
• Drawing ops (OpalGState.m): filled in missing paths, fixed
  CTM and clipping around the compositing path.
• Font hinting (OpalFontInfo.m): propagate hint settings to
  cairo font options; correct _cairo_extents_for_NSGlyph.
• Gradients and blend modes: implemented CG linear/radial
  gradients; mapped NSCompositing operators onto CG blend modes.
• Grayscale colors: convert NSColor gray values to device-RGB
  CGColorRef so gray fills/strokes take effect.
• Window-drag smearing: flush both backing and X11 contexts in
  -handleExposeRect:.

Scope

No other backends touched. No shared code (Source/gsc/,
Source/x11/, Source/gui/) touched. Cairo path is unaffected.

Building and testing

cd libs-back                                                                                                                                                                                                                                                                         
./configure --enable-graphics=opal --enable-server=x11                                                                                                 
make -j$(nproc)                                                 
sudo -E make install

Verified: opal-backed apps render correctly. Workspace (cairo-backed)

[pkgdemon]

@gcasa Here is the last PR for what we talked about last month in gnustep meeting. ^^

[pkgdemon]

@ivucica @fredkiefer Let me know if this is something GNUstep might want or not in the near term.

There are still some issues with it I need to work out namely terminal rendering, fonts rendering for menus that I've been stuck on but I've made some progress for terminal. Then there is a delay launching GNUstep apps in non EMWH compliant window managers (that I've fixed in another more experimental fork not here because I don't want to touch code outside of Opal in this PR).

A few months ago first I started out tinkering with libs-corebase, libs-opal, libs-quartzcore integration as an idea to facilitate easier application porting for things like texmate. It then extended to an idea for a future display server to replace both X11 and wayland as I learned about this code in libs-back that I've been working on for a few months in parallel.

So I have this WindowServer.app piece somewhat working, not pushed anywhere yet. Ignore the theme issues rendering a double menu and so on (trivial to solve, but is a hack to reparent menus in Menu.app Gershwin uses) I have been working to use some shared components that X or wayland would use such as libinput.

Anyway my goals was to fix the terminal, menu items rendering issue before pivoting back to the display server. But the idea to use a refreshed Opal vs Cairo drawing backend appealed to me for this project as being more architecturally correct over time. So step 1 is fixing opal to be on par with Cairo for X11 (I consider this PR a great first step with a follow up coming in time). Step 2 is finish WindowServer.app. Step 3 is port WindowManager.app to X11.app (think xquartz).

The ideas is that there would a fully independent display server model for running GNUstep apps natively only requiring KMS drivers, libinput, and a few EGL related packages. Then I would make a separate application for optional compatibility with X11 applications (mostly I already have it with WIndowManager.app just needs a refactor), and eventually I would make something similar for Wayland applications both as optional bundles.

[fredkiefer]

This looks like a great improvement. The code here is really in a very bd state and I am glad someone is fixing it.
Please feel free to review some of my suggestions but I am willing to merge even without further changes.

[pkgdemon]

This looks like a great improvement. The code here is really in a very bd state and I am glad someone is fixing it. Please feel free to review some of my suggestions but I am willing to merge even without further changes.

Thanks @fredkiefer I've addressed 3/4 but I am not sure how to address this one yet for 4/4. Do you think just a comment update is in order for now? #77 (comment)