Hi On Sun, 2004-03-07 at 21:10, Brock Peabody wrote:
Peter Dimov wrote:
The other important principle that GUI programmers will inevitably need to learn, earlier or later, is that appearance and logic must be kept as separate as possible. (Just ask anyone that has been programming active Web sites.)
The reason that this is true in traditional GUI environments is that there is a tremendous amount of housekeeping and overhead in even very simple interfaces. It makes sense to isolate this code because there is so much of it that has very little to do with the logic of your program.
The truth is, however, that the appearance of an application has a great deal to do with its logic. Changes in a program's logic will almost always change its appearance. If you can automate the largely redundant bookkeeping behind a GUI all you really have left is expressing the relationship between your program's logic and its appearance. This is done with a DSEL.
This is definitely beside the point. It may make sense to lay out the GUI with a DSEL, and it may make sense to use a data file. I'm not interested in tackling that problem (directly), and I don't think it's the business of the hardware abstraction layer to present one or another interface. The HALs job is to be as close as possible to the hardware - but no closer. This GUI library is, by and large, a hardware abstraction layer. In many ways, it's comparable to boost::thread or boost::filesystem: it represents the underlying primitives directly, but in such a way as to be (a) much easier to use in terms of housekeeping, and (b) safer in terms of reducing programmer errors. Fancy frameworks can be built on top of it.
My goal with the GUI library I've made is that you only need to know C++ to use it - I don't want our programmers to have to waste their time mastering the ins and outs of MFC - I've already suffered for them :). Again, I don't see how any platform independent library can "map closely" to the underlying architecture.
The devil is in the details, as they say. In fact, almost all platforms that have a GUI support more or less the same primitives: windows, buttons, text-entry boxes, menus, selection boxes, list boxes. The abstract representations of these can be mapped very closely indeed to the underlying implementation without any significant impact on portability. I think there is a threshold where the underlying implementation changes from being dead-simple to being a nasty, bloated hack that's difficult to follow and dangerous to maintain. The trick is to sneak in just under that threshold, while still keeping the interfaces abstract enough to be unsurprising. Have you had a look at the current interface? I think it's very unsurprising. From a newbie perspective, anyway. Regards David Turner