search

doy / runes

a modern terminal client
Other
35 stars 1 forks source link

Move Cairo out of runes.h and display.h #43

Closed dolmen closed 10 years ago

dolmen commented 10 years ago

display.h looks like a good abstraction for a rendering backend. Unfortunately the API currently has a few references to Cairo types. For the best flexibility, Cairo should be just one backend, to allow native ones. Same for runes.h.

doy commented 10 years ago

Cairo already is an abstraction for a rendering backend. The intention is that window-*.c includes the platform-specific code, and so we have window-xlib.c that use cairo_xlib, and there could also be a window-quartz.c that uses cairo_quartz, and a window-win32.c that uses cairo_win32. Is there a reason why you'd want another layer of abstraction here?

dolmen commented 10 years ago

My idea was a native Win32 GUI backend, not using Cairo. But I'm not yet committing to implement it.

I admit I have zero experience with Cairo but I wonder because I see no Cairo apps on Win32 except a few Gtk+ ones. The Win32 port of Gtk+ is known to have issues, but I don't know how much this is due to Cairo. I may just be FUDding...

doy commented 10 years ago

Firefox used cairo as its rendering backend for all platforms (including Windows) for quite a while - I don't think there should be problems. If there are, we can address them as they come up - I'm really trying to avoid doing extra work when it might not even be necessary. I'm not particularly tied to cairo, but I'm also not very interested in maintaining my own cross-platform graphics layer if at all possible, because that is quite a lot of effort to do well.