Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Dec 1997 04:46:37 -0800
From:      Jonathan Mini <j_mini@efn.org>
To:        "Jordan K. Hubbard" <jkh@time.cdrom.com>
Cc:        Jonathan Mini <j_mini@efn.org>, The Classiest Man Alive <ksmm@cybercom.net>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Why so many steps to build new kernel?
Message-ID:  <19971215044637.29929@micron.mini.net>
In-Reply-To: <26106.881834408@time.cdrom.com>; from Jordan K. Hubbard on Thu, Dec 11, 1997 at 02:00:08AM -0800
References:  <19971211013734.16942@micron.mini.net> <26106.881834408@time.cdrom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard <jkh@time.cdrom.com> 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."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971215044637.29929>