Re: Emacs and Gnome Canvas

[joakim@verona.se]

Jan Djärv <jan.h.d@swipnet.se> writes:

> And besides this, you would have to have a GnomeCanvas per Emacs window.

If we are considering new display engines, I think we should have
pluggable display engines.

As a stupid example, consider embedding emacs within emacs, using the
xwidget branch. The embedding emacs can then send a lisp representation
of the buffer to the embedded emacs that will then display it.

Im not saying the above example is the way forward technically, but
having pluggble display engines would be very interesting.

Something similar I'm working on is having Inkscape embedded in
Emacs. Emacs then communicates with Inkscape via dbus.

>
> 	Jan D.
>
> Jan Djärv skrev 2010-07-15 09.46:
>>
>>
>> Eli Zaretskii skrev 2010-07-15 08.55:
>>>
>>> . 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?
>>
>> Gtk+ is required, you would have to have a parallel display engine for all
>> non-Gtk+ cases.
>>>
>>> . 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+?
>>
>> Yes. Now we run the Gtk+ event loop (or actually not the loop, just a step)
>> only when we know there is events pending. Again, parallel implementation for
>> non-Gtk+. But normal redisplay for Gtk+ also happens in idle handlers. We are
>> in the Gtk+ event loop often enough for this to happen often enough. Sometimes
>> though (scroll bars mainly) we force redisplay in Gtk+. I assume you can do
>> that for the Canvas also.
>>
>>>
>>> . 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.
>>
>> The changes that require redisplay would have to notify the Canvas that things
>> changed. I think this style is more efficient.
>>
>> But I'm not sure it is the right way to go for Emacs unless Gtk+ can run on
>> all platforms now. Even if it can, do we want Gtk+ look and feel on W32, OSX,
>> Nextstep etc.? TTY is still a separate issue though.
>>
>> Jan D.
>
-- 
Joakim Verona