Re: GTK+ 4 suggestions

[scott <scott mayo comcast net>]

On 07/22/2018 02:37 PM, Paul Davis wrote:

On Sun, Jul 22, 2018 at 1:26 PM, scott via gtk-list <gtk-list gnome org> wrote:

Abolish the concept of a main gtk thread. "Anything anywhere and real soon now" should be the motto.

​this is a terrible, terrible idea.

the benefits of a single-threaded GUI are huge. it makes reasoning about stuff that happens in the View (and Controller) components of the application vastly simpler.

​"It has a lot of threads, each doing independent tasks with sockets and things, and sometimes they want to update a label with new text or new colors"  .... this is just a sign of not using proper MVC design.

Yes. It's not MVC. Because MVC is a way of doing things, but not the only way. MVC came about (partially) in response TO single threaded tookits. That doesn't mean it's a justification for one.

That's the point. Design patterns are approach, but there's advantage to having more than one aprpoach available. And in Gtk+3, there seems to have been a march towards this One True Approach.

As an example, my application takes no inputs. You don't click on it. You look at it. Originally it wasn't a GUI at all; it was an invisible service. But letting it paint a screen with current status was deemed useful, so I bolted a GUI on the side. Where, in this case, it belongs.

All I can tell you is, in the one case I had the freedom to write with a thread safe toolkit, everything became simple. Granted I wasn't writing a text editor. But there's design cost and effort in designing everything around some central graphics thread, and seeing as Gtk took two passes at supporting threading, it's clear there's some pain in deciding how to support it. My contention is that it's simply in the wrong place, and has been since the early days of the inherently single-threaded Windows message loop.

If everything was thread safe, you can still do MVC. And often you should. There's just not a gun pointing at your head telling you you must and will.
  

In other words there's a place in the world for the ability to Visual-Basic-Style-I-said-This-Big-And-Right-Here-and-no-backtalk-out-of-you nailing down of widgets,...

https://developer.gnome.org/gtk3/stable/GtkFixed.html

Will investigate, thanks.

​you can't get the flexibility and portability of the CSS model without some costs (mostly just some learning). If you had used older versions of GTK (as I still do), you'd find lots and lots of reasons why CSS is incredibly desirable.​

I'm sure it rocks, but I didn't need it or want it. It was forced on the app because I couldn't find another way. And if you need the all the infrastructure of css just to turn a window black, something is wrong.

i don't love GTK. but i think it's pretty good, and at least as good as the alternatives. i don't agree with any of your criticisms, and wouldn't want to seem them implemented. some of this is because i do not (and could not) use glade effectively.

I think that's telling. If Glade isn't effective, that says something about GTK right there. But I don't think implementing my suggestions requires obsoleting the existing interface. Continue to pump your functions into the idle loop if you want to; you just wouldn't have to.