Self-interest October 1990

self-interest@lists.selflanguage.org

17 participants
26 discussions

Abstract views
by R James Noble 30 Oct '90

30 Oct '90

The problem with abstract views (in terms of an concrete artificial reality interface) is that (unlike the current interface, where although ab ox can represent the root of a tree of objects, they are not actually drawn) for most abstract views, the contained objects will be pictured, often in their own abstract views. For example consider a fishtank with various fish inside it. Each fish would be an object, a presumably a member of a set contained in one of the slots of the fishtank object. (Yes, fishtank could refine set. No, I don't want to open that can of worms). Obviously, if you allow multiple views, you could also have a view of the fish and tank and so on as object, as per the prototype interface. This presents no problems technically, but breaks the object identity constraint of the interface. The real fun begins if you allow editing operations on a higher-level representation, message sending to objects (or display the UI on a running program). The display must be updated to keep in step with the actions of the system. So if I edit the box representation of a fish, say, and change its species, I expect the higher level view to react appropriately (redisplay the fish in a different colour). Similarly, if I run a simulation of the fishtank, I expect both the higher level and lower level display keep in step with the lower level situation. David writes: > Your last question (about views) points out the toughest feature about reality -- > the absence of views. That's not a feature, it's a bug :-). It all depends whose reality and what you are trying to achieve. For example, most large and complex machines have multiple views built in to their control systems to oversee their operations. On the other hand, TV sets don't. (And if the problem is more than trivial, they are usually connected to a detailed, multiple view user interface). What I am doing is a research project in visualising and animating programs, what you are doing is a language user interface. kjx

1 0

Re: Self UI
by vme131!lsi4!jecel＠uunet.UU.NET 29 Oct '90

29 Oct '90

Bay writes: > In an artificial reality model, however, actions such as object creation and > slot addition most likely would not be achieved by conventional text editing: > you would probably grab some prototype object, clone it, and add or remove > slots as necessary by dragging slots onto or off the object. Editing code > (in methods) could conceivably also be done in a graphical way, though I > think it may almost always be easier to type the code conventionally. > Editing capabilities would be built in to the face of objects with code > (methods). James writes: > It seems to me that editing and cloning objects should be easy to add, > and unless someone comes up with a good graphical syntax for self code > (put blocks explicitly into separate objects :-), textual editing for > that seems the way to go. I agree that if we were to edit text to change objects we might as well use a terminal. I was thinking of editing high-level objects like Email or a painting. Changing objects by dragging boxes around counts as editing also. There are many graphical notations that could be adapted to represent Self code. The problem is that they would be usually harder to understand than text simply by being too large for us to take in all at once. The details would overshadow the whole more easily than in the compact text representation. One possibility is to use animation rather than static diagrams. It doesn't help you see the whole any better, but at least makes for less clutter. You could scroll forward and backward in time instead of scrolling around a huge flowchart. Supposing an interface with icons and menus ( I invented this before I saw Artificial Reality ) you could represent sending an object a message as highlighting the icon and popping up a menu from which the message selector is chosen. Since this isn't run-time, the result would be a new, generic icon whose name would be the name of the original object plus the message selector. Programming would look a lot like using the system, and code animations would always end with a single generic icon whose name would be the Self expression you would type to obtain the same result. Blocks could be placed in graphical blocks, although that might turn out to be inconvenient. Debugging would be exactly like programming animations, except that generic icons would be replaced with real objects. Experienced programmers would type Self expressions directly as the icon name, rather than go through the pop-up message charade. James writes: > Different views of objects are more tricky. The problem is that an > abstract view of a given object can be a view of that object and it's > component objects - that is, more than one low-level object. This > probably destroys the "integrity of object identity". An abstract view would really represent a collection of objects, but that is just the way things are! At the lowest level when I get a pointer to an object it really is a pointer to the root of a whole object tree. That the objects is not truly isolated - it contains other objects - doesn't mean it doesn't have a unique identity. David writes: > Your last question (about views) points out the toughest feature about reality-- > the absence of views. Yet, we do manage to function in the real world. > I remember when the TV repairman would use a mirror to see the front of the set > while he adjusted the back. There is a game I saw many years ago on an Apple II where you controlled a bug in a maze that was infested by killer ants. The maze was very complex and was entirely shown in the low resolution screen so the ants were barely a pixel in size. A rectangle always moved around your bug, however, magnifying that region some eight times. The total effect was that 15 seconds into the game you completely forgot about the funny floating lens and would have a single high-resolution maze in your mind. What if the high-level representation of a chip was a tiny layout in a fully functional editor. I could place a lens to get a close up view of what I was doing ( maybe even two or three lenses ) but I would be working on the chip. I know this is cheating - a lens is just a window, a tool. But it is a very special tool in that it draws your mind away from itself to the object being examined. It's implementation would be simple: mouse and keyboard events on the lens would be redirected to the appropriate point on the object, and rendering operations on the screen would be duplicated on the lens ( pixel magnification like that provided by an Open Windows utility would be useless ).

1 0

Re: self-organization
by ungar＠thoreau 26 Oct '90

26 Oct '90

From trost%reed.BITNET(a)Forsythe.stanford.edu Fri Oct 26 14:22:52 1990 Return-Path: <trost%reed.BITNET(a)Forsythe.stanford.edu> Date: Fri, 26 Oct 90 14:21:51 PDT To: self-interest(a)self.stanford.edu Subject: self-organization Is there any style-guide for Self, and has anyone organized alternate styles? For instance, why do we put spaces between our parentheses and our vertical bars? What are good tabbing conventions? If I write a package to answer my mail for me, where in the (Self) world do I put it? Obviously, some of these ideas probably deserve experimentation, but maybe some of them have already been sort of worked out. Interesting! I'm afraid there is no written style guide, but there is the body of code to serve as examples. I put spaces in to avoid confusion when using small fonts ( (| can be hard to see ). Tabbing: we use four character indents (assuming 8--character tab stops) as a compromize between density and legibility. We generally put the closing bracket ("]" or "| )") at the same indent as the opening line, but put the closing paren of a method at the end of a line, to draw attension to the value returned by the method. We generally put the opening bracket or paren on the same line, rather than starting a new line because our taste runs towards density, I suppose. I guess all the superficial style issues seem completely subjective and a matter of artistic taste to me. But I would prefer a world in which I could read other's code without have to reindent it first. If you write a new application, you might put it's traits in the traits applications object, same for its prototypes and oddballs. Or, if there are prototypes or traits that no one will ever need to reuse, you can put them in more obscure places. Anyway, those are my thoughts, given that half of my brain is still in another country. What do others think? David

1 0

self-organization
by trost%reed.BITNET＠Forsythe.stanford.edu 26 Oct '90

26 Oct '90

Is there any style-guide for Self, and has anyone organized alternate styles? For instance, why do we put spaces between our parentheses and our vertical bars? What are good tabbing conventions? If I write a package to answer my mail for me, where in the (Self) world do I put it? Obviously, some of these ideas probably deserve experimentation, but maybe some of them have already been sort of worked out.

1 0

test
by bay 26 Oct '90

26 Oct '90

test

1 0

Re: My impression on Self
by bay＠amuck 26 Oct '90

26 Oct '90

Thanks for your comments (Sept 11) on Self. > From my experience you cannot make a snapshot on a sun4 and run it later > on a sun3, this was disappointing as I am addicted to Smalltalk-80. This > may be an area for future work, although it may be quite a bit of work. Snapshots should be independent of sun3/4 architecture. I'm not sure why this wasn't working for you; perhaps it had to do with the ui/snapshot bug that you mention below. > More problematic is that I'd like to start the graphic stuff (UI at least) > in monochrome even if I am on a color fb. This saves a looooootttttttt of > memory when it's a scarce ressource and when you swap over the net. This would be definitely be a good feature. The next generation UI should have a flexible enough graphics hierarchy to permit this trivially. In addition, the UI caches bitmaps to speed up future allocations, but I think the scheme it uses now may hurt more than it helps in some situations. I'll let you know if we add monochrome support for color fb's. > One more bad thing is that when you've loaded the ui stuff started it, then > back to the command mode, making a snapshot sometimes produces bad files > which cannot be run later. I'll compile more info on it if possible. Thanks for the hint on this bug. I've tracked it down--it had to do with referencing a dead pixrect pointer. Contact me if you're interested in the fix. Bay

1 0

Re: My impression on Self
by bay 26 Oct '90

26 Oct '90

1 0

Re: Self UI
by R James Noble 25 Oct '90

25 Oct '90

There are several interesting issues (to me, at least) that this discussion concerning the prototype UI has raised. Jecel has raised several points, most of which Bay replied to - and this is my $0.02. It seems to me that editing and cloning objects should be easy to add, and unless someone comes up with a good graphical syntax for self code (put blocks explicitly into separate objects :-), textual editing for that seems the way to go. Different views of objects are more tricky. The problem is that an abstract view of a given object can be a view of that object and it's component objects - that is, more than one low-level object. This probably destroys the "integrity of object identity". The same problem may occour with simultaneous different views of the same object - however this may be more amenable to a "user interface design" solution such as using multiple panes in a single window for a single object, and then seperate windows for seperate objects. The final item is the possibility of sending messages to objects - that is, maintaining a good display of these multiple windows on multiple objects as the world they are displaying changes about their ears (without, of course, degrading the performance of the system). This is possible, but I don't think it's just a part of a language browser yet. James

1 0

Re: Self UI
by bay 23 Oct '90

23 Oct '90

Jecel writes: > I keep wondering how you can have traditional editing capabilities in Self > Artificial Reality. Maybe I am missing the point entirely and you don't > need editors, is that it? Well, I agree that some sort of editor is probably still needed. The paper "Experiencing Self Objects" describes the prototype Self UI, as included in the release. This prototype merely allows browsing and inspecting of objects, with no support for creating objects, adding slots, or editing code. Of course, in a full UI these functions must be supported. In an artificial reality model, however, actions such as object creation and slot addition most likely would not be achieved by conventional text editing: you would probably grab some prototype object, clone it, and add or remove slots as necessary by dragging slots onto or off the object. Editing code (in methods) could conceivably also be done in a graphical way, though I think it may almost always be easier to type the code conventionally. Editing capabilities would be built in to the face of objects with code (methods). Jecel also brings up the question of different "views" of objects in the UI. The representation of objects in the UI currently is a very low-level one, and it would be useful to have alternative representations that may be determined by the kind of object. For example, a collection object could have a representation that was some sort of container holding the element objects. Since we seek to maintain a one-to-one correspondence between Self objects and their representations in the UI, these high-level representations would not be a separate object on the screen, but the same object that would perhaps mutate itself on command from low-level rep to high-level rep. Or as Jecel suggests, would turn to reveal another face, which would be the high-level rep. > When I design integrated circuits I like to open multiple coordinated > windows on the same layout showing different parts at the same time. This > would be impossible in the last paragraph's model. Being able to compare two views of the same object at the same time certainly has advantages in some circumstances. I suspect that there are ways to achieve this while still maintaining the integrity of the object identity. The sense of identity of the Self object is crucial in our UI, we believe, because the immediacy of the object helps dissolve some of the subtle barrier that any interface necessarily introduces. Bay

1 0

Self UI
by vme131!lsi3!jecel＠uunet.UU.NET 23 Oct '90

23 Oct '90

I found the paper "Experiencing Self Objects" by B. Chang and D. Unger on the SELF user interface a refreshing departure from the current GUI clone wars. I had some ideas for a Self interface, but they are much more conventional. Every Self object would be an icon on the screen. You could send them messages by placing buttons on them and "pressing" the buttons ( in ARK style ). You would edit the objects by creating views on them. These views would have view- traits and the object as parents, so they would really be extensions of the object they represent. Sending a message to a view would send it to the object ( unless view-traits or the view itself implemented it ). There are no LOAD/SAVE semantics in this model as the view is tied to a single object during it's lifetime - so it is a little more concrete than a conventional tools model. I keep wondering how you can have traditional editing capabilities in Self Artificial Reality. Maybe I am missing the point entirely and you don't need editors, is that it? I think that editors could be added to the current UI without spoiling the object's single indentity if we could "look under" the objects. When you clicked on an object it would flip over ( in 3D space :) and reveal an entirely different look-and-feel. If you flipped it over once more you might see yet another appearance and behavior ( another editor ). Just a few more turns through the object's many faces and you would be back to the good old boxes and arrows face. If done properly, the result would be a single, solid object in the user's mind. When I design integrated circuits I like to open multiple coordinated windows on the same layout showing different parts at the same time. This would be impossible in the last paragraph's model. Must I give up this feature? - Jecel - University of Sao Paulo - Brazil

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest October 1990