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