unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: joakim@verona.se
To: Aiko Kyle <aikokyle@gmail.com>
Cc: Po Lu <luangruo@yahoo.com>, Lars Ingebrigtsen <larsi@gnus.org>,
	Anand Tamariya <atamariya@gmail.com>,
	Emacs Devel <emacs-devel@gnu.org>
Subject: Re: Multimedia dashboard in GNU Emacs
Date: Wed, 29 Dec 2021 21:08:57 +0100	[thread overview]
Message-ID: <87lf035g2u.fsf@tanaka.verona.se> (raw)
In-Reply-To: <CAPWcbYGpbyk9DWoU0J=B1HR+GwFMNys=Dn1ALVCiZO1Md6Xo-g@mail.gmail.com> (Aiko Kyle's message of "Wed, 29 Dec 2021 12:08:08 -0700")

Aiko Kyle <aikokyle@gmail.com> writes:

> Hi Joakim!
>
> Po and I were previously discussing this in the context of the webkit
> xwidget on this thread:
> https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01914.html
>
> On Wed, Dec 29, 2021 at 6:34 AM <joakim@verona.se> wrote:
>>
>> It kind of has to, in order to preserve the way emacs behaves.
>> That is multiple views of the same buffer, and so on.
>>
>> In the original xwidget branch there were some alternative behaviours
>> implemented as proof of concepts, and they worked to some degree, but
>> breaks the emacs paradigm, so they arent really all that useful IMHO.
>>
>
> I think that the question of how well an xwidget obeys "the emacs
> paradigm" depends on the content it's displaying. If it were a button
> or some other element in a larger button, I agree that the current
> model fits the emacs way well enough. However I think when the xwidget
> is the only element in a buffer and takes up a large portion or even
> the whole window, then I think the correct paradigm would resemble
> something like doc-view, where the two widow's xwidgets can show
> different views if they have some notion of scrolling.

This was one of the methods that was evaluated in the original branch,
that is, every emacs window got its own separate gtk component.

So, if the xwidget was a gtk button, for example, inserted in a buffer,
and there were several emacs window showing the same area, each emacs
window would get a separate gtk button representing the same xwidget.
This worked okay-ish, for buttons. But for sliders it didnt turn out so
well, because one needed special glue code to make each separate gtk
slider be in sync with every other instance. It's doable, but
convoluted. Anyway, I'm sure theres been plenty of progress since the
original experiments, so maybe today it's less convoluted.

>
>> There might also be some kind of experiment involving redirection of an
>> applications main window to an offscreen widget, that might be useful
>> for xwidget, but I'm not entirely sure.
>>
>
> This is the current implementation that Po Lu has fixed various
> flickering bugs on master for xwidgets on x. However both the xwidgets
> on ns and my emacs module emacs-webkit, handles this in a different
> way where the webkitview can only be displayed in one window.
-- 
Joakim Verona
joakim@verona.se



  reply	other threads:[~2021-12-29 20:08 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 [this message]
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
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=87lf035g2u.fsf@tanaka.verona.se \
    --to=joakim@verona.se \
    --cc=aikokyle@gmail.com \
    --cc=atamariya@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    --cc=luangruo@yahoo.com \
    /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).