We had a long discussion on the french community developpez.com recently about exactly this subject. Most of the participants were fighting over the fact that Qt is well enough and that working with high level C++ for GUI is not currently necessary. In the discussion some thought were put in a library concept (that was started after the discussion but I'm not sure about it's current state) and I remember proposing some kind of design, something similar to what we see in recent boost libraries(boost::log, boost::msm) : having the lib being a meta-library with customizable front-end and back-end. I don't think it's possible to build a GUI framework that is general enough for any kind of use. But I think it's possible to provide a way to plug a input-specific-strategy and an output-specific-strategy in some kind of meta-library providing ways to define controls behaviour in a general way, with possibility to use input-strategy-implementation-specific interface if required and output-strategy-implementation specific interface f required too. I'm not sure I'm clear enough (and it's late)... anyway I never implemented something like that so I might be talking about unessessary magic. That said, I and others put a lot of thought in some kind of implementation but I personally don't have time for such an epic task at the moment (I wish I had). The main problem I see is not about technique but about the domain's knowledge, because I see that a lot of us mere programmers don't know much about abstract of graphic communication. For french-speakers, the discussion can be read there : (the server is down, i'll post it later) On Thu, Sep 2, 2010 at 00:46, Edward Diener <eldiener@tropicsoft.com> wrote:

On 9/1/2010 3:38 PM, Ralf Globisch wrote:

...

...

...

...

I don't know if there's enough space for this. There are a plenty of GUIs Framework,

Giorgio Zoppi 09/01/10 2:17 PM>>> like Qt or wxWindows, which are more advanced.

wxWindows is horrendous as a modern C++ GUI library. It uses C++ as it was used some 15 to 20 years ago and makes endless excuses about why its dialect of C++ must never be upgraded centered around support for hopelessly non-compliant C++ compilers.

Qt is a proprietary framework, also not using modern C++ but its own in-house ideas instead, which have long ago been superceded by modern C++ constructs such as in Boost libraries. Furthermore one can not create commercial applications with it without either releasing the source code or paying Trolltech, or whoever owns them now, some large amount of money. Neither solution is practical for Boost end-users.

There are also lots of other C++ GUI systems around, none of which I have ever found personally flexible enough.

Whoever would be capable of creating a modern C++ GUI system, as difficult as it would be to do, might find it worthwhile. However a number of others have pursued this goal in the past with appropriate Boost vault and Boost sandbox libraries, without getting very far in interesting other Boost users/developers in the practical usage of their systems, or encountering endless discussions and disagreements among programmers who want different things in their GUI library.

So I too think it is an extremely difficult task but not for the reason that there exists anything out there good enough or useful enough as an alternative.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Edward Diener wrote:

On 9/1/2010 3:38 PM, Ralf Globisch wrote:

...

...

...

...

Giorgio Zoppi 09/01/10 2:17 PM>>> I don't know if there's enough space for this. There are a plenty of GUIs Framework, like Qt or wxWindows, which are more advanced.

wxWindows is horrendous as a modern C++ GUI library. It uses C++ as it was used some 15 to 20 years ago and makes endless excuses about why its dialect of C++ must never be upgraded centered around support for hopelessly non-compliant C++ compilers.

Qt is a proprietary framework, also not using modern C++ but its own in-house ideas instead, which have long ago been superceded by modern C++ constructs such as in Boost libraries.

It's not clear whether those "modern C++ constructs" bring much practical advantage.

Furthermore one can not create commercial applications with it without either releasing the source code or paying Trolltech, or whoever owns them now, some large amount of money.

This is not true. You can use Qt for all kind of projects, including commercial closed-source, without paying a dime. It's under LGPL on all platforms, and "L" matters -- it means you are only prevented from making local modifications to Qt and distributing modified version. - Volodya

Am Donnerstag, den 02.09.2010, 10:14 -0400 schrieb Edward Diener:

... I personally would prefer a modern C++ GUI based around Boost and any other modern C++ libraries as well as the constructs soon to be incorporated in the next C++ standard.

Who would not? If Boost had such a library, would anyone around here even consider using wxWidgets or Qt? Probably not? I think then anyone should agree that such a library could be useful to have in Boost. Whether it is worth the effort to create such a library is a completely different question. cheers, Daniel

...I think a better question is: could enough people agree on its design?

It is unlikely that enough people will agree on a GUI that is usable as it comes; So it would be a better use of time at this point to provide the tools needed to build a portable GUI Library (so they will not need to worry about adding support for all the diffrent platforms) and tools that can make the task of making said library less monumental. After all, that is what the Standard Library and Boost do: they provide an interface for accessing system services in a portable manner and tools to make writing applications easier.

...

Cory Nelson wrote: We could do _so much better_ than wxWidgets, Qt, and GTK.

We could also do worse :-) , given : 1/ the needed time that won't be available 2/ the fact that people have highly various needs for a GUI. 3/ that graphic designers are already trained on flash/web technologies (that can be used to do beautiful interfaces at cheap prices).

...

I think a better question is: could enough people agree on its design?

You could check notus (http://notus.sourceforge.net/) , which was developped by some boosters I think, and which has a modern c++ approach and also design documents. If you are looking for a minimalist 'open window' gui library, I think it's possible to find very good multi-platform projects that can do that (dlib, cimg, ...). Best regards, Pierre Morcello

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

Gwenio 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: - 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

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

Edward Diener wrote:

Qt is a proprietary framework, also not using modern C++ but its own in-house ideas instead, which have long ago been superceded by modern C++ constructs such as in Boost libraries. Furthermore one can not create commercial applications with it without either releasing the source code or paying Trolltech, or whoever owns them now, some large amount of money. Neither solution is practical for Boost end-users.

As Vladimir Prus already mentioned, this is not true.

There are also lots of other C++ GUI systems around, none of which I have ever found personally flexible enough.

Still, why start yet another imperfect GUI system then? Wouldn't it make more sense to help one of the existing GUI systems to become more perfect (or at least perfect enough to be acceptable)?

Whoever would be capable of creating a modern C++ GUI system, as difficult as it would be to do, might find it worthwhile.

What do you think about Adobe's Adam & Eve then? Regards, Thomas