E. Gladyshev wrote: >> Microsoft has a Windows Template Library, WTL, for >> Windows specifically, >> which is template-based but which they barely >> support for their VC++ users. > > The main point of the proposed library is not a > wrapper. WTL is just a Win32 wrapper. > The main idea is to simplify the use of STL containers > as data sources for UI widgets (in a portable way). > See my ListControl sample in a prev. message. > Also the proposed library will help to organize the > GUI/GDI elements and controlling data structures in a > consistent (with the C++ standard) way using the > 'iterator' paradigm.
I understand that. > > It seems to me that in our practicle life, we ended up > with two different worlds in our hands. One is the > nice and clean C++ template world which works great to > program algorithms and data strucures and another one > is the dirty GUI world that we have to use to present > our nice data structures. Most of the time when we try > to bring these two together, the nice structure of C++ > template programming doesn't look so nice anymore. Again I see what you want to do. > > It is a big project but at the end, it should bring > these two worlds together (at least bit). I am not trying to discourage you on working on such a project but the differences in GUI widgets and GDI functionality between operating systems is still very great. As a very simple example, realizing that most examples will be much more complex, items in a listbox may be representable by a std::vector or even a std::map in one operating system but may have much more complex requirements in another OS. Besides the issue of mere representation of the items in the listbox is the way the listbox gets populated with data and the way one reads data from the listbox back into your containers. This also varies from OS to OS. Some OS's use messages to transport data, some use callbacks, some use direct API calls, some use enumerations, some use asynchronous I/O, and there may be other mechanisms for all I know. And this is just a listbox, a very simple widget, and yet you are going to have to write code for this that works for Windows, Linux, Unix flavors, MacIntosh, VMS, OS2, and whatever else OSs Boost supports. Think of more complicated widgets which have been developed like tree views, page controls, list views, track bars, toolbars, edit controls, combo boxes, and many others. On the GDI side there is the drawing of bitmap images, geometrical figures, text, regions, vector images, low-level APIs like OpenGl and DirectX, the list goes on and on. The task is daunting. Add to this the fact that nearly every C++ programmer already works with a framework library depending on his implementation of choice. On Windows alone I know of WTL, ATL, MFC, OWL, VCL, wxWindows, QT, and no doubt others about which I have no knowledde, each tied very closely to a particular C++ compiler, IDE, and implementation. While there may well be C++ programmers looking for a cross-platform GUI/GDI from Boost, most programmers are already very comfortable with the framework which comes with their C++ compiler and with the IDE features and tools that make using their "widgets" very easy. Some of these frameworks, hooked to dialog editors or window placement tools, allow the programmer to literally draw or place the widget exactly where it should go and specify both the widget's physical representation and data representation, and even the structures by which the data will be passed from and to the widget. The amount of code which must be written often becomes negligible by the programmer after the design time interfaces have been set up. Yes, the data structures are pretty primitive compared to C++ template containers and whatever other good things you might create, but it will be very hard for most C++ programmers to give up their RAD and RAD-like tools for manipulation of a library entirely by code. Finally many C++ programmers, being the creators that they are, have already invented C++ template-based mechanisms to use on top of the GUI/GDI framework of choice which their compiler and implementation provides. They may be very loath to use another more general template-based framework no matter how good it is. I am not trying to argue you against pursuing your goal but simply trying to point out the difficulties that exist and the barriers against many C++ programmers adopting your implementation as opposed to what they have already been using. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost