From owner-freebsd-hackers Mon Dec 15 04:46:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA23823 for hackers-outgoing; Mon, 15 Dec 1997 04:46:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA23813 for ; Mon, 15 Dec 1997 04:46:53 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id EAA27121; Mon, 15 Dec 1997 04:46:38 -0800 (PST) Message-ID: <19971215044637.29929@micron.mini.net> Date: Mon, 15 Dec 1997 04:46:37 -0800 From: Jonathan Mini To: "Jordan K. Hubbard" Cc: Jonathan Mini , The Classiest Man Alive , freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Reply-To: Jonathan Mini References: <19971211013734.16942@micron.mini.net> <26106.881834408@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <26106.881834408@time.cdrom.com>; from Jordan K. Hubbard on Thu, Dec 11, 1997 at 02:00:08AM -0800 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > Give me something that's written in straight C and easy to wrap into > TCL (which should be possible unless you decide to pass all kinds of > nasty structures around and expose that in the C API) and I'll be your > friend for life. OK, so maybe that doesn't sound like such a treat, > so let me just say that I'd really really appreciate it and so would > many others. :) I've never used Tcl, so I don't know what kind of exportability it has, but the following system (which I'm planning on using for a network exportable GUI) should be exportable to practically any langauge. The following system may seem a little overkill, but I'm writing it for another project, (I have to write a development kit to ship with my game, and it needs it's own GUI, there are other things in that product that need it also) you're baiscally getting half of it for free. (yay :)) This GUI is split into four layers, while one layer is technically the "application," and may or may not count in your book, it's still there. :) The layers are the device layer, the interface layer, the transport layer and the application layer. The device layer implements sources for events (this is an event-driven system, of course) from actual real-world devices, such as timers, a keyboard, a mouse, whatever. It is responsible for interfacing with the world, so to speak. The other thing the device layer does is display objects. Objects are an encapsulation structure which can represent (and does represent) every item in the GUI. When an object needs to be displayed, an event is generated and (eventually) sent to the display layer, which then displays it. Obviously, this means that the display layer must know how to draw every possible kind of object, and that everything which could possibly be displayed on-screen must be representable in the form of an object. The second layer, called the interface layer, actually handles the user interface itself. That is, it responds to events by either rearanging objects, filtering those events, or generating new events. Although it does nothing directly with either the user or the application, it is the essence of the user interface, and defines all of its behaviour. (well, most of it) The third layer, called the transport layer, holds two jobs : + The first is like what a window manager does for X. It manages windows and other similar groups of objects in ways that are transparant to both the objects themselves and the application. + Secondly, it manages the transportation method between the actual user interface (embodied by the display layer and the interface layer) and the actual application. This layer can talk to any of the other layers, and in some cases re-arranges the layering. For exameple, the transport layer is repsonsible for doing things like exporting the user's devices to (possibly) multiple clients. To do this, it takes the place of all of the lower layers for the client, and all of the upper layers for the server. The fourth, and final, layer is the application itself, or more rightly, the interface the application has to the UI system. (i.e. the application's API) Because this layer is above the transport layer, it could be anything. It is feasable to implement the fourth layer using a pipe which sends events back and forth as text strings. With that method, a Bourne shell script could be the final application, so I don't think Tcl will have any problems. > What do you think? Not next Tuesday, but I'll (hopefully) have a version working in a month. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."