help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Would there be a drawback of using the same graphical toolkit on eve


From: Arthur Miller
Subject: Re: Would there be a drawback of using the same graphical toolkit on every platform?
Date: Sun, 20 Feb 2022 14:46:30 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Po Lu <luangruo@yahoo.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> That is because Emacs reverse the framowork roles, which does not work
>> always well with toolkits that are designed to be in driving seat of
>> the application main loop and display. There is an interesting post
>> about Emacs and how it threats graphical displays by D. Colascione who
>> I believe implemented, or helped to implement double buffering in
>> Emacs:
>>
>> https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A10107017870677858%7D&path=%2Fnotes%2Fnote%2F&refsrc=deprecated&_rdr
>
> That article is misleading.

Is it?

> The GLib (GTK) event loop is the least of our problems, which is handled
> very well with a small amount of code in xgselect.c.  That toolkit has
> its own ideas of how not to listen to the programmer which makes it very
> annoying to deal with (i.e. in both the X and PGTK builds, it keeps
> fighting with Emacs over the size of frames, and it's the only build
> where `scroll-bar-width' doesn't work.)
>
> It also has various bugs in features the developers deem uncommon, such
> as crashing when a display connection is closed.

Several entire desktops and countless applications implemented with Gtk
for different OS:s certainly speak in favor of your arguments.

Cetainly it must be problem to Gtk and someone elses incompetence, can't be
that Emacs is using it in a manner it wasn't supposed to be used.

> Using GTK all by itself also leads to various missing features and
> problems with keyboard input.  There was a thread on emacs-devel about
> it lately, and countless bug reports, which cannot be resolved.
>
> The event loop is certainly not the problem, since none of these
> problems are present in the Haiku port where the event loop for each
> window is run by the toolkit itself in a separate thread, or in an X or
> Xt build where Emacs drives the event loop with pselect, XPending, and
> XtDispatchEvent.

So Gtk should be designed as Haiku? Otherwise it is a bug? :)

You can either do as you do and consider a framework design to be a bug
because it does not fit into your wishful expectations, or you can recognize
that the design does not fit a particular application in this case Emacs. There
is nothing wrong with that, none framework is required to fit each and every use
case in existence. Emacs uses Gtk in a way it is not supposed to and that
creates some friction. I don't understand why you need to blame that on Gtk? I
am not even very fond of Gtk myself, but there is no reason to be unfair.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]