[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL-Leaders: Berlin GUI info
------- Forwarded Message
Return-Path: mmessier@prilnari.com
Received: from pop3.aracnet.com (localhost [127.0.0.1]) by router.omegacs.com (8.8.5/8.6.12) with SMTP id JAA01058 for <omega>; Wed, 13 Aug 1997 09:25:02 -0700
Received: from scorpion.aracnet.com for omega
with Cubic Circle's cucipop (v1.10 1996/09/06) Wed Aug 13 09:25:02 1997
X-From_: owner-berlin@prilnari.com Wed Aug 13 07:40:46 1997
Received: from bob.prilnari.com (majordom@bob.prilnari.com [207.60.233.33])
by scorpion.aracnet.com (8.8.5/8.8.5) with ESMTP id HAA24278
for <omega@aracnet.com>; Wed, 13 Aug 1997 07:40:42 -0700
Received: (from majordom@localhost) by bob.prilnari.com (8.7.5/8.6.12) id KAA20559 for berlin-outgoing; Wed, 13 Aug 1997 10:19:15 -0400
X-Authentication-Warning: bob.prilnari.com: majordom set sender to owner-berlin@prilnari.com using -f
Received: from norman.prilnari.com (mmessier@norman.prilnari.com [207.60.233.34]) by bob.prilnari.com (8.7.5/8.6.12) with SMTP id KAA20556 for <berlin@prilnari.com>; Wed, 13 Aug 1997 10:19:11 -0400
Date: Wed, 13 Aug 1997 10:18:14 -0400 (EDT)
From: Matt Messier <mmessier@prilnari.com>
To: The Berlin Consortium <berlin@prilnari.com>
Subject: Window Managers and widgets
Message-ID: <Pine.LNX.3.96.970813100344.13505A-100000@norman.prilnari.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-berlin@prilnari.com
Precedence: bulk
Reply-To: berlin@prilnari.com
Berlin will not be implementing a window manager a la X. Berlin will also
not be implementing widgets a la Windows. Berlin will be implementing
something that is a cross between the two and OS/2's PM.
Widgets will be pluggable. The Registrar will contain information about
what widget sets you wish to use. Let's consider a bare frame window.
A frame window is a window that has a sizing border, titlebar, system menu,
and close/iconify/maximize(restore) buttons.
Windows implements such a window as a single window with the OS doing the
underlying implementation for the frame controls. It paints them, handles
user interaction with them, etc. X windows implements these through the
window manager. OS/2 implements these as four separate windows, and a
fifth that is the client area of the window.
Berlin will implement such a window as OS/2 does -- five windows. The
library where the code resides to manage these windows (paint, handle
mouse button clicks, etc.) will be defined by the Registrar (thus completely
configurable), and each window will be handled within the context of the
thread that created the frame window to start with.
So, you've got the configurability of a window manager. You can define your
own widget sets to behave as you want them to behave. You've got the cross-
app consistency in look and feel. So far, what you don't have is a central
authority cleaning up after a window that is unresponsive.
There will be other details in the lower-level implementation that will deal
with dead and unresponsive windows. The details are beyond the scope of
this list, and I don't have the time to explain them very well right now
anyhow.
The Berlin server will be quite different from the X window server. It will
also be different from the server used by Windows NT. If a window becomes
unresponsive, there are a couple of approaches that can be taken. First, you
can kill the offending application from a command window or pretty process
tree viewer. Or, when the GUI detects it, it can present the user with the
option of cleaning up the window. The second is what OS/2 does (although
you can also do the first on OS/2.)
When a dead window is detected, the Berlin server will have the ability to
clean up the window. Although not officially decided how this will be
handled from a user's point of view, a choice could be presented to the
user to destroy the window, hide the window until (or if) it becomes
responsive again, or leave the window alone. The exact means by which this
choice would be presented to the user is to be decided, but would probably
be done by way of the desktop through a message box.
Anyway, assuming that the user chooses to either hide or destroy the window,
the task would be taken care of by the Berlin server, and everybody would be
happy again. The cleaning up of dead windows that have an existing
application still tied to them will be done in much the same manner as
cleaning up windows owned by a process when the process dies without cleaning
up after itself.
+-----------------------------------------------------+
| Matt Messier | Phone: 401-726-4828 |
| Lincoln, RI, USA | PGP mail encryption OK |
|-------------------------+---------------------------|
| Finger mmessier@bob.prilnari.com for public PGP key |
+-----------------------------------------------------+
------- End of Forwarded Message
Erik Walthinsen - Programmer, webmaster, 3D artist, etc. __
__ / /\
/ \ omega@sequent.com Work: (503)578-5314 / / \
| | M E G A omega@aracnet.com Home: (503)281-4281 / / /\ \
_\ /_ psu12113@odin.cc.pdx.edu Majoring in CS / / /\ \ \
/ /_/__\ \ \
Omega Station: http://www.aracnet.com/~omega/ /________\ \ \
Info on Linux, Graphics, Descent, Laptops, etc. \___________\/
----------------------------------------------------------------------------
Simple End User Linux Leader Mailing list
----------------------------------------------------------------------------