From: Po Lu <luangruo@yahoo.com>
To: Aiko Kyle <aikokyle@gmail.com>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,
Anand Tamariya <atamariya@gmail.com>,
joakim@verona.se, Emacs Devel <emacs-devel@gnu.org>
Subject: Re: Multimedia dashboard in GNU Emacs
Date: Thu, 30 Dec 2021 12:48:19 +0800 [thread overview]
Message-ID: <87lf02pujw.fsf@yahoo.com> (raw)
In-Reply-To: <CAPWcbYE6Sso3yvX9nG4XJ7OJrrYrprQVYb627KW_PbTgKA3-ow@mail.gmail.com> (Aiko Kyle's message of "Wed, 29 Dec 2021 21:18:59 -0700")
Aiko Kyle <aikokyle@gmail.com> writes:
> 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.
> 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.
next prev parent reply other threads:[~2021-12-30 4:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-24 6:35 Multimedia dashboard in GNU Emacs Anand Tamariya
2021-12-24 9:46 ` Lars Ingebrigtsen
2021-12-24 10:03 ` Po Lu
2021-12-27 4:22 ` Anand Tamariya
2021-12-27 5:03 ` Po Lu
2021-12-29 1:44 ` Aiko Kyle
2021-12-29 13:34 ` joakim
2021-12-29 19:08 ` Aiko Kyle
2021-12-29 20:08 ` joakim
2021-12-29 23:39 ` Aiko Kyle
2021-12-30 1:02 ` Po Lu
2021-12-30 3:21 ` Aiko Kyle
2021-12-30 3:29 ` Po Lu
2021-12-30 4:18 ` Aiko Kyle
2021-12-30 4:48 ` Po Lu [this message]
2021-12-30 20:25 ` Aiko Kyle
2021-12-31 0:59 ` Po Lu
2021-12-31 2:39 ` Aiko Kyle
2021-12-31 3:38 ` Po Lu
2021-12-27 4:16 ` Anand Tamariya
2021-12-27 12:06 ` Lars Ingebrigtsen
2021-12-28 4:19 ` Richard Stallman
2021-12-28 5:41 ` Po Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lf02pujw.fsf@yahoo.com \
--to=luangruo@yahoo.com \
--cc=aikokyle@gmail.com \
--cc=atamariya@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=joakim@verona.se \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).