Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)

[Tomas Hlavaty <tom@logand.com>]

On Wed 02 Dec 2020 at 17:24, Akira Kyle <akira@akirakyle.com> wrote:
> On Tue, Dec 01, 2020 at 12:44 AM, Tomas Hlavaty <tom@logand.com> 
> wrote:
>
>> On Mon 30 Nov 2020 at 10:03, Akira Kyle <akira@akirakyle.com> 
>> 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?