Re: [boost] GUI foundations

From: Andy Little (andy_at_[hidden])
Date: 2005-09-29 04:03:08

"Reece Dunn" <msclrhd_at_[hidden]> wrote
> I have, as well as many others, have made attempts into this brave new world
> ;).
>
> I suggest getting the framework right first to allow the support for the
> GUI/Graphics libraries to be build on top of them.
>
> (1) Platform -- detection for what GUI library is being used; native (GTK?,
> PalmOS API, Win32 API, etc.), native extension (ATL/WTL, MFC, GDK+, etc.) or
> cross-platform (wxWidgets, Qt, etc.) and the platform being used for that
> cross-platform GUI. This could be an extension to Boost.Config with
> platform/win32.hpp, platform/wxwidgets.hpp, etc.

(Are all these libraries equivalent? Arent QT and WxWidgets at a higher level
than Win32 Api?. Should we also include XWindows in the set of low level
libraries. BTW My thoughts on C++ GUI was to implement in parallel on Win32 API 
and XWindows initially)

I'm not at all keen on this approach because it is hugely platform dependent,
like wrapping yourself up in sticky mud. Code is never going to be portable.
Remember that the ultimate goal is standardisation. There is no standard library
that is a wrapper for / or has dependencies on an outside commercial library. I
believe that would be unacceptable. The approach I would take is to require a
common interface across platforms. Design of a GUI  should start from abstract
concepts not implementation needs.

> (2) String Library -- helpers to interact with native string types (e.g.
> wxString and ATL::CString) and C++ strings std::[w]string; native version of
> std::[w]string for platforms that use wide character strings; conversion
> routines and other helpers.

I would just use std::string. I dont understand why this "native conversion"
thing is so important. I dont think it would be acceptable either to standards
committes.

> This should be one of the goals. It should also be possible to hook into the
> native code (GTK, wxWidgets, WTL, Win32, PalmOS API, etc.) when/if you want.

This would be easy to do from any given implementation but would just represent
a failure of the GUI library to provide the required functionality.

regards
Andy Little