Back in the days I was against frameworks not using native widgets. So I tend to use wxWidgets where I can (say instead of MFC). I shied away from Qt only for t

Back in the days I was against frameworks not using native widgets. So I tend to use wxWidgets where I can (say instead of MFC). I shied away from Qt only for that petty reason. I'm not visually/hearing impaired, but thought for a long time that unless you use the native widgets, your apps won't be accessible to people with such conditions. So maybe I was half-right, but then I've found out that Windows provides API for one to expose widget contents in a way that the system can assist with reading the text, enhancing this and that, etc. Same with Eclipse, which relies on native toolkit, vs. Swing. But then if you compare Eclipse and IntelliJ - the difference is huge. Eclipse is clumsy, the widgets even though they are supposed to be native - somehow look baroque, oversized, while in IntelliJ/CLion things can be customized (Darcula+font settings) and look pretty sweet. Same with Qt. With good stylesheet you can make an artist, a game scriptor, or level builder happy. They won't even care that you haven't used the native toolkit. Then as it goes, it's more easier to expose/subclass/customize non-native toolkit compared to native, or even native which was wrapping internal widgets and exposing them other way. In a previous company I worked, we ported our game level editor (Radiant) from MFC -> Qt and saw burst of development going on, as people from all backgrounds were able to add more things in the UI. Collaboration was thriving, while with MFC you had to spent years learning how to do bits and pieces. Same with wxWidgets btw, as we also used in projects. And at last, some rather specific story about wxWidgets on Windows - I think we had an editor, or a launcher of sorts, and it was tracking/showing log of operations. If you wanted to jump/search to a line it was rather slow, and limited... Turns out wxWidgets on Windows would use some native control, and the implementation of "give me the current line" in the editor would scan the log from begining to end, counting all \n\r, until it came to your buffer position and tell you the number. The GTK version, which someone else used for other tool did not had this problem... TL'DR'... Leaky Abstraction! nuff' with ranting...