Andy Little 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
"Reece Dunn" <msclrhd@hotmail.com> wrote 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.
Ok. At the very least it should hook into the platform's low-level API and be able to interact with (if not targetted for) other libraries such as Qt and WTL. I agree that the library should be designed on the abstract level, but it should also be possible to pass a rectangle object to GetClientRect (or the equivalent in Mac, PalmOS, etc.) without having to write a lot of platform-dependant code yourself. This could either be via an extension, or define something like: class geometry::rect { public: /implementation defined/ native(); }; native() -- returns a type that is compatible with the platforms rectangle representation that does native <--> geometry::rect conversions. [--example geometry::rect area; GetClientRect( window.native(), area.native()); std::cout << "window area = " << area << std::endl; --end example] That is, I want it to be easy to interact with Win32, XWindows or Mac code /in a way that is simple for the user/. I would also like the option of using native control/component types (or at least in terms of L&F and usability) as well as a cross platform L&F that Java can produce. Skinnable components at compile time (allowing a run-time skin option). This would allow you to hook into drawing the component type (push button, radio button, tree view), sub-element (expand/collapse on the tree view) and state (hot tracked (mouse over), pressed, inactive/disabled, normal, selected, other). Thus, you could have: template< typename Skin > class button { void draw( canvas & c ) { Skin::draw_item( c, ui::radio, ui::selected, ui::pressed ); } };
(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.
The Win32 API can use either wide character or narrow versions. Using the narrow versions on WinNT and above can cause performance issues with the narrow -> wide -> narrow string conversions done by the OS. Therefore, it would be useful to have something like a gui::string that is std::string on narrow character platforms (Win32 built with *A API variants, XWindows, etc.) and std::wstring on wide character platforms (Win32 built with *W API variants). This also has an impact on platform Unicode support. The "native conversion" I was referring to was that you cannot do: std::wstring str( "foo" ); at the moment. std::basic_string< native-character-type > should be the string type of preference.
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.
Ok. If each type had a native() method (see above), I'd be happy.