On Thu, Sep 2, 2010 at 5:04 PM, Simonson, Lucanus J < lucanus.j.simonson@intel.com> wrote:
Have you ever written a GUI framework before? Have you ever done cross platform applications (with a gui) that work with both Mac and Windows, for example? What application domain are you targeting? Games have pretty different requirements from office type applications. Before you attempt to improve on the state of the art be sure you have mastered the state of the art and are in a position to make the right calls on what the next steps are.
What exactly is wrong with QT and why is dynamic polymorphism, which is bad for so many other things, not the correct solution for GUI widgets? In a GUI you almost by definition don't care about runtime overhead because the latency requirement gives you plenty of time for everything but a dog slow java GUI to be adequately responsive. Just what is it about a "modern" C++ design that you think will be to your great benefit?
Arguments about which dialect of C++ to use are about as tired as arguments about which programming language to use. Frankly multi-language application environments where C++ provides the back end speed and core logic while some scripting language provides the GUI seem to work perfectly fine. I don't really want to do GUI programming at all but I'm not sure I want to do it in C++. From my perspective GUI programming is the scut work you can contract out cheaply and get good enough implementations with reasonable turn around time. You don't need an "expert friendly language" for scut work and we can't expect the bottom of the barrel programmers who are currently able to excel at programming user interfaces to make sense of a boost style GUI framework API.
In short you can't argue that a "modern" design for a GUI framework is a good design by pure virtue of being new. You have to state what your design goals are and how the design elements you choose achieve those goals better than the alternatives. Remember who your user is when designing a library. If you restrict your user base to people exactly like yourself by making design decsions based upon personal preference you will end up with at least one happy user of your framework, but by no means good odds of having many more.
Regards, Luke
My current target right is to create the abstraction layer between the application and the system. Everything else will be worked on later, once the minimum requirements for building a GUI library are close to being met. I am not building everything to my tasts; instead I am posting concepts for discussion (though no one has responed to them).