From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.devel Subject: Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets) Date: Thu, 03 Dec 2020 09:07:22 +0100 Message-ID: <87k0tzcnyd.fsf@logand.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> <86wny293pg.fsf@akirakyle.com> <87eeka7yxk.fsf@logand.com> <86360nwxch.fsf@akirakyle.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37376"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Akira Kyle Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 03 09:09:08 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 1kkjfo-0009cW-0i for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Dec 2020 09:09:08 +0100 Original-Received: from localhost ([::1]:32924 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkjfn-00016U-25 for ged-emacs-devel@m.gmane-mx.org; Thu, 03 Dec 2020 03:09:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36194) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkjeC-0000Hw-44 for emacs-devel@gnu.org; Thu, 03 Dec 2020 03:07:28 -0500 Original-Received: from logand.com ([37.48.87.44]:53744) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkjeA-00012R-2l for emacs-devel@gnu.org; Thu, 03 Dec 2020 03:07:27 -0500 Original-Received: by logand.com (Postfix, from userid 1001) id 0382D19F103; Thu, 3 Dec 2020 09:07:23 +0100 (CET) X-Mailer: emacs 26.3 (via feedmail 11-beta-1 I) In-Reply-To: <86360nwxch.fsf@akirakyle.com> Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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:260201 Archived-At: On Wed 02 Dec 2020 at 17:24, Akira Kyle wrote: > On Tue, Dec 01, 2020 at 12:44 AM, Tomas Hlavaty > wrote: > >> On Mon 30 Nov 2020 at 10:03, Akira Kyle >> wrote: >>> and because I see pgtk as the future of Emacs on GNU/Linux systems >>> as X becomes increasingly obsolete. >> >> I am not sure such future is bright. >> >> In that future, is there no way to do graphics without a widget >> toolkit? > > Sure there is. Under wayland you can just dump pixels into a > shared buffer to render them to the screen or use EGL to render > using a GPU. The difference from X is that wayland offers no > convince functions to actually draw pixels into such a buffer, its > up to the client to do so. In order to not reinvent the wheel, its > much more convenient to use a toolkit to draw the elements it's > good at drawing. "just dump pixels" and "no function to actually do that" and "use toolkit" does seem to contradict the point of being able to do it without toolkit. How long will pgtk future last? Compare that kind of future with for example ansi terminal future. Which one do you think has longer future ahead? Why? >>> 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. >> >> Also popup menus that pop up on a mouse click are gtk iirc. >> >> And maybe scrollbars? >> >> It may have changed since I turned these distractions off a long >> time >> ago. > > I think this is really ultimately a personal preference. It was not my personal preference to implement popup menus and scrollbars as proper widgets. >> I think that they are also fundamentally flawed: How can I search in >> menu? Maybe it should be a buffer. New Gtk hides menu under an >> unintuitive button anyway so this could just display searchable Menu >> buffer. > > I think it would be possible to implement such menus without GTK using > just child frames. Why not also implement the rest without GTK? >>> 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. >> >> Maybe that is a good thing. >> >> Widget toolkit dependency is a heavy price to pay for. > > I don't think it's a "heavy price to pay" in general. It greatly > simplifies many applications, which if they were to forego a toolkit, > would likely have codebases comparable to GTK or Emacs. But its true > that Emacs is far more decoupled, for better or worse, from toolkits > than your average GUI app. Emacs already has to forego a toolkit, doesn't it? Why? Because it has to work portably without any particular toolkit or with all chosen toolkits. It does not simplify Emacs I think, on the contrary. Would not it be better to extend the canvas idea you mentioned above to allow graphics in general, portable, toolkit independent way?