🚀 go-pugleaf

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

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."

> [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

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

In response to a couple of questions about SunView 2.0:

At the Usenix about a month ago there was public evening presentation
by the Sun staff people working on their window systems.  They said
that SunView 2.0 would be done on top of X "if possible".  They said
if possible because they were worried that they would find at the last
minute that there was some critical thing that couldn't be done
reasonably in X and had to use NeWS.  However the manager said that he
had a very strong desire to do the whole thing in X, and thought he
could do so.  I don't recall anyone asking specifically "What about
previous statements that SunView would be done in NeWS?" but from what
was said, it sounds like plans have changed.  No solid dates were
given, but one gets the impression of the merged X/NeWS server and
SunView 2.0 in the late fall, with possible slippage into the
beginning of 89, and the final NeWS development environment sometime
in early 89 with possible slippage to late 89.  So it looks like
there's a good chance that Sun will release a solid X before they
release a solid NeWS.  (I use NeWS 1.1 now and prefer it in many ways
to SunView and X, but until there is a terminal emulator equivalent in
performance and reliability to the SunView or X one, NeWS can hardly
be said to be solid.)

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

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

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

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

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-

>                                       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