Rob Stewart wrote:
My point, then, is that choosing the non-native route must be done carefully or it *will* turn off users. Still, an alternative L&F isn't *necessarily* a turn-off.
Agreed. I don't think anybody actually advocated to do things differently compared to any particular GUI. The question simply was about who will be in control of the decision. In the past developers chose a particular API (*) not only because of its merits in terms of API design, but also because of the visual appeal (or lack thereof) of the GUI itself. It would be great if they could choose boost's GUI for the same reason they would choose other boost libraries, and not getting turned away because they like the 'boost GUI L&F' no matter what that will turn out to be. Other GUI toolkits have shown how to get this right. Regards, Stefan (*) assuming that they did have a choice at all