From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets) Date: Sat, 28 Nov 2020 10:38:22 +0200 Message-ID: <83wny5naf5.fsf@gnu.org> References: <864kmzupp0.fsf@akirakyle.com> <86pn46awrr.fsf@akirakyle.com> <87y2ise7j5.fsf@gnus.org> <86tutfwhr6.fsf@akirakyle.com> <87h7pfb76z.fsf@gnus.org> <86h7peqkt5.fsf@akirakyle.com> <83tutdsc8i.fsf@gnu.org> <86eeker01y.fsf@akirakyle.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29345"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Akira Kyle Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 28 09:39:18 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 1kivlG-0007XN-HP for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 09:39:18 +0100 Original-Received: from localhost ([::1]:52572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kivlF-000439-Ja for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 03:39:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47848) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kivkc-0003dK-GL for emacs-devel@gnu.org; Sat, 28 Nov 2020 03:38:38 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41842) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kivkb-0001WV-GA; Sat, 28 Nov 2020 03:38:37 -0500 Original-Received: from [176.228.60.248] (port=4735 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kivka-0001M6-VM; Sat, 28 Nov 2020 03:38:37 -0500 In-Reply-To: <86eeker01y.fsf@akirakyle.com> (message from Akira Kyle on Fri, 27 Nov 2020 13:56:25 -0700) 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:259938 Archived-At: > From: Akira Kyle > Cc: larsi@gnus.org, emacs-devel@gnu.org > Date: Fri, 27 Nov 2020 13:56:25 -0700 > > > It is a relatively simple matter to disable some optimizations > > when a widget is displayed. It is also relatively simple to tell > > the widget to redraw itself when redisplay changed its position on > > the screen. > > Yes, but you had previously pointed to that fact that xwidgets > needs to such disable such optimizations as part of the "kludge" > that would need to be resolved for xwidgets to be considered > viable for a path forward. Having looked at that, I'm not sure gtk > will ever want to cooperate without doing things that would be > considered hacks by gtk folks. I'd appreciate more details on the GTK part of this. I only said that from the Emacs display engine side things are not too hairy. from my POV, xwidgets integration simply stopped short of going all the way towards integration into the redisplay framework, and I don't think anyone said before that this was done because better integration was impossible or very hard. > > I don't see why you consider this such a significant problem. The > > number of interfaces that such a "rich" display element needs to > > support is very small and well-defined. The problem with xwidgets > > in this regard is that its interaction with the display code was > > left unfinished, it basically just copy/pastes the code which > > supports display of images, which is not 100% correct, since > > xwidgets don't display a static bitmap. > > The "number interfaces" will likely be small no matter what > solution is taken, its more about how easy you want to make it for > a "rich" display element to really mess with Emacs' display and > input handling. For example with xwidgets the onus is on the > widget implementation to not totally steal keyboard focus from > Emacs. I've found that gtk widgets really like stealing keyboard > focus so its easy to end up in a state you can't escape out > of. Keyboard focus is a separate issue. I only talked about integration with redisplay. For keyboard input integration, we'd need to develop some infrastructure, if the existing one doesn't provide enough hooks. If you or someone else can describe the details, we could discuss that in more practical terms. I think it's too soon to give up on the practical possibility to solve these problems before we discussed that, or are even fully aware of the problems and the potential solutions. > Similarly gtk widgets won't always easily draw themselves > where you want at the size you want so its easy for widgets to > render, say, across window boundaries. If that is true, then your method of letting the widget display in a window won't work well either, right? IOW, whether the screen area given to the widget is a full Emacs window or just its part is not an important aspect of the integration of such widgets into the Emacs display. > The xwidget approach requires non-insignificant work on the widget > end to ensure the widgets will work within the confines of Emacs' > redisplay. As long as the widget can be told to use a given rectangular portion of the screen, we should be fine: the current Emacs display engine is perfectly capable of handling display elements that occupy an area of certain dimensions. > I'd think that such an interface to support "rich" display elements > should be restrictive enough to not easily allow the "rich" display > elements to misbehave. Please tell more about the reasons for this conclusion. I don't yet see the difficulties you envision.