Prior art invalidates Adobe's illegitimate patent. Adobe's lawsuit against Macromedia is FUD.
Don Hopkins
them alleging patent infringement is totally without merit.
Adobe's patent is invalid, because of prior art that they conveniently
neglected.
Adobe has no chance of winning their lawsuit in court, and as the developer
and publisher of some of that prior art, I will gladly testify against them.
Their offensive and ill conceived legal action against Macromedia should not
discourage Macromedia nor anyone else from using tabbed windows, or
improving on the concept.
Adobe is abusing the patent system and trying to unfairly inhibit progress
by spreading FUD (Fear Uncertainty and Doubt, aka malicious bullshit).
They should be ashamed of themselves, and drop the lawsuit immediately, and
fire the lawyers that gave them such horrible legal advice.
In no way does Adobe's patent and lawsuit benefit their any of their users
or shareholders.
In fact it's a huge waste of money and time, and has caused a great deal of
bad publicity and negative reactions against Adobe.
Adobe should invest its resources towards improving their products, instead
of throwing money away by paying foolish incompetent lawyers to file
illegitimate patents and frivolous lawsuits.
In 1988, UniPress Emacs version 2.20 for the NeWS window system shipped with
"tab windows" and "pie menus", that I implemented using the "Lite Toolkit",
which ran on Sun NeWS 1.1 and SGI 4Sight.
I published the source code for tab windows and pie menus on the internet
for free and unrestricted use (before the term "open source" was popular).
I later used Emacs with tab windows to implement an authoring tool for
HyperTIES, a hypermedia browsing/authoring research project developed in Ben
Shneiderman's Human Computer Interaction Lab, at the University of Maryland
College Park.
Later on I wrote and freely published several different implementations of
"tab windows", using The NeWS Toolkit version 1.0, 2.0, and 3.0.
They allowed you to drag the tab around to any edge of the window, lay the
windows out sequentially so they overlapped and each of their tabs was
visible, and you could bring any window to the top by clicking on the tab,
move the windows by dragging the tab, etc.
Sound familiar? It's called prior art. I believe it makes Adobe's patent
invalid.
Here's the reference to and a quote from a paper we published in 1991,
although we performed the research a few years before that (which explains
the words "Look Back" in the title).
-Don
Designing to Facilitate Browsing: a Look Back at the HyperTIES Workstation
Browser.
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, and
William Weiland.
Hypermedia, V3 #2, 1991
Page 115.
The more recent NeWS version of Hyperties on the SUN workstation uses two
large windows that partition the screen vertically. Each window can have
links and users can decide whether to put the destination article on top of
the current window or on thee other window. The pie menus make it rapid and
easy to permit such a selection. When users click on a selectable target a
pie menu appears (Fig. 1) and allows users to specify in which window the
destination article should be displayed (practically users merely click then
move the mouse in direction of the desired window). This strategy is easy to
explain to visitors and satisfying to use. An early pilot study with four
subjects was run, but the appeal of this strategy is very strong and we have
not conducted more rigorous usability tests.
In the author tool, we employ a more elaborate window strategy to manage the
15-25 articles that an author may want to keep close at hand. We assume that
authors on the SUN/Hyperties will be quite knowledgeable in UNIX and Emacs
and therefore would be eager to have a richer set of window management
features, even if the perceptual, cognitive, and motor load were greater.
Tab windows have their title bars extending to the right of the window,
instead of at the top. When even 15 or 20 windows are open, the tabs may
still all be visible for reference or selection, even though the contents of
the windows are obscured. This is a convenient strategy for many auithoring
tasks, and it may be effective in other applications as well.
CONCLUSIONS
The documents written with Hyperties have been used by hundreds of users at
demonstrations, and some components have been studied in controlled
experiments. A full usability study with a realistic application to compare
Hyperties/SUN documents with other electronic forms or paper is a desirable
goal. We believe that the components are important contributions and
encourage other developers to try them and refine them further.
We see further opportunities for improving the hypertext browsing
environment with ideas such as multiple indexes to permit partitioning of
large databases, graphic browsing capabilities (not a node-link diagram, but
a higher level representation), various bookmarks, and still larger,
sharper, and faster displays. Improved search facilities would include
flexible string searching, search for graphic images, search within a
restricted distance from the current node, weighted search results,
intersections/unions of searches, and search by node-link structures. Our
recent efforts have been to develop structural analysis software tools and
metrics to provide authors with suitable feedback to better guide the
document creation process. The future of hypertext will be brighter if the
user interface for browsing can be made more attractive and effective.
J. Cranmer
<xar...@mindspring.com> wrote:
>Macromedia is correct in their announcement that Adobe's lawsuit against
>them alleging patent infringement is totally without merit.
>Adobe's patent is invalid, because of prior art that they conveniently
>neglected.
Do you have the relevant patent numbers so we can read them.
John Cranmer
Robert Barnett
OS and not Windows or MAC. I am willing to bet that Adobe's patent only
applies to Windows and MAC in which case this guys argument is worthless.
Why on Earth would Adobe patent it for every operating system out there even
on ones that Adobe will probably never develop for.
Robert
"J. Cranmer" <john.cr...@ntlworld.com> wrote in message
news:l6kcpso57jopp8g4a...@4ax.com...
> On Sat, 12 Aug 2000 16:41:25 -0700, "Don Hopkins"
> <xar...@mindspring.com> wrote:
>
> >Macromedia is correct in their announcement that Adobe's lawsuit against
> >them alleging patent infringement is totally without merit.
> >Adobe's patent is invalid, because of prior art that they conveniently
> >neglected.
>
Robert Barnett
that just because this guy did it first and plastered the information all
over everything unless he patented the information he shit out of luck. The
US patent office would not have grated a patent for something that is
already patented. Therefore Adobe's law suite will do just fine as they hold
the patent for it.
Robert
"J. Cranmer" <john.cr...@ntlworld.com> wrote in message
news:l6kcpso57jopp8g4a...@4ax.com...
> On Sat, 12 Aug 2000 16:41:25 -0700, "Don Hopkins"
> <xar...@mindspring.com> wrote:
>
> >Macromedia is correct in their announcement that Adobe's lawsuit against
> >them alleging patent infringement is totally without merit.
> >Adobe's patent is invalid, because of prior art that they conveniently
> >neglected.
>
TacitR
>SUN OS and not Windows or MAC. I am willing to bet that Adobe's patent only
>applies to Windows and MAC in which case this guys argument is worthless.
That is incorrect. If you patent a design, idea, algorithm, process, or model,
that patent applies to every expression of that design, idea, algorithm,
process, or model.
For example, if I patent an algorithm for processing images, or if I patent a
user interface design, and my program runs on a Mac, my patent still prevents
you from using the same interface element or algorithm on ANY computer of ANY
sort, or even on a device or in a process that is not a computer at all! You
patent the IDEA or PROCESS, not a specific IMPLEMENTATION of that idea or
process.
>I would also like to point out that even if my last message is incorrect
>that just because this guy did it first and plastered the information all
>over everything unless he patented the information he shit out of luck.
>The US patent office would not have grated a patent for something that is
>already patented.
No. But if they do grant a patent, that patent is invalid if it exists in the
"prior art."
What is prior art?
Prior art is the sum total of the entire body of knowledge, methods, or
procedures already in existance.
Suppose I invent a widget or a program or algorithm, and I do not patent it.
Then, three years later, you come up with the same idea. You can not patent it,
because it exists in the "prior art"--that is, I invented it before you did.
An indexed, searchable online version of the entire text of the United States
Patent Law (35 USC) is available on the Web at
http://www.bitlaw.com/source/35usc/index.html
------
Onyx, the game of sexual exploration; Xero, the industrial magazine
of art, fiction and photography; and online photo gallery--all at
http://www.xeromag.com/franklin.html
willia...@my-deja.com
take this one up directly with Macromedia. I'm
sure they would welcome your knowledge.
William
Macromedia loyalist
In article <8n4ndg$4s7$1...@slb0.atl.mindspring.net>,
Sent via Deja.com http://www.deja.com/
Before you buy.
willia...@my-deja.com
you should take your knowledge directly to Macromedia, if you haven't
done so already.
Elizabeth Nelson is the CFO and secretary and would surely get you and
your info through the right legal channels. (415) 252-2000
William DeLey
Eminent Style
Macromedia Fan
J. Cranmer
<robert....@ickybits.com> wrote:
Unfortunately the US patent system is in such a mess over software
patents and to a lesser extent other patents that they can and do
grant patents for ideas already patented. I have come across this in
my line of work.
I would not be surprised if Adobe only has a US patent for this and
not a European one. European patents, while not perfect, arew much
better controlled.
Still no patent patent numbe to refer to though
John Cranmer
>I would also like to point out that even if my last message is incorrect
>that just because this guy did it first and plastered the information all
>over everything unless he patented the information he shit out of luck. The
>US patent office would not have grated a patent for something that is
>already patented. Therefore Adobe's law suite will do just fine as they hold
>the patent for it.
>
>Robert
>
>
>"J. Cranmer" <john.cr...@ntlworld.com> wrote in message
>news:l6kcpso57jopp8g4a...@4ax.com...
>> On Sat, 12 Aug 2000 16:41:25 -0700, "Don Hopkins"
>> <xar...@mindspring.com> wrote:
>>
>> >Macromedia is correct in their announcement that Adobe's lawsuit against
>> >them alleging patent infringement is totally without merit.
>> >Adobe's patent is invalid, because of prior art that they conveniently
>> >neglected.
>>
Keith Clark
"J. Cranmer" wrote:
> On Sun, 13 Aug 2000 16:56:41 GMT, "Robert Barnett"
> <robert....@ickybits.com> wrote:
>
> Unfortunately the US patent system is in such a mess over software
> patents and to a lesser extent other patents that they can and do
> grant patents for ideas already patented. I have come across this in
> my line of work.
Yes, like Cobalt patenting the shape "cube" and suing Apple for infringing their
patent by having the nerve to make a cube shaped computer.
I think it's high time someone sued the US Patent Office for incompetence.
Keith
Robert Barnett
interface elements should be patentable. There are just so many ways to do a
interface that is usable that patenting icons, palettes, etc. is a bit
stupid.
For example I don't think anyone would run out an patent the Kai's Power
Tool 3 interface's. At least I wouldn't for me those are not useable
interface's they are eye candy and not very good ones at that. They are
innovative, but not overly useable.
Robert
"Keith Clark" <clarkpho...@spiritone.com> wrote in message
news:3997E59C...@spiritone.com...
TacitR
Adobe's patent number is 5546528
Adobe Systems Incorporated
Patent US05546528: Method of displaying multiple sets of information in the
same area of a computer screen
Filed Date: June 23, 1994 Issued Date: Aug. 13, 1996
Abstract: A method for displaying on a computer screen multiple sets of
information needed on a recurring basis, comprising the steps of: (1)
Establishing an area on the computer screen in which the multiple sets of
information are to be displayed, the established area having a maximum size
which is substantially less than the entire area of the screen. (2) Providing
within the established area a plurality of selection indicators, one for each
of the multiple sets of information. (3) Selecting one of the multiple sets of
information for display within the established area by pointing to one of the
selection indicators within the established area, whereby the selected set of
information will be substituted within the established area for the set of
information previously being displayed therein. A selected set of information
may also be moved out of the selected area by pointing to its selection
indicator and dragging it away.
http://www.patents.ibm.com/details?pn=US05546528__
Don Hopkins
that idea?
-Don
"Robert Barnett" <robert....@ickybits.com> wrote in message
news:kpAl5.2140$bZ.1...@typhoon.sonic.net...
> The problem I have with this guys theory is that he is talking about the
SUN
> OS and not Windows or MAC. I am willing to bet that Adobe's patent only
> applies to Windows and MAC in which case this guys argument is worthless.
> Why on Earth would Adobe patent it for every operating system out there
even
> on ones that Adobe will probably never develop for.
>
> Robert
>
>
> "J. Cranmer" <john.cr...@ntlworld.com> wrote in message
> news:l6kcpso57jopp8g4a...@4ax.com...
> > On Sat, 12 Aug 2000 16:41:25 -0700, "Don Hopkins"
> > <xar...@mindspring.com> wrote:
> >
> > >Macromedia is correct in their announcement that Adobe's lawsuit
against
> > >them alleging patent infringement is totally without merit.
> > >Adobe's patent is invalid, because of prior art that they conveniently
> > >neglected.
> >
> > Do you have the relevant patent numbers so we can read them.
> >
> > John Cranmer
>
>
Don Hopkins
The text of the illegitimate patent is available from the Adobe site in
Acrobat format, of course:
http://www.adobe.com/adobefacts/patent.html
Macromedia's categorical denial of Adobe's frivolous patent infringement
claims is at:
http://www.macromedia.com/macromedia/proom/pr/2000/index_adobesuit.fhtml
-Don
"J. Cranmer" <john.cr...@ntlworld.com> wrote in message
news:l6kcpso57jopp8g4a...@4ax.com...
> On Sat, 12 Aug 2000 16:41:25 -0700, "Don Hopkins"
> <xar...@mindspring.com> wrote:
>
> >Macromedia is correct in their announcement that Adobe's lawsuit against
> >them alleging patent infringement is totally without merit.
> >Adobe's patent is invalid, because of prior art that they conveniently
> >neglected.
>
Dave
specific use. Working with a particular operating system could be an
example. I believe this is more the norm these days because it's
extremely hard to get a universal patent anymore.
Don Hopkins
"Robert Barnett" <robert....@ickybits.com> wrote in message
news:kpAl5.2140$bZ.1...@typhoon.sonic.net...
> The problem I have with this guys theory is that he is talking about the
SUN
> OS and not Windows or MAC. I am willing to bet that Adobe's patent only
> applies to Windows and MAC in which case this guys argument is worthless.
> Why on Earth would Adobe patent it for every operating system out there
even
> on ones that Adobe will probably never develop for.
>
> Robert
It's "Sun" not "SUN", and "Mac" not "MAC".
And Adobe develops software for the Sun and other platforms besides Mac and
Windows.
I don't know where you got the idea that patents only apply to particular
operating systems.
The patent system has been around for many years before operating systems
were "invented".
Patents are usually written to be as broad as possible, so even if it were
possible for a patent to only apply to particular operating systems, nobody
in their right mind would ever want to do such a thing. But then again,
there are a lot of crazy patents.
So the reason why on earth that Adobe would patent it for every operating
system out there is because their stockholders would sue them if they
didn't.
Robert, are you really willing to bet real money with me? I'll take you up
on that offer, whatever the amount!
Or was that just a turn of phrase?
-Don
Don Hopkins
prior art that invalidates Adobe's tabbed window patent.
The ironic thing is that it's a visual PostScript programming environment
for NeWS.
It's got an interactive PostScript interpreter window with a "spike"
sticking out of the top, that held all the objects on the PostScript stack,
like a short order cook's pile of orders. Each object had a tab (which you
could move to any edge of the object) and contained an editable tree view of
the object. You could push the object on the stack by dragging its tab onto
the spike, and manipulate the order of the objects on the stack by dragging
them up and down on the spike.
http://catalog.com/hopkins/psiber/psiber.html
Please note section 5.2, "Tab Windows".
-Don
The Shape of PSIBER Space:
PostScript Interactive Bug Eradication Routines
by Don Hopkins
Published in the Proceedings of the 1989 Usenix Graphics Conference,
Monterey California.
Abstract
The PSIBER Space Deck is an interactive visual user interface to a graphical
programming environment, the NeWS window system. It lets you display,
manipulate, and navigate the data structures, programs, and processes living
in the virtual memory space of NeWS. It is useful as a debugging tool, and
as a hands on way to learn about programming in PostScript and NeWS.
Introduction
"Cyberspace. A consensual hallucination experienced daily by billions of
legitimate operators, in every nation, by children being taught mathematical
concepts ... A graphic representation of data abstracted from the banks of
every computer in the human system. Unthinkable complexity. Lines of light
ranged in the nonspace of the mind, clusters and constellations of data.
Like city lights, receding ...."
[Gibson, Neuromancer]
The PSIBER Space Deck is a programming tool that lets you graphically
display, manipulate, and navigate the many PostScript data structures,
programs, and processes living in the virtual memory space of NeWS.
The Network extensible Window System (NeWS) is a multitasking object
oriented PostScript programming environment. NeWS programs and data
structures make up the window system kernel, the user interface toolkit, and
even entire applications.
The PSIBER Space Deck is one such application, written entirely in
PostScript, the result of an experiment in using a graphical programming
environment to construct an interactive visual user interface to itself.
It displays views of structured data objects in overlapping windows that can
be moved around on the screen, and manipulated with the mouse: you can copy
and paste data structures from place to place, execute them, edit them, open
up compound objects to see their internal structure, adjust the scale to
shrink or magnify parts of the display, and pop up menus of other useful
commands. Deep or complex data structures can be more easily grasped by
applying various views to them.
Figure 1, Simple Objects.
There is a text window onto a NeWS process, a PostScript interpreter with
which you can interact (as with an "executive"). PostScript is a stack based
language, so the window has a spike sticking up out of it, representing the
process's operand stack. Objects on the process's stack are displayed in
windows with their tabs pinned on the spike. (See figure 1) You can feed
PostScript expressions to the interpreter by typing them with the keyboard,
or pointing and clicking at them with the mouse, and the stack display will
be dynamically updated to show the results.
Not only can you examine and manipulate the objects on the stack, but you
can also manipulate the stack directly with the mouse. You can drag the
objects up and down the spike to change their order on the stack, and drag
them on and off the spike to push and pop them; you can take objects off the
spike and set them aside to refer to later, or close them into icons so they
don't take up as much screen space.
NeWS processes running in the same window server can be debugged using the
existing NeWS debug commands in harmony with the graphical stack and object
display.
The PSIBER Space Deck can be used as a hands on way to learn about
programming in PostScript and NeWS. You can try out examples from cookbooks
and manuals, and explore and enrich your understanding of the environment
with the help of the interactive data structure display.
2. Interacting with Data.
A PostScript object is a reference to any piece of data, that you can push
onto the stack. (The word "object" is used here in a more general sense than
in "object oriented programming." The words "class" and "instance" are used
for those concepts.) Each object has a type, some attributes, and a value.
PostScript objects are dynamically typed, like Lisp objects, not statically
typed, like C variables. Each object is either literal or executable. This
attribute effects whether the interpreter treats it as data or instructions.
Compound objects, such as arrays and dictionaries, can contain references to
other objects of any type. [Adobe, Red, Green, and Blue books] [Sun, NeWS
1.1 Manual] [Gosling, The NeWS Book]
2.1. Viewing Data
Objects on the PSIBER Space Deck appear in overlapping windows, with labeled
tabs sticking out of them. Each object has a label, denoting its type and
value, i.e. "integer 42". Each window tab shows the type of the object
directly contained in the window. Objects nested within other objects have
their type displayed to the left of their value. The labels of executable
objects are displayed in italics.
2.1.1. Simple Objects
Figure 1, Simple Objects.
Figure 1 shows some simple objects: an integer, a boolean, a literal string,
an executable string, a literal name, and an executable name -- the results
of executing the string "42 false (flamingo) (45 cos 60 mul) cvx /foobar
/executive cvx".
Strings are delimited by parenthesis: "string (flamingo)". Literal names are
displayed with a slash before them: "name /foobar". Executable names are
displayed in italics, without a leading slash: "name executive". Names are
most often used as keys in dictionaries, associated with the values of
variables and procedures.
2.1.2. Compound Objects
Compound objects, which contain other objects, can be displayed closed or
opened. The two basic kinds of compound objects are arrays and dictionaries.
Arrays are indexed by integers, and dictionaries are indexed by keys.
Figure 2, Compound Objects.
Figure 2 shows a literal array, an executable array, and a dictionary.
An opened compound object is drawn with lines fanning out to the right,
leading from the object to its elements, which are labeled as "index: type
value", in a smaller point size.
Literal arrays are displayed with their length enclosed in square brackets:
"array [6]". Executable arrays (procedures) are displayed in italics, with
their length enclosed in braces: "array {37}". The lines fanning out from an
opened array to its elements are graphically embraced, so they resemble the
square brackets or braces in the label of a literal or executable array.
PostScript arrays are polymorphic: Each array element can be an object of
any type. A PostScript procedure is just an executable array of other
objects, to be interpreted one after the other.
The label of a dictionary shows the number of keys it contains, a slash, and
the maximum size of the dictionary, enclosed in angled brackets: "dict
<5/10>".
The lines that fan out from opened dictionaries resemble the angled brackets
appearing in their labels.
Dictionaries associate keys with values. The key (an index into a
dictionary) can be an object of any type (except null), but is usually a
name. The value can be anything at all. Dictionaries are used to hold the
values of variables and function definitions, and as local frames,
structures, lookup tables, classes, instances, and lots of other things --
they're very useful!
The dictionary stack defines the scope of a PostScript process. Whenever a
name is executed or loaded, the dictionaries on the dictionary stack are
searched, in top to bottom order.
2.1.3. Classes, Instances, and Magic Dictionaries
NeWS uses an object oriented PostScript programming package, which
represents classes and instances with dictionaries. [Densmore, Object
Oriented Programming in NeWS] [Gosling, The NeWS Book]
When a class dictionary is displayed, the class name is shown, instead of
the "dict" type: "Object <10/200>". When an instance dictionary is
displayed, its type is shown as a period followed by its class name:
".SoftMenu <31/200>".
Figure 3, Class and Instance.
Figure 3 shows the class dictionary of Object, and the instance dictionary
of the NeWS root menu.
Magic dictionaries are certain types of NeWS objects, such as processes,
canvases, and events, that act as if they were dictionaries, but have some
special internal representation. They have a fixed set of keys with special
meanings (such as a process's "/OperandStack", or a canvas's "/TopChild"),
that can be accessed with normal dictionary operations. Special things may
happen when you read or write the values of the keys (for example, setting
the "/Mapped" key of a canvas to false makes it immediately disappear from
the screen). [Sun, NeWS 1.1 Manual] [Gosling, The NeWS Book]
Figure 4, Magic Dictionaries: Canvas. (PostScript: 4.ps)
Figure 5, Magic Dictionaries: Process. (PostScript: 5.ps)
Figure 4 shows a canvas magic dictionary (the framebuffer), and figure 5
shows a process magic dictionary, with some interesting keys opened.
2.1.4. View Characteristics
The views of the objects can be adjusted in various ways. The point size can
be changed, and well as the shrink factor by which the point size is
multiplied as the structure gets deeper. The point size is not allowed to
shrink smaller than 1, so that labels will never have zero area, and it will
always be possible to select them with the mouse. If the shrink factor is
greater than 1.0, the point size increases with depth.
The nested elements of a compound object can be drawn either to the right of
the object label, or indented below it. When the elements are drawn indented
below the label, it is not as visually obvious which elements are nested
inside of which object, but it takes up a lot less screen space than drawing
the elements to the right of the label does.
Any of the view characteristics can be set for a whole window, or for any
nested object and its children within that window.
Figure 6, View Characteristics. (PostScript: 6.ps)
Figure 6 shows some nested structures with various point sizes and shrink
factors, with elements opened to the right and below.
2.2. Editing Data
There are many ways to edit the objects displayed on the screen. There are
functions on menus for converting from type to type, and for changing the
object's attributes and value. You can replace an element of a compound
object by selecting another object, and pasting it into the element's slot.
There are also a bunch of array manipulation functions, for appending
together arrays, breaking them apart, rearranging them, and using them as
stacks. You must be careful which objects you edit, because if you
accidentally scramble a crucial system function, the whole window system
could crash.
2.3. Peripheral Controls
Peripheral controls are associated views that you can attach to an object,
which are not directly contained within that object. They are visually
distinct from the elements of a compound object, and can be used to attach
editor buttons, computed views, and related objects. Several useful
peripheral views have been implemented for manipulating various data types.
There are three types of numeric editors: the step editor, the shift editor,
and the digit editor. The step editor has "++" and "--" buttons to increment
and decrement the number it's attached to, by the parameter "Step". The
shift editor has "**" and "//" buttons to multiply and divide the number
it's attached to, by the parameter "Shift". The "Step" and "Shift"
parameters appear in the peripheral views as normal editable numbers, to
which you can attach other numeric editors, nested as deep as you like. The
digit editor behaves like a numeric keypad, with buttons for the digits 0
through 9, "Rubout", "Clear", and "+-".
The boolean editor has "True", "False", and "Not" buttons that do the
obvious things, and a "Random" button, that sets the boolean value randomly.
Since the button functions are just normal data, you can open up the
"Random" button and edit the probability embedded in the function "{random
0.5 lt}".
You can open up a definition editor on a name, to get editable references to
every definition of the name on the dictionary stack (or in the context to
which the enclosing class editor is attached).
The scroller editor allows you to view a reasonably sized part of a large
array or dictionary. The peripheral controls include a status line telling
the size of the object and how much of it is shown in the view, "Back" and
"Next" buttons for scrolling the view, and a "Size" parameter that controls
the number of elements in the view. You can edit the "Size" parameter of the
scrolling view by attaching a numeric editor to it, or dropping another
number into its slot, and it will take effect next time you scroll the view.
When you open a class editor, it attaches the following peripheral views:
"ClassDicts", an array of the class dictionaries, "SubClasses", an array of
a class's subclasses, "InstanceVars", an array of instance variable names,
"ClassVars", an array class variable names, and "Methods", an array of
method names. You can open up scrolling views on the arrays, and open up
definition editors on the names, and you will be able to examine and edit
the definitions in the class.
The canvas editor gives you a graphical view of the canvas's relation to its
parent, and an array of the canvas's children. You can grab the graphical
view of the canvas with the mouse and move the canvas itself around. You can
open up the array of child canvases (with a scroller editor if you like),
and attach canvas views to them, too.
Figure 7, Peripheral Controlers.
Figure 7 shows some digit editors, step editors, shift editors, a boolean
editor, and a canvas editor.
Figure 8, Class editor: rootmenu. (PostScript: 8.ps)
Figure 8 shows a class editor, some scroller editors, name editors, and
digit editors.
2.4. Printing Distilled PostScript
The data structure displays (including those of the Pseudo Scientific
Visualizer, described below) can be printed on a PostScript printer by
capturing the drawing commands in a file.
Glenn Reid's "Distillery" program is a PostScript optimizer, that executes a
page description, and (in most cases) produces another smaller, more
efficient PostScript program, that prints the same image. [Reid, The
Distillery] The trick is to redefine the path consuming operators, like
fill, stroke, and show, so they write out the path in device space, and
incremental changes to the graphics state. Even though the program that
computes the display may be quite complicated, the distilled graphical
output is very simple and low level, with all the loops unrolled.
The NeWS distillery uses the same basic technique as Glenn Reid's
Distillery, but it is much simpler, does not optimize as much, and is not as
complete.
3. Interacting with the Interpreter.
In PostScript, as in Lisp, instructions and data are made out of the same
stuff. One of the many interesting implications is that tools for
manipulating data structures can be used on programs as well.
3.1. Using the Keyboard
You can type PostScript expressions into a scrolling text window, and
interact with the traditional PostScript "executive," as you can with "psh"
to NeWS or "tip" to a laser printer. Certain function keys and control
characters do things immediately when you type them, such as input editing,
selecting the input, pushing or executing the selection, and completing
names over the dictionary stack (like "tcsh" file name completion).
3.2. Using the Mouse
The mouse can be used to select data, push it on the stack, execute it, and
manipulate it in many ways.
Pointing the cursor at an object and clicking the "Menu" button pops up a
menu of operations that can be performed on it. All data types have the same
top level pop-up menu (for uniformity), with a type specific submenu (for
diversity). There are lots of commands for manipulating the object and the
view available via pop-up menus.
You can select any object by clicking the "Point" button on it. A printed
representation of the current selection is always displayed in a field at
the top of the scrolling text window. If you click the Point button over an
object whose label is too small to read, it will appear in the selection
field, in a comfortable font.
Each object has its own button handler function that is called when you
click the "Adjust" button on it. The default "Adjust" handler implements
"drag'n'dropping". If you drop an object onto itself, its view toggles open
or closed. If you drop it on top of a compound object element, it is stored
into that memory location. If you drop it over an unoccupied spot, a new
window viewing the object appears on the deck.
Another useful "Adjust" handler simply executes the object that was clicked
on. This can be used to make buttons out of executable names, arrays, and
strings.
3.3. Using Dictionaries as Command Pallets
A PostScript dictionary can be used as a pallet of commands, by defining a
bunch of useful functions in a dictionary, opening it up, and executing the
functions with the mouse. You can open up the functions to see their
instructions, and even edit them!
3.4. Using a Text Editor
It is very helpful to be running a text editor on the source code of a
PostScript program, while you are debugging it. You can select chunks of
source from the text editor, and execute them in the PSIBER Space Deck (in
the appropriate context). This is especially useful for redefining functions
of a running program in memory, as bugs are discovered and fixed in the
source code. It saves you from having to kill and restart your application
every time you find a trivial bug.
5. The User Interface
5.1. Pie Menus
The mouse button functions and menu layouts were designed to facilitate
gestural interaction, to simulate the feel of tweaking and poking at real
live data structures.
There are several "pull out" pie menus, that use the cursor distance from
the menu center as an argument to the selection.
The pie menu that pops up over data objects has the commonly used functions
"Push," "Exec," and "Paste" positioned in easily selected directions (up,
down, and left). Once you are familiar enough with the interface to "mouse
ahead" into the menus, with quick strokes of the mouse in the appropriate
direction, interaction can be very swift. [Callahan, A Comparative Analysis
of Pie Menu Performance] [Hopkins, A Pie Menu Cookbook]
When you mouse ahead through a pie menu selection quickly enough, the menu
is not displayed, and the shape of a pac-man briefly flashes on the screen,
with its mouth pointing in the direction of the selected menu item. This
"mouse ahead display suppression" speeds up interaction considerably by
avoiding unnecessary menu display, and makes it practically impossible for
the casual observer to follow what is going on. The flashing pac-man effect
gives you some computationally inexpensive feedback of the menu selection,
and reassures observers that you are racking up lots of points.
5.2. Tab Windows
The objects on the deck are displayed in windows with labeled tabs sticking
out of them, showing the data type of the object. You can move an object
around by grabbing its tab with the mouse and dragging it. You can perform
direct stack manipulation, pushing it onto stack by dragging its tab onto
the spike, and changing its place on the stack by dragging it up and down
the spike. It implements a mutant form of "Snap-dragging", that constrains
non-vertical movement when an object is snapped onto the stack, but allows
you to pop it off by pulling it far enough away or lifting it off the top.
[Bier, Snap-dragging] The menu that pops up over the tab lets you do things
to the whole window, like changing view characteristics, moving the tab
around, repainting or recomputing the layout, and printing the view.
6. The Metacircular PostScript Interpreter.
A program that interprets the language it is written in is said to be
"metacircular". [Abelson, Structure and Interpretation of Computer Programs]
Since PostScript, like Scheme, is a simple yet powerful language, with
procedures as first class data structures, implementing "ps.ps", a
metacircular PostScript interpreter, turned out to be straightforward (or
drawrofthgiarts, with respect to the syntax). A metacircular PostScript
interpreter should be compatible with the "exec" operator (modulo bugs and
limitations). Some of the key ideas came from Crispin Goswell's PostScript
implementation. [Goswell, An Implementation of PostScript]
The metacircular interpreter can be used as a debugging tool, to trace and
single step through the execution of PostScript instructions. It calls a
trace function before each instruction, that you can redefine to trace the
execution in any way. One useful trace function animates the graphical stack
on the PSIBER Space Deck step by step.
The meta-execution stack is a PostScript array, into which the metacircular
interpreter pushes continuations for control structures. (forall, loop,
stopped, etc...) A continuation is represented as a dictionary in which the
state needed by the control structure is stored (plus some other information
to help with debugging).
It is written in such a way that it can interpret itself: It has its own
meta-execution stack to store the program's state, and it stashes its own
state on the execution stack of the interpreter that's interpreting it, so
the meta-interpreter's state does not get in the way of the program it's
interpreting.
It is possible to experiment with modifications and extensions to
PostScript, by revectoring functions and operators, and modifying the
metacircular interpreter.
The metacircular interpreter can serve as a basis for PostScript algorithm
animation. One very simple animation is a two dimensional plot of the
operand stack depth (x), against the execution stack depth (y), over time.
7. The Pseudo Scientific Visualizer
"Darkness fell in from every side, a sphere of singing black, pressure on
the extended crystal nerves of the universe of data he had nearly become...
And when he was nothing, compressed at the heart of all that dark, there
came a point where the dark could be no more, and something tore. The Kuang
program spurted from tarnished cloud, Case's consciousness divided like
beads of mercury, arcing above an endless beach the color of the dark silver
clouds. His vision was spherical, as though a single retina lined the inner
surface of a globe that contained all things, if all things could be
counted. "
[Gibson, Neuromancer]
Figure 9, Pseudo Scientific Visualizer: rootmenu. (PostScript: 9.ps)
The Pseudo Scientific Visualizer is the object browser for the other half of
your brain, a fish-eye lens for the macroscopic examination of data. It can
display arbitrarily large, arbitrarily deep structures, in a fixed amount of
space. It shows form, texture, density, depth, fan out, and complexity.
It draws a compound object as a circle, then recursively draws its elements,
scaled smaller, in an evenly spaced ring, rotated around the circle. The
deeper an object, the smaller it is. It will only draw to a certain depth,
which you can change while the drawing is in progress.
It has simple graphical icons for different data types. An array is a
circle, and a dictionary is a circle with a dot. The icon for a string is a
line, whose length depends on the length of the string. A name is a
triangle. A boolean is a peace sign or an international no sign. An event is
an envelope. A process is a Porsche.
It randomly forks off several light weight processes, to draw different
parts of the display, so there is lots of drawing going on in different
places at once, and the overlapping is less regular.
After the drawing is complete, the circular compound objects become mouse
sensitive, selectable targets. The targets are implemented as round
transparent NeWS canvases. When you move the cursor over one, it highlights,
and you can click on it to zoom in, pop up a description of it, open up
another view of it, or select it, and then push it onto the stack of the
PSIBER Space Deck.
Figure 9 shows a Pseudo Scientific visualization of the NeWS rootmenu
instance dictionary, also shown in figure 3 and figure 8.
Figure 10, Map of Adventure. (PostScript: 10.ps)
Figure 10 shows two views of a map of the ARPAnet, and you can even explore
the WWW PseudoScientific Visualization Map of the ARPAnet.
Figure 11, Map of ARPANET, around Berkeley IMP. (PostScript: 11.ps)
Figure 11 shows two views of a map of Adventure.
8. References
Abelson, Harold; Sussman, Gerald
Structure and Interpretation of Computer Programs; 1985; The MIT Press,
Cambridge, Mass. and McGraw Hill, New York
Adobe Systems
PostScript Language Tutorial and Cookbook (The Blue Book); 1985;
Addison-Wesley Publishing Company, Inc., Reading, Mass.
Adobe Systems
PostScript Language Reference Manual (The Red Book); 1985; Addison-Wesley
Publishing Company, Inc., Reading, Mass.
Bier, Eric A.; Stone, Maureen
Snap-dragging; SIGGRAPH'86 Proceedings; Page 233-240; 1986; ACM, New York
Callahan, Jack; Hopkins, Don; Weiser, Mark; Shneiderman, Ben
A Comparative Analysis of Pie Menu Performance; Proc. CHI'88 conference,
Washington D.C.; 1988; ACM, New York
Densmore, Owen
Object Oriented Programming in NeWS; November 1986; USENIX Monterey Computer
Graphics Workshop; Usenix Association
Gibson, William
Neuromancer; 1984; ACE Science Fiction Books; The Berkley Publishing Group,
New York
Gosling, James; Rosenthal, David S.H.; Arden, Michelle
The NeWS Book; 1989; Springer-Verlag, New York
Goswell, Crispin
"An Implementation of PostScript", in Workstations and Publication Systems;
Rae A. Earnshaw, Editor; 1987; Springer-Verlag, New York
Hopkins, Don
"Directional Selection is Easy as Pie Menus!", in ;login: The USENIX
Association Newsletter; Volume 12, Number 5; September/October 1987; Page 31
Hopkins, Don
A Pie Menu Cookbook: Techniques for the Design of Circular Menus; (Paper in
preparation. Draft available from author.)
Hopkins, Don; Callahan, Jack; Weiser, Mark
Pies: Implementation, Evaluation, and Application of Circular Menus; (Paper
in preparation. Draft available from authors.)
Reid, Glenn
The Distillery (program); available from ps-file...@adobe.com
Reid, Glenn; Adobe Systems
PostScript Language Program Design (The Green Book); 1988; Addison-Wesley
Publishing Company, Inc., Reading, Mass.
Shu, Nan C.
Visual Programming; 1988; Van Nostrand Reinhold; New York
Sun Microsystems
NeWS 1.1 Manual; 1987; Sun Microsystems; Mountain View, California
9. Acknowledgments
This work could not have been done without the greatly appreciated support
of the University of Maryland Human-Computer Interaction Lab, Grasshopper
Group, Sun Microsystems, and NCR Corporation.
Many thanks to Owen Densmore, Hugh Daniel, Mike Gallaher, John Gilmore,
James Gosling, Marja Koivunen, David LaVallee, Julia Menapace, Rehmi Post,
Brian Raymor, Glenn Reid, David Rosenthal, Robin Schaufler, Ben Shneiderman,
Josh Siegel, Stan Switzer, and Martha Zimet, people who gave me much
valuable advice, encouragement, feedback, and lots of neat ideas.
10. Index of Illustrations
Figure 1, Simple Objects.
Figure 2, Compound Objects.
Figure 3, Class and Instance.
Figure 4, Magic Dictionaries: Canvas.
Figure 5, Magic Dictionaries: Process.
Figure 6, View Characteristics.
Figure 7, Peripheral Controlers.
Figure 8, Class editor: rootmenu.
Figure 9, Pseudo Scientific Visualizer: rootmenu.
Figure 10, Map of Adventure.
Figure 11, Map of ARPANET, around Berkeley IMP.
Don Hopkins
> I think this is one state we can all agree on. Frankly, I am not sure that
> interface elements should be patentable.
I don't believe they should be, but the subject is certainly debatable.
>There are just so many ways to do a
> interface that is usable that patenting icons, palettes, etc. is a bit
> stupid.
The fact that there are a lot of different techniques, does not mean that
those techniques should not be patentable.
The real issues are much more complex than that.
> For example I don't think anyone would run out an patent the Kai's Power
> Tool 3 interface's. At least I wouldn't for me those are not useable
> interface's they are eye candy and not very good ones at that. They are
> innovative, but not overly useable.
Not "anyone" can run out an patent the Kai's Power Tools interface -- only
the original inventor or whoever owns the rights to their work.
So it's not "anyone's" decision whether or not to patent something, it's the
original inventor's (or whatever company the original inventor works for).
If somebody who isn't the original inventor applies for a patent, and it is
granted, then it's an illegitimate patent and it can be invalidated by
showing prior art.
Adobe is not the original inventor of tabbed windows, which is why I am
posting references to prior art that I developed: to help invalidate their
illegitimate patent.
-Don
Don Hopkins
patent system, or are you just saying it because it sounds to you like it
might be true?
Can you please tell me where you got that information, or post an example of
a patent that purposefully limits itself to particular operating systems?
Remember, operating systems have only been around for a short time compared
to the patent system, so there are no check boxes on the patent application
to say which operating system you want the patent to apply to. The patent
would have to limit itself explicitly.
Even if it's possible for a patent to limit itself to particular operating
systems, do you see any language in the Adobe patent that states it does not
apply to other operating systems as well, and do you really actually think
that my prior art does not apply to the patent because of that? Do you have
a theory for why Adobe would want to forfeit their rights for other
operating systems? If they were so altruistic, I don't believe they would
have bothered to apply for the patent in the first place.
-Don
"Dave" <moor...@home.com> wrote in message
news:399AF23B...@home.com...
Don Hopkins
> I would also like to point out that even if my last message is incorrect
Yes, your last message was deeply incorrect.
> that just because this guy did it first and plastered the information all
> over everything unless he patented the information he shit out of luck.
And that is also absolutely incorrect.
> The US patent office would not have grated a patent for something that is
> already patented. Therefore Adobe's law suite will do just fine as they
hold
> the patent for it.
>
> Robert
Adobe's frivolous lawsuit doesn't stand a snowflake's chance in hell,
because their patent is invalid.
The US patent office has granted many patents that have been invalidated
because of prior art.
Have you ever heard of Compton's New Media's patent on "Multimedia"?
There are many other examples.
Please don't post misinformation about subjects you know nothing about.
It's extremely rude to the thousands of people who you are misleading.
When you broadcast misinformation (like Adobe is doing with their press
release about their frivolous lawsuit and illegitimate patent), you force
people to correct you in public, which only wastes their time and makes you
look foolish.
-Don
Don Hopkins
making ad homin attacks against me in the third person.
Are any of the statements I made in my post inaccurate, or are you just
attacking me as a pain in the ass, because you have no better reply?
If I made a factual error, please address it, and provide references so we
can know where you're getting your information, and verify it ourselves.
I have posted the patent number. Have you actually looked it up and read it
yourself?
It personally annoys me when Adobe illegitimately patents something I
researched and published papers about years ago, then claims their work is
original and starts filing frivolous lawsuits.
So I hope I've only been a pain in the ass to people who are spreading
misinformation, like Mr. Barnett and Adobe's lawyers.
-Don
RossF
<robert....@ickybits.com> wrote:
>I don't know about anyone else, but this Mr. Hopkins is becoming a real pain
>in the ass. If he knows so damn much how come he is posting here and not
>part of the Macromedia legal team? Or, if he knows so damn much then why
>isn't he a patent lawyer?
>
>Robert
>
Seems he's just looking for an argument. Maybe Don has a right to be
pissed, I don't know. Whatever is decided will be decided in court, or
between lawyers who won't be seeking legal advice here.
Ross
Robert Barnett
in the ass. If he knows so damn much how come he is posting here and not
part of the Macromedia legal team? Or, if he knows so damn much then why
isn't he a patent lawyer?
Robert
"Don Hopkins" <xar...@mindspring.com> wrote in message
news:8nkatn$6fe$1...@slb6.atl.mindspring.net...