Re: Emacs and Gnome Canvas (was: Emacs, QT and Cairo)

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Wed, 14 Jul 2010 23:24:03 +0200
> 
> I'm very interested on this. Which are those requirements that gnome's
> canvas can not meet?

To answer that, we need someone with good knowledge of both the
requirements of the Emacs display engine and of the features and
possibilities of the Gnome Canvas library.  Do we have such an
individual?

This white paper:

   http://developer.gnome.org/doc/whitepapers/canvas/canvas.html

gives some initial overview of Canvas, but a more in-depth description
is required to fully understand the impact of using Gnome Canvas as
the Emacs display engine.  A few initial thoughts from someone who is
entirely ignorant about Canvas, based on that white paper (which could
be outdated, since it was written 11 years ago):

 . Canvas seems to need GTK+.  What does this mean for platforms where
   GTK+ is unavailable or not maintained?  What about supporting the
   TTY?  Do these issues mean we will need to keep the existing
   display engine in parallel with the Canvas-based one?

 . The Canvas redisplay runs from the GTK+ idle handlers.  In Emacs,
   the idle loop, in addition to triggering redisplay, also checks for
   input from the keyboard and from subprocesses.  Does this mean that
   part of the input handling will need to be run by GTK+?

 . Canvas redisplay is caused by requests from the application to
   update some "canvas item" when the underlying application's objects
   are modified; these requests are then served when GTK+ idle
   handlers are run.  Emacs display engine works differently: changes
   that require redisplay are not considered until redisplay is
   entered; the "requests" to update the display are implicitly
   recorded in the buffers and in the various related data structures
   (text properties and overlays, display strings, etc.), but not
   explicitly translated to display terms until redisplay time, and as
   an inherent part of redisplay itself.  These two very different
   models will need to be reconciled in some reasonably efficient way.

> > I'm not sure I follow: are you looking for toolkits that can be used
> > to replace the Emacs display engine, i.e. those toolkits that support
> > everything Emacs needs and does today?
> 
> I think he is looking for something that *expands* what Emacs can do
> today.

To be able to expand Emacs you need first be able to do what Emacs
does today.