Xref: utzoo comp.windows.x:33222 comp.windows.x.motif:2027 comp.windows.open-look:695 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!samsung!uunet!visix!amanda From: amanda@visix.com (Amanda Walker) Newsgroups: comp.windows.x,comp.windows.x.motif,comp.windows.open-look Subject: Re: Toolkit for Open Look *and* OSF/Motif Look and Feel Keywords: toolkit, Open Look, OSF/Motif, GUI Message-ID: <1991Feb25.212238.4525@visix.com> Date: 25 Feb 91 21:22:38 GMT References: <1057@attc.UUCP> <1991Feb19.210822.26826@visix.com> <1991Feb20.170617.15372@cs.umn.edu> Organization: Visix Software Inc., Reston, VA Lines: 74 brsmith@cs.umn.edu (Brian R. Smith) writes: >Ack! An unbeliever! :-) >I don't understand why they didn't use constructors, and my first >guess is that the implementor wasn't completely comfortable with C++. This was my impression as well. OI, while it uses C++ object inheritance, still seems pretty C-oriented stylistically. And if you're going to use C style, you might as well use C, as far as I'm concerned. To me, C++ isn't worth it to gain a *little* bit of leverage; it's only worth doing if it's a fairly big win. I agree that InterViews gains a lot more from C++, comparatively speaking. >I don't think it's going to be possible to express the functionality >of an "application" generically and yet with enough detail that it >could be expressed meaningfully in multiple different look-and-feels. Well, most L&F specs are functionally oriented. Taking a functional view of the API helps a whole lot here. >The only way I can think of to do something like it, and do it well, >would be to implement the application the same way as the base user >interface objects - so that IT also understands each of the possible >look-and-feels necessary. >I.E. Say you were making a simple "edit" window that needed to be >scrollable. It consists of a vertical string of data and a scroll >bar, pasted together in some magic way. GUI X *requires* that >scrollbars be on the right, while GUI Y lets the user decide. The >edit window must understand both of these conventions, and decide >between them. This doesn't seem intractable to me. It just shows that you need a generic "editing area" abstraction. As an example of this, one of the standard items in our toolkit is, roughly, "a scrolling view of an ordered stack of 2-D object extents." Sort of like a drawing program that doesn't actually draw anything itself (like, zen, eh?). The application doesn't worry about how to scroll, or manage selections, or stacking order, or whatever. It describes the behavior it wants, and supplies code to customize some actions (like drawing individual objects, etc.). It doesn't care where the scroll bars are, or even how scrolling is handled at all--the L&F could just as easily specify that Alt-mouse-drag did scrolling. This is the sort of thing I mean when I say that having to know about the L&F (at an application level) shows that the API needs to be improved. The application should (IMNSHO) take a purely functional view of how the interface is presented to the user. Insofar as that interface is affected by the L&F, it should be implemented at the toolkit layer, not in the application itself. >Trying to make a toolkit that understands application-by-application >foibles is hard. Yes. > Extending the toolkit to include the objects YOUR >application requires makes much more sense to me. This seems to be a somewhat separate issue to me. >So you need a toolkit that is easily extensible. >Yay for C++ and subclassing... Well, C++ isn't the only way to do subclassing. It's not even the only easy way (although I will grant that Xt's approach is pretty unwieldy). We use a bare-bones template based system that fits well into "vanilla" C code, for example. It gives us what we want with a minimum of baggage. -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "Furious activity is no substitute for understanding." --H. H. Williams