From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Akira Kyle 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 10:03:55 -0700 Message-ID: <86wny293pg.fsf@akirakyle.com> 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> <83360qlupj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12002"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.13; emacs 28.0.50 Cc: larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 30 18:06:27 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 1kjmd8-00032X-LM for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Nov 2020 18:06:26 +0100 Original-Received: from localhost ([::1]:39388 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjmd7-00039N-N4 for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Nov 2020 12:06:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40196) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjmaq-0000Ox-Cx for emacs-devel@gnu.org; Mon, 30 Nov 2020 12:04:05 -0500 Original-Received: from mail-il1-f181.google.com ([209.85.166.181]:44567) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kjmal-0006jO-Tz; Mon, 30 Nov 2020 12:04:03 -0500 Original-Received: by mail-il1-f181.google.com with SMTP id r17so11949159ilo.11; Mon, 30 Nov 2020 09:03:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=csNhNEv6qKK3xW9NK5Z7I3siXR3sFiH/uVaYOi9GEc4=; b=sjYYdW2jsIgYP4DvA3mlPj9vZmVPc/r6Zb9kV3pz6VwOmJwyH4Y5zA5PHIul1Be1fw t5lEWnehEyC/QMetgb2Nhc9mO7O4JVteyeJp17dVJSoLjbSiICZQz93ivuwYswG/PyPW pFbRV4WlkYzJs0PpN66fTwyMgf5MhwnA4fr+u37V6Z0nwuvTv5UM1ai8Miz078q25ok5 TJzlt2PS48MMxosL72lCSnnpHPimTvOA4wZDteMkkUPRMa+lkHwnclj1FrdkXr+IG2qR vW7LQuc4s75fJa5glouKOIFEiMVqH7zOgbIwEa2BeUQP499AcGch8YyLHe320iJsOAr+ QRUw== X-Gm-Message-State: AOAM531ZghVVgWF98el7AV4VK8EI3CFQmDMBK+6kwK6eDNS16y0bXMhc fkBi5bGP87I7CM9bnhD1F9GKVYQMmjPusA== X-Google-Smtp-Source: ABdhPJxKHSmElsNsSJKxDTKZTJA8idBKnTG7q9aG8wZzqjGj6LMrrdh2gX45X99K2peQ/pvnEuXZag== X-Received: by 2002:a92:6403:: with SMTP id y3mr20754234ilb.72.1606755837146; Mon, 30 Nov 2020 09:03:57 -0800 (PST) Original-Received: from data ([2601:281:8080:45f0:f489:d915:ca06:64f6]) by smtp.gmail.com with ESMTPSA id v63sm8182797ioe.52.2020.11.30.09.03.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Nov 2020 09:03:56 -0800 (PST) In-reply-to: <83360qlupj.fsf@gnu.org> Received-SPF: pass client-ip=209.85.166.181; envelope-from=aikokyle@gmail.com; helo=mail-il1-f181.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:260078 Archived-At: On Mon, Nov 30, 2020 at 08:39 AM, Eli Zaretskii wrote: >> > 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? All of them. > And second, there's a branch in our repository where Emacs _is_ > made > to be a GTK application, AFAIU. If you're referring to Yukki Harano's feature/pgtk branch, then that's actually what I'm primarily targeting in my development of emacs-webkit since the usual Emacs compiled `--with-x` has an additional problem from what I've previously described. It seems gtk widgets (or at least the webkit widget), flicker constantly on `--with-x`. It seems to be related to the double buffering implementation since setting the frame parameter `(inhibit-double-buffering . t)` fixes it. I haven't had the motivation to debug this due to the mess of xterm.c and because I see pgtk as the future of Emacs on GNU/Linux systems as X becomes increasingly obsolete. AFAIU the pgtk version, like the ns version it was modeled after, doesn't implement everything in the main frame area of Emacs as widgets, only the tool and menu bars are implemented as proper widgets. The main frame area is treated as just one big canvas that redisplay works its magic on as it would if it were just a TUI. >> > 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? That's fine, and would be the expected behavior when lines are supposed to wrap. But when lines are not wrapped, I would not expect a display element to disappear as soon as one pixel of it exceeds the window border. >> 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? Take the drawing canvas idea, the canvas widget would be the size of an image. Already I find the way redisplay doesn't like to display images clipped at the top of the window jarring. If I wanted to zoom into the widget if it was displaying something detailed, I wouldn't want it to suddenly disappear. I think Emacs needs to be able to clip the elements its displays in order to not end up with what I would call surprising and frustrating behavior. Hence my original argument that the way gtk widgets are currently handled is not in general, a good path forward for such features. >> 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? Images are the only other large display element that I'm aware of and images are clipped in such cases, which is good as large images make their line very tall so very often they end up partially displayed in the last line.