On Sun, Jul 22, 2018 at 1:26 PM, scott via gtk-list <gtk-list@gnome.org>
wrote:
> I'm new here, and here to cause some trouble. I just wrote my first GTK+3
> app - or rather, I adapted an existing C++ program to give it a GUI with
> GTK+3, and the distinction is important for reasons I'll make clear. It
> wasn't a fun experience, and I'll try to keep ranting to a minimum, but I'm
> here to ask people to seriously and thoughtfully consider that gtk+4
> embrace some new ideas.
>
> 1. Threads are here to stay
> A number of years ago I was doing something in python and tkinter, and got
> a crash out of tkinter. I dug a bit and realized I'd found a tkinter issue,
> and there wasn't a workaround. Since I was stuck - and annoyed - I wrote my
> own GUI toolkit, specific to Windows (but using openGL) and python. Frankly
> it looked like crap, but it had the feature of features I'd always dreamed
> of - thread safety. Complete thread safety, invisible to the coder. You
> could delete a widget from any thread at any time, including from the click
> callback of the widget itself, and it sorted everything out for you. No
> explicit locking, no hangs or crashes.
>
> I can't tell you how freeing this was or how much I've missed it since.
> Widgets are just resources and should be like any other resource. Think of
> files on linux. If one thread is writing to a file and another decides to
> delete the file, well, maybe you got what you wanted or maybe you didn't,
> but the operating system does not refuse your request, hang or crash. The
> file is your resource, and as such, you do what you want with it, from any
> thread at any time. The resource manager, in this case the OS, deals with
> it all, leaving you free to Just Code(tm).
>
> My C++ application is now riddled with gdk_threads_add_idle calls. It has
> to be. 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. And instead of calling GTK and saying "do this", I now have a bunch
> of functions that have to get injected into GTK, each returning false. Now
> the code is ugly. And I'm not going to redesign it around some central GTK
> world view; the fact that it paints a screen with status is not the main
> point of the application and GTK shouldn't demand a starring role.
>
> 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. stuff
driven by the socket should change the model; the view should always update
in response to changes in the model. if you design things correctly, this
just happens.
Now, if you just want a wrapper around idle_add() functions, so that they
become "invisible to the coder", fine. We have code in Ardour that looks
like sigc++ signals, but are actually cross thread:
some_signal.connect (boost::bind (&SomeObject::some_method,
an_object), ...., ui_thread()); // when "some_signal" happens, call
SomeObject::some_method in the GUI thread
this doesn't use idle_add() either (it uses a FIFO that is used as a source
for the main event loop). This sort of design is actually very nice, but I
don't regard it as the job of my GUI toolkit to offer this, because in fact
I need cross-thread callbacks between any of the dozens (or even hundreds)
of threads inside my application.
> 2. My pixels, not yours. Hands off.
> I know that Gtk has huge investment in flowing, springy, widget layout.
> Yay adaptability to new screen sizes. But sometimes, you know, I just want
> a widget to stay where I put it.
>
> Sure, if you're writing an app that has to adapt to a 2x3" phone's screen
> or a 20x8' foot, twenty billion pixel wall screen, having the GUI engine
> manage sizing is nice. And monitors keep getting bigger, so...
>
> Except wait. They don't anymore. These days, there's small screens,
> desktop screens, and massive wall displays, and applications rarely cross
> from one to the other. When they do, they're already coded to adapt,
> because layout is philosophically different for a phone and a huge screen,
> and different in ways that the GUI engine isn't likely to be smart about
> without help.
>
sure, but much more common is "desktop, but with various different sized
monitors, and users who prefer different sized windows and window layouts".
that's where the box-packing paradigm wins. i don't really anyone
advocating GTK for phones, and never have.
> 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, for specific niche applications. Maybe Glade can
> do this, but every time I Googled, I found threads saying "that's not the
> Gtk way".
>
> One True Wayism can have merits, but not in GUIs. Make a GTK API that
> makes it easy to draw exactly what I want. My application is a fixed
> display on a wall, and I'm not happy to see fields shifting around because
> the very large Current Time field ticked over to skinnier numbers. (I'm
> sure this is fixable using the current toolkit - but apparently not
> trivially.)
>
https://developer.gnome.org/gtk3/stable/GtkFixed.html
>
> 3. I have to do what? Just to control colors and text in labels?
> Maybe I did this wrong, but my goal was a black background, and then a
> bunch of labels of various sizes. I need to be able to update the text
> color and background color of the labels on the fly; everything from slow
> adjustment of text color to indicate changing states, to ohMyGoshAProblem!
> flashing labels at 4/sec because something's badly wrong. Simple, no?
>
> Simple not. It took a few days and I still didn't get exactly what I
> wanted.
>
> First of all, I learned the hard way that if you specify a widget's
> background color in Glade, nothing you do at runtime can change it. (That's
> probably overstated, but none of the existing or depreciated calls I tried
> did anything.) That's just a weird bug or documentation failure, but the
> upshot is that it's critical to specify as little as possible in Glade and
> do as much as possible in code. That's simply weird. And since Glade isn't
> making it easy to get the layout I wanted anyway, why did I bother with it?
>
> Second, in other to get a black background everywhere, I had to use css.
> Not a lot of it: *{background-color: black;} got it done. But then there
> was learning curve with providers and those are tricker than they should
> be; it was a great moment when the window finally turned black. It should
> have taken ten seconds boring seconds in Glade. Why did I need a css file?
> What is this stuff about providers and screens?
>
>
> 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 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.
_______________________________________________
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
