dwj@THINK.COM (David Jacobs) (06/30/88)
I am new to xwindows and am seeking some basic information.
In particular, I would like to find out about existing Xwindow
toolkits that will help me build an application. This application
will run on a SUN using X11. I am using Lucid Common Lisp, but
I assume that I can also use toolkits written in C. Some of the
functions I want to perform are to:
- Put up a menu of options for the user to mouse on.
- Allow the user to position a window with the mouse.
- Display a binary image inside a window.
- Display an image of straight lines inside a window.
I would appreciate information about any toolkits that could make
this task easier, or pointers to more appropriate places to ask
this question. Thanks in advance for your help.
-- dwj@think.com.arpabzs@bu-cs.BU.EDU (Barry Shein) (07/01/88)
>I am new to xwindows and am seeking some basic information. >In particular, I would like to find out about existing Xwindow >toolkits that will help me build an application. This application >will run on a SUN using X11. I am using Lucid Common Lisp, but >I assume that I can also use toolkits written in C. Some of the >functions I want to perform are to: > - Put up a menu of options for the user to mouse on. Although other window systems have certainly made some use of "menus" it is antithetical to the X model (particularly in the sample server, which you didn't pay for anyhow), options are something which should be handled later, perhaps by a presentation manager built upon the soon to be released Toolkit (Consortium members are reviewing a document which might help clarify this common confusion.) > - Allow the user to position a window with the mouse. Positioning the window involves a clash of philosophy between the client, server and window manger's distinct roles, who should do the moving? Obviously a serious problem, suggestions welcome. > - Display a binary image inside a window. Binary images, although superficially desirable, cannot be efficiently updated and therefore have not been included in the distributed protocol model. Sorry. > - Display an image of straight lines inside a window. Lines (or, to be truly general, let me rephrase that as filled polygons of one dimension with arbitrary clipping) are part of an imaging model which is hoped to be supplied by vendors' packages, they were never intended to be accessible by ordinary users. However, a multiply constrained, composite widget could be easily created which *simulates* Lines, see the source. :-) :-) :-) -Barry Shein, Boston University
price@WSL.DEC.COM (07/02/88)
regarding Barry Shein's response to your query: I *do* hope you realize that his smiley faces applied to the entire response! Menus: The xtoolkit Intrinsics and associated widget sets will help you solve your problem. The Intrinsics provide support for "popup shells", which are a generalized mechanism for creating "detached" widgets such as menus within an application. Layered widget sets, such as the Xaw widget set and the HP widget set capitalize on this support to some degree. Digital's widget set will also provide support for a wide varieties of menus. Positioning a window with the mouse: "Window Manager" applications perform these services on behalf of users. User positioning of top level windows should never be built into applications themselves. Some window managers currently available include uwm, twm, awm, and now even the infamous rtl window manager :-). Positioning of subwindows is handled to some degree by widgets within toolkits. The Xtoolkit architecture describes the mechanisms and conventions for supporting "geometry management", ie, the position and size of widgets within an application. Display a binary image inside a window: Static images (Pixmaps) can be handled by some widget sets. The Xaw widget set does not currently support Pixmaps, but I suspect it will at the next release. I believe the HP widget set does now, and the Digital set will also. If you need a dynamic image, you can create an instance of the Core widget, or use "Window" widgets provided by other widget sets. Display an image of straight lines in a window. Use an instance of Core or a "Window" widget from a widget set. (I don't believe the Xaw widget set currently has a Window widget, though). Another alternative is to write a widget which handles display lists. References of interest to you are: Xlib Reference Manual (Gettys, et al). Xtoolkit Intrinsics - C Language X Interface (McCormack, et al) * Using the X Toolkit - or - How to Write a Widget (McCormack, et al). X Toolkit Widgets - C Language Interface (Swick, et al). * you might consider starting with this one. All can be found in the doc directory on the R2 release, I believe. -chuck
diamant@hpfclp.SDE.HP.COM (John Diamant) (07/03/88)
> Positioning a window with the mouse: > "Window Manager" applications perform these services on behalf of users. > User positioning of top level windows should never be built into applications > themselves. Some window managers currently available include uwm, twm, > awm, and now even the infamous rtl window manager :-). This is an interesting question, but I don't think it is quite as clear cut as it sounds. Currently, uwm (and probably awm, though I haven't tried it), at least, ignore the position if specified by the program, as opposed to the user. Actually, uwm will use the program specified hints on transient windows, which seems reasonable (since rubber banding is unreasonable for a dialog box and the application is probably in a better position to place the dialog box than the window manager). Typically, a dialog box is a separate top level shell (in the Xt Intrinsics, anyway), so I'm not sure if you meant your comments to apply to them as well. I can easily conceive of cases where the window manager could not possibly place a dialog box as well as an application could (because the application has knowledge of the contents of the dialog box). So, I agree with you, only if you didn't mean to include transient windows when you said top level windows (even though they are in the sense of the X window tree). There is yet another problem with this whole distinction. I admit I may have misunderstood the code when looking at it, but it appeared that the Xt Intrinsics will call a geometry specification user-specified if they come out of the resource database, and program specified only if not specified in the database. But, in fact, the geometry is program specified if it appears in app-defaults and user specified if it appears in .Xdefaults or any of the other user controlled access points to the database (xrdb, XENVIRONMENT). The user rarely will have control over the app-defaults file except to the extent that he may also be system administrator and muck with the standard files. Typically, programmers and systems integrators will change app-defaults files, but not users. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
mls@whutt.UUCP (SIEMON) (07/04/88)
In article <8807011738.AA08056@eros.dec.com>, price@WSL.DEC.COM writes: > regarding Barry Shein's response to your query: I *do* hope you realize > that his smiley faces applied to the entire response! And reading your "serious" suggestions, I find Barry's comments even more poignant than I did on first reading them. X is a plot to make emacs look simple. -- Michael L. Siemon contracted to AT&T Bell Laboratories ihnp4!mhuxu!mls standard disclaimer
price@WSL.DEC.COM (07/06/88)
>I can easily conceive of cases where the window manager could not possibly >place a dialog box as well as an application could (because the application >has knowledge of the contents of the dialog box). > >So, I agree with you, only if you didn't mean to include transient windows >when you said top level windows (even though they are in the sense of the >X window tree). Right, I guess I should have been more specific. When I stated that window management should never be built into applications, I meant that the application programmer should adhere to the IC3M conventions and not take things into their own hands, ignoring the (or assuming a particular) window manager. I believe that window managers such as uwm are broken if they are not compliant with the current IC3M draft spec (but, since the IC3M is currently a draft spec, I am not surprised or disappointed [yet :-) ]). Regarding app-defaults vs. user preference defaults: An interesting point, but the distinction is probably not important in practice. I believe that most window managers should attempt to grant initial geometry specs whether user preference or programmer specified, to the best of their ability. If I as a user have placed a geometry spec in a defaults file, I don't want the window manager to ignore it and ask me where to place the window. Similarly, if a program is creating a transient window, the window manager should attempt to honor window positioning specified by the program, and not force a rubberbanding operation on the user. -chuck digital equipment corporation % cat .std_disclaimer >/dev/null