Re: Emacs and Gnome Canvas

[Stephen Eilert]

Geez.I've gone away for a day and come back to a mail fest :)

When I first proposed the Cairo idea, it wasn't designed to replace
the current redisplay engine. Rather, to draw everything *except* the
buffer text, precisely because of the redisplay engine. Customize
windows could be "prettified" by drawing buttons and other elements
with Cairo, programatically and apart from the text, as images are
nowadays. The speedbar could benefit from better and dynamic icons and
draw real lines. Not to mention org-mode's spreadsheet (plotting a pie
graph inside Emacs would be huge :) )

I do not know if the current engine is able to draw into an offscreen
buffer, which would then receive Cairo enhancements. But that would be
less of a surgery and allow us to validate the Cairo bindings and
common use cases. UML diagrams, for instance, could also be done in a
whole buffer, or inside defined boundaries.

For comparison, i was thinking along the lines of a 'canvas element',
as implemented by recent browsers.


--Stephen

Sent from my Emacs



On Thu, Jul 15, 2010 at 3:02 PM, Óscar Fuentes <address@hidden> wrote:
> Chong Yidong <address@hidden> writes:
>
>> Óscar Fuentes <address@hidden> writes:
>>
>>> Would that system allow to draw UML diagrams with real graphics, instead
>>> of ASCII? Would it allow to implement a real graphical view for the DAG
>>> of a dVCS history? In short, would it a real drawing surface where you
>>> can draw arbitrary stuff and react to user actions such as the user
>>> clicking and dragging a line, preferably from Elisp code?
>>
>> If this is the reason you want to work with Canvas, I don't think it's
>> necessary to overhaul the Emacs redisplay engine at all.  A better
>> approach would be to create a system that allows Canvas objects to be
>> embedded in an Emacs display, in the same way that images can be
>> embedded.
>>
>> Thinking of this problem as "replacing" redisplay, or creating an
>> alternative to redisplay, is unnecessary.
>>
>> Joakim's patch for embedding gtk widgets is an interesting existing
>> experiment, somewhat along these lines.
>
> I don't think this is poweful enough. There should be no separation
> among text areas and drawing areas. Text should be just another kind of
> item on the canvas. How do you represent an UML diagram with editable
> areas inside the boxes, or editable rotated text along the lines that
> connects them? Or even simpler: how about implementing something like a
> tree widget on pure Elisp? It seems to me that doing that with the
> approach you propose will be very difficult, at best.
>
> My impression (and this is something that remains to be checked) is that
> implementing a new general display engine will be faster than enhancing
> the current one for adding a subset of the features the new one would
> bring on, not mentioning long term benefits like hackability and easy of
> maintenance.
>
>
>
>