clutter integration in the xwidget branch

clutter integration in the xwidget branch

[joakim]

I did a preliminary "hello world" type xwidget using clutter-gtk.

Information about clutter:
http://www.clutter-project.org/

My example just loads a hard coded svg file into a clutter canvas inside
emacs. This happens through librsvg->cairo->clutter-gtk. The example is
much speedier than our current svg support, but can be optimised more
still.

So what's missing to get an animated GPU accelerated Gnu herd jumping about in Emacs?

- research how to implement MVC with Clutter

- research proper lisp bindings for Clutter. (so you need to read and
respond to my other thread. You guys spend too much time trolling about
mail setting and too little on my important threads :) Possibly one
could benefit from Guile Clutter?





-- 
Joakim Verona

Re: clutter integration in the xwidget branch

[Antoine Levitt]

28/06/11 09:05, joakim@verona.se
> I did a preliminary "hello world" type xwidget using clutter-gtk.
>
> Information about clutter:
> http://www.clutter-project.org/
>
> My example just loads a hard coded svg file into a clutter canvas inside
> emacs. This happens through librsvg->cairo->clutter-gtk. The example is
> much speedier than our current svg support, but can be optimised more
> still.
>
> So what's missing to get an animated GPU accelerated Gnu herd jumping about in Emacs?
>
> - research how to implement MVC with Clutter
>
> - research proper lisp bindings for Clutter. (so you need to read and
> respond to my other thread. You guys spend too much time trolling about
> mail setting and too little on my important threads :) Possibly one
> could benefit from Guile Clutter?

FWIW, I (and probably others) am very interested in your work, and am
looking forward to the day I can run mplayer/chrome/a pdf viewer from
the comfort of my emacs. I just don't answer for lack of knowledge :)

Re: clutter integration in the xwidget branch

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]

On Tue, Jun 28 2011, joakim@verona.se wrote:

> Information about clutter:
> http://www.clutter-project.org/
>
> My example just loads a hard coded svg file into a clutter canvas inside
> emacs. This happens through librsvg->cairo->clutter-gtk. The example is
> much speedier than our current svg support, but can be optimised more
> still.
>
> So what's missing to get an animated GPU accelerated Gnu herd jumping about in Emacs?
>
> - research how to implement MVC with Clutter
>
> - research proper lisp bindings for Clutter. (so you need to read and
> respond to my other thread. You guys spend too much time trolling about
> mail setting and too little on my important threads :) Possibly one
> could benefit from Guile Clutter?

On Tue, Jun 28 2011, Antoine Levitt wrote:

> FWIW, I (and probably others) am very interested in your work, and am
> looking forward to the day I can run mplayer/chrome/a pdf viewer from
> the comfort of my emacs. I just don't answer for lack of knowledge :)

I am too very interested in the work done in that direction. I
understand that the finality is to control application in Emacs, for an
obvious win to us, Emacs users.

However, I'm not sure the xembed approach is relevant anymore, nowadays.
I don't think it will work on long term.
Many application can't be embeded, or won't work correctly when they
will be. Thinking that you will be able to control them from Emacs, is
naive, unless they have been though that way¹. Thinking that upstream
will fix or enhance their apps to be embeded, is naive too.

So here the question I wonder for days now and I need to ask out loud:

   Why not embed WebKit as a display engine?

I think Emacs would win on every side. The current Emacs display engine
is very limited (to be not rude). With such an engine, Emacs could
display image *properly* (with real position, in text flow, or
floating). It could play videos. It could have widgets that 1988 will be
jealous about. It could even display HTML correctly, something that is
needed everywhere nowadays, like in Gnus (see shr.el).

The only downside I see so far is the inability for the terminal based
engine to match such technical requirements offered by WebKit. I don't
have a solution for this, but would hate that it'd be the thing keeping
Emacs to a so low standard about its display engines.


¹  I'm thinking about uzbl.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: clutter integration in the xwidget branch

[chad]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]


On Jun 28, 2011, at 1:49 AM, Julien Danjou wrote:
> 
> So here the question I wonder for days now and I need to ask out loud:
> 
>   Why not embed WebKit as a display engine?

It would probably be a large amount of difficult work.  

Over the years, multiple groups have tried this approach using less
complicated versions of the web (pre-javascript, pre-css, pre-xhtml,
etc) and less complicated editing systems (more `notepad' than
`emacs'), and have fallen under their own weight.

I hate to be gloomy, but I'm pretty sure that's the reason.  Someday,
another epoch or Gerd Moellmann-style effort will arise and implement
this idea or something like it, but, believe it or not, xembed is
probably an easier path.

Hope that helps,
*Chad

[-- Attachment #2: Type: text/html, Size: 1205 bytes --]

Re: clutter integration in the xwidget branch

[Miles Bader]

Julien Danjou <julien@danjou.info> writes:
> Why not embed WebKit as a display engine?

As chad said, it would likely be pretty difficult.  Emacs is not a
simple text editor with generic requirements for redisplay that can
easily be fulfilled by random toolkit text widgets.

Emacs redisplay implements many specialized features which are used by
lots of lisp code.  All that would either have to be emulated (how?)
or abandoned.  Moreover, the traditional web-browser method of display
-- calculating a DOM from the underlying document, and then letting
the engine display the DOM efficiently -- is not a particularly good
match with the traditional Emacs display architecture, which mostly
only incurs overhead for _displayed_ portions of the text.  A big
change in models like that would very likely to have some big
repercussions.[*]

The existing terminal display code of course can't support many
features of the graphical display, but it still shares much of the
same code, and respects the same basic constraints.

This has been suggested many times before in various forms, and I'm
not aware that there's ever been a very positive answer.

[*] Visit a 500MB document in Emacs? No prob, displays quickly!  Open
the same document in Google Chrome [a speed-focused browser which uses
webkit]?  System brought to knees, I had to kill it after my system
started thrashing itself to death.

-Miles

-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen