From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: Multimedia dashboard in GNU Emacs Date: Wed, 29 Dec 2021 21:08:57 +0100 Message-ID: <87lf035g2u.fsf@tanaka.verona.se> References: <87pmpm2v4b.fsf@gnus.org> <874k6ye2w4.fsf@yahoo.com> <87wnjq1vwn.fsf@yahoo.com> <87zgoj5ycl.fsf@tanaka.verona.se> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25510"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Po Lu , Lars Ingebrigtsen , Anand Tamariya , Emacs Devel To: Aiko Kyle Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 29 21:09:51 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 1n2fGh-0006XE-Gh for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Dec 2021 21:09:51 +0100 Original-Received: from localhost ([::1]:33634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n2fGg-0006tC-LQ for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Dec 2021 15:09:50 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60770) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n2fFx-0005tf-5C for emacs-devel@gnu.org; Wed, 29 Dec 2021 15:09:05 -0500 Original-Received: from smtp.outgoing.loopia.se ([93.188.3.37]:45855) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n2fFu-0003lk-Gm for emacs-devel@gnu.org; Wed, 29 Dec 2021 15:09:04 -0500 Original-Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id DD91D2EA7A4C for ; Wed, 29 Dec 2021 21:08:58 +0100 (CET) Original-Received: from s934.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id CDEE32E29D5D; Wed, 29 Dec 2021 21:08:58 +0100 (CET) Original-Received: from s474.loopia.se (unknown [172.22.191.6]) by s934.loopia.se (Postfix) with ESMTP id CAD6D7DE92D; Wed, 29 Dec 2021 21:08:58 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Original-Received: from s499.loopia.se ([172.22.191.5]) by s474.loopia.se (s474.loopia.se [172.22.190.14]) (amavisd-new, port 10024) with LMTP id 02iuFHWM2UFX; Wed, 29 Dec 2021 21:08:58 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: joakim.verona@chimeslab.se X-Loopia-Originating-IP: 193.234.148.196 Original-Received: from tanaka.verona.se (unknown [193.234.148.196]) (Authenticated sender: joakim.verona@chimeslab.se) by s499.loopia.se (Postfix) with ESMTPSA id E71D31CE2242; Wed, 29 Dec 2021 21:08:57 +0100 (CET) In-Reply-To: (Aiko Kyle's message of "Wed, 29 Dec 2021 12:08:08 -0700") Received-SPF: pass client-ip=93.188.3.37; envelope-from=joakim@verona.se; helo=smtp.outgoing.loopia.se X-Spam_score_int: 0 X-Spam_score: -0.0 X-Spam_bar: / X-Spam_report: (-0.0 / 5.0 requ) RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:283590 Archived-At: Aiko Kyle 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 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