Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Rebol Fluid

From: chaz:innocent at: 10-Dec-2000 2:49

You were talking about a REBOL "Fluid", how about an "Sea"? There's a group called KOSH, "Kommunity Operating System and Hardware" and they're trying to figure out how to implement something they call the Object Sea . It would be a very different way of interacting with a computer. Seems to me that maybe this could be implemented using some kind of combination of REBOL/Command and REBOL/View... <crossposting> Date: Tue, 14 Nov 2000 17:48:18 -0500 From: Dave Haynie <[dhaynie--jersey--net]> To: "kosh List Member" <[kosh--chaossolutions--org]> Subject: [kosh] Ideas :) X-Mailer: Becky! ver 1.26.03 X-Return-Path: [List-Admin--chaossolutions--org] X-MDMailing-List: [kosh--chaossolutions--org] X-MDSend-Notifications-To: [List-Admin--chaossolutions--org] Reply-To: [kosh--chaossolutions--org] X-MDaemon-Deliver-To: [chaz--innocent--com] On Tue, 14 Nov 2000 23:22:03 +0100 (CET), Marcus Petersson <[d4marcus--dtek--chalmers--se]> jammed all night, and by sunrise was overheard remarking:
> On Sun, 12 Nov 2000, chaz wrote: > > Tell me a story, paint a picture in words, of what the Object Sea would > > "look" like to a user in front of it. > That's a pretty large request, but I guess it has been long overdue. :-)
Well, I think, from the casual user's point of view, the Object Sea is not really something normally all that obvious. After all, are you necessarily presented with functions, procedures, and libraries in the normal, user-level experience in AmigaOS, Windows, MacOS, Linux, etc?
> Basically, the Object Sea is a collection of objects. You can have many > different views of it. One view is the hierarchial one - it's a tree with > a root, branches and leaves (or nodes). The root object is the grandparent > of all other objects, and in a way it also contains all of them. This is > actually what we call the Object Sea (or Cybersea as it's called elsewhere > - a silly name in my opinion).
I coined the "Object Sea" phrase, that's how I've thought of the concept for the last 10 years or so. Anyone's free to come up with a better description. Anyway, for programmers, what you say is somewhat true, in that classes are objects (at least in my model). But in a user's experience, you can still think of "files" if you like. An object sea based OS could still seem to have a perfectly ordinary user file structure. The difference is salient, but perhaps not something the user ever cares about. In fact, one major point of the object sea idea is to make things easier on the user. Since everything is, in fact, an object, the user can directly do things with any object, and something meaningful nearly always happens. For example, if you click on an object, it'll probably either run or display itself. If you drop a data object into a running program, it'll try to do something useful -- directly, if the application knows that object interface; via system level translators if this isn't the case (for example, you could write a translator that does "image to text", and from then on, any text file dropped into a graphics program would render graphically as text, best as possible). Stuff that, really, lives above the object sea would give rise to the user's interactive experience. For example, what's the default action when you click on a data object? In the Mac and BeOS world, this is usually going to mean "launch the 'parent' application". But I don't believe in parent applications; or more specicially, single ones. I guess that's something I learned on the Amiga with graphics, and continue to experience on the PC. So I would have the default method be "display" (technically, you're sending a "mouse-click" method to the object, but most will translate this into object-centric default actions). When you call up a "display", you get what I call a "pad", a very basic box for holding some kind of image, movie, sound, etc -- less than a window. If you just clicked on a JPEG, you'd get that pad in a window. If you dropped it into an application, the OS would provide the message of object dropping. If the app handles the object type directly, it gets the object. Otherwise, the OS builds a pad for that, which is handed to the application (most applications would handle pads). When you have a pad, anywhere, objects can be dropped into it, too. For example, if I clicked on that JPEG alone, I would have a pad with the JPEG image running in it. Let's say I then drag a "DPaint XIII" object into that pad. The expected result would be that the DPaint tool bars dock on an edge of that pad, and immediately, the image is made much more active, under the rules of DPaint. If I then dropped "Imagine 10" onto the pad, it, too, would fire up its control panel. Multiple apps on the same pad would grow some kind of "activation box" -- you'd click on that to make the associated app the one immediate to the pad (after all, you can't have two sets of rules applied, unless they're somehow complementary applications -- in a sense, a master and a plug-in).
> Every other object is a child of a parent object, it inherits its parent's > propererties, but usually also include some characteristics of its own.
Well, yes and no. A class object contains a mix of data and methods, which you could calls its characteristics. Class objects create instance objects, which typically add additional, instance-specific data, but rarely new functions. These are instances of said class object, not children. You can also create a new class object which inherits methods and global data from one or more existing class objects, and extends these in some way, either by making an interesting mesh of multiple classes, or perhaps adding new, more focused/specific, or just plain different methods. This is what you'd probably call a child object.
> The common user collection object is called a set. It differs from a > directory foremost in being an object (which can be powerful enough), but > also in that it can have attributes.
Here, I disagree. For one, a "set" has certain mathematical connotations I don't think you want here. A very, very basic feature of my abstract object model, which gave rise to the whole object sea concept, is the notion of container objects: you can have an object which can hold, in some reasonable way, other objects. Methods on a container object can be things like add, delete, list, sort, etc. More sophisticated operations include things like method broadcast (eg, send a method to every object in the container), which forms the basis for "translucent" containers. In a translucent container, the the container plus contained takes on something of the appearance of an object of both classes, but of course, it's dynamic. The simplest type is basically a container than handles its own methods but broadcasts all methods it doesn't understand. When you have container objects, and you know that everything stored on disc is inherently an object, it's easy to see that the equivalent of a directory in a file system is nothing more than a container object, perhaps optimized for some specific use. -- Dave Haynie | V.P. Technology, [Met--box] AG | ------------------------ To unsubscribe - post to [mdaemon--Chaossolutions--org] with Unsubscribe kosh as the only line in the body. Problems, complaints - [List-Admin--chaossolutions--org] Web site - </crossposting> At 09:05 PM 12/6/00 +1300, you wrote: