
"Reece Dunn" <msclrhd@hotmail.com> 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