From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs canvas support Date: Wed, 29 Apr 2020 14:47:10 +0300 Message-ID: <83imhizf7l.fsf@gnu.org> References: <875zdikdge.fsf.ref@yahoo.com> <875zdikdge.fsf@yahoo.com> <834kt21yyo.fsf@gnu.org> <87zhau1uog.fsf@yahoo.com> <83sggmzjp8.fsf@gnu.org> <87mu6u1tii.fsf@yahoo.com> <87ftcm1t96.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="43094"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 29 13:48:10 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jTlCD-000B5C-Na for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Apr 2020 13:48:09 +0200 Original-Received: from localhost ([::1]:34936 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTlCC-0002CR-PS for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Apr 2020 07:48:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50248) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTlBa-0001eS-2M for emacs-devel@gnu.org; Wed, 29 Apr 2020 07:47:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53052) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTlBZ-0000fR-PH; Wed, 29 Apr 2020 07:47:29 -0400 Original-Received: from [176.228.60.248] (port=1324 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jTlBZ-0003fb-2B; Wed, 29 Apr 2020 07:47:29 -0400 In-Reply-To: <87ftcm1t96.fsf@yahoo.com> (message from Po Lu on Wed, 29 Apr 2020 18:27:49 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:248117 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Wed, 29 Apr 2020 18:27:49 +0800 > > >> That's the technical description of the implementation. It doesn't > >> explain when canvases can be useful and for what purposes. > > > > Canvases are useful for when I want to be able to control a portion of a > > screen dynamically, in a fast way, from Lisp code. For instance, > > displaying a constantly changing bar chart or graph inside Emacs. > > > >> But the result of this painting is some graphical object, similar to > >> an image, that will be displayed within a buffer, right? > > > > Correct. > > > >> Did I miss the code that tells Emacs the click was on a canvas? E.g., > >> if you click on a canvas, what does posn-object return when passed the > >> click event as its argument? > > > > Oops. I missed that. Thanks for bringing it up. > > Here is a version of the patch with several of the problems you > mentioned rectified. Thanks. > +@node Canvases > +@cindex drawing canvases > +@cindex drawing areas > +@cindex canvases > +@section Canvases > + > +This chapter describes canvases, objects that can store drawing operations > +which are then displayed inside buffer text. Please consider telling something here about when this is useful. Also, I think there should be a short subsection in "Editing Types" with the description of the canvas type, like we have for other editing types. > @@ -4371,6 +4374,11 @@ scrolling_window (struct window *w, int tab_line_p) > return 0; > #endif > > + /* We need this to fix canvas movement detection in a reliable way. > + FIXME. */ > + if (w->have_canvas_p) > + return 0; This is sub-optimal. Please don't follow the xwidget example of disabling redisplay optimizations because it might be hairy to support them. It would make any window with canvases redisplay much slower in many cases. > @@ -5462,6 +5470,10 @@ buffer_posn_from_coords (struct window *w, int *x, int *y, struct display_pos *p > if (img && !NILP (img->spec)) > *object = img->spec; > } > + else if (it.what == IT_CANVAS) > + { > + XSETCANVAS (*object, it.canvas); > + } > #endif This is just the object. That's okay, but don't you want to support clicks on various parts of the canvas, like we do with images? That would require more info to be returned.