Around that time I worked for Trolltech and got a good view of how that project was run. The trolls took compatibility very seriously. From devs that were running KDE 3 using the current nightly build of Qt 3 to swapping out the Qt library of various Qt applications with the next Qt release to find any regressions ourselves, keeping things working was important. Dogfooding with KDE, internal tools etc was expected by developers. It is not to say we didn't make mistakes, but we did try to prevent as much as we could. A good API really goes hand in hand with compatibility. Because almost any API change in C++ is incompatible and because any public API we would be stuck with for years there was a huge incentive to get it right. When designing any new API there was always multiple rounds of API design sessions often with many different developers providing feedback and always feedback from the documentation team. Is this API extensible? Does it use the same terminology as the rest of Qt? Could any of the function names be named better? Is there any api missing or that could be removed, etc. New classes had examples and demos not just for documentation purposes, but often enough written first to help find the best API (before actually implementing it) and second to be used to regression test compatibility. Before a release all new API was reviewed one last time to catch any errors that might have slipped through. Many of the lessons learned can be found in "The Little Manual of API design" that was written by one of the Tolls Jasmin Blanchette http://www4.in.tum.de/~blanchet/api-design.pdf It is because of all of this effort that when you are using classes in Qt you often can intuitively know what how the api would work. Again we did make mistakes, but we tried to learn from them and we were not shy about holding back on an API that wasn't ready for a release rather than commit to an API that we were not sure about. I recall more than one API being delayed for the better 6 months or so before being included in the next release (4.3 v.s. 4.2 for example). The result was always a better API and a more bug free class, a win all around.
Nice, but they didn't follow their advice in the case of creating parent-less widgets up to Qt4.
I.e. in Qt3 and previous versions, creating a parent-less widget resulted in a window frame being created. Why was that? If I am creating a button I do not want a window frame around it. I am going to insert the button to another widget later.
Thank God they fixed that in Qt4 and later versions.
