jcb@frisbee.Sun.COM (Jim Becker) (08/22/89)
janssen@holmes (Bill Janssen) writes: ->In article <122257@sun.Eng.Sun.COM>, jcb@frisbee (Jim Becker) writes: ->>... How has it happened that so many intelligent ->>people have assumed that windows are a cheap resource that can be used ->>freely? ->I thought that "the X Window System" was spec'ed that way? Are you ->implying that some implementations have failed to meet system design ->goals? Even if that was a design goal of X, it seems that this is idea is overkill for the large part. There are examples where the use of a window is helpful, such as the clipping that comes for free. But on a per interactive item level, usage of a window seems a bit much. Before widgets came along there have been quite a number of GUIs that have worked without making the distinction of windows for each interactive element; these also used a lot less memory than what a normal Unix box comes with. My initial exposure to UI systems on X was (early) versions of Interviews. The rational in this release of the package made everything that was potentially interactive, as well as that that was merely ornamental or geometry based (borders, vbox and hbox glue structures), a window. In a basic interactive painting window the overhead would be over a hundred windows, when two could do the job better. Walking menus consumed over a hundred windows. The system performance was not good, to say the least. [please no Interviews flames]. Early versions of other toolkits also followed the same route of using lots of windows. I guess that this in line with the line of thinking that as machines become faster we can more freely use the resources of the machines. This is not my way of thinking, I would rather use a minimalist approach and take the speed advantage of new hardware rather than writting bigger programs to consume the increase in resources. With the R4 release I have the impression that window overhead is lessened to a great degree. I'm still partial to only using them when needed though. ->Bill ->-- -> Bill Janssen janssen.pa@xerox.com (415) 494-4763 -> Xerox Palo Alto Research Center -> 3333 Coyote Hill Road, Palo Alto, California 94304 -Jim -- + + Jim Becker jcb@sun.com :: Sun Microsystems, Inc.
marbru@auto-trol.UUCP (Martin Brunecky) (08/22/89)
Before entering the discussion wheather X Window System was or was NOT spec'ed out that way, some notes on Gadgets: Most people (so far) seem to concentrate on Gadgets used as (cheap?) substitute for X Window. In my opinion, this is only ONE, very special and very limited usage of the Xtoolkit OBJECT CLASS. For example, we are using gadgets (ObjectClass) for Text widget source and sink, for colormap object, for an extended GC, for rubberbanded-object and plan for more. Why ? Xtoolkit gives us an object-oriented environment in "C", with a basic set of methods, basic objects and tools. It has a little "twist", and sometimes you have to be carefull - but it works GREAT. So from that standpoint, I vote YES for Gadgets with all my hart. Now, the issue of the "rectangular object" - i.e. DECwindows/Motif Gadget. Both implementations use Gadgets for one and same reason: assuming STATIC user interface defintion (such as UIL), a fairly simple menu cascade requires LOTS of Widgets and X Windows ( hundreds and more ...). Even though at any given time there will be no more than ... 50 windows on the screen, STATIC approach requires that (sooner or later) all of the hundreds of windows (and widget instances) are created. To solve the problem, DECwindows elected to cure the symptom, not the disease. Instead looking into ways how to re-use menus (which might require something more intelligent than UIL), they elected to "spoil" the toolkit with gadgets. I say "spoil", since the way gadgets are used by DECwindows (and little better by Motif) is to DUPLICATE X(server) functionality. Rather than using Xserver, pointer/window interaction is handled by the manager widget. Even worse, to do the above right, the manager widgets must make assumptions about their children. And that's where I see the major problem. Once widgets make assumptions about other widgets, it becomes really difficult (if not impossible) to merge widgets from different sources, to add your own widgets to the existing toolkit, to modify existing classes. You are locked into a particular toolkit, no matter wheather a "propriatory" or an "open" one. So, in my belief, the "X windows system" HAS been designed to make window a "cheap" resource. In my belief even the implementation(s) did not FAIL. What FAILED is a "reasonable use" of the technology. Developers prefered simplistic, STATIC approach (buy more memory...), rather than more intelligent, dynamic user interface components. Gadgets have their advantages and disadvantages, and rather than glorifying or denying them, we better learn WHEN and HOW to use them.