> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Beman Dawes > Sent: Wednesday, July 30, 2003 7:09 AM > To: Boost mailing list > Subject: Re: [boost] Re: GUI/GDI template library > > At 02:24 AM 7/30/2003, E. Gladyshev wrote: > > >...[compile-time or run-time?] I don't know what is the best way to go. > > It is always hard to know the best way to go if you don't know where you > are going. > > A GUI/GDI library might fill one or more needs: > > 1) A conceptually clean library, easy-to-use, good for teaching GUI > principles, and useful for real applications where the emphasis is on > portability. Controlling the look-and-feel on different platforms not a > concern. Access to platform specific features not a concern. > > 2) An adaptable library for applications which do need a certain amount of > control over look-and-feel on different platforms. Portability is quite > important, but so is ability to adapt look-and-feel to different > platforms. > Access to some platform specific features may be a concern. > > 3) Totally controllable library for applications which need to manage > every > aspect of look-and-feel, and need access to every feature the platform > provides. Portability not a concern. > > (That's an oversimplification, but good enough for discussion.) > > Baring a stroke of genius (although on Boost that isn't totally > impossible), it seems very hard to fill all of those needs. > > It seems to me that most people who need (3) (or think they need (3)) > aren't going to use a portable library anyhow. I'd write-off (3) as a > target. > > Once you get over the mental hurtle of being willing to say "this library > doesn't try to fill every possible need", then (1) starts to look very > attractive. It is a niche many other GUI libraries seem to have ignored. > If > you concentrate on a conceptually clean and elegant design, then it may > turn out that it can also accommodate (2) fairly well. > > --Beman
I agree completely. Just getting (1) done will be enough work and we'll learn a lot. I think the focus should be on a clean and elegant interface. My suspicion is that applications generated with (1) will look more 'typical' for their platform than those making applications that need (3). They'll be portable, and at the same time exhibit more platform specific run time behaviour. Programmers using (3) need more control because they are not making an application that has a GUI typical for their platform. If you want all of your application's list boxes to behave exactly the same on all platforms, you are going to have to do a lot more work than if you want windows list boxes to behave like windows list boxes, and Mac list boxes like Mac list boxes, etc... We had a programmer who was resistant to using our GUI libraries because they limited his ability to add his own custom look and feel to each of his applications. His applications looked cool - but not like standard windows programs. They also tended to take a long time to produce and debug. The code was complicated and his custom logic had to be reimplemented for each new application. We don't want complicated applications with a custom look and feel. We want simple applications with a uniform look and feel. This need can be filled by (1) and I suspect many others will feel the same. Brock _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
