[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New windows



On Tue, 22 Jun 1999, Revenant wrote:

> > On Mon, 21 Jun 1999, Christian Dysthe wrote:
> > > Instead I am again presented with the taskbar and popup menus that hasn't
> > > really changed for years. Is this to conquer new users, or is it becuase Linux
> > > users "secretly" have missed the look and feel of MS Windows?

> Well, this seems like the ideal opportunity for me to advertise my
> ignorance:
 
> What exactly is the difference between a window manager and a desktop
> environment?

A disclaimer:  I'm not part of the GNOME or KDE development effort.  I
don't really know where they're going so all this is just speculation.

A window manager manages windows.  (Duh!)  A desktop environment does
other things.

Look, the window manager does things like lets you position and resize
your windows and crud like that.  The desktop environment allows you to
interact with the system.  Whereas the window manager knows about icons
only so far as to allow you to interact with iconized programs, a desktop
environment knows about icons that do things like launch applications.

Is this a giant step backwards?  Hasn't this been done in Windows for
years?  Well, yes, if you limit yourself to Windows, there really isn't
much more there than having your UI be your file manager.  However, OS/2's
Workplace Shell (what I sincerely hope GNOME, at least, is trying to
achieve) shows that what you CAN achieve is a whole lot more than a
simple file manager.

With an object-oriented window manager, those icons on the desktop become
code that standalone applications can interact with in well-defined ways
that are moderated by the "environment".  (Actually, they're moderated by
the object broker, but that's a distinction without a difference for the
end user.)

What you end up with is something that's like OLE (now ActiveX) but where
the underlying system participates in the object model.  This can be
really incredibly neat because you can build "componentware" from it.

An example might prove useful:  One of the applications that I was working
on back when I still worked on OS/2 applications was a satellite tracking
system.  Under Windows, and "regular" X, such an application would
normally read a file with the satellite data (called "keplerians") and
then present the user with a list of kinds of things he might want
(AOS/LOS predictions, real-time tracking, and so forth.)  Even if the
internal structure of the program is MVC (Model-View-Controller) the
application still is a single, monolithic program.  It can't be embedded
or extended without knowing the details of the source.

With the WPS, what you do is create desktop objects for satellites and
ground stations.  These desktop objects include the data and code needed
to determine the position and motion of an object given the time and are
created through some sort of object creation process.  When you write your
application, you then don't need to include any satellite tracking stuff.  
Instead, you simply interact with those desktop objects (usually, but not
always, using some sort of drag-and-drop interface) and do whatever it is
you want to do.

The "environment" does things like moderating the interaction and
generating menus and such so that those objects are "first class" objects
in the system.  It also keeps track of the state of the system so you can
do something like declare one of the ground stations as the default
station since that's where you expect to be most of the time.

If the guy who defines the objects does his job correctly, and the
satellite and station objects are both derived from the same superclass,
other objects can be defined that also work with the original programs.  
An example might be an object that is like a station object, but whose
position is read from a GPS receiver rather than being fixed in space.

That means that someone else who sees a better way of presenting the
information but who doesn't know beans about the "universal variable
formulation" can create a better tracking program ("better" in the sense
that it fills some need better, has a better display, or whatnot)  and
it'll work just as well, in terms of tracking satellites, as the one
written by the orbital mechanics guru.  As long as the interface is
published, it's automatic.  Back before IBM (in effect) pulled the plug on
OS/2, the development tools were getting in to the act so that the
applications using the objects could be done in REXX or languages similar
to Visual BASIC(tm).

This is truly nifty and is truly a goal worth working towards even if it
results in systems that appear to be superficially similar to the the
craptacular stuff that come out of Redmond, WA.  That's why it's the sort
of thing _I_ would expect to see them working towards.  I wonder what they
expect to achieve.
-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Brokersys  +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA


Reply to: