Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!auto-trol!marbru
From: marbru@auto-trol.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: Re^4: Gadgets in Motif
Keywords: Xtoolkit, Objects, Gadget
Message-ID: <246@auto-trol.UUCP>
Date: 22 Aug 89 15:44:33 GMT
References: <322.8908161255@jupiter.cmi.no> <1443@riscy.dec.com> <122257@sun.Eng.Sun.COM> <2586@arisia.Xerox.COM> <122837@sun.Eng.Sun.COM>
Reply-To: marbru@auto-trol.UUCP (Martin Brunecky)
Followup-To: janssen.pa@xerox.com
Organization: Auto-trol Technology, Denver
Lines: 46

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.