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

Subject: Re: [boost] Thoughts for a GUI (Primitives) Library
From: Marsh Ray (marsh_at_[hidden])
Date: 2010-09-02 19:11:56

On 09/02/2010 04:04 PM, Simonson, Lucanus J 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:
>> ...
>> 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.

All first-class GUI libraries have had commercial backing, multiple full 
time develop and testing staff, going for several years. It's an insane 
amount of work, however you slice it.

By all means, it could produce something magnificent. But I would not 
want to see Boost's energies get diverted for a quagmire like that.

Perhaps you could start out with something small, like just a edit 
control? It needs to support all the usual modern UI interactions. 
Unicode and bidirectional text rendering of course. Mouse selection 
(including of bidirectional text). It needs to be efficient enough to 
run on a mobile, or to have hundreds of them on a single screen. 
Multi-level undo support is important. Don't make the mistake of the 
Eclipse guys and neglect to support rectangular text selection regions 
in your design. Also, it needs to follow the fonts, color scheme, and 
keyboard conventions of the host OS such as multilingual text input. It 
needs to interoperate with the clipboard formats of the host as well. It 
also has to work with screen readers and other accessibility features, 
and comply with government regulations in that area in general. It 
probably needs some support for printing too. Of course, most developers 
will expect it to support data binding to relational data sources and 
that can be dragged-and-dropped as a component in some UI design tool.

> 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.

I think there's a time and place for experimental projects too.

> What exactly is wrong with QT

I've looked into using QT now and again since they opened the license. 
What gets me:

1. It seemed to require a toolchain oriented around QT (e.g., CMake), 
not just something you can #include and link into an existing source tree.

2. It seemed to require some custom preprocessing step that made it not 
valid C++. Aside from my strong preference for sticking with a standard 
source language, this caused minor annoyances like messing up the syntax 
highlighting and indention rules in my source editor.

3. It didn't throw exceptions.

> 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.

All this builtin UI functionality was supposedly a major advantage for 
Java over C++. But big UIs frameworks tend to fall out of favor every 
few years. AWT, Swing, SWT, and "the web interface" and so on. Java 
became inseparable from its built-in APIs supplying concrete 
functionality and, frankly, I haven't heard many new ideas coming from 
there in the last few years.

On the other hand, C++ doesn't promise much more than file and console 
IO, which is even optional. It adopts new features very slowly, but 
usually they're the kind of useful abstractions that never go out of 
style. Coincidentally, there's a wide ecosystem of UI toolkits with 
varying levels of specialization and platform dependence. It's possible 
(if not preferred) to write an efficient UI in C++ on just about any 
platform (except /Apple iP\w+s/).

> 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 sure wouldn't mind if somebody would put the snappiness back in the 
mouse clicks the way we had it with a 386 running Windows 3.1. Modern 
OSes seem to have so much background processing and layers of 
virtualization I sometimes see the hard drive start churning when just 
hovering the mouse over some icons.

> 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.

I sometimes feel that way too, maybe you and I aren't good candidates 
for this project then? Nothing wrong with that.

> 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 my (moderate) experience, the more UI-heavy a company's product is, 
the closer to the bottom of the design hierarchy the people who actually 
write code are kept.

But I don't think it's fair to generalize them as "bottom of the barrel" 
programmers. I'd imagine there are lots of industry-specific apps being 
written where the chief scientist just happens to be the one also making 
the UI.

I found this to be a great and inspiring story:
http://www.nucalc.com/Story/
http://video.google.com/videoplay?docid=-7497796873809571567

> 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.

Now that's kinda putting the horse before the cart, don't ya think?

>  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.

This is all good design advice.

But there's also value in writing interesting C++, learning from it, 
trying something different in the UI space, and possibly ending up with 
something useful along the way. There's nothing sane or prudent about 
starting a massive programming project like a generalized UI framework. 
Let's not think it through to the point that everyone is convinced to 
stick with the status quo for another several years.

My only suggestion is that it be done on a separate mailing list.

- Marsh