From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Julien Danjou Newsgroups: gmane.emacs.devel Subject: Re: clutter integration in the xwidget branch Date: Tue, 28 Jun 2011 10:49:58 +0200 Message-ID: <87ei2ez6fd.fsf@keller.adm.naquadah.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: dough.gmane.org 1309252935 6189 80.91.229.12 (28 Jun 2011 09:22:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 28 Jun 2011 09:22:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 28 11:22:11 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QbUUk-0007NS-RA for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2011 11:22:11 +0200 Original-Received: from localhost ([::1]:60092 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbUUj-0000AA-5A for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2011 05:22:09 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbUGv-00059m-Ne for emacs-devel@gnu.org; Tue, 28 Jun 2011 05:07:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbUGt-0004EU-KF for emacs-devel@gnu.org; Tue, 28 Jun 2011 05:07:53 -0400 Original-Received: from prometheus.naquadah.org ([212.85.154.174]:47082 helo=mx1.naquadah.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbU0x-0000R3-Mn for emacs-devel@gnu.org; Tue, 28 Jun 2011 04:51:24 -0400 Original-Received: from keller.adm.naquadah.org (AMontsouris-651-1-41-193.w82-123.abo.wanadoo.fr [82.123.236.193]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.naquadah.org (Postfix) with ESMTPSA id B177F5C0CF; Tue, 28 Jun 2011 10:51:15 +0200 (CEST) Mail-Followup-To: joakim@verona.se, emacs-devel@gnu.org In-Reply-To: (joakim@verona.se's message of "Tue, 28 Jun 2011 09:05:04 +0200") User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 212.85.154.174 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:141116 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 abo= ut 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=C2=B9. 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. =C2=B9 I'm thinking about uzbl. =2D-=20 Julien Danjou =E2=9D=B1 http://julien.danjou.info --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJOCZW2AAoJEGEbqVCLeKXCTOMP/jQYjxbk3YS7P4RhZ+Dlym/b 45Yv7dG2mgGBfx74gEjrWUkhY74LvFkbFHpG+iqaxgGX2j7ltotAzPTOaen3aAhL d8ouDDlY445ch+EGMulFwF3myw5X4Cy/z3t3s7B19HIeWMtoSQ/+3A5+peVGheN/ RPtVMrVweHYYp2c2sl/7sJXbhmw22LQICkinklVbqGgJ35ObMMjch6Cl1vhG7ZWz 9FuDnC+cNiLXYxXpidAPMh1cwyevyPI3pLnh8my2Be5sYVa7ql64AMiEXYvN5f8v Sn0eew3RGlDfpaNYZYN73VrdTSk6tvkg/+7QzrDV6yx7FaNajo36A59ozb9XRNp8 vYKwQdDFlGZXKEdD7b8diFn+O/wNx9KuBPjp9LQFaFe7BE1vy3sfI+bP8y0nA7oL +LoMtLrQH797AySzvaOB9czH7b1frLvy43mE5YdKFHCRjcyWnyAIcmiynRQ4sQIO hkLVQEa7HqEwf4zqAyCSyK6ca5Axf1Sivb/TNUK/vF5rPJSSmuwI2aHt4D+ymyfd jILaMCkoNSGDaDckD7DsOEJygCCloDD+AmrnBSw3Gtpf9rlPvSkV7Z6Mc6F481hn sAHI+qqlEiohiMrLNNsGF9Ep7UeA3syppOdgVEYCHnm3Q/X6sNAWR4HVViF9Uatd GHqnWjMsYmIsuSVdaHtr =tkCK -----END PGP SIGNATURE----- --=-=-=--