[Top][All Lists]

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


From: Adam Fedor
Subject: Re:
Date: Fri, 9 Jul 2004 22:07:52 -0600

On Jun 25, 2004, at 8:16 AM, MJ Ray wrote:

To retemplate a secondary page, currently, one uses a command like:

./scripts/reframe.scm infile.html secondary.html.template outfile.html

...with the LGPL'd MzScheme (from and newBSD'd SSAX (from ) installed. I've not yet fixed the whitespace hiccough. Can you tell me whether all of the above files are in scripts for you?

I tried this, and get:

Eldorado /Local/Software/gstep/web>./scripts/reframe.scm information/mission.html secondary.html.template o.html

Warning in /Local/Software/gstep/web/secondary.html.template at position 130 (DOCTYPE DECL html found and skipped)

Warning in /Local/Software/gstep/web/information/mission.html at position 165 (DOCTYPE DECL html found and skipped)
Picked main!
Picked title!
Found title!
Found main!

and the output is not like the input (it should be the same shouldn't it? Since I'm using the same template file that the input was supposedly generated with).

GNUstep Objectives

The GNUstep Objectives describe the 'official' position regarding the direction and goals of GNUstep.

API Objectives

GNUstep's goal is to create a free, superior development environment based on and inspired by the OpenStep standard developed by NeXT Computer Inc. (now Apple Computer Inc.) and the OPENSTEP implementation of this standard. Apple has continued to update this specification in the form of Cocoa and Mac OS X, and there is no hope of GNUstep guaranteeing that we shall maintain compatibility with an Apple API that is constantly changing.

Our target implementation for the core libraries is the OpenStep standard and OPENSTEP implementation. However, we do consider changes and additions to this API under the following circumstances.

  • We add methods and classes, either from Cocoa or our own extensions, if they add substantial value and don't interfere with OpenStep and/or Cocoa compatibility.
  • We won't remove things, even if they have been removed by Apple.
  • Where there is a real problem with a change, we find a technically superior work-around. In rare cases, this might involve a change in the original OpenStep API

Note that it is not the responsibility of the main developers to achieve or maintain Cocoa compatibility! We accept patches and bug reports that detail Cocoa additions and/or changes and we do our best to integrate these changes as long as they do not conflict with the previously stated rules.

We typically code to the most recent documented API we can find. Where the latest documentation actually conflicts with the original, the latest version generally wins. Better or more explicit Cocoa documentation wins over ambiguous OpenStep documentation.

In some cases, classes or parts of classes have been added that are clearly specific to a particular platform. Since we provide a cross-platform solution, we will probably not add these classes to our core libraries. Although we do accept submission of code for these classes and perhaps put them in a separate library

We may add non-standard extensions that people might find useful, although these are generally contained in a separate library.

We also may be able to provide more comprehensive or flexible solutions than are available in Mac OS X. In this case, classes or functionality may be missing from the core libraries, but may be available in other libraries.

For instance, instead of adding the 20 or so trivial scripting classes to the base/Foundation library for scripting, we have StepTalk, Rigs, and gnustep-guile.

Display Model

GNUstep has split the GUI into a front-end GUI "interface" and a backend window-server specific implementation. With this architecture it is possible to support several window-server backends (DPS, X, libart, Windows). Our main interest is supporting the Display PostScript drawing model (at least conceptually), but we may support other models in the future.

Look and Feel

While we are not fanatical about the look and feel of a system, one of the primary reasons we are all working on an OpenStep system is the superior design and consistent interface defined in the specification. We will generally avoid specifying a look for GNUstep, except where not doing so may degrade the consistency of the interface. However, the feel of the interface is more deeply embedded in the specification and we agree that this aspect of an interface design is vital to the aesthetic appeal and user-friendliness of a system. We in general like the NeXT GUI, at least the fact that it does provide a uniform look and feel, and will probably continue to support this style.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]