johns@hpwade.hp.com (John Silva) (06/26/90)
In trying to use Xlib with C++ there are cases where there are inconsistent definitions of the parameters to the Xlib function calls. This causes grief in C++ (or with ANSI C) parameter type checking !! Here are a couple of examples : in XChangeActivePointerGrab and XGrabPointer() event_mask is defined as unsigned int, whereas in XChangeGC() and XMaskEvent() event_mask is defined as unsigned long !! also in the Xlib XWindowAttributes structure the all_event_masks, your_event_mask, and the do_not_propagate_mask are defined as long, again inconsistent with the four function calls above. This parameter represents the same type of data ... why is it typed inconsistently ?? (I imagine that on most 68K machines unsigned long and unsigned int are the same, but this may not be so on Intel machines.) There needs to be a cleanup of the parameters (and data structures) in Xlib to make sure they are consistent and work correctly with ANSI-C and C++. Thanks, John
mike@bach.cs.byu.EDU (Mike Burbidge) (06/27/90)
How about some kind of graphical transformation model, for doing rotations, scaling, and translations? Mike Burbidge mike@bach.cs.byu.edu
goodman@sequent.UUCP (George O. Goodman) (06/28/90)
Some attention to making the c l i e n t side memory utilization and performance of xlib/Xt would be nice. -- george g.
graeme@labtam.oz (Graeme Gill) (06/28/90)
In article <2493@acorn.co.uk>, john@acorn.co.uk (John Bowler) writes: > > In article <4865@labtam.oz> graeme@labtam.oz (Graeme Gill) writes: > ><stuff deleted> While I understand there > >would be restrictions in poly-copy operations, in that the copies would > >have to be independent (ie. the source for one must not overlap the > >destination of a previous copy), > > Why? Handling overlapping source regions is easy. The sample server > already has a body of code which does this (the region code). It is > easy to implement a general purpose ``move region'' interface (and > this is quite useful in general). > My comment about non-overlapping copies was really made with the general case in mind - ie. if each copy allowed different source/destination drawables for each copy. If however a poly-copy operated in a similar manner to other poly operations, and assumed the same drawables within one operation (the only practical assumption), then I agree that there would not be any problem with overlapping copies as long as the order was preserved. > > some applications make extensive use of > >copies, and the ultimate performance is currently limited by the number > >X operations/sec the server and communication medium are capable of. > > I don't understand the point. Poly{CopyArea,CopyPlane} is easy to > simulate at present:- > > < stuff about using clip region > Two points: A poly-copy would be different from setting a clip region in that the displacement of the copy could be different for each rectangle. ie a client could then load an image set (ie "font" or colour images) as a single pixmap, and in one operation copy many different sub images from the pixmap to different position on the screen. I think this capability would make for a more symmetric range of graphics primitives. The other thing is that poly operations transmit information and work faster than a series of separate operations. ie. our X terminal will do about 11000 separate invert 10x10 rectangles/sec, while as a poly-fill invert rectangle it can do 18700 10x10 rectangles/sec. The difference is that done separately there may be separate packets sent for each invert, a validate is done on the gc and drawables each time, and other setup code is executed for each operation. For a poly-operation all this is done once, and the server then just has to sit in a tight loop, whipping rectangles off the poly list and executing the operation. Doing them one at a time also suffers from the problem that the performance varies a great deal depending on how much opportunity xlib gets to package separate operations up into poly operations (if they are available !), and also the ability of the networking code to combine X buffers into larger buffers for transmission. The above mentioned 11000 figure was under favorable condition - under other conditions I have seen this particular test drop as low as 3500 rectangles/sec. > The ``some applications'' which you > mention wouldn't happen to be FrameMaker would they? FrameMaker has a > specific problem - it has large numbers of fonts which it really wishes Yes, one of the applications I had in mind was FrameMaker, although I agree that it is not doing things properly. I don't claim to understand enough about fonts to know why it does things the way it does instead of using the X font capability. I am told there is an assumption in the X11 server that fonts are stored locally (ie. the server is running on a workstation), and that this creates problems downloading fonts from different hosts. From a server code point of view, it would be nice to have the option of caching fonts in expanded form (ie. expanded to the depth of the screen drawable), and/or having separate external and internal packing and bit/byte order so that fonts could be downloaded from any machine a client might run on. > my session produced 359 NoExposure events corresponding to 145 CopyArea and > 214 CopyPlane requests (plus over 1000 PutImage requests from, I think, > downloading the fonts). > > John Bowler (jbowler@acorn.co.uk) Another major advantage of supporting a poly-copy primitive would be the reduction in NoExposure events that have to be transmitted by the server and thrown away by the client. A poly-copy consisting of perhaps hundreds of copies would produce only one event - a NoExpose event or an expose region. From my look at how FrameMaker works, it seems to cache some things in the server as bitmaps, but draws most of its text line by line as loadimage requests. This is rather slow over a limited bandwidth medium like ethernet (400 Kbytes/sec) compared to copying from locally stored bitmaps (7 Mbytes/sec) or pixmaps (14 Mbytes/sec). Graeme Gill graeme@labtam.oz.au Labtam I.S.D. Pty. Ltd. Telephone +61 3 587 1444 43 Malcolm Road, Fax +61 3 580 5581 Braeside, 3195. Victoria, Australia.
drapeau@sioux.Stanford.EDU (George Drapeau) (06/28/90)
In article <9006222202.AA17654@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:
Send your thoughts directly to me, or post them on the net if you prefer.
I'd love to see somebody contribute a Display PostScript extension
(perhaps DEC or Adobe would be so kind).
If not that, at least an Adobe Type Manager extension would be nice.
It seems that Adobe is already writing one for every other window
system. It seems to me that Adobe would win big-time by opening up a
huge new market for its font packages -- it could give away the ATM
code, and sell those beautiful fonts.
George
--
______________________________________________________________________________
George D. Drapeau Internet: drapeau@jessica.stanford.edu
Academic Information Resources
Stanford Universityramani@charity.Stanford.EDU (Ramani Pichumani) (06/28/90)
> > I'd love to see somebody contribute a Display PostScript extension > (perhaps DEC or Adobe would be so kind). > ... > > George D. Drapeau > Academic Information Resources > Stanford University The usefulness of a real PostScript Interpreter cannot be overstated. I would rank this as one of the most important possible features for X11R5. Needless to say, PostScript is not a trivial language to implement properly. Because PostScript is more than just a language (it is also a rich set of fonts and font technologies), it is perhaps the most underestimated language to implement. Anyone who has used NeWS, GhostScript, xps, etc, would attest to this fact. I would be ecstatic if X could incorporate Display PostScript into it's server but I also realize that Adode is earning its income for good reason. Great suggestion nonetheless George! Ramani Pichumani Tel: (415) 723-2902 or 723-2437 Department of Computer Science Fax: (415) 725-7411 Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani
vladimir@prosper (Vladimir G. Ivanovic) (06/28/90)
In article <1990Jun28.081549.22442@Neon.Stanford.EDU>, ramani@charity (Ramani Pichumani) writes: > >The usefulness of a real PostScript Interpreter cannot be overstated. >I would rank this as one of the most important possible features for >X11R5. > It already here (and has been for a while): Sun's X11/NeWS server. A new release, OpenWindows Version 2, is imminent. See your Sun salesperson for details or send me mail. -- Vladimir -- Vladimir G. Ivanovic vladimir@sun.com M/S 12-33 or Sun Microsystems, Inc. vivanovic@sun.com
dwl@udev.cdc.com (Daren W Latham) (06/29/90)
In article <138022@sun.Eng.Sun.COM>, vladimir@prosper (Vladimir G. Ivanovic) writes: > In article <1990Jun28.081549.22442@Neon.Stanford.EDU>, ramani@charity (Ramani Pichumani) writes: > > > > >The usefulness of a real PostScript Interpreter cannot be overstated. > >I would rank this as one of the most important possible features for > >X11R5. > > > > It already here (and has been for a while): Sun's X11/NeWS server. A new > release, OpenWindows Version 2, is imminent. See your Sun salesperson for > details or send me mail. > And these will be available on platforms other than Sun?? Perhaps our environment is different from most, but "we" don't have a Sun on every desk... The above mentioned capability would be nice to have in R5. -- Daren -- Daren W. Latham | dwl@mercury.udev.cdc.com Control Data Corporation | {uunet}!shamash!punjab!mercury!dwl Arden Hills, MN 55126 | (612)482-3457 --
rick@hanauma.stanford.edu (Richard Ottolini) (06/29/90)
In article <23067@shamash.cdc.com- dwl@udev.cdc.com (Daren W Latham) writes: -In article <138022@sun.Eng.Sun.COM>, vladimir@prosper (Vladimir G. -Ivanovic) writes: -> In article <1990Jun28.081549.22442@Neon.Stanford.EDU>, ramani@charity -(Ramani Pichumani) writes: -> -> > -> >The usefulness of a real PostScript Interpreter cannot be overstated. -> >I would rank this as one of the most important possible features for -> >X11R5. -> > -> -> It already here (and has been for a while): Sun's X11/NeWS server. A new -> release, OpenWindows Version 2, is imminent. See your Sun salesperson for -> details or send me mail. -> - - And these will be available on platforms other than Sun?? Perhaps our - environment is different from most, but "we" don't have a Sun on every - desk... The above mentioned capability would be nice to have in R5. Sun has been offering the source code to NeWS since its creation four years ago. Silicon Graphics and Grasshopper (IBM-PC ??) have ported it. X11/NeWS has many features superior to XWindows and could have been the industry standard IF (in my opinion) Sun had (1) not charged a lot of money for the source; (2) made updates faster (NeWS 2 is shipping about 3 years after NeWS 1); (3) coordinated their interative PostScript with Adobe and the DPS people.
dsr@luke.mitre.org (Douglas S. Rand) (06/29/90)
!!!! flame warning !!!! I don't know about other people but I'm tired of the adverts for X11/NeWS from SUN. This is not a general solution (just one vendor) and doesn't answer the needs of many people (do you still need a minimum of 8 Mb to get any kind of performance?). For that matter one can tout Display Postscript as an answer for rendering Postscript/scalable outline fonts. Just as valid an advertisement and still doesn't answer the problem. !!!! flame off !!!! IMHO scalable graphics and text don't belong in X. There are many rendering schemes which can run on top of X to provide more then adequate solutions. To name a few: GKS (from U Illinois (xgks) or U Lowell (gksul) PHIGS (as evolving PEX) Display Postscript (from Adobe) Interviews (Mark Linton at Stanford) etc. Douglas S. Rand Internet: <dsrand@mitre.org> Snail: MITRE, Burlington Road, Bedford, MA Disclaimer: MITRE might agree with me - then again...
janssen@parc.xerox.com (Bill Janssen) (06/29/90)
In article <138022@sun.Eng.Sun.COM> vladimir@prosper (Vladimir G. Ivanovic) writes:
It already here (and has been for a while): Sun's X11/NeWS server.
Not really a responsive answer. The two sides are still fairly separate, and
I have to turn to NeWS to do PS imaging. NeWS also provides other non-imaging
facilities, which, although interesting in their own right, could be usefully
left out in an "MIT Standard" PostScript imaging extension.
Bill
--
Bill Janssen janssen.pa@xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304pnakada@oracle.com (Paul Nakada) (06/29/90)
In article <1990Jun28.081549.22442@Neon.Stanford.EDU> ramani@charity.Stanford.EDU (Ramani Pichumani) writes: > > I'd love to see somebody contribute a Display PostScript extension > (perhaps DEC or Adobe would be so kind). > ... > > George D. Drapeau > Academic Information Resources > Stanford University The usefulness of a real PostScript Interpreter cannot be overstated. I would rank this as one of the most important possible features for X11R5. Needless to say, PostScript is not a trivial language to implement properly. Because PostScript is more than just a language (it is also a rich set of fonts and font technologies), it is perhaps the most underestimated language to implement. Anyone who has used NeWS, GhostScript, xps, etc, would attest to this fact. I would be ecstatic if X could incorporate Display PostScript into it's server but I also realize that Adode is earning its income for good reason. Great suggestion nonetheless George! The reason for incorporating something like Display PostScript into X is to remove any dependence on the display resolution. X tries to allow for device independence by providng the display resolution to the client, letting the client render device independently. This approach works well, except for rendered text, which is not easily scaled. I see Adobe Type Manager as a good compromise. This would eliminate a huge portion of a Full PostScript interpreter, while still giving device independence. Adobe may even consider donating ATM, giving them a huge new market for outline font sales. -Paul Nakada -- Paul Nakada | Oracle Corporation | pnakada@oracle.com
jimf@SABER.COM (06/29/90)
|It already here (and has been for a while): Sun's X11/NeWS server. A new |release, OpenWindows Version 2, is imminent. See your Sun salesperson for |details or send me mail. When it runs on my HP, DEC, IBM, DG, and i386, *then* it's available. jim frost saber software jimf@saber.com
pusateri@macbeth.cs.duke.edu (Thomas J. Pusateri) (06/29/90)
Okay, since you ask, here's my 2 cents worth. I like the athena widget set because it is "middle of the road". I hate these Open Look vs. Motif wars and the constant bashing. But I think the athena set could use some improvements in the area of form layout. For instance, it would be nice to have the right side of all of your widgets line up. In addition, a general purpose graphing widget would be wonderful. I know you can always draw in a pixmap now but I'm talking about a widget that takes care of axis', scaling, etc. It would also be nice if you could select more than one item in the List Widget without the highlighting of the previously selected items disappearing. And it would be wonderful to be able to have more than one font in a text widget. (Change fonts on the fly.) Like I said, I like the Athena Set for its simplicity and I don't have to side with any particular vendor. Tom Pusateri pusateri@macbeth.cs.duke.edu
jordan@morgan.COM (Jordan Hayes) (06/29/90)
Joe Hodedo <zealot@big-company.com> writes: > The usefulness of %s cannot be overstated. I would rank this > as one of the most important possible features for X11R5. It already here (and has been for a while): %s's server. A new release, %s version %d, is imminent. See your %s salesperson for details or send me mail. I think we've had just about enough of this exchange: Q: "What would you like in R5?" A: "I'd like %s! It would be great!" Idiot: "You can have that in %s's proprietary binary-only release!" Q-to-Idiot: "What makes you think %s's proprietary binary-only server could be classified as R5?" Idiot: "..." /jordan
hoyle@HPLSLH.HPL.HP.COM (Steve Hoyle) (06/30/90)
I would like to see the server redesigned internally so that the server procs (the procedures which directly service protocol requests such as procCreateWindow and ProcCopyArea) are re-entrant and can be exposed as a public library. With support for dynamic linking Xlib could be implemented to decide at runtime to either work as it does now over a stream connection (to service a remote client), or in terms of new code based directly on the server proc library (to service a local client). For X servers running on workstations this architecture could be used to improve the interactive performance of remote clients as well as local clients. Toolkit servers running on the X server machine, for example, could use the proc server path of Xlib to make widget/server conversations more efficient. Ideally a server/Xlib shared queue mechanism for dispatching events would be part of the new proc library. These suggestions are essentially a step beyond multi-threading in the server. It seems to me, however, that in either case the most difficult part would be to satisfy (with efficiency) all of the re-entrancy requirements. If multi-threading in the server is to be attempted for R5, would it be much more difficult to support a public server proc library? Steve Hoyle Hewlett-Packard Laboratories hoyle@hplabs.hp.com
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (06/30/90)
>>> I'd love to see somebody contribute a Display PostScript extension >>> (perhaps DEC or Adobe would be so kind). >> The usefulness of a real PostScript Interpreter cannot be >> overstated. I would rank this as one of the most important possible >> features for X11R5. Please, Consortium...if you do decide to include this, make it configurable out. I have no use for such a thing and have much better uses for the memory it would eat up. (Making it an extension, like the SHAPE extension in R4, would be a very sane way to go.) > The reason for incorporating something like Display PostScript into X > is to remove any dependence on the display resolution. And it would do that tolerably well. But I argue that this is not something you want to do. Not until we have displays whose pixels are too small to see. (Current displays don't begin to approach this; even laser printers aren't that good yet.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
bjaspan@athena.mit.edu (Barr3y Jaspan) (06/30/90)
The general-layout support in the Athena widget is very lacking. There are
two things I'd like to see:
(1) The current form widget modified so that it does name -> widget binding on
it's children's resources when XtRealizeWidget is called. Currently, if
i create
widget FOO and then widget BAR, I cannot place BAR to the left or above FOO
because if I reference BAR in FOO's resources the form widget chokes (since BAR
doesn't exist yet). An important part of a form widget is to allow the user to
*completely* redesign the layout; presently, the layout is constrained
by the order the widgets are created in the C source code.
(2) A general-layout widget based on the "boxes and glue" concept of
TeX, much like the InterViews form widget. There would have to be a way
to specify (a) the relative positions of all the widgets and (b) the
glue between them completely in resources. Glue would not be difficult;
just use TeX's syntax (<natural size>+<strechability>-<shrinkability>
where the last two are optional and can be special strings for various
levels of infinity). The positioning stuff could probably be done as in
the current form, with (of course) the modification of binding names to
widgets at realize time. {Going back and rereading this paragraph, I
realize that the "boxes" part was completely left out. That's okay, you
wouldn't want to use my design anyway. :-)}
There are lots of other details that a general-layout widget must be able to
support. Will there be a "This Is Our General Design For New Stuff In R5"
document availabe to consortium members?
Barr3y Jaspan
Student Information Processing Board (SIPB)ramani@modesty.Stanford.EDU (Ramani Pichumani) (07/01/90)
When trying to come up with new ideas, it is generally a good practice to broaden one's horizons a bit and not be too judgemental. Criticism during the conceptual phase inhibits the creation and free exchange of new ideas. People should be encouraged to submit as any many ideas as they can without fear of being publicly criticized for coming up with "bad ideas" that are unworkable, undesirable or inefficient. In short, no idea is a bad idea. Consider the fact that ideas such as the UNIX operating system and personal computers, just to mention a few, were initially rejected by experts at AT&T, HP, IBM, DEC, Xerox, et. al., all of whom supposedly knew better. The designers of X are highly competent people who are aware of the tradeoffs involved in coming up with an efficient, workable system. They already know enough reasons why they *shouldn't* implement something. It is useful to them and others to know why something *should* be implemented. Ramani "For, dear me, why abandon a belief merely because it ceases to be true? Cling to it long enough, and not a doubt, it will turn true again, for so it goes." - Robert Frost -- Ramani Pichumani Tel: (415) 723-2902 or 723-2437 Department of Computer Science Fax: (415) 725-7411 Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani
crouch@axion.bt.co.uk (Chris Rouch) (07/02/90)
In <9006222202.AA17654@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: |> I'm interested in "big" things, not adding another frobnotz resource |> to xterm. Examples of big things that were in R4: ICCCM, XLFD, XDMCP, |> Compound Text, SHAPE extension, lotsa bitmap fonts, server performance. I don't think these are especially 'big', but they'd be very useful all the same: 1) spell checking ability in the text widget. 2) patchlevel.h somewhere in the source tree. Chris ----------------------------------------------------------------------------- Chris Rouch crouch@axion.bt.co.uk RT3141, BTRL, Martlesham Heath, Ipswich, England. +44 473 646093 Pick a card. Any card. WRONG.
mayer.WBST128@XEROX.COM (07/03/90)
Here is my list:
(1) A font server protocol that can describe arbitrary scaling and
rotation of fonts. Even an implementation based on bitmap scaling would
be acceptable.
(2) I would like to be able to access font metrics in sub-pixel units
(1/100 of a point? Whatever AFM's use?) . Perhaps this could be folded
in with the font server. I would like to see library support for
writing text with sub-pixel metrics.
(3) Support for properties on different visuals. My group has a number
of two headed systems and the current way of doing things is not nice.
(4) Convenient support for specifying distances in standard dimensional
units rather than in pixels. The place where this is most critically
needed is in parsing resources. The decision to have the protocol deal
with pixels is defensible, but the lack of convenient library support
for inches/cm/points/ems/etc. has led to a really bad situation. One
possibility would be to extend the current converters to accept
dimensions... this would allow current applications to benefit from
device independent size specifications.
(5) A standard extension for imaging with Redbook + color PostScript.
This is distinct from NeWS or Display Postscript support. The intent
would be to support least common denometer (printer) PostScript in an X
window. Personally, I see no need to supply a PostScript implementation
with this.
(6) I would like to see an extension that supported translating the
source of a graphics operation through a lookup table (software color
map?). The software color map would allow 8->24 bit data conversion
(very useful with XPutImage, common for gray-scal e images, and
currently very inefficient), and would also support nifty 8->8 bit image
transforms (in conjunction with XCopyArea).
(7) I would like to see support for anti-aliased text and graphics on
color and gray-scale devices.
Note:
Perhaps (1), (2), and (4) could be combined into a device independent
imaging library that supported both an X11 and PostScript back end. I
think a library of that sort would be extremely useful, particarly in
conjunction with (5).
--- Jim Mayer
Xerox Webster Research Center
Phone: (716) 422-9407 FAX: x2126 800 Phillips Road, 0128-29E
Internet: mayer.wbst128@xerox.com Webster, New York 14580jacobi.pa@XEROX.COM (07/03/90)
Here my whish list for today. I have purposefully limited myself to small changes not modifying the flavor of X. The ordering is random; for this minute I would consider 6) the most important. Of course I would consider something like Display Postscript very nice, but my list concentrates on small and less extension related features. 1) All (more) events need a timestamp. I leave it open which time is reported. The missing timestamps in focusIn, focusOut hurt me specially. While it is particularly hard to fit more data into keymapNotify events, this is one of the events where I would consider a timestamp useful because I would like to lazy-evaluate keyboard mappings. 2) A time-out event. After an user action (like button or key) the server will send a timeout event every 50 milliseconds for two seconds or until an other event is sent which constitutes a new user action (to any window of the connection). Don't take my example 50 milliseconds and two seconds literally. I would use this feature to time-out absence of double click using server time instead of client time. 3) A convention is needed: When using different color maps and the displayed color maps get changed by the server the color of window headers, borders, and, window manager menus get unreadable. As a client creating my own color map is should be possible to keep some few entries in the clients own colormap displaying standard colors, to avoid that effect (Of course it is possible, but which are the ones?). 4) The resources naming hierarchy should be allowed do differ from widget nesting hierarchy. The resource naming should contain some screen or visual dependent part. (Going slightly wild: Give up the Class-Instance paradigm for resource names; a widget implementor should specify a list of names which could be used for matching resources. This list would frequently consist of a class, instance relating names pairs, but occasionally it would be longer, frequently shorter). 5) In PutImage request, allow non zero left-pad for ZPixmap. 6) A modified AddToSaveSet request. Meaning: If the owner itself of a window adds it to the modified-save-set it is protected in the following sense: The window is protected from destruction if the parent of the window is destroyed or the parent windows connection is closed, as long as the parent window did belonged to a different connection. (In such a case, the window is reparented (and maybe unmapped)). Maybe generate an extension event which allows to distinguish the case of a closed connection from a destroyed window. This extension would enable to graft widget tree branches on into some other widget tree, even if the trees might run with different intrinsics, or, belong to different clients or even came from different host processors. 7) Shared memory transport. (BTW. I already use and love shared memory "images") 8) (Getting wild here). An override children cursor command/option (Temporarily changing the cursor in a window and its children, even if children have their own, different cursor). In languages which have garbage collection I would like to feed back to the user when garbage collection happens. (I have thought about changing a window header, but that is not where the user looks when the window appears dead for a second). (Don't answer: when a garbage collection is going to happen you can't issue a request anymore; it wouldn't be true in Cedar). 9) GrabServer needs a timeout mechanism. Its not trivial in the sense that the timing out client should be noticed about his failure at latest on his Ungrabserver call. (Similar but different for grab of Keys, Buttons...) 10) I would like to ask for a multithreaded XLib, if I would use XLib at all. (The protocol already has no hindrance against multithreading). 11) Performance. 12) Security. 13) Dynamicly loaded extensions. (Clients must be noticed when an extension is loaded) 14) This won't be possible given the existing framework: Move window from one screen to another. 15) Test tools (testing the application, not the server). 16) Performance evaluation tools. (I don't ask for evaluation of the X server performance. This must be done of course, but I don't have any interrest). I would like to know how well or not well behaved my own application is. 17) Pen input. Christian Jacobi Xerox PARC
meo@rsiatl.UUCP (Miles ONeal) (07/03/90)
To add to what Barry Jaspan said, a truly dumb layout widget would be handy as well - a bulletin board widget. Just give it a widget and some coordinates, and there the widget goes. Resizing optional, I don't care if the layout widget clips its children. -Miles O'Neal
jjh@knorr.ll.mit.edu (James J Hunt) (07/03/90)
There are three things I would like to see in R4: 1) an additional standard resource & switch which would allow a user to specify any valid X11 bitmap file of any size as icon for an application, 2) have a standard event for ``drag and drop'' which includes the files machine, path, and mount information (both local and remote), 3) a method to change the event inheritance so that events not in a given windows event mask could be passed to any window. The first item may not seem very important, but being able to customize icons really improved their informational content and hence their usefulness. For instance, I like to have a special icon for my console xterm. I suggest using -ibm for the switch and .iconBitmap as the resource name. Drag and drop is well suited to unsophisticated users. I do not particularly like this metaphor, but many people do. We are starting to see it used in X based UIs such as XView, and it would be nice to have a single standard. Specifying just a file path name is insufficient in a multi-host environment, so passing a host name as well is appropriate. This is often not optimal do to the use of a remote file system, so enough mount information should be given to decide if the receiving application has the file mounted locally, and if not where is the best place from which to get it. This is better than sending the entire file, especially for things like editors that want to write the file back at the end. Being able to change the event inheritance is another way of smoothing out the user interface. For example, in a panel it should be possible to direct all keyboard inputs to a particular window when the cursor is over the panel; and in a drawing window it should be possible to send keyboard events to a command interpreter window. In general this would reduce the necessity to move the cursor when doing mix mouse/keyboard entry. Certainly all the tools in the mit directory will accept and follow all the standard switches/resources. It is probably too much to ask that all the tools in the contrib directory do likewise. Instead the contrib directory should be broken up into those tools that CLAIM to follow the user interface standards and those that do not. This should not require much extra work on the part of the distributors of X, but would give the user community a little more information about the contributed tools in the distribution. JJHunt
aperez@cvbnet.UUCP (Arturo Perez x6739) (07/04/90)
What I would like to see is general support for the thing ATT calls dynamic resources. That is, whenever I modify the value of a resource, ALL the applications with instances of that resource are notified and update their appearances. Yes, I heard that Chris Peterson is already working on this. I just want to see it today :-). Way to go, guys! BTW, I would like to reiterate that the job you've done so far is outstanding! Arturo Perez ComputerVision, a division of Prime aperez@cvbnet.prime.com Too much information, like a bullet through my brain -- The Police
milgr@teapot.prime.COM (Marc Milgram) (07/04/90)
How about more sophisticated security -- on a user basis rather than a
host basis.
For example, xhost would take user-machine tuples.
ie. (milgr, *) - so I could pop up a window from
anywhere
(secretary, secretary_computer) - so the department secretary
could pop up messages from her desk
(*, my_lab_machine) - so I could test things from
different logins on my secure
lab machine.
Marc Milgram
milgr@teapot.prime.com
My ideas are my own.rjc@uk.ac.ed.cstr (Richard Caley) (07/04/90)
I'd like to be able to specify a stipple patern anywhere I can give a colour. This would let those of us with black & white displays to have things like menu shadows be grey. Lots of things should understand `save-yourself'. Xterm should probably pass the message on by sending an escape sequence to whatever is running in it. That would make `sm' useful. The whole thing should be about 10 times faster :-). -- rjc@uk.ac.ed.cstr
erc@pai.UUCP (Eric Johnson) (07/04/90)
In <9006222202.AA17654@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > No, I won't tell you when R5 is, and no, > I won't tell you what we do or > don't have planned for it. Why not? > This is your chance to flame, cajole, and lobby > for what you think the priorities for R5 should be. I don't guarantee I'll > agree or even have time to respond, but I do guarantee I'll listen. > I'm interested in "big" things, not adding another frobnotz resource > to xterm. Examples of big things that were in R4: ICCCM, XLFD, XDMCP, > Compound Text, SHAPE extension, lotsa bitmap fonts, server performance. I hope these are big enough. > Send your thoughts directly to me, or post them on the net if you prefer. I'm both mailing and posting this. The list below is in the order of importance to me. (I've noticed that each release of the X Window System is better and more professional than the last. I make extensive use of X and am very grateful for all the work that has been done, so please take all the suggestions below as constructive suggestions. I intend no flames, so please don't take anything as such.) 1) Make X easier for USERS to use. That is, have less reliance on resource files and other hard-to-understand configurations. X is still a developer's windowing system and isn't quite there yet as an end-user's windowing system. Perhaps a resource file editor with a graphical interface and a LOT of on-line help would improve things? Most users don't have the faintest idea what a widget hierarchy is, so being able to see and modify that won't really help much. We need something that is EASY. 2) More "transparent" support for international users of X. (I understand the Consortium is working in this area.) What I'm looking for are a set of routines that I can use in my programs to draw and read in text that may be formatted in may different national styles. To start with, I'm asking for some form of merger between all the 8-bit and 16-bit string functions, e.g., XTextWidth(), XTextWidth16(), XTextExtents(), XTextExtents16(), XQueryTextExtents(), XQueryTextExtenst16(), XDrawText(), XDrawText16(), XDrawString(), XDrawString16(), XDrawImageString() and XDrawImageString16(). An X programmer shouldn't have to worry so much about the actual formatting of the text. Let's face it, I doubt many X programmers use any of the *16 functions at all. If we are ever going to make software that works in other countries, we need to make the task easier on the software developers. In addition, an analog of XLookupString() would be required for character input. We'd also need functions to convert C strings to and from whatever string encoding is used (compound text, text properties, et. al.?). I'm sure there are a few other areas (Glen Widener of Tektronix mentioned a few last time I saw him). 3) An Xlib #define that states what version of Xlib you are compiling on, e.g., #define X11R4 for Release 4, etc. This would ease the programmer's task where changes are introduced to the X library. #ifdef X11R4 ...new stuff here... #else ..old stuff for compatibility... #endif If such a symbol were built in, then people could standardize on how to handle the changes. 4) Distribution of the X Consortium releases on QIC-formatted 1/4" cartridge tapes, in addition to the current 1/2" mag tapes. In three years, CD-ROM will probably be the format of choice, but for now many users never see 1/2" tapes (except in 1960s science fiction movies). 5) Contrib code that compiles on the new release. Perhaps the contrib tape(s) should be released after the core release (by about a month, say). This way, those who contribute software could make sure their code will work on the new release. This would also cut down on the number of patches sent out right after an X release. I know it would be a pain, but so is having a tape full of programs that if they even compile, chances are don't work. (I'm not trying to flame anyone here, I'm just trying to find a way to allow the contrib authors to update their stuff before it goes out with the new release. My goal is better, more usable software, not complaints.) 6) X11R5 support for UNIX System V 3.2 on 386 machines as part of the core release. There are quite a few of these machines out there (mainly because of the low costs involved), even if real programmers hate Intel architectures. 7) Improved support for selections. Right now, most users of selections are just cutting and pasting text--something that the much-maligned cut buffers did, but only in a way that is 100 times more complex and difficult than the simple cut buffers. The X core software set should make better use of selections to show more of the potential of selections and provide examples of the use of selections (to teach and encourage others). For example, the bitmap client should be able to exchange bitmaps as selections, supporting some form of cut and paste. (Xedit should be willing to support a FILENAME target, too, etc..) If more clients supported selections (or supported selections more thoroughly) then users would gain a lot more in--I hate this word-- interoperability. Much like the UNIX philosophy, each X client could be a small, interoperable program that communicates well with other X clients and does just one thing, but does that thing well. 8) Xt and Xaw toolkit support for both OSF/Motif and OpenLook ClientMessages, Properties and Selections. The idea here is to make Xaw/Xt programes interact better with the two major (two other major :-) X toolkits and window managers. I'm sure the X Consortium doesn't want to choose any sides in these interface wars, but I think we can all agree that OpenLook and OSF/Motif (and Xaw) are the toolkits/interfaces with the most going for them right now. 9) Include M. Ackerman's Answer Garden (or whatever he calls his set of software designed to help answer frequently-asked questions regarding X) as part of the core release. Or anything to help new X programmers, X installers and X users get going. 10) Provide more information on X changes, in advance, even to non-consortium members. The message I heard from you at the X Technical Conference in January was essentially "don't join" the consortium (basically since any new members would have to pay for the two previous years as well, with no added benefit). Add in this don't-join message and the if-you're-not-a-member,-you-lose message, and you put a lot of people in a no-win situation. Would it really hurt to let people know, in advance, what's coming up in the new release? I'm not expecting you to say "I promise that xxxx will be in the next release," but something like "We are working on improving xxxxx or adding yyyyy to the next release" or "People who make extensive use of zzzzz should watch out" would certainly help. 11) Include a mention about running ldconfig, in REALLY BIG TEXT, as part of the documentation on installing X on Suns (if it is still applicable). (This must be one of most-asked questions in comp.windows.x.) Perhaps the make install could use banner to blare out a big message--just to remind folks what else needs to be done. 12) Better performance of ovals (arcs), especially for windows using the SHAPE extension. (Try a 200x200 window that has a shape of many 10x10 rectangles and compare to a window that has a shape of 10x10 ovals. The rectangle-based window does OK, the oval-based window crawls painfully slow.) 13) Many more program examples to help new programmers learn how to program in X, especially X toolkits. 14) 24-bit colour support. (Another frequently-asked question.) Have fun, -Eric -- Eric F. Johnson phone: +1 612 894 0313 BTI: Industrial Boulware Technologies, Inc. fax: +1 612 894 0316 automation systems 415 W. Travelers Trail email: erc@pai.mn.org and services Burnsville, MN 55337 USA
ramani@modesty.Stanford.EDU (Ramani Pichumani) (07/04/90)
A very useful addition to Xlib would be the ability to draw a Gouraud shaded polygon. My guess is that this would not be difficult to do at the Xlib level. The simple addition of a Gouraud shaded polygon would open the door to a large class of 3D solid and surface rendering capabilities without having to incur the expense of running the PEX extensions or relying on expensive 3D graphics hardware. Also, if color dithering was employed in the polygon function, users with 8-bit color frame buffers could benefit greatly also. They would have the ability to view vivid 3D color graphics without expensive 24-bit color graphics support. With the use of a color intensity table, dithered polygons would enable monochrome users to also view 3D color objects in digital halftones. This would also provide a more general solution than using stipples to perform shading on monochrome displays. For people who need to do high-performance 3D color graphics generation, there is no substitute for 3D graphics hardware. However, the addition of this one function would enable users who are more interested in *viewing* 3D graphics (e.g. from a color X terminal) a much more economical solution. The XDraw* functions are fairly complete for drawing a large class of 2D and 3D graphical objects. The ability to draw a rotated ellipse is one of the few additional changes I would like to see in this area. Why a rotated ellipse and not rotated lines, polylines, etc? Because rotated polylines can still be achieved by passing transformed data to their respective drawing functions whereas there is no way to pass transformed data to the XDrawArc function to draw a rotated ellipse. This would be fairly easy to do at the Xlib level and would eliminate having to decompose a rotated ellipse into polylines just because the angle of rotation is non-zero. Ramani ------ Ramani Pichumani Tel: (415) 723-2902 or 723-2437 Department of Computer Science Fax: (415) 725-7411 Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani -- Ramani Pichumani Tel: (415) 723-2902 or 723-2437 Department of Computer Science Fax: (415) 725-7411 Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani
mouse@SURYA.MCRCIM.MCGILL.EDU (der Mouse) (07/04/90)
> There are three things I would like to see in R4: > 2) have a standard event for ``drag and drop'' which includes the > files machine, path, and mount information (both local and > remote), *Which* file's machine/path/etc? You surely don't expect to restrict drag-&-drop to files! (And what if more than one thing is being dragged-and-dropped? What if the machine doesn't have a path-and-mount based filesystem?) (As an aside, IMO the protocol should not involve itself with things as "high-level" as drag-and-drop. Mechanism not policy.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
fwp1@CC.MsState.Edu (Frank Peters) (07/04/90)
erc@pai.UUCP (Eric Johnson) writes: > ...I > make extensive use of X and am very grateful for all the work that > has been done, so please take all the suggestions below as > constructive suggestions. I intend no flames, so please don't take > anything as such.) Yeah! What he said. > 1) Make X easier for USERS to use. That is, have less reliance on > resource files and other hard-to-understand configurations. X is > still a developer's windowing system and isn't quite there yet as > an end-user's windowing system. Perhaps a resource file editor > with a graphical interface and a LOT of on-line help would > improve things? Most users don't have the faintest idea what > a widget hierarchy is, so being able to see and modify that won't > really help much. We need something that is EASY. I agree with this wholeheartedly. While I am all for improved speed and bigger and better FX (Features and Xtensions) I'd really like to see R5 emerge as the first X release that users (as opposed the just programmers) can really use. Remember that the ultimate purpose of windowing systems isn't to make programming easier or more interesting or more fun. The ultimate purpose (IMHO I suppose) is to make systems more usable. X has all of these wonderful programs and capabilities and such and actually setting up your environment the way you want it and learning to use it is difficult and arcane and, IMHO, beyond the average computer user. I suspect our site is not unique in the fact that X is for the most part used by programmers while mathematicians and engineers and administrators and everybody else uses sunview or MacOS or DOS. I basically can identify from my users three areas that need to be improved. 1) A richer set of basic utility programs. The favor with which users look upon X would be vastly improved by the addition of a button driven mail interface, a rolodex/note card manager and a useful calendar program. I know that such things are available commercially but I have excellent implementations of all three under sunview for FREE...and have been unable to locate any such for X (xmh comes close for the mailer...but requires users to learn an entirely new mail interface for line terminals to intigrate it). These three tools would be an immense boon because they'd be useful to just about ALL users. Some people use xdbx, some use xfig, some use xtex (and others xtroff) but almost everyone would have a use for a rolodex with simple string searching. Almost everyone on a networked computer uses electronic mail. Almost everyone has appointments and birthdays to keep track of. 2) Layout management. This is a difficult one I know. Such management almost has to be under the control of the window manager since ultimately it has control of what goes where (and knows of the affects of things like title bars). Right now about the best you can come up with for most window managers is to record the layout with something like xplaces and then edit it by hand to adjust for window decorations. I know this is an issue full of little difficulties (what if a user later tells the window manager not to add a title bar to an application?) but it is an issue that must be resolved if X is to be made acceptable to the averange sunview or mac user. 3) Resource files have GOT to go. I've seen quite a few users get over the two hurdles above only to be utterly appalled and confused and annoyed by .Xdefaults. A nice interface client that helps manage at least the simpler features is critical. The way I'd see this working is something like this: A directory rather like /usr/lib/X11/app-defaults is set up. Each program as it is installed inserts a file here which lists the configurable features, legal values and their defaults. Start with a file for X in which defaults for things like the window manager and background color/pattern and root cursor glyph and so on are held. An interface basically similar in concept to the sunview defaults editor can then be used. On startup it would display a menu of the files in that defaults directory. When a user chooses an item the defaults editor reads in the system defaults file, then any defaults in the users personal database (which could be the standard resource file for all I care) and displays the configuration items (with some sort of useful name or description). The user can changes what he or she wants and the changed values can be written to the personal database. It'd be great to be able to open such an application, select the X item and enter a new root window color and a new window manager name, then select the item for your new window manager and tell it through a simple interface which options you want off and on, which windows you want decorated and the like...then save and restart X and have it come up the way you told it to. Again, I know it would be difficult to implement (though not all that difficult to migrate to if the personal database were in standard resource format) but it is the kind of thing that other windowing systems offer and that general users base their choice of a windowing environment upon. Thanks for taking the time to listen to a relative X novice. Regards, --Frank -- Frank W. Peters Systems Programmer Computing Center & Services fwp1@CC.MsState.Edu Peters@MsState.Bitnet (601)325-2942 "I can't give you brains, but I can give you a diploma." -- The Wizard of OZ
stripes@eng.umd.edu (Joshua Osborne) (07/04/90)
In article <1336@pai.UUCP> erc@pai.UUCP (Eric Johnson) writes: >5) Contrib code that compiles on the new release. Perhaps the contrib >tape(s) should be released after the core release (by about a month, say). >This way, those who contribute software could make sure their code >will work on the new release. This would also cut down on the number >of patches sent out right after an X release. I know it would be >a pain, but so is having a tape full of programs that if they even >compile, chances are don't work. (I'm not trying to flame anyone >here, I'm just trying to find a way to allow the contrib authors to >update their stuff before it goes out with the new release. My goal >is better, more usable software, not complaints.) Please don't do this. I had 50% of what was in X11R4/contrib/clients up in less then 9 days after the Release (about 6 days after I got a disk big 'nuf to play with the Release). I don't mind the work, I got alot of neat programs, and learned a bit about X11R4 by doing it. It was a "Good Thing". I was a little disapointed when my patches didn't match the authors, mabie next time :-) -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't try to change C into some nice, safe, portable programming language with all sharp edges removed, pick another language." - John Limpert
dagenais@vlsi.polymtl.ca (Michel Dagenais) (07/05/90)
You said important new features... Getting a pixel independant layer (a la PostScript) on top of the existing low-level libraries would make applications more portable (at the price of some speed). This obviously includes outline fonts and possibly a font cache. Well, this is a bit like the difference between MacPaint and MacDraw. Of course this is available under X11/NeWS but having to deal with yet another different language is not really exciting (PostScript with window extensions). Is it dreaming to think about dynamic X extensions in C instead of NeWS interpreted PostScript; send a C routine to the server which compiles it and adds it to the available extensions in the X protocol. Michel Dagenais dagenais@vlsi.polymtl.ca ================================================================== -- --------------------------------------------------------------------------- Michel Dagenais dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (07/05/90)
> [...desired new feature for R5...] > Of course this is available under X11/NeWS but [...] Only on a Sun. Surely you expect R5 to run on more than just Suns. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
ramani@modesty.Stanford.EDU (Ramani Pichumani) (07/06/90)
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) writes: >> The reason for incorporating something like Display PostScript into X >> is to remove any dependence on the display resolution. > And it would do that tolerably well. But I argue that this is not > something you want to do. Not until we have displays whose pixels are > too small to see. (Current displays don't begin to approach this; even > laser printers aren't that good yet.) Perhaps you haven't used the NEXT Machine? The characters on that machine seem to be at least as good as any I've seen on any monochrome monitor. >> The usefulness of a real PostScript Interpreter cannot be >> overstated. I would rank this as one of the most important possible >> features for X11R5. > Please, Consortium...if you do decide to include this, make it > configurable out. I have no use for such a thing and have much better > uses for the memory it would eat up. (Making it an extension, like the > SHAPE extension in R4, would be a very sane way to go.) A feature doesn't have to be in the X Server to be a part of X11. It can either be part of the server or it can just be in the mit/{clients,...} hierarchy (or partly in both). Programs that are under contrib/{clients,...} are not really part of X but they do work on some machines, under some platforms, under some versions of X11... The difference between being part of mit/... versus contrib/... is that the former is essentially a standard X utility whereas the latter is not. That means you don't have to worry about whether or not the user has this function/feature. Chances are very good that they have it. So if you've got it, use it. Not to belabor the point about PostScript fonts, but one should realize that there is already a sizable amount of code and memory in the X server and Xlib devoted to rendering text. As has been suggested by several people in earlier postings, employing Adobesque font techniques at the Server/Xlib level and a PostScript Interpreter at the mit/client level would allow for a very powerful and sensible implementation of Display PostScript. Applications that don't need the interpreter can still leverage off of the generalized, device-independent font mechanism since they need some sort of text capabilities anyway. After all, isn't the goal of a device/machine/OS independent graphical windowing system the entire raison d'etre behind X? Ramani -- Ramani Pichumani Tel: (415) 723-2902 or 723-2437 Department of Computer Science Fax: (415) 725-7411 Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani
ramani@modesty.X@@3ford.EDU (Ramani Pichumani) (07/06/90)
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) writes: >> The reason for incorporating something like Display PostScript into X >> is to remove any dependence on the display resolution. > And it would do that tolerably well. But I argue that this is not > something you want to do. Not until we have displays whose pixels are > too small to see. (Current displays don't begin to approach this; T4 9> laser printers aren't that -9@Nyet.) Perhaps you haven't used the NEXT Machine? The characters on that machine seem to be at least as good as any I've seen on any monochrome monitor. >> The usefulness of a real PostScript Interpreter cannot be >> overstated. 6%K!ld rank this as one of the most important possible >> features for X11R5. > Please, Consortium...if you do decide to KI Ade this, make it > configurable out. I have no use for such a thing and have much better > uses for the memory it would eat up. (Making it an extension, like the > SHAPE extension in R4, would be a very sane way to go.) A feature doesn't have to be in the X Server to be a part of X11. It can either be part of the server or it can just be in the mit/{clients,...} hierarchy (or partly in both). Programs that are under contrib/{clients,...} are not really part of X but ]hey do work on some machines, under some platforms, under some versions of X11... The difference between being part of mit/... versus contrib/... is that the former is essentially a standard X utility whereas the latter is not. That means you don't have to worry about whether or not the user has this function/feature. Chances are very -9@Nthat they have it. So if you've got it, use it. Not to belabor the point about PostScript fonts, but one should realize that there is already a sizable amount of code and memory in the X server and Xlib devo%77to rendering text. As has been suggeS(!B by several people in earlier postings, employing Adobesque font techniques at the Server/Xlib level and a PostScript Interpreter at the mit/client level would allow for a very powerful and sensible 8;<8entation of Display PostScript. Applications that don't need the interpreter can still leverage off of the generalized, device-independent font mechanism since they need some sort of text capabilities anyway. After all, isn't the goal of a device/machine/OS independent graphical windowing system the entire raison d'etre behind X? Ramani -- Ramani PichumaniLDAN Tel: (415) 723-2902 or 723-2437 "!@0rtment of Compute( 14ienceLDAN Fax: (415) 725-7411 Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu X@@3ford, CA 94305 USA 7)S%!patience.stanford.edu!ramani #! rnews 892 Path: xr4ads!as (" Is.utexas.
jpenny@ms.uky.edu (Jim Penny) (07/06/90)
I would most like to see a trip-test. There seems to be very little uniformity in the treatment of many details in server inplementation. In fact, many things which were written with portablility in mind, for example xmntn, will run rather strangely on a some servers. Sun 3/110 gives very different behavior than the Spacstation. XDrawImageString is wrong on the Sun. The At&T6386 server has a LOT of anomolies. (Yes, I know that designing such a test is an ENORMOUS amount of work, but you asked ) Jim Penny
janssen@parc.xerox.com (Bill Janssen) (07/06/90)
In article <1990Jul4.125628.16560@eng.umd.edu> stripes@eng.umd.edu (Joshua Osborne) writes: In article <1336@pai.UUCP> erc@pai.UUCP (Eric Johnson) writes: >5) Contrib code that compiles on the new release. Perhaps the contrib >tape(s) should be released after the core release (by about a month, say). Please don't do this. I had 50% of what was in X11R4/contrib/clients up in less then 9 days after the Release (about 6 days after I got a disk big 'nuf to play with the Release). I don't mind the work, I got alot of neat programs, and learned a bit about X11R4 by doing it. It was a "Good Thing". I was a little disapointed when my patches didn't match the authors, mabie next time :-) Please *do* do this. I do mind the work, I'd like to have 100% of the programs work, they'll still be neat, and the authors' patches will match my sources. Nice timing for a reminder on this topic, Eric. Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
stripes@eng.umd.edu (Joshua Osborne) (07/06/90)
To: jacobi.pa@XEROX.COM Subject: Re: what's most important to you for R5? Newsgroups: comp.windows.x In-Reply-To: <900702-140906-1044@Xerox> References: <JANSSEN.90Jun28140947@holmes.parc.xerox.com> Organization: College of Engineering, Maryversity of Uniland, College Park Cc: Bcc: In article <900702-140906-1044@Xerox> you write: >8) (Getting wild here). An override children cursor command/option >(Temporarily changing the cursor in a window and its children, even if >children have their own, different cursor). In languages which have >garbage collection I would like to feed back to the user when garbage >collection happens. (I have thought about changing a window header, but >that is not where the user looks when the window appears dead for a >second). (Don't answer: when a garbage collection is going to happen you >can't issue a request anymore; it wouldn't be true in Cedar). Create a InputOnly window that covers all child windows, give it the cursor you want. Works for me. -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't try to change C into some nice, safe, portable programming language with all sharp edges removed, pick another language." - John Limpert
dennisg@kgw2.bwi.WEC.COM (Dennis Glatting) (07/07/90)
In article <1990Jun26.210151.12045@planck.uucp> meyer@planck.UUCP (Bob Meyer) writes: > >While were on the subject of wish lists, how's about a nice clean file selector >ala MacIntosh or Atari ST et.al. that allows parameters such as default search >patterns, starting directory and amount of info about each file to >display. Mebbe >something that can identify and traverse directories without opening window >after window for each one. similar to the NeXT browser. multiple bays, maybe... -- -- dennisg@kgw2.bwi.WEC.COM | Dennis P. Glatting ..!uunet!tron!kgw2!dennisg |
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (07/07/90)
>>> The reason for incorporating something like Display PostScript into >>> X is to remove any dependence on the display resolution. >> And it would do that tolerably well. But I argue that this is not >> something you want to do. Not until we have displays whose pixels >> are too small to see. (Current displays don't begin to approach >> this; even laser printers aren't that good yet.) > Perhaps you haven't used the NEXT Machine? The characters on that > machine seem to be at least as good as any I've seen on any > monochrome monitor. It's a two-bit grayscale display, not truly monochrome. But that's irrelevant, because the characters are usually displayed in a two-gray-level way, typically full-black on full-white. Yes, I have tried to use a NeXT. (I found it unusable, because the user interface is so incredibly expert-hostile. But that's not the point.) The characters look reasonable, yes - provided you use one of the standard fonts at one of the standard resolutions. While this could be done in X as well (and indeed, at the moment that's effectively all you *can* do), that's not my point. I was referring less to characters than to other graphics. I have had occasion to try to do graphics on a PostScript 300dpi printer, and getting the results to look good is very difficult, precisely because it is hard-to-impossible to specify things at the pixel level. For example, if I specify a line width that isn't an exact number of pixels wide, and then draw a horizontal or vertical line of this width, it will come out in different widths depending on where within the pixels the endpoints fall. As another example, I drew a grid of equilateral triangles. When the triangles were small (say, ten pixels high), the mesh was visibly irregular because the triangle corners were not positioned regularly. I suppose my point can be summed up as "as long as you can see the pixels, you have to draw in pixel terms to get high-quality results". And PostScript makes it somewhere between difficult and impossible to draw in pixel terms. Indeed, on the 300dpi printer I mentioned above it may be that it's *impossible* to draw in pixel terms because of floating-point problems (1/300 is not exactly representable on most machines). But I can't even find out whether this is true or not. >>> The usefulness of a real PostScript Interpreter cannot be >>> overstated. I would rank this as one of the most important >>> possible features for X11R5. >> Please, Consortium...if you do decide to include this, make it >> configurable out. > A feature doesn't have to be in the X Server to be a part of X11. A very good point. Thank you. If it does not impose a significant overhead on users that don't use it, I withdraw my objections. (All I'm left with then is balancing the possible usefulness of having it available against the possible siphoning off of X staff time from other tasks, and I have no grounds to judge either way on that.) > Not to belabor the point about PostScript fonts, but one should > realize that there is already a sizable amount of code and memory in > the X server and Xlib devoted to rendering text. Well, most of the hair is devoted not to rendering text so much as to rendering text *fast*. It may turn out that enough code is eliminated or simplified that it isn't a big overhead. In that case, by all means please go ahead. My main worry is that it not make things worse for someone who doesn't touch it, "worse" including memory use, speed, complexity of client code, etc. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (07/07/90)
>> 8) (Getting wild here). An override children cursor command/option >> (Temporarily changing the cursor in a window and its children, >> even if children have their own, different cursor). > Create a InputOnly window that covers all child windows, give it the > cursor you want. Works for me. I nearly suggested that, but unfortunatly there's no way to have pointer events still sent to the correct windows when you do that. Presumably the person wants pointer events to still happen correctly and be held for processing when whatever's happening is over. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
root@vicorp.com (Super User) (07/07/90)
In article <900702-140906-1044@Xerox> you write: >8) (Getting wild here). An override children cursor command/option >(Temporarily changing the cursor in a window and its children, even if >children have their own, different cursor). In languages which have >garbage collection I would like to feed back to the user when garbage >collection happens. (I have thought about changing a window header, but >that is not where the user looks when the window appears dead for a >second). (Don't answer: when a garbage collection is going to happen you >can't issue a request anymore; it wouldn't be true in Cedar). Create a InputOnly window that covers all child windows, give it the cursor you want. Works for me. -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't try to change C into some nice, safe, portable programming language with all sharp edges removed, pick another language." - John Limpert
harp@cadillac.CAD.MCC.COM (Christopher North-Keys) (07/08/90)
(Also forwarded to rws@EXPO.LCS.MIT.EDU (Bob Scheifler))
(I've been using X since release 10, as user, programmer, and sysadmin.)
--------------------"Need" list:
3d
Currently, solid rendering has to be done almost entirely in the
client, although the graphic-support hardware exists on the server. This
makes it nearly impossible to take advantage of a decent graphic
accelerator, and almost rules out the use of X in software involving
modeling, virtual reality, CAD, graphic simulation, etc., due to rendering
and animation speed constraints. I have heard that work is underway on
this issue, and I hope that is correct. So who wants to write the X11R5
flight simulator?
Text
The current implementations of the various text-using X items have
evinced discrepancies in many areas including:
o Fascist restrictions to ASCII, hardly a global standard.
o Failure to use proportionality in fonts.
o The *16 text routines should (somehow) be merged with the 8-bit routines.
PS
Avoid forcing everyone to pay the performance penalty associated with
PostScript display support. Although supporting fonts in the server seems
reasonable, I think support for full PostScript would be better relegated
to the mit/client or contrib/client level. This issue was discussed well by
(der Mouse) <mouse@larry.mcrcim.mcgill.edu> article 20446 in comp.windows.x.
Xterm
(I don't envy anyone working on this program; it's scary in there.)
Xterm currently utterly fails to support proportional fonts, and even
has difficultly with some of the fixed-width oblique fonts. There is no
provision for colored-highlights, nor for color display in the Tektronics
mode. This last, alone, is forcing several of my users to continue using
SunView instead of X. Xterm should do bitwise tabbing in proportional mode
instead of spacewise, which breaks, etc. Since Xterm *is* the primary
interface to Unix (or whatever) while within X, the investiture of some
addition cleanup/enhancement should be well-warranted, particular in
improving its common appeal.
Primitives
Improved support for curve-display functions: removal of the orthagonal
restriction in the oval primitive, etc.
Validation
A program to fully test an X server.
--------------------Wishes
SoftLock
A generic "lock" paradigm to replace CapsLock. This SoftLock key would
have the following functionality:
Definition: shift-set = {shift,control,meta,alternate,super,hyper, ... }
1. If a SoftLock<KeyPress> occurs while any member of the shift-set
is depressed, then that member's next <KeyRelease> event is ignored.
In the event several shift-set members are depressed, each of their
respective next <KeyRelease> events will be ignored.
2. If a SoftLock<KeyPress> occurs while no members of the shift-set are
depressed, than <KeyRelease> events are generated for all members of
the shift-set.
Selections
Improved selection support, including bitmaps and so forth. This issue
has already been discussed in comp.windows.x
Contrib
The contrib directory should be better-verified against the core
release. However, I agree with another poster in that it is *very* nice to
have the contrib disseminated at the same time as the core. Any suggestions?
Defaults
~/.Xdefaults files are driving the common user crazy. This, too, has
already been discussed. *I* have the additional gripe, however, that a
nice functionality in X11R3 has apparently been lost. In R3, one could
specify a set of defaults as an alteration of another set in a
semi-hierarchical fashion. Something like:
...
consoleXterm.baseResource: Xterm
consoleXterm*vt100.geometry: 80x4+0+0
consoleXterm*scrollBar: true
...
to specify the consoleXterm resources as a modification of the xterm
resources would be convenient. In R3, I seem to remember the "name"
resource would allow this sort of thing.
--
______________________________________________________________________________
Christopher North-Keys Assoc. Systems Analyst
Group Talisman Harp[@Mcc.Com]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~guy@auspex.auspex.com (Guy Harris) (07/09/90)
>Xterm > (I don't envy anyone working on this program; it's scary in there.) > Xterm currently utterly fails to support proportional fonts, So do most other terminals. In fact, so do a lot of programs that *run* on terminals; for what would proportional-font support in "xterm" be better than, say, having the application run as an X application rather than as a "dumb terminal" application? >and even has difficultly with some of the fixed-width oblique fonts. >There is no provision for colored-highlights, nor for color display in >the Tektronics mode. This last, alone, is forcing several of my users >to continue using SunView instead of X. I wasn't aware that "shelltool" nor "cmdtool" - the SunView moral equivalents of "xterm", basically - supported color, as you seem to be implying. (BTW, you *are* aware that there are X versions of "shelltool" and "cmdtool", right? Check out XView - you even get source....) >Since Xterm *is* the primary interface to Unix (or whatever) while >within X, It's the primary interface for some people at some times. Some people run other terminal emulators ("shelltool"/"cmdtool", Andrew "tm", etc.); some people might run inside some file manager application; at some times, some people would be interacting with some X-based application, not some dumb tty application running inside an "xterm". Were I editing a document in an interactive editor/formatter capable of displaying proportionally-spaced text, for example, I would probably *not* be running it "inside" an "xterm"; it would probably have its own X window(s) and not be bound by "xterm"s limitations. "xterm" certainly appears to be the *default terminal emulator interface* to X, but that doesn't mean it needs to be all things to all people.
bob@MorningStar.Com (Bob Sutterfield) (07/09/90)
In article <9529@cadillac.CAD.MCC.COM> harp@cadillac.CAD.MCC.COM (Christopher North-Keys) writes:
Since Xterm *is* the primary interface to Unix (or whatever) while
within X...
I suspect my cursor spends more time in my Emacs window than in any of
my xterm windows. Xterm is the thing in which I most frequently
interact with shells, but that's a relatively small (and decreasing)
part of what I do.
"Emacs - it's not just an adventure, it's a way of life."
"I've heard there's a text editor in there too!"jpc@fctunl.rccn.pt (Jose Pina Coelho) (07/09/90)
Error messages (I mean with a few more bits of information) Let's show it: I'm debugging a program which opens windows and has to widgets of my own. It runs and runs and runs and then: > X Error of failed request: BadValue (integer parameter out of range for operation) > Major opcode of failed request: 1 (X_CreateWindow) > Minor opcode of failed request: 0 > Resource id in failed request: 0x96 > Serial number of failed request: 228 > Current serial number in output stream: 229 Interesting to know that there is an integer out of range, but which one ?, I mean, there are eight integer arguments to the function, which of them? Is it invalid class ? Is it negative width (or height or border or depth) Is it too much planes for the poor machine ? The message format could have one more line with the call arguments. > Call: XCreateWindow(0x347452, 0x436485, 10, 20, 200, 110, 2, -2, 1, 0x234567, 23, NULL); or > Call to XCreateWindow with negative depth (-2) I know of debuggers, but the bug depends on the phase of xphoon and the debugger is almost unusable and it's a lot easier to find the bug if you know which values are bad. -- Jose Pina Coelho | BITNET/Internet: jpc@fctunl.rccn.pt Rua Jau N 1, 2 Dto | UUCP: jpc@unl.uucp 1300 Lisboa, PORTUGAL | ARPA: jpc%hara.fctunl.rccn.pt@mitvma.mit.edu Home phone: (+351) (1) 640767 - If all men were brothers, would you let one marry your sister ?
janssen@parc.xerox.com (Bill Janssen) (07/10/90)
In article <9529@cadillac.CAD.MCC.COM> harp@cadillac.CAD.MCC.COM (Christopher North-Keys) writes: > Since Xterm *is* the primary > interface to Unix (or whatever) while within X, the investiture of some > addition cleanup/enhancement should be well-warranted, particular in > improving its common appeal. Doubt if I've used xterm more than 5% of my shell-interaction time in the last year. A version of Andrew 'typescript' is more usual. In addition to proportionally spaced fonts, it supports rasters, animations, sound objs, etc., in the sense that if that is what appears on your standard output, that is what the typescript displays to you. And the rest of the time is in GNU Emacs 'shell'. But we do have some programs with a hard-wired need for a vt100... Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
rjc@uk.ac.ed.cstr (Richard Caley) (07/11/90)
In article <3628@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >Xterm > (I don't envy anyone working on this program; it's scary in there.) > Xterm currently utterly fails to support proportional fonts, So do most other terminals. In fact, so do a lot of programs that *run* on terminals; for what would proportional-font support in "xterm" be better than, say, having the application run as an X application rather than as a "dumb terminal" application? Fine if you want to rewrite every program that ever was. Eg of where I'd like to use a proportional font. I have a console window which is an ``xterm -C'' in which my window manager runs and nothing else. This means that console messages and window manager message turn up in there. Since this is output only it would be nice if it were as readable as possible, a nice proportional font would do nicely.
andreas@hpcvlx.cv.hp.com (Jim Andreas) (07/11/90)
> vladimir@prosper (Vladimir G. Ivanovic) 2:32 pm Jun 25, 1990 writes: > > Every week or so, someone posts a request for a tool which > will automate the testing of X applications. Currently, (as > far as I am aware of) there is no MIT X Consortium support > for such a tool. [stuff deleted] > What I'd like to see is an extensible, customizable, fully though out > solution. I would like to second Vladimir's request. Right now, near as I can tell, only the HP and the Tek sample server incorporate the Input Synthesis Extension in the X server, so there is partial support for such a tool. Also, a Client Exerciser regression test record/playback tool is available as part of the XTEST package on expo, but this has not been widely publicized. The Input Synthesis Extension and the Client Exerciser would be a lot more useful if all of the sample servers incorporated the extension. It appears to be pretty simple to patch into the sample servers (requiring just a test and function call in the DDX layer's handling of input events, plus the usual care and feeding of an extension... ) > > Some ideas: > * Recording of events and correct playback even with timing differences It's in there > * A run-time langauge for talking about or editing of events The Client Exerciser can convert its machine readable log file to a human readable file. > * Knowledge of windows, even if they are differently sized and have moved Oops this is not there, and would really be nice to have > * Ability to recover from server or client errors Umm this sounds rather hard. Bottom line - support for testing of the infinite numbers of applications that will exist for X shortly seems like a pretty high priority to me. ----------------------------------------------------------------------- Jim Andreas | andreas@cv.hp.com | INTERNET Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!andreas | UUCP 1000 N.E. Circle | (USA) (503) 750-2860 | VOICE Corvallis, OR 97330 | (USA) (503) 750-3788 | FAX ----------------------------------------------------------------------- This response does not represent the official position of, or statement by, the Hewlett-Packard Company. The above data is provided for informational purposes only. It is supplied without warranty of any kind. -----------------------------------------------------------------------
crouch@axion.bt.co.uk (Chris Rouch) (07/11/90)
I polled our users to find out what they'd like to see in R5. They are mostly from a technical background, but see X as a tool, i.e. they just want to login and go, they're not that interested in configuring it. Anyway the sensible suggestions were: a resource editor (akin to Sunview's defaultseditor perhaps) a good file organiser (perhaps similar to the sunview organizer), the idea being that naive users don't need or want to learn how to use unix - they're much happier with a wimp interface. An improved xedit, allowing WYSIWYG editting and multiple windows. (What I'd really like to see is some good spreadsheets, databases, word processors, project management tools, etc. for X, so we can get rid of all the bl**dy PCs, but I suspect this is not something the consortium will be providing.) ----------------------------------------------------------------------------- Chris Rouch crouch@axion.bt.co.uk RT3131, BTRL, Martlesham Heath, Ipswich, England. +44 473 646093 We came, we saw, we lost on penalties.
wood%lavc3.dnet@SMITHKLINE.COM (Bill Wood, SKB Pharmaceuticals R&D, 215-270-5163) (07/12/90)
I would like to see "politcally correct" X11 support for printer ports on X windows terminals. Most manufacturers (IBM, Graphon, HDS, for instance) who have printer ports on their terminals use a socket interface to the OS on the terminal for downloading to the port. This method bypasses any present or future X windows security mechanisms, and only works on a TCP/IP transport layer. An X extension for output or input from ports on the server is the natural way to handle printer ports, and other ports as well (eg. data collection ports). I am interested in your feedback on this idea. - Bill wood@smithkline.com
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/12/90)
I would like to see "politcally correct" X11 support for printer ports on
X windows terminals.
Sorry, I believe the politically correct support is that which has nothing
whatsoever to do with the X protocol. I've flamed at X terminal vendors
privately in the past to avoid using an X extension, it's good if they're
agreeing with me. :-)guy@auspex.auspex.com (Guy Harris) (07/12/90)
> So do most other terminals. In fact, so do a lot of programs that *run* > on terminals; for what would proportional-font support in "xterm" be > better than, say, having the application run as an X application rather > than as a "dumb terminal" application? > >Fine if you want to rewrite every program that ever was. Some of them will need to be modified *anyway* to work with proportional fonts on a terminal that supports them; that's what my "In fact, so do a lot of programs that *run* on terminals" meant.... >Eg of where I'd like to use a proportional font. I have a console >window which is an ``xterm -C'' in which my window manager runs and >nothing else. This means that console messages and window manager >message turn up in there. Since this is output only it would be nice >if it were as readable as possible, a nice proportional font would do >nicely. You might try "xconsole" instead. "xterm" seems like overkill for an output-only console messages window, and adding proportional spacing just for that purpose seems even more so.
stripes@eng.umd.edu (Joshua Osborne) (07/12/90)
In article <1990Jul11.152749.10928@axion.bt.co.uk> CRouch@axion.bt.co.uk writes: [...] >a good file organiser (perhaps similar to the sunview organizer), the >idea being that naive users don't need or want to learn how to use unix >- they're much happier with a wimp interface. Sun has a nice XView filemgr, mabie they could be convinced to donate it. (somehow I doubt it, but... it would give more sys. mgrs. a good reason to compile XView) >An improved xedit, allowing WYSIWYG editting and multiple windows. Why do you need xedit to give >1 window? Bring up another xedit. For WYSIWYG, I think Andrew has something close but I havn't had the time to get and compile a working version of Andrew... >(What I'd really like to see is some good spreadsheets, databases, word >processors, project management tools, etc. for X, so we can get rid of >all the bl**dy PCs, but I suspect this is not something the consortium >will be providing.) GNU is/was working on a spreadsheet, if gnumacs is an indication it will have X support. For the rest you are on your own... -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't try to change C into some nice, safe, portable programming language with all sharp edges removed, pick another language." - John Limpert
casey@gauss.llnl.gov (Casey Leedom) (07/18/90)
| From: stripes@eng.umd.edu (Joshua Osborne) | | > From: erc@pai.UUCP (Eric Johnson) | > | > 5) Contrib code that compiles on the new release. Perhaps the contrib | > tape(s) should be released after the core release (by about a month, say). | | Please don't do this. I had 50% of what was in X11R4/contrib/clients up in | less then 9 days after the Release (about 6 days after I got a disk big | 'nuf to play with the Release). Your nine days is one of the shortest I've heard of. You must have a very good background in X11. That's very nice for you. It took me about five weeks to get the contrib programs that I could get compiled and running up. But, even if my time was excessive and we assume that yours is more normal, why should everyone in the world waste nine days of their time (and their employer's time) working redundantly on exactly the same problem? Typically a month without the newest foobaz versions of various contrib programs won't bother anyone. After all, the old compiled versions will still work as long as the protocol stays the same. | I don't mind the work, I got alot of neat programs, and learned a bit about | X11R4 by doing it. It was a "Good Thing". I learned a lot in the process too. I'm not sure I can justify calling it a good thing however. If I got a car from the factory and had to spend a month fixing it before I could drive it, and in the process learned a lot about the car ... Well, you get my point. Along these lines, I'd also like to suggest that two things be done for the R5 release: 1. Install the distribution in some non-standard place and make sure it runs from there. It only has to be done once. I'd say that 50% of my initial R4 bug reports to MIT were because of hard coded paths. 2. Install and test the distribution on more hardware/software platforms. Somewhere on the order of 30% of my initial R4 bug reports were because R4 had never been tested under SunOS 3.5 ... Yes, I realize that MIT doesn't have the machine or people resources for this. I suggest that MIT use volunteer BETA sites to perform prerelease testing. I myself would be willing to help along those lines. And yes, I'm willing to sign non-disclosure agreements, etc. I think that these two steps would improve the initial quality of the distribution tremendously. Casey