john@acorn.co.uk (John Bowler) (02/01/89)
It is very clear from the design of the protocol and from examples such as Xt that windows are intended to be used not just for display and input but also for window layout and general programming convenience, but what limits should be placed on such use of windows? For example, if I am writing a bitmap image manipulation program I presumably should not allocate a window for every pixel - but if I am writing a directory browser should I avoid allocating a window for every file? Bear in mind that I may make the mistake of looking at the release 2 doc/Xlib/Xsrc directory... 937 files = 937 windows, about 300 bytes/window minimum in the server - I doubt an Acer Xebra would allow that. Of course this is under user control - the application writer has no way of limiting the number of files in a directory, or the number of pixels in an image, or the number of lines in a text file. So I would have thought that using windows in a way which means that the number in existence at any one time is limited only by the actions of the user is unreasonable. Of course the user is free to start up as many applications as he/she wants... for i in doc/Xlib/Xsrc/*; do xedit $i &; done ...but the windows created by this and the effects on the system are obvious - whereas inserting lines into a file, or innocently opening a large directory seems quite benign. Is this contrary to ``the X philosophy''? John Bowler jbowler@acorn.co.uk
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (02/02/89)
Is this contrary to ``the X philosophy''? The X philosophy is "mechanism, not policy", which translates to "here's some rope, bet you'll hang yourself" :-) How many windows (or more generally how many resources) you consume will affect the number of servers you can run against. An X terminal with .5Mb of memory just won't be able to handle very much, period. Some of the early product application builders were seen creating hierarchies of 3000 windows, which is not hard to do with an Xt-based toolkit if you aren't careful. There are definite performance problems (and memory limitations) with huge numbers of windows. One reaction to this in the Xt world has been the design (from DEC) of "gadgets" (windowless widgets). Formal inclusion of this mechanism into Xt is now under review in the X Consortium. The answer to your question is rather difficult, there's no single answer. You have to understand what application mix you think your "customer" will be using, and how many resources those applications will consume. You also have to understand what range of servers you care about.
ben%hpcvlx@HPLABS.HP.COM (Benjamin Ellsworth) (02/04/89)
> ... One reaction to this in the Xt world has been the design > (from DEC) of "gadgets" (windowless widgets). ... ^^^^^^^^^ --Ahem-- We have done gadgets also. They (HP's design, not DEC's) will be part of the OSF User Environment Component library (Motif) that we are currently building . They (any gadget) are a trememdous boon to large applications. ----------------------------------------------------------------------- Benjamin Ellsworth | ben%hp-pcd@hp-sde.sde.hp.com | INTERNET Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP 1000 N.E. Circle | (USA) (503) 750-4980 | FAX Corvallis, OR 97330 | (USA) (503) 757-2000 | VOICE -----------------------------------------------------------------------
janssen@titan.sw.mcc.com (Bill Janssen) (02/05/89)
In article <8902032010.AA08214@hpcvlx.HP.COM>, ben%hpcvlx (Benjamin Ellsworth) writes: > > >> ... One reaction to this in the Xt world has been the design >> (from DEC) of "gadgets" (windowless widgets). ... > ^^^^^^^^^ > >--Ahem-- We have done gadgets also. They (HP's design, not DEC's) ^^ >will be part of the OSF User Environment Component library (Motif) that -- AHURM!! (hack! coff!) -- Guess what we call the little nifties in our DELI CLOS Application Support Environment UI Toolkit? But they have a mixed design -- some are windows, others aren't. Bill
ben@hpcvlx.HP.COM (Benjamin Ellsworth) (02/07/89)
> Yes, surely. I was attempting to refer to the more generic aspects > of the gadget design (which DEC did first)... "First" is an interesting concept, but of little or no meaning in our industry when the difference between first and second is only a few months. If you wish to assert that DEC was first, I am willing to plead "no contest" in order to avoid this debate turning into a round of one-upmanship (can you say "piss fight?"). > ... not the particular aspects of whether gadgets have full or partial > resources, or whether or not all composites support gadgets. I designed and wrote a good deal of the HP gadgets (although I must admit another engineer was heading that project), I have the DEC code in front of me. The differences in design and implementation between HP and DEC are a good deal more involved than you allude. However, in a minimalist sense, a "windowless widget" is a "windowless widget" ("parts is parts?" ;-). > Credit where credit is due (which is not to say that HP doesn't > deserve some). Agreed. I in no way wish to depreciate the gadgets that DEC did. They address the need in an effective manner. An interestig debate (although impossible in a public forum due to the confidentiality of the information) could ensue over which implementation is "better." I'm sure that OSF had such a debate, and right or wrong, their decision was in favor of the HP design. I mentioned OSF not to smear of DEC, but rather to establish some credibility of our design (you, and your messages, provide DEC's credibility). To restate, DEC has working gadgets, DEC may even have had them a few months ahead of HP. I feel to dispute none of this. It is the idea that DEC has pre-eminence in gadget technology that I take issue with. ----- Ben ----------------------------------------------------------------------- All relevant disclaimers apply. -----------------------------------------------------------------------
ben@hpcvlx.HP.COM (Benjamin Ellsworth) (02/07/89)
> -- AHURM!! (hack! coff!) -- Guess what we call the little nifties > in our DELI CLOS Application Support Environment UI Toolkit? You call them "little nifties." No? In the Bible there's a story about how the people tried to build a tower to reach to "heaven." God got ticked-off by their pride and confounded their language so that the couldn't communicate with each other. Sometimes when I see all of the confusion surrounding names and definitions, I wonder how I missed the groundbreaking for "Babble II." Seriously, I don't think that either Bob's or my comments were directed at your little-nifties --er, um, gadgets. I'm glad to hear that others are having success with mixed (with and without windows) strategies. Are you in a position to tell us more about what you folks did? --- Ben
ric@rioja.ifs.umich.edu (Richard Campbell) (02/08/89)
>> ... One reaction to this in the Xt world has been the design >> (from DEC) of "gadgets" (windowless widgets). ... > ^^^^^^^^^ > >--Ahem-- We [[HP]] have done gadgets also. They (HP's design,not DEC's) >will be part of the OSF User Environment Component library (Motif) that >we are currently building . They (any gadget) are a trememdous boon to >large applications. I thought that OSF had accepted DEC's Toolkit (presumably equivalent to the MIT Xt Intrinsics) and DEC's User Interface Language? If they have done so, doesn't this mean that OSF already has DEC's "gadgets"? Aren't "gadgets" at a lower architectural level than the look&feel of the User Environment Component? If OSF is using "gadgets" in their toolkit, doesn't that give an unfair advantage to either DEC or HP - they've been working with *dgets for months apparently, the rest of us will have to wait until either MIT X Consortium or OSF formally releases the little critters. By the way, DEC salespeople have stated that DEC *will* switch from DECwindows to Motif. When? And when will Apollo switch from Open Dialogue or IBM from NextStep to Motif??
erf@apollo.COM (Kate Erf) (02/10/89)
> By the way, DEC salespeople have stated that DEC *will* switch > from DECwindows to Motif. When? And when will Apollo switch from > Open Dialogue or IBM from NextStep to Motif?? Open Dialogue is not inconsistent with Motif. Open Dialogue has qualified as an OSF catalogue technology. One of the requirements for that program is compatibility with the core OSF technology. Apollo is *not* abandoning Open Dialogue or switching from it to anything. Quite to the contrary, Apollo is committed to integrating Open Dialogue with the core technology. Kate Erf erf@apollo.com