jcb@frisbee.Sun.COM (Jim Becker) (08/18/89)
graham@fuel.dec.com (kris graham) writes: ->>Gadgets versus Widgets in Motif ->>------------------------------- ->>Motif has introduced the user interface object "Gadget" as an alternative to ->>"windowless" Widgets ( arrow, button, label, separator etc). ->>Is the advantage converting a Widget into a functionally equilavalent Gadget ->>primarily speed, memory savings or both? Is this a Motif-only toolkit extension? ->Gadgets have been in the DECwindows toolkit long before Motif was created. I ->(am not sure) believe the MIT folks have it also. Gadgets have been used in form and function in the Intuition interface system for the Amiga since 1985. The names the same and the implementation technique is a lot simpler to understand and utilize. ->The implementors of gadgets say that there are tremendous performance improvements ->both in execution speed and data space.....for *both* application and server processes.... ->and reduces the incidence of lost functionality associated with widgets. It has always been very difficult for me to understand the reasons behind making each interactive element of the interface a server level resource, when it should simply be regions of the screen defining interactive elements. The drain of the performance of the Server has been clearly shown with early widget programs. How has it happened that so many intelligent people have assumed that windows are a cheap resource that can be used freely? ->-- ->Christopher Graham ->Digital Equipment Corp ->Ultrix Resource Center ->New York City (usual disclaimers go in here) -- +---------------------------------------------------------+ | Jim Becker jcb@sun.com :: Sun Microsystems, Inc. |
rws@EXPO.LCS.MIT.EDU (08/18/89)
It has always been very difficult for me to understand the reasons
behind making each interactive element of the interface a server level
resource, when it should simply be regions of the screen defining
interactive elements.
The argument is hardly as trivial as you make it sound. There are lots of
potential reasons on both sides of this issue. I'm sure the Amiga is a nice
system, but it isn't X, and the same arguments don't necessarily apply. In
the X world, there are issues like having elements with different Visuals,
different depths, different colormaps. There are issues like establishing
non-conflicing passive grabs. There are issues like avoiding duplicating
lots of complicated server machinery on the client side.
The drain of the performance of the Server has been clearly shown with
early widget programs.
Yes, although it's mostly been shown on early server implementations. The
performance drain has been demonstrated most clearly, I think, with menus
that have each item as a separate window. I'm happy to agree that's a bad
design, but I wouldn't want to blindly extrapolate from that to the conclusion
that no windows is good windows. I'm not saying gadgets are a bad idea, but
they bring on their own set of problems.
How has it happened that so many intelligent
people have assumed that windows are a cheap resource that can be used
freely?
How has it happened that so many intelligent people have assumed that windows
can't be made a whole lot cheaper? R4, here we come ...ben@hpcvlx.HP.COM (Benjamin Ellsworth) (08/18/89)
>>... The latter may take some careful enhancements to the Xt >>Intrinsics. > > Or, you can wait for the R4 intrinsics, which will fully support > gadgets, compatibly with Motif, XUI, the Athena widgets, or any other > R3-based widget set. > > -paul asente Yeah, but... There are a specific and fairly common set of design decisions/compromises that are embodied in the three gadget implementations that you mention. It is that design which is supported in a general way by R4. I was alluding to the potential for a conflicting set of design requirements that might require changes to the intrinsics which were different than the R4 set of changes. If you are interested in an "industry standard" or quick approach, use R4. If you are interested in exploring the extents and limits of the "Xt" technology, do whatever looks promising -- upto and including poking around in the intrinsics. ---- Ben
janssen@holmes (Bill Janssen) (08/19/89)
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? Bill -- Bill Janssen janssen.pa@xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
jg@max.crl.dec.com (Jim Gettys) (08/29/89)
> 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? If you look at X10, you will find that windows used a small fraction of the amount of memory of windows in the current (R3) sample server implementation. The X11 sample server implementation was originally done under tremendous time pressure (I know R1 almost killed me and those people working on it with me). Getting the spec implemented was more important than getting it small and fast (or at least that is what everyone was telling us). I think you'll see R4 server memory usage dramatically better than R3, and very much higher windowing performance, given the work that Bob, Kieth Packard, and Joel McCormack have done. But I'll let Bob comment on how much better when the time is appropriate; I know I am extremely happy with what I know about it :-). So yes, windows should be regarded as "cheap". They are not "free" however. But as I've stayed away from toolkit wars, I'll stay away from commenting on whether gadgets are a good idea or not. - Jim
marbru@auto-trol.UUCP (Martin Brunecky) (08/30/89)
> But as I've > stayed away from toolkit wars, I'll stay away from commenting on whether > gadgets are a good idea or not. Why scared ? The issue of gadget is like everything else. No matter if they are good or bad, they may be MISUSED. I myself like the concept of "ObjectClass", using "objects" for things like WsText widget source/sink, colormap gadget, GC gadget etc. YES, there are holes in R3 Xt support, but still - it gives us object oriented environment in "C", with a LOTS of good features. Now, there are many flavors of Gadgets. One of them pretty much reminds me a doctor curing SYMPTOMS, not the DISEASE. DISEASE, in this particular case, is a STATIC creation of ALL user interface objects ( menu cascade may need hundreds of objects ). However, in a real life, only a fraction of those objects will be active (mapped, used) at any given time - but all of them will eat resources (yyap, memory is virtual). Now, symptomatic treatment will try to make ALL those objects "smaller", "cheaper", while the REAL cure is DYNAMICS. Build the user interface which re-uses objects (such as menus, buttons). Your menu cascade will require 30 buttons instead of 600 (and you will learn how to use SetValues). Naturally, you will need something more reasonable than UIL ( Unfriendly Idiotic Language) - but that's another subject. Gadgets that require a manager widget re-implementing lots of the server functionality (such as tracking pointer to generate gadget enter/leave events, generating expose events) not only create overhead (lots of protocol traffic, potential for receive buffers overflow when client is busy etc.etc.etc.) They have another problem. To do it's things "right", the manager widget makes ASSUMPTIONS about children. He "knows" what children wil be, how they behave, how to highlight them etc. And I consider that fundamentally WRONG. WRONG, because it makes it really difficult to add/augment/modify/enhance existing widget set - and how often are we happy with what we get. ############################################################################### Martin Brunecky, Auto-trol Technology Corporation, 12500 North Washington Street, Denver, CO-80241-2404 (303) 252-2499 ncar!ico!auto-trol!marbru ###############################################################################