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: Mon, 30 Nov 2020 17:39:52 +0200 Message-ID: <83360qlupj.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> <83wny5naf5.fsf@gnu.org> <86o8jh9cij.fsf@akirakyle.com> <83czzwkmwk.fsf@gnu.org> <86lfeja49y.fsf@akirakyle.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1169"; 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 Mon Nov 30 16:40:48 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 1kjlIF-0000BZ-QZ for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Nov 2020 16:40:47 +0100 Original-Received: from localhost ([::1]:47128 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjlIE-0002ka-Qu for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Nov 2020 10:40:46 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42048) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjlHb-0002Le-Rq for emacs-devel@gnu.org; Mon, 30 Nov 2020 10:40:07 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57739) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjlHa-0007Do-FY; Mon, 30 Nov 2020 10:40:07 -0500 Original-Received: from [176.228.60.248] (port=4294 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kjlHU-0004DD-BY; Mon, 30 Nov 2020 10:40:01 -0500 In-Reply-To: <86lfeja49y.fsf@akirakyle.com> (message from Akira Kyle on Sun, 29 Nov 2020 20:54:01 -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:260067 Archived-At: > From: Akira Kyle > Cc: larsi@gnus.org, emacs-devel@gnu.org > Date: Sun, 29 Nov 2020 20:54:01 -0700 > > > Anyway, this just tells me that GTK is not a good starting point > > for embedding widgets. Do other projects build embedded widgets > > on such shaky grounds? > > I wouldn't say GTK isn't good for embedding widgets. In fact I'd > say it's probably great if you're wanting to extend an existing > GTK app with custom widgets. The problem is Emacs, despite using > GTK as a toolkit, isn't really a GTK app. First, which of the problems you mentioned are related to Emacs not being a GTK application? And second, there's a branch in our repository where Emacs _is_ made to be a GTK application, AFAIU. > > This is solvable. We already have similar situation in the > > display engine, where some display element cannot be usefully > > "clipped". We either don't display it at all or display it on the > > next screen line, depending on the wrap mode. > > I don't doubt its solvable, but how satisfactorily and at what > complexity? No complexity at all, it's almost trivial, because the display code already does that. As for "satisfactorily" part: what can be unsatisfactory about displaying the widget on the next screen line? > What if the element is large and 99% of it could be visible? What if > the element is wider than the window? These are marginal cases: you are talking about very large widgets that in addition refuse to be resized. How many are like that? And what else can we do with widgets that are (1) large, (2) won't resize, and (3) cannot be clipped? The perfect should not be the enemy of the good, right? > What if `window-resize-pixelwise` or `frame-resize-pixelwise` > non-nil and the element is on the last, partially clipped line? We don't display it. How is this different from a any other large display element that cannot be shown in the viewport?