[svlug] StarOFfice to be GPL'd, integrated with Gnome

[Karen Shaeffer]

On Thu, Jul 20, 2000 at 01:13:21PM -0700, J C Lawrence wrote:
> On Thu, 20 Jul 2000 20:00:02 +0000 (GMT) 
> Aaron Lehmann <aaronl at vitelus.com> wrote:
> 
> >> All NIX code should be crafted as such. Large application suites
> >> like Star Office could be architected in this manner, if they
> >> would have been thinking clearly. You should always have the
> >> capacity to take the core and use it without any dependencies on
> >> the GUI.
> 
> > How would you do Emacs like this?
> 
> What's missing in that diagram is the framework. 

Yes it is. 

> Instead it defines socket/pipes as the mandated framework.  While that'a
> a fair approach, its not great universally.

I explicitly said pipe or UNIX socket or some other IPC. There are other
forms of IPC and new variants will continue to evolve. So I did not mandate
anything other than the abstraction of core utilities and a GUI that will
communicate with core utilities. In point of fact, my architecture is
completely open. If you don't need IPC or prefer to set it up independently
between processes or threads or whatever, then you are free to do whatever
(see process Z below).

I would go further and mandate that the GUI can interact with users in any
way it sees fit. But it needs to have the capacity to facilitate the
creation of IPC channels, and, of course, this extends to an arbitrary
number of such processes:

  a.) between process A and the GUI as well as process B and the GUI and
      between process A and B via the GUI... Etc..

  b.) between process A and process B, and ... where the GUI gets out of
      the way, except for the capacity to relay user related signals to
      process A or B or both. This form is just a glorified shell with a
      graphical user interface. But it should incorporate all possible
      modes of communication between an arbitrary number of processes,
      including INET and any other OSI layer 2, 3, and 4 protocols. Why
      limit such a system to a desktop...


Here, b.) precludes any circular dependencies--because it should be
clear that process A and B could set this up without a need for the
GUI. Based on my perspective, the GUI is used by choice and gives you the
added benefit of a user interface.

OTOH, let's say you develop process Z, which has new and revolutionary ideas
and code incorporated into it's source tree. You can do whatever you want.
You can link with any other core without the GUI. But you can still
interact with the GUI as a simple user interface---without using any other
resources offered by the GUI.

The problem with GNOME is that it sees itself as being the center of all
development. It does not accept the reality that it should be limited to
facilitating a user interface and a framwork to communicate with core
processes. Period. The rest should be left to particular utilities. These
ideas can easily extend across various languages as well.


Dumping GNOME and KDE was a wonderful experience for me. I got my
computer back. I never actually *used* either GNOME or KDE--but they were so
resource intensive that I couldn't accept either on my systems. I highly
recommend this to everyone who enjoys computing.


> Emacs actually takes the same
> approach diagrammed, it just substitutes elisp and its surrounds for
> the framework.

I don't use Emacs but am completely agnostic towards it... More power to
the Emacs crowd--just don't force it on me. For that matter, more power to
the GNOME and KDE crowds--just don't force them on me.

c,
-- 
 Karen Shaeffer
 Neuralscape; Santa Cruz, Ca. 95060
 shaeffer at neuralscape.com  http://www.neuralscape.com