games that need any kind of UI must link against heavy-weight UI libraries (GTK, QT, etc) which typically impose some kind of application framework Library mak

games that need any kind of UI must link against heavy-weight UI libraries (GTK, QT, etc) which typically impose some kind of application framework Library makers need to be aware of this danger and prevent their libraries from unnecessarily becoming frameworks. If you want to provide framework-like functionality, separate the core functionality from the framework and make it available separately. You don't want to impose your build tools, application structure, and a bunch of application infrastructure on some poor guy who just wants to pop up a dialog. Even libraries that are advertised, documented, and distributed as simple libraries tend to acquire framework-like restrictions if the authors aren't careful. For instance, a few years ago I wanted to add some simple visualization to a program I wrote, so I linked in SDL and added a thread to plot the state of the program periodically. (It was the only graphical element of the program; the program's input and output were files.) My sample code worked in standalone tests, but it didn't work when I ran it in my program. Logically it had to be a threading problem, but I was only making SDL calls from a single thread in the application, so I was left scratching my head until I talked to a developer on IRC and discovered that I had to make all SDL calls from the main thread. I was flabbergasted. (It was clear in the documentation that you couldn't make calls from "other" threads, but I didn't realize "other" meant "other than the main thread.") Anyway, I was kind of stunned that this library wanted me to completely restructure my application before I could make a few simple function calls. I ended up sending state information to standard out and piping it to a separate process that used SDL to do the visualization. By that point I was pissed that I had chosen SDL, but I didn't want to throw away all the code I had written. I could have changed the application to reserve the main thread for SDL, but the program was usually run without visualization, and besides, what would I do with the next library that forced me to make all my calls from the main thread? Create a main thread pipeline that did nothing but make calls to various libraries? And that's the final straw for self-centered, overly restrictive frameworks: they don't compose with each other. Even if structuring my program around your framework is totally worth all the awesome functionality, it won't be possible if I'm already committed to a different framework.