lam@muddcs.Claremont.EDU (Grace Lam) (07/21/88)
I am developing an interactive graphics program for viewing the structure of software etc... The problem I face is porting around many hardware platforms (ie. VAX-VMS, VAX-Unix, Sun, Apollo) and among multiple operating and window systems (X, NEWS, Sun Windows, HP and others). The graphics will be fairly normal stuff: zooming, panning, mutiple windows. Are there any graphics toolkits around that can help? For example a drawing and widget toolkit that provides a common interface to a variety of window systems, so I only have to write graphics code ONCE. Any help will be greatly appreciated. Ken Nelson Software Systems Design Claremont, CA
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (07/21/88)
In article <732@muddcs.Claremont.EDU> lam@muddcs.Claremont.EDU (Grace Lam) writes: >Are there any graphics toolkits around that can help? For example a >drawing and widget toolkit that provides a common interface to a >variety of window systems, so I only have to write graphics code >ONCE. This is what Open Look (OPEN LOOK is the real name of it, but I don't like to SHOUT all the time) is supposed to provide. Sun is implementing it for NeWS, ATT is implementing it for X11, and the spec book will allow others to implement it for Joe's Window System, Plumbing Supply and Bowl-a-teria. In theory, there will be common set of objects and toolkit calls for you to code. Then you take your same source and link it against libOLX11.a or libOLNeWS.a or perhaps libOLJWSPSB.a, depending upon your mood and what platform you'd like to ship it on. Careful adherence to the specs should lend portability, at the possible expense of nifty features native to a particular window system. I haven't seen either toolkit nor the specs, but the demos look kinda pretty and the idea is attractive as well. -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@cis.ohio-state.edu or ...!{att,pyramid,killer}!cis.ohio-state.edu!bob
mlandau@bbn.com (Matt Landau) (07/22/88)
In comp.windows.misc, bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >In article <732@muddcs.Claremont.EDU> lam@muddcs.Claremont.EDU (Grace Lam) writes: >>Are there any graphics toolkits around that can help? For example a >>drawing and widget toolkit that provides a common interface to a >>variety of window systems, so I only have to write graphics code >>ONCE. > >This is what Open Look is supposed to provide. >In theory, there will be common set of objects and toolkit calls for >you to code. According to all the information I've been able to get from both Sun and AT&T, this is (unfortunately) *not* what Open Look is supposed to provide. Open Look will be a specification for an application "personality" (I hate the term "look and feel"), rather than any one toolkit or set of toolkits. There will be toolkits that implementation the Open Look personality built on top of several host window systems -- NeWS and X are the first two that have been announced. However, and this is a big however, the Xt and NDE implementations of the Open Look personality will NOT provide applications with source level compatibility across the underlying window systems. The Xt-based toolkit will provide one programming interface, and the NDE another. If you want an application to run in both environments, you still have to write it twice. Personally, I think this was a bad decision. There's a great need for toolkits that are window-system independent, at least from the software developer's point of view. We have developed one such toolkit internally for building applications that run under either SunView or X11, and while it's not a simple task, I think it's certainly possible to do a reasonable job, and I don't quite understand why none of the commercial players are pursuing this as an option. (I wonder if SunView might not have a chance at becoming such a thing, if it's really true that SunView 2.0 has been implemented on top of X11. The SunView programming interface is really nice, and I don't think it would be THAT hard to do a SunView toolkit for NeWS. -- Matt Landau "Don't make me angry. mlandau@bbn.com You wouldn't like me when I'm angry."
tony@linus.UUCP (Tony E. Davis) (07/22/88)
> [Claim that SunView 2.0 will be implemented on top of X11.] Could be; I haven't heard that; it would be nice. > [Hope that it will be implemented on top of NeWS.] I HAVE seen Sun releases which say SunView will be implemented on top of NeWS. Tony Until 8-26-88: Tony Davis (617) 271-2146 The MITRE Corporation MS A114 Burlington Road Bedford, MA 01730 U.S.A. linus!tony tony%linus@mitre-bedford.ARPA After 8-26-88: Still Tony Davis, but phone, address, and email will change: <who-knows-yet>@cs.brown.edu
freek@uva.UUCP (Freek Wiedijk) (07/22/88)
In article <732@muddcs.Claremont.EDU> lam@muddcs.Claremont.EDU (Grace Lam) writes: >Are there any graphics toolkits around that can help? For example a >drawing and widget toolkit that provides a common interface to a variety >of window systems, so I only have to write graphics code ONCE. > > Ken Nelson At the Centre for Mathematics and Computer Science (CWI) here in Holland, Guido van Rossum has made exactly what you describe here. It is called STDWIN, and it is intended to be an analogon to STDIO for windowing. The describing report is: Guido van Rossum, STDWIN - A Standard Window Interface. Centre for Mathematics and Computer Science, Report CS-R8817. Amsterdam, 1988. Abstract: STDWIN is an interface layer placed between an application written in C and arbitrary window system, making the use of windows both easier and more portable. For applications using STDWIN for their window management requirements, adaptation to a different window system is as easy as linking with an appropriate version of the STDWIN library. So far, STDWIN libraries are available for the Apple Macintosh, for the Whitechapel MG-1 (running Oriel), for MIT's X Window System version 11, for the Atari ST, and (subsets) for alphanumeric terminals on UNIX and MS-DOS. New implementations are easily written. Like STDIO, C's Standard I/O library, STDWIN's aim is to give a simple interface, high-level functionality, and portablility. It does not attempt to allow access to all possible features of window management systems; rather, it provides the programmer with a model wich allows easy construction of that part of the program which is concerned with window management. STDWIN's high-level operations include automatic window positioning and resizing, scrolling, menus, keyboard shortcuts, and multiple-click detection. If you want to learn more about STDWIN I suggest you should try to contact the author. His e-mail address is guido@cwi.nl or mcvax!guido The address of the CWI is: Centre for Mathematics and Computer Science P.O. Box 4079 1009 AB Amsterdam The Netherlands I've appended the file stdwin.h, to give you an impression of the interface. Greetings, Freek. -- Freek Wiedijk <the pistol major> UUCP: uunet!mcvax!uva!freek #P:+/ = #+/P?*+/ = i<<*+/P?*+/ = +/i<<**P?*+/ = +/(i<<*P?)*+/ = +/+/(i<<*P?)** ------------------------ This is the file stdwin.h --------------------------- /* GENERIC STDWIN -- INTERFACE HEADER FILE. */ #ifndef GENERIC_STDWIN #define GENERIC_STDWIN /* So this header file is skipped if included twice */ #define CURSOR_CARET /* Defined so textedit will always set the caret at the start of the focus -- useful only for ASCII terminals. */ #ifndef ARGS #define ARGS(x) () /* replace by x for ANSI C */ #endif #ifndef NOARGS #define NOARGS () /* replace by (void) for ANSI C */ #endif #ifndef bool #define bool int #endif void winit NOARGS; void winitnew ARGS((int *pargc, char ***pargv)); void wdone NOARGS; void wgetscrsize ARGS((int *pwidth, int *pheight)); void wgetscrmm ARGS((int *pmmwidth, int *pmmheight)); void wsetmaxwinsize ARGS((int width, int height)); void wsetdefwinsize ARGS((int width, int height)); void wsetdefwinpos ARGS((int h, int v)); #define MENU struct menu /* The contents of a text attributes struct are disclosed here because the interface allows the programmer to declare objects of this type. (I'm not so sure anymore that this is the right thing to do!) */ struct textattr { short font; unsigned char size; unsigned char style; }; #define TEXTATTR struct textattr #ifndef WINDOW struct window { short tag; }; #define WINDOW struct window #endif WINDOW *wopen ARGS((char *title, void (*drawproc)(/*WINDOW *win, int left, int top, int right, int bottom*/))); void wclose ARGS((WINDOW *win)); #define wgettag(win) ((win)->tag) #define wsettag(win, newtag) ((win)->tag= newtag) void wsetactive ARGS((WINDOW *win)); WINDOW *wgetactive NOARGS; void wgetwinsize ARGS((WINDOW *win, int *width, int *height)); void wsetdocsize ARGS((WINDOW *win, int width, int height)); void wsettitle ARGS((WINDOW *win, char *title)); void wsetorigin ARGS((WINDOW *win, int h, int v)); void wshow ARGS((WINDOW *win, int left, int top, int right, int bottom)); void wchange ARGS((WINDOW *win, int left, int top, int right, int bottom)); void wscroll ARGS((WINDOW *win, int left, int top, int right, int bottom, int dh, int dv)); void wfleep NOARGS; void wmessage ARGS((char *str)); void wperror ARGS((char *name)); bool waskstr ARGS((char *prompt, char *buf, int buflen)); int waskync ARGS((char *question, int dflt)); bool waskfile ARGS((char *prompt, char *buf, int buflen, bool newfile)); void wsetcaret ARGS((WINDOW *win, int h, int v)); void wnocaret ARGS((WINDOW *win)); void wsettimer ARGS((WINDOW *win, int deciseconds)); MENU *wmenucreate ARGS((int id, char *title)); void wmenudelete ARGS((MENU *mp)); int wmenuadditem ARGS((MENU *mp, char *text, int shortcut)); void wmenusetitem ARGS((MENU *mp, int i, char *text)); void wmenusetdeflocal ARGS((bool local)); void wmenuattach ARGS((WINDOW *win, MENU *mp)); void wmenudetach ARGS((WINDOW *win, MENU *mp)); void wmenuenable ARGS((MENU *mp, int item, int flag)); void wmenucheck ARGS((MENU *mp, int item, int flag)); /* The following is only available in termcap stdwin: */ void wsetshortcut ARGS((int id, int item, char *keys)); #include "stdevent.h" void wgetevent ARGS((EVENT *ep)); void wungetevent ARGS((EVENT *ep)); void wupdate ARGS((WINDOW *win)); void wbegindrawing ARGS((WINDOW *win)); void wenddrawing ARGS((WINDOW *win)); void wflush NOARGS; void wdrawline ARGS((int h1, int v1, int h2, int v2)); void wxorline ARGS((int h1, int v1, int h2, int v2)); void wdrawcircle ARGS((int h, int v, int radius)); void wdrawelarc ARGS((int h, int v, int hrad, int vrad, int ang1, int ang2)); void wdrawbox ARGS((int left, int top, int right, int bottom)); void werase ARGS((int left, int top, int right, int bottom)); void wpaint ARGS((int left, int top, int right, int bottom)); void winvert ARGS((int left, int top, int right, int bottom)); void wshade ARGS((int left, int top, int right, int bottom, int percent)); int wdrawtext ARGS((int h, int v, char *str, int len)); int wdrawchar ARGS((int h, int v, int c)); int wlineheight NOARGS; int wbaseline NOARGS; int wtextwidth ARGS((char *str, int len)); int wcharwidth ARGS((int c)); int wtextbreak ARGS((char *str, int len, int width)); void wgettextattr ARGS((TEXTATTR *attr)); void wsettextattr ARGS((TEXTATTR *attr)); void wgetwintextattr ARGS((WINDOW *win, TEXTATTR *attr)); void wsetwintextattr ARGS((WINDOW *win, TEXTATTR *attr)); void wsetplain NOARGS; void wsethilite NOARGS; void wsetinverse NOARGS; void wsetitalic NOARGS; void wsetbold NOARGS; void wsetbolditalic NOARGS; void wsetunderline NOARGS; void wsetfont ARGS((char *fontname)); void wsetsize ARGS((int pointsize)); #include "stdtext.h" #endif /* GENERIC_STDWIN */ ----------------------- This was the file stdwin.h -------------------------- -- Freek Wiedijk <the pistol major> UUCP: uunet!mcvax!uva!freek #P:+/ = #+/P?*+/ = i<<*+/P?*+/ = +/i<<**P?*+/ = +/(i<<*P?)*+/ = +/+/(i<<*P?)**
bader+@andrew.cmu.edu (Miles Bader) (07/25/88)
The andrew toolkit (atk, aka be2) is window-system independent. It currently runs under X and cmu's home-grown windowing sytem; I've heard rumors that some has ported it to NeWS as well. -Miles
johnr@praxis.co.uk (John Richards) (07/25/88)
In article <732@muddcs.Claremont.EDU> lam@muddcs.Claremont.EDU (Grace Lam) writes: > >I am developing an interactive graphics program for viewing the structure >of software etc... The problem I face is porting around many hardware >platforms (ie. VAX-VMS, VAX-Unix, Sun, Apollo) and among multiple operating >and window systems (X, NEWS, Sun Windows, HP and others). The graphics will >be fairly normal stuff: zooming, panning, mutiple windows. > We are using ICpak-201 from Stepstone for exactly the same porting problem as you describe. ICpak-201 is written in Objective-C and will work with a number of window management systems because it has a layer (called 'Earthbase') which sits between it and the window system. We are actually using ICpak-201 to build a user interface on Suns which will be ported to Apollos, but it also has some graphics functions (pretty basic stuff - it's not GKS or PHIGS - you will have to write your own transformation functions) and we will be using it for graphics applications later. We looked at user interface toolkits at the end of last year and decided that Apollo's Open Dialog wasn't ready yet and the X Toolkit was too low-level and very buggy (though I believe it is much better now). We worried a bit at first about using Objective-C but have grown to like it. Currently, Earthbases exist for X10, SunView, Apollo DM and they say that X11 is in preparation. Once you have bought the software, you get all future Earthbases for nothing - in the worst case you could always knock one up yourself. Give Stepstone a ring on 203 426 1875. --- John Richards Tel: +44 225 444700 Praxis Systems plc Telex: 445848 PRAXIS G 20 Manvers Street, Bath, BA1 1PX, U.K. Fax: +44 225 65205 mcvax!ukc!praxis!johnr johnr%praxis.uucp@ukc.ac.uk John Richards
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (07/25/88)
We are also looking for a window toolkit for user interfaces. The primary feature we are looking for is the ability to quickly develop complex applications. We have used an internally developed package that lets you interactively lay out panels with buttons, sliders, etc. Unfortunately, this isn't adequate. We *Would* like an interactive, object oriented environment. We would also like to have a somewhat portable window system, running on common workstations. (Sun, Apollo, DEC, HP, Symbolics). The Symbolic's Presentation Manager is nice, but is too text oriented. Common Windows is close, but lacking in some respects. (i.e. no control panels). NeWS has some advantages, but without a toolkit it is difficult to develop complex applications quickly. Are there plans for a DEC, HP or Apollo port of NeWS from a third party? Does Apollo's openDialogue provide more than an interactive panel layout facility? What other packages are available? Followups to comp.windows.misc. I will summarize email responses, etc. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
barmar@think.COM (Barry Margolin) (07/28/88)
In article <4937@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: >We are also looking for a window toolkit for user interfaces. >The Symbolic's Presentation Manager is nice, but is too text oriented. Huh? The Presentation Manager allows arbitrary output to be associated with an object, e.g. (defun number-circle (number x y &optional (stream *standard-output*)) (dw:with-output-as-presentation (:object number :type 'number :stream stream) (graphics:draw-circle x y number :stream stream))) This displays a circle but it is treated as a number. While it isn't currently possible to make the default output format of a presentation type be graphical, the above mechanism provides most of the flexibility you need. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
david@geac.UUCP (David Haynes) (07/28/88)
In article <4937@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes: >We are also looking for a window toolkit for user interfaces. The >primary feature we are looking for is the ability to quickly develop >complex applications. We have used an internally developed package >that lets you interactively lay out panels with buttons, sliders, >etc. Unfortunately, this isn't adequate. > >We *Would* like an interactive, object oriented environment. > >We would also like to have a somewhat portable window system, >running on common workstations. (Sun, Apollo, DEC, HP, Symbolics). It seems to me that asking your window manager to supply all this is a bit much. As I see it, when people say "portable" they really mean that they do not have to re-write the code in order to get it from one system to another. The objective of the requirement of portability is one of cost --- the lower the better. However, if you are writing your application such that it depends on the tools of a particular window manager, you are effectively reducing your portability rather dramatically. In addition, you may be setting yourself up for "look and feel" problems from the point of view that your product does not have a "perceivable market difference". One of the ways around this is to add a layer of protocol between the application and the window manager. This is the approach taken by both NeWs and the X Windowing System. However, certainly in the case of X, I think that they have made an error in their way of implementing the Toolkit libraries. X causes the toolkit libraries to be linked in with the application code. This causes large applications which are only portable between X servers -- fair enough. But, what if I only have a few X servers and a few NeWs servers and a few dumb terminals to support? I would have to have my application written in X, NeWs (postscript) and, say, curses. Hardly a portable solution either. [To be fair, X does not force you to do things this way. It's just that this is the common way in which X is being used today] So, why not add layers of protocols between the application, something I will call the "agent" and the window manager? The agent in this case, could be something as simple as a forms manager, or as complex as a 3D graphics package. The point is this: Since the agents hold the knowledge of how a task is to be presented, the application has only to be concerned about how the data is to be manipulated. Again, since the window manager is concerned about how the data from the agent is to be physically converted for the display device, the agent is only responsible for determining how to format the data from the application in a virtual sense. What does this gain us? 1. Portability -- an application, speaking the correct protocol, would not have to be re-written to support either X or NeWs. 2. Clearer programs: Application code need only deal with the manipulation of data, not the presentation of data. 3. Customizability -- If you don't like a particular agent, substitute your own. 4. Growth -- As new systems become available, only the agents would have to be re-written (only is not a small thing however) In addition, the protocol can be grown as the requirements for it become more complex. Does it work? Yes, these comments are basically about a small system I and Stephen Lane developed here to test these ideas. Using the X Windowing System, we were able to develop an application for taking telephone messages using only 14 protocol commands from the application (eg: Load_form("telephone.msg");) Unfortunately, the plug was pulled on this before I could take it as far as I wanted to (sigh)... If anyone is interested in discussing this further (or wants to talk about data dictionaries for forms systems such as these) drop me a line. (Of course, if you want to hire me to continue on this concept, call collect ;-) ) -david-
jim@expo.lcs.mit.edu (Jim Fulton) (07/29/88)
> However, certainly in the case > of X, I think that they have made an error in their way of implementing > the Toolkit libraries. > > X causes the toolkit libraries to be linked in with the application > code. This causes large applications which are only portable between > X servers -- fair enough. X (i.e. the X Protocol) has nothing to do with whether or not a toolkit is linked into an application. Also, if one has shared libraries, even sophisticated applications aren't all that large. The X Toolkit was designed to take maximum advantage of the X Window System. People who want window-system independence, or who aren't running X, will probably want to choose another toolkit (such as Andrew, STDWIN, etc.) or design their own. It all depends on what one's definition of "portability" is, or more importantly, on what the requirements of the situation are. > So, why not add layers of protocols between the application, > something I will call the "agent" and the window manager? Ah, motherhood and apple pie! This "agent" is often called a User Interface Management Systems and is rapidly becoming one of the hotter topics for research and development. Lots of opportunities for Cognitive Scientists, Graphic Artists, and even Software Engineers. :-) Providing a good foundation for building UIMS's was one of the design goals of the X Toolkit. There are currently several commercially available UIMS's (e.g. X-Pression, Open Dialogue, XUI, New Wave, etc.) and I expect to see a flurry of new announcements over the next year. Jim Fulton MIT X Consortium
david@geac.UUCP (David Haynes) (07/31/88)
In article <4502@mit-vax.LCS.MIT.EDU: jim@expo.lcs.mit.edu (Jim Fulton) writes:
:> However, certainly in the case
:> of X, I think that they have made an error in their way of implementing
:> the Toolkit libraries.
:>
:> X causes the toolkit libraries to be linked in with the application
:> code. This causes large applications which are only portable between
:> X servers -- fair enough.
:
:X (i.e. the X Protocol) has nothing to do with whether or not a toolkit is
:linked into an application.
Yes, I recognized this and stated in the next paragraph that X did not
require you to do this, simply that this was the way it was being used.
I also recognize that X `The Protocol' is completely independant of
the particular implementation. However, I had hoped that the statement
about `implementing the Toolkit libraries' was clear enough in that
I was refering to the implementation not the protocol.
However, upon reflection, I think that `error in implementation' was
a poor choice of words. What I was trying to say was that the X
toolkit routines, being presented as linkable subroutines, were temping
many people to call them from directly within their client applications
and that, this may not be the best choice under my definition of
portability.
: Also, if one has shared libraries, even
:sophisticated applications aren't all that large.
Unfortunately, even today, that if is a pretty big one! Yes, I know
that all systems will tend toward shared libraries eventually, but,
some of us are trying to use the X system today (both protocol and
implementations) in `older' environments.
:The X Toolkit was designed to take maximum advantage of the X Window System.
:People who want window-system independence, or who aren't running X, will
:probably want to choose another toolkit (such as Andrew, STDWIN, etc.) or
:design their own. It all depends on what one's definition of "portability" is,
:or more importantly, on what the requirements of the situation are.
Again, we agree. For the article I was using `the ability to move to
other windowing systems with minimum effect on the application' as a
localized definition of `portability'.
:> So, why not add layers of protocols between the application,
:> something I will call the "agent" and the window manager?
:
:Ah, motherhood and apple pie! This "agent" is often called a User Interface
:Management Systems and is rapidly becoming one of the hotter topics for
:research and development. Lots of opportunities for Cognitive Scientists,
:Graphic Artists, and even Software Engineers. :-)
I was not willing to use the term IUMs initially since that term was
rather over-used and abused in the Office Automation market about
5 years ago. I built IUMs for curses-based screens at that time,
but was never really satisfied with them since, in my opinion, they
never really hit to the center of the problem. (which I will outline
at the end of this)
:Providing a good foundation for building UIMS's was one of the design goals of
:the X Toolkit.
And in this, I think you have succeeded! The fact that I could implement
so much of Prism (my UIM environment) with it lends strong credence to
the statement.
: There are currently several commercially available UIMS's (e.g.
:X-Pression, Open Dialogue, XUI, New Wave, etc.) and I expect to see a flurry of
:new announcements over the next year.
: Jim Fulton
: MIT X Consortium
Jim, somehow it appears that you have mistaken my comments to be an
attack of X (or the X toolkit at any rate). This was not my intention.
I am the Canadian X Software Repository moderator and support the X
system to its fullest. My comments were more a comment on the way in
which the X toolkit was being used by current implementors and how
their method of implementation required that their applications would
have to be substantially rewritten in order to move to another windowing
system. Good software is expensive to write once, let alone for each
type of bitmapped windowing system available.
Now, to the problem I alluded to: In building the prototype for Prism,
it quickly became apparent that, not only was there a need for a
separation of the precedural and the presentational aspects of the
data (this separation is the role of the UIMs), but another layer
of separation was required between the logical (symbolic) and the
physical representation of the data being manipulated by the program.
For example, Ingres has a textual data element which can store up
to 2000 characters (called text I believe), however, in an application,
I may have entites called `address' or `comments' which are of
type text for ingres but of type `string' for another database.
In addition, this logical description of the data is where I would
like to place my presentational information such as the fact that
a date is three numeric entities in the format dd/mm/yy.
Has anyone done any work on this logical entity to physical mapping
of data? For want of terminology, I have called the physical mapping
the data dictionary (which I believe is the correct term) and the
logical mapping to the data dictionary the `data definition'.
-david-
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Haynes
Geac Computers Canada Ltd. Telephone: +1 416 475 0525
350 Steelcase Road West, FAX : +1 416 475 3847
Markham, Ontario, CANADA. L3R 1B3 UUCP : utgpu!geac!david
Official Keeper of the Canadian X11 Sources Repository