From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aiko Kyle Newsgroups: gmane.emacs.devel Subject: Re: Multimedia dashboard in GNU Emacs Date: Thu, 30 Dec 2021 13:25:51 -0700 Message-ID: References: <87pmpm2v4b.fsf@gnus.org> <874k6ye2w4.fsf@yahoo.com> <87wnjq1vwn.fsf@yahoo.com> <87zgoj5ycl.fsf@tanaka.verona.se> <87ee5usy5x.fsf@yahoo.com> <87v8z6py7p.fsf@yahoo.com> <87lf02pujw.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9779"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Emacs Devel , joakim@verona.se, Anand Tamariya To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 30 21:27:05 2021 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 1n320u-0002Or-RN for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Dec 2021 21:27:04 +0100 Original-Received: from localhost ([::1]:59546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n320t-0003Wj-51 for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Dec 2021 15:27:03 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50726) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n31zy-0002pD-7w for emacs-devel@gnu.org; Thu, 30 Dec 2021 15:26:06 -0500 Original-Received: from [2a00:1450:4864:20::12c] (port=42791 helo=mail-lf1-x12c.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n31zw-0000bf-Mr for emacs-devel@gnu.org; Thu, 30 Dec 2021 15:26:05 -0500 Original-Received: by mail-lf1-x12c.google.com with SMTP id h2so46026709lfv.9 for ; Thu, 30 Dec 2021 12:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R/XzEC3a+Y26y2r98xj9R6jG5flFd6lCBH5TZv6dbzc=; b=ax4J1QPnBuixt20FgzwgnKXw1nAa/uv0WEqCBHbdO+DrafyUS0VGRkA13rmXtnSkzM /3bUxWtK+ax/4nq1nKebf2RuUwk61YVT8hhCy7zSYwtcMAHTn1iXZ2TEErKwrWqGqFDw bsJnxLJvTO+53yz0IEV9YoOJsw5AyLYtbQfWVnX7i8DFss+BdLcpp4e9ShupoU1HBcA8 uVXJIVRIWszQFhbJg1QeQMI+qGNt5yfnSbBzllY3BudjqPq5J28xHmkUQcU4qpjXn3h4 56ZZX40CnV6pARbnuzP7r00SPelSy6XPNDj7aMDER/hj9pHHFhWMWtEh603UhmBT5iiD mqBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R/XzEC3a+Y26y2r98xj9R6jG5flFd6lCBH5TZv6dbzc=; b=L8uufU3EbJ/0En8eRYYjXhJ10NIb5Oy6Wg3B0uKzNiNmhVYTaB5A3aEpNPuOjT/0ZM ABkdoRFfIm5DOCLeXOCo1VJKX6h6Gv0vFFRF1/7UNXE9q7r1Cw3Jwq6V5mAPyF2g8cVO WtQ/Zqs0b/IxHS+Ulbe0b+vXBsTc7TE8QlhiYJ11VQ0ibnetjxEqzFNekTK6BCj/Pg5t TGlu2FPECe3xLKGuw2nz+Gd2dm3eUGeyqNqxkq1EUQz4NNWYDkebVws6+s1VBjmuOGFf jrszPa5fH2UKP9GdrwZDP1IrI9w+jnMEc9wRy9eOqhovAiFnqk4M2gR1v2MfWt2rW63T QTmg== X-Gm-Message-State: AOAM533D5ay/5wnnjspDTbFlqWvsCfW/Ga0QOwafBQDRfVjT6+7T8XHg ImSqK85vWZK+hhw5QLlo3xxLXVIB6n0QF7RHthE= X-Google-Smtp-Source: ABdhPJwSOQ7rLWjSt8kHdyaEr4QDk0AMLDHJa0Vku7ot6iWcogCzBOcLF5ad8YHtpcGyWujLQqRt0KgkdfNjXU1jZ8s= X-Received: by 2002:a05:6512:3182:: with SMTP id i2mr26951353lfe.673.1640895962771; Thu, 30 Dec 2021 12:26:02 -0800 (PST) In-Reply-To: <87lf02pujw.fsf@yahoo.com> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::12c (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::12c; envelope-from=aikokyle@gmail.com; helo=mail-lf1-x12c.google.com X-Spam_score_int: 6 X-Spam_score: 0.6 X-Spam_bar: / X-Spam_report: (0.6 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, 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.29 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:283681 Archived-At: On Wed, Dec 29, 2021 at 9:48 PM Po Lu wrote: > > > Doesn't this have to do more with syncronizing two DOMs though? There > > isn't much gtk state attached to webkit webviews that would need to be > > shared. > > The idea is to give the view a large enough allocation and to put it > into a GtkScrolledWindow, which can then be scrolled however you want > it. > As I see. So in this idea, the entire webpage would be rendered in the case of a xwidget webkit? That seems like it would be costly for especially large webpages. > > Fundamentally the emacs window/buffer paradigm doesn't fit with the > > browser DOM/webview paradigm. This again goes back to my opinion that > > enforcing a one-to-one correspondence between a webkit xwidget window > > and buffer is the better UI paradigm for meshing the two than the > > offscreen rendering technique. > > If an xwidget is only displayed in a single window, it behaves the same > way as in any other application, so I see no reason to prevent it from > being displayed in multiple windows. > > It won't hurt for the people who want it the way it is, and the people > who want to keep an xwidget-webkit buffer from being displayed in > multiple windows can simply refrain from opening those other windows. > > > I'm curious as to what your workflow/use case with them might look > > like? Understanding that might help me to better understand your > > opinion on why the osr technique results in a better UI in this case. > > I'm not arguing about user experience (I have no opinion on that), only > about what fits in better with the Emacs display architecture. Do you then plan on implementing other xwidget types besides the webkit one? I think with respect to the UI, osr makes more sense for other widget types like buttons. I agree the offscreen rendering is more general, however it seems to me to add significant complexity that would be unnecessary if the UI for it doesn't require it. Especially since the one-to-one webkit buffer-window paradigm already has to be accounted for on ns, where osr isn't available.