On Sun, Jul 22, 2018 at 11:58 PM, scott via gtk-list <gtk-list@xxxxxxxxx> wrote:
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 you need to do is to take those sockets, turn them into sources that are handled inside the GUI event loop, and there's no threading anymore
now, should the communication taking place over the sockets have some time constraints that the event-handling + drawing aspects of the GUI event loop interfere with, then sure, you need threads.
but look ... in the Unix/X Window world, the fundamental design of GUI code has always been single threaded in the sense that if you want to use multiple threads to draw, you need to explicitly take locks to make it work. in the MS world, the opposite it true: there are implicit locks around everything, and you can use threads without thinking about it too much.
my reading is that one of these models is right, and one of them is wrong. if you want to tie drawing into the underyling hardware refresh cycle, then you're faced with the ultimate reality that drawing is single threaded (there's a single current screen state that gets delivered to the video hardware on each refresh cycle, by a single thread). if you want multiple threads to possibly affect what's in that screen state, then you either have to composite multiple thread outputs when handling the refresh or you have to use locks. The first one is basically insane. The second one leaves open the question of whether the locks are explicit or implicit (buried in the API implementation).
Most Unix-y programmers tend to prefer that things with costs are left explicit. MS cultivated a different culture, where (some) things were eas(ier), but the costs were hidden.
The fundamental drawing model of GTK+ is really incompatible with multi-thread drawing. It is supposed to occur in an expose event handler ONLY, with no specification of when or why that expose event is generated (could be a hardware refresh (vblank); could be a window geometry or visibility change; could be other things. The idea that your socket-listening thread can "just draw somewhere" is at odds with this, unless you draw into an off-screen buffer of some sort. Problem is, you still need locks to use these buffers during the expose handler, and you're basically talking about compositing the result of each thread. Which is nuts.
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.
i wasn't commenting on glade's effectiveness. our development model just doesn't use RAD tools, because it's not really the right concept for how our GUI operates. it's not Glade that we don't use - we wouldn't use any similar tool on any platform.
finally, i don't believe that your observations about the origins of MVC are even remotely correct, but that's a sideshow.
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
