UI: Qs to get the ball rolling

[Francois-Rene Rideau]

> First, what IS a UI, anyway?  Is there some part of an OS you can
> point to and say, "Ah, this is the UI!"?
   Hehe. And is there a point in the system that you can point to and
say "Ah, this is the OS!" ?
   UI, as OS, is a fuzzy concept. Only the ANS and other committees
think it can be settled clearly (some companies try to have customer
believe it too).

> To me, the UI is
> composed of everything involved with presenting a useful computing
> abstraction to the user (aka programmer).  So this could include a
> monitor, a mouse or keyboard, a sound card, a printer, a 3D rendering
> engine, a speech synthesis program, some interrupt routenes, etc..
> The point here is that depending on how liberal you are with your
> definition, the term UI could encompass dang near the entire computer.
> So the scope of the UI subproject is a bit of an issue.
   Exactly. It's a fuzzy, and relative concept, not a clear absolute one.
Some module is the UI to another one, but has got a module nearer the
human, etc, until we eventually reach the outermost, lowest-level layers.
The recursion is potentially indefinite, but never infinite (the nuance
is very important: indefinite is *not* infinite); it's well founded,
but different systems may have a very differently founded and more or less
deep foundation.


> For an example of the parallels between UI and non-UI things, consider
> what Fare has put forward (with pretty good-seeming support)--that the
> UI should concentrate more on getting things done, not how to get them
> done.  This is obviously very important to a revolutionary UI--if we
> want it to be one.  (I'd like that.  =)) But could it not be applied to
> other standard functions?
>[quicksort example]
   Exactly ! That's all the difference between being defining the object
components of the OS from a low-level, or from a high-level. In one
case, you describea particular construction of these, and you must
then adapt to this actual representation. In the other, you describe
the semantics of the objects, i.e. what really matters about them,
stripped of any implementational dependency; you then  have much more
freedom, portability, upgradability et al. Strip everything that isn't
meaningful, and let the implementors (compiler with human annotations)
implement it as efficiently as possible (reducing resource use as much
as the freedom we have allows; the less you overspecify, the more freedom
you have to implement well, and reimplement better on other architectures).

> The question I have is if there should be some universal way to do so.
   Yes. That's call higher-order programming. See the Coq computation
proof system. It's not very usable as a platform to program optimized
programs, and I don't know well enough about the new extensible syntax,
but it's got all the power to do it.


>[examples of the UI being generic, and existing UIs being specific
> instances for it]
> But at the same time, there must be a high degree of standards, so
> that a program/object created on one machine will not be totally
> irrelivant on the next.  At what level these standards take place, and
> how to do this, is a bit of a question.  Assuming our UIs are at some
> level event-based, do you write the application around the UI, having
> the program call some event-dispatch routene, or does the UI dispatch
> events at a higher level to the program?  I'd certainly vote for the
> latter--event-dispatch routenes are very non-OO.  I guess we need to
> abolish the whole concept of applications, and replace them with
> objects of varying integration levels.
   Yes, yes, yes !


> Is there a single API for all classes of applicaton/objects--business,
> graphics, arcade games, etc., or are different things availible for
> different uses?  And is the whole UI API monolithic, like (evil)
> UNIX kernels, or is it small and flexible, so that only the necesary
> parts are used?  The latter is obviously preferable, but can this be
> maintained while maintaining standards?  Stated another way: how can a
> UI be even-present enough to provide good standards, while not being
> monolithic, and against the TUNES philosophy?
   There's total freedom on that. We will provide fine-grained modules,
that depend on other modules, etc. Again, for a module to run, there
must be a well founding of it from the basic objects of the computer,
but locally, a module is as small as possible, and relies on other modules,
that must be given as parameters, and fulfill some requirements,
(algebraic relations between them), e.g. a stack's push and pop
operations verify some relations, etc. We'd have completely independent
modules, completely generic ones, and we combine them to obtain simply
object quite more powerful than existing monolithic UIs.
   Instead of having a large finite number of obfuscated objects, we'll have
a small number of simple ones, with infinite number of possible combinations.


> I guess now I should probably present some sort of direction to take
> this subproject in, so that we can actually do something.  =)  I guess
> one of the first things to know--before what things should look like,
> before how the APIs should work--is what classes of apps/objects we
> wish to support.  Do we want to cater to any particular kind, or are
> we going to be very general purpose?  Are we even going to support any
> of the traditional kinds of program?  We obviously need some way to
> compose text, for example, but modern word processors--those wonderful
> everything-but-the-kitchen-sink programs--are far from the way to
> solve the problem.  If we take a more modular approach to things, what
> level of modules does the user get to view?  It would certainly be
> anoying, in a word processer, to have to deal with each pixel as a
> seperate object.  =)
   It seems that the UI project goes from two directions:
* defining small standard generic modules, which is building the HLL standard
 library.
* building interfaces between existing low-level objects and the previous,
 that is, HLL specifications of these: accessing the video memory as an
 array, but with special functions satisfying some relations, etc...


> Please comment/trash/agree away....
   Agree !