Re: [boost] Thoughts for a GUI (Primitives) Library

Subject: Re: [boost] Thoughts for a GUI (Primitives) Library
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-09-02 17:04:08

Gwenio wrote:
> On Thu, Sep 2, 2010 at 4:09 PM, Binglong Xie <binglongx_at_[hidden]>
> wrote: 
> 
>> For example, when different platforms are considered, GUI is very
>> complex and debatedly harder to abstract than process, thread, file
>> system and others.
> 
> 
> While such matters are beyond the scope of what I would like to
> accomplish 
> at this time, my general thoughts one how to build an abstract and
> flexible GUI is based on the iostreams in the Standard Library.
> Summary:
> - You have a class that define the function of various GUI
> components and can be extened or rewritten by inheritance (like
> std::iostream).
> - You have data objects that will consume user input to modify it, and
> produce any output for the control (like stream buffers).
> - You can imbue the component with an object that defines how it is
> drawn (like std::locale, only it is more like a single facet that
> than an entire locale).
> 
> Before going farther, I would like to have a working design for the
> ground work needed for a GUI to be created.

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