On 09/02/2010 04:04 PM, Simonson, Lucanus J wrote:
On Thu, Sep 2, 2010 at 4:09 PM, Binglong Xie<binglongx@gmail.com> 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