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."
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?)**
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