BOOST WIKI | RecentChanges | Preferences | Page List | Links List
Discussion and working notes on the specification and design of a cross-platform GUI library for Boost.
Discussions on the Boost.Devel Mailing List
Gui toolkit development has been discussed on the developer's mailing list
a number of times over the years.
BoostDevelGuiThreads has links to the major threads
A pragmatic GUI proposal GuiDesignDoc.
Existing GUI Libraries to Survey
A list of libraries to survey along with volunteers to complete individual survey components. Just suggestions for now. We can hash out the exact list on the developers list.
Specific Technologies / Techniques to Survey
A list of specific technologies / techniques to consider. Just suggestions for now. We can hash out the exact list on the developers list.
Survey Evaluation Points
A list of specific evaluation points to be addressed for each library in the survey. Just suggestions for now. We can hash out the exact list on the developers list.
- Message encoding, dispatch, handling strategies.
- Class composition strategies (for implementation hiding, specialization, extensibility).
- Use of C++ language features and language extensions/additional compilation steps.
- Should it be done with a 3D interface in mind (as MS Avalon)?
- What about the underlying primitives drawing API?
- DDX (dynamic data exchange)
Survey Results Summary by Library / Evaluation Point
To be worked on later.
My two cents: Apple's Cocoa, an Objective-C framework spawned from NextStep/OpenStep? is percieved as one of the best GUI libraries available by many people whose opinion I respect. As it is written in Objective-C, some of it's techniques are not transferable to C++ (nor should they be, Obj-C is dynamically typed). One of the finest things in Cocoa is it's TableViews and OutlineViews? (AKA TreeViews?). Cocoa TableViews are extremely easy to use now with ArrayControllers?, which map standard Cocoa NSArray's to table elements. I would very much like to see boost::GUI TableViews just as easily compatible with STL containers, perhaps something like this:
template<typename Iter_t> void set_data_source(Iter_t begin, Iter_t end) { /*...*/ }
Anyways, I think however it is done, TableViews ought to be very simple to use.
Top Ten Hassles All GUI Programmers Have to Deal With
What are the largest challenges faced by GUI programmers?
- A GUI library needs a decent callback mechanism. It should not be functions (or static member functions, but could be an option), as it makes the code pretty ugly. Also the Boost.Signals library is too oversimplified for this. I think of two places to look at for ideas:
- To make the interface as resolution / window-size independent as possible it's very important to have a layout mechanism.
- Or a means of specifying units such as pixels, millimeters etc like in SVG - AndyLittle?
- A programmer needs to be able to use the GUI in conjunction with other libraries (frameworks?) that an application needs with a minimum of hassle. Ideally, a GUI library should not "take over" main(), or dictate a specific kind of "model" (in the MVC sense). Practically, this probably means GenericsNotFrameworks?.
Definitely - this needs to be a library, not a framework. Taking over main is unacceptable -- MK.
- OTOH, if this is neither a framework nor a library, then what is it? "Generics" is surely a catchy name, but that sounds a bit hollow:
- if you provide buiding blocks "mechanisms" without specifying any policy, you can't enforce their use nor the consistency of a developer's code w.r.t the stated goal of your "toolkit" (for a lack of a better name that doesn't imply either "framework" or "library")
- In turn this renders any middle-tier next to impossible, for lack of a model to adhere to (ie no Boost.GUI based "libraries" of second order)
- finally, you probably want any Boost.GUI based application to be responsive to the user, so you have very little options but use threads to off-load the main loop... but then how do you not "take over main" for each such thread? More obviously when the "main" thread, that you will probably want to make the GUI thread, is just a special case? -- JFB
- Common GUI applications have no problem using very invasive frameworks because the GUI per se isn't "strategic"; important code can (and should) be confined in event handling callbacks. Varying degrees of dynamic UI modifications cover the spectrum between boring static definitions (sometimes from configuration files; see Glade for GTK) and tight coupling with the GUI mechanisms. - LorenzoGatti?
Top Ten Ideas For NEW Features Not Included in Surveyed Libs
Ideas (potentially stupid) for NEW features that we could integrate into a Boostified GUI library.
- Constraints. The Lit Window Library adds rule-based development (constraints) to traditional UI mechanisms to reduce the amount of coding neccessary for a UI: [http://www.litwindow.com/Library/index.html]. Adobe's Adam and Eve [http://opensource.adobe.com/] uses constraints for both inter-control data rules and layout. Amulet [http://www-2.cs.cmu.edu/~amulet/] uses constraints in a similar fashion.
- ADime [http://adime.sourceforge.net/] automatically creates simple dialogs through a "scanf"-like scheme. Provide a list of pointers to variables with captions for each control and the entire dialog (including validation and binding) is generated for you.
- data binding? (-- QT4 has got data binding to some of the widgets)
- power through simplicity?
Notes
General notes and commentary.
- Why is Boost.Signals "too oversimplified", apart from the fact that it's not thread safe? Examples would be good. -- AndrewBromage?
- As an example, develop a Boost sourcecode editor called BoostEdit?. This could turn into a nice IDE in the future with preprocessor preview and debugging via Wave, bjam project files, ... --Kevin Sopp
- Eugene Lazutkin's rant posted previously to boost mailing list: http://swsw.motovilov.net/weblogs/swsw/archives/2005/05/portable_c_gui.html --- it failed to agitate developers like all previous attempts.
Top One Issue To Be Solved First
- What is it that one wants to achieve by designing a C++ portable UI "library" ? -- JFB
- The questions of "overtaking main()" or not "generic vs framework" and the rest are pretty moot until that mission statement is defined.
- Windows uses [w]WinMain/DllMain? depending on whether you are targeting a GUI application or a DLL, whereas others use main as the entry point. Therefore, providing a layer around this would help writing platform-independant code. However, using the GUI library/framework should not require the use of the independant entry point. Another issue is the use of classes to define GUI behaviour (found in ATL/WTL, MFC, wxWidgets? amongst others). -- ReeceDunn?
- (It seems to be ok to define an int main(...) function alongside WinMain? though )- AndyLittle?
- ( And apparently changing compiler/linker options allows use of main . VCF does this ) - AndyLittle?
- Among the question to answers:
- What is a UI? What is the problem it solves?
- A cross-platform C++ GUI in the standard library. C++ is lagging behind Java because it doent have a standardised GUI. - AndyLittle?
- Platforms, not languages, have a standardized GUI. Java is a single-language platform, C++ is a cross platform language. Even Java has at least two completely different standard graphical interfaces (Swing and MIDP) for different needs, not counting SWT, Java3D etcetera; how can a Boost library be portable to all kinds of systems? For example to embedded systems with a 2 by 20 character display, to cluster nodes without graphics capabilities, to Symbian cellphones? A GUI library must be designed with a limited scope of portability (to find a common denominator) and of purpose (to make serious decisions); but this is not the approach of Boost libraries.- LorenzoGatti?
- Why do we want one? For what tasks and for what kind of users?
- My goal would be the ability for those new to C++ to be able to write a GUI application very quickly by just including a standard library header. This functionality is already available in Java. - AndyLittle?
- How is usability taken into account (or not) ?
- If the only impetus is to provide a boost branded UI, that's pretty dumb, isn't it?
- Boost is particularly good at cross-platform development and is a testing ground for the standard libraries. - AndyLittle?
- Boost libraries are cross platform because they depend on standard C++; Cross platform GUI libraries need multiple implementations for the different platforms; not little workarounds or short adaptation of small APIs like threading, but large and complex frameworks.
- What are the sacrifices that one is willing to make in order to get an UI that users will use, as opposed to developers?
- Why making yet another clone of Windows (whether you name it KDE or Gnome) is such a good thing? Just to favor "Rolling Our Own" ?
- KDE and Gnome and Windows are Window Managers. They are built on GUI toolkits like Qt, GTK, and MFC respectively. Perhaps we need to make the definition of a GUI, i.e. what is being proposed more clear, and also to explain the advantages and disadvantages.
- Wrong, window managers aren't directly involved; GUI toolkits like Qt, GTK and (potentially) MFC and Motif are portable because they are abstractions over a general graphics and I/O system (commonly X or Windows (GDI etc.) or OpenGL?); these can be themselves portable (particularly OpenGL?) or emulated on top of one another, but it isn't a generic library's business. - LorenzoGatti?
- What are the problems that users encounter with current UIs ?
- What are the problems that developers encounter with current UIs? Of what nature?
- For example, is the developer problem "difficult to program to" of any relevance to user problems ?
- Its simple. If its too complex then few will use it. I believe this is the fate of http://www.fresco.org. - AndyLittle?
- Is the developer problem "I developed on Windows, Mac users hate my product" of any significance?
- A cross-platform look and Feel is essential. For history look at Java AWT and Swing. It would be interesting to study the reasons for the change to Swing from AWT. I believe that they found the high level dependence on platform dependent components too limiting. - AndyLittle?
- Is the developer problem "there isn't a consistent set of UI guidelines to adhere to" and my progran won't talk with XYZ on Linux/Qt? because there's no interop between our boost UI and Qt/KDE/You?-name-it something to just scorn?
- The way custom Look and feel is handled per platform is a major issue cited by potential users.- AndyLittle?
Completely Cheeky Interjection
Since you guys seem to be looking at the whole topic of GUI design, why not add http://superficial.sourceforge.net to your sources of inspiration. It's not strictly a GUI toolkit and the demo implementation is in Java, but have a look anyway.
Another Interjection
Don't forget the looks. Although not all people care, many people get pissed off if a widget set looks plain alien on the desktop. It can lead even to the point where the software doesn't get used because of it. For instance GTK(-wimp) looks very bad on all Windowses, Tk looks like crap everywhere etc etc. If you're going to make a GUI library make sure it uses widget libraries that are able to look good on all/most of the targeted platforms. For instance wxwidgets is fabulous on that area...
Yet Another Interjection
Dovetailing on the previous question of looks, would the library be sufficiently abstracted that it could support a console as well as a graphical mode? There are plenty of use-cases (headless servers, embedded, OS installations, etc.) when operating in a pure 80-column mode would enhance the capability of the library.
GUI ?
An important consideration is the scope of the library. This sort of ties in with JFB's One Thing above. Most current GUI toolkits solve far more problems than just widgets: they contain threading, filesystem access, networking, and so on.
Boost already provides some of these. But even those not provided by Boost now should not be part of a GUI library; they should be separate libraries.
Even within the graphical stuff, there is the question of scope. Does Boost.GUI provide just drawing and windowing primitives? Does it provide a set of widgets? How large a set should it provide? Should there perhaps be two libraries, similar to GDK and GTK? Or two libraries in a different way, with one providing primitives, and the other a widget set?
Very often when looking at GUI libraries, I get the feeling that the authors aren't entirely clear on the scope of their library.
- SebastianRedl?
GUI libraries will always have specialized widgets, arbitrary graphics, deep operating system dependencies, different architectures; no GUI framework is good for everyone, so a "Boost::GUI" would be at best a popular option for specific tastes and needs, not a standard.
To help GUI programmers, both of applications and of frameworks, Boost could instead analyze their needs to reduce wheel reinvention.
Some difficult items that often get a low quality, low portability or low functionality treatment in GUIs include:
- Generic constraint systems (for layout and for inputs)
- The Observer design pattern and similar ways to propagate events
- Unicode text
- 2D geometry (e.g. polygon intersection)
- Keyboard input
- Mouse etc. input
- Colour conversion and management
Some of these needs are outside Boost's scope or addressed by existing libraries, but I think that some brainstorming could allow the design of new libraries with a wide applicability, including non-GUI uses, and a well defined purpose, instead of a vague mega-library with undecidable requirements. - LorenzoGatti?
Scope of modern GUI
If we speak of GUI only (without built-in XML parser, networking objects, embedded-browser widgets, custom template library, like in Qt etc.),
we end up with following issues:
- User Interface - widgets, buttons, controls, viewing-controls (e.g. directory trees) etc.
- Input System - mice, keyboards, joysticks and maybe other controls.
- Graphics
- Raster Graphics - surface upon which you can draw (a bunch of pixels data)
- Vector Graphics - scalable images, OpenGL? etc.
- Text support
- Unicode - huge issue addressed by ICU library which is optionally used with boost.regex
- Fonts - even more complicated issue than Unicode
Fonts are a great trouble. It is hard to think of a way to make them system independent. Rendering some complex scripts can be
a very difficult task. Some scripts have diactric marks and stuff. Each such script has to be addressed separately. There are a lot of different
font formats - Raster, Vector, OpenType?, Type1 to name a few. You can render them in plenty of ways. High complexity level.
Generally it's a great trouble as you can not create a separate and unrelated library for each and every one of those issues.
They're all related. And together they produce a huge scope. You can not create a GUI library without relying on existing non-boost libraries.
You need things like Freetype library etc. So I don't see how fully-functioning GUI library within boost is possible.
Only small-scope implementation is possible.
Disclaimer: This site not officially maintained by Boost Developers
![[Home]](/boost.png)
BoostGUI