DE69522684T2

DE69522684T2 - Statusanzeiger einer graphischen benutzerschnittstelle

Info

Publication number: DE69522684T2
Application number: DE69522684T
Authority: DE
Inventors: A Jones; L Mayle; K Parsons; L Shalit; H Strassmann
Original assignee: Apple Computer Inc
Current assignee: Apple Inc
Priority date: 1994-05-19
Filing date: 1995-05-04
Publication date: 2002-06-20
Anticipated expiration: 2015-05-05
Also published as: EP0760117A1; AU2477595A; EP0760117B1; DE69522684D1; WO1995032462A1; US5644334A

Description

GEBIET DER ERFINDUNG

Diese Erfindung betrifft interaktive Benutzeroberflächen für Computersysteme und insbesondere Statusanzeiger einer anpaßbaren Browser-Grundstruktur für eine verbesserte graphische Benutzeroberfläche.

HINTERGRUND DER ERFINDUNG

Graphische Benutzeroberflächen basieren typisch~rweise auf graphischen Bitmap-Anzeigetechnologien, die figürliche (bildliche) Darstellungen, Text in typographiechem Stil irr mehreren Schriftarten und anderes Bildmaterial auf einem Anzeigebildschirm eines Computersystems verwenden. Diese Oberflächen enthalten eine Fenster(Window)-Umgebung, die den Bildschirm dazu konfiguriert, einer graphischen Anzeige zu ähneln, in der ein Benutzer Informationen eingeben oder ansehen kann. Im allgemeinen stellt ein auf dem Computersystem ausgeführtes Anwendungsprogramm die Informationen dem Benutzer durch ein Fenster dar, indem es Bilder, Graphiken oder Text innerhalb des Fensterbereichs zeichnet. Der Benutzer kommuniziert seinerseits mit der Anwendung, indem er auf Objekte in dem Fenster mit einem Cursor "zeigt", der durch eine handbediente Zeigevorrichtung, wie z. B. eine Maus, gesteuert wird.
Unter den verschiedenen Typen von Fensteranordnungen zeigt das Dokument "IBM TECHNICAL DISCLOSURE BULLETIN, Band 34, Nr. 7A; Dezember 1991, Seiten 431-433" Unterfenster mit variabler mehrspaltiger Anordnung zur Anzeige von Textinformationen.
Kurzzeitige "Fop-up"- oder "Pull-down"-Menus listen Befehlsauswahlen auf, die dem Benutzer jederzeit zur Verfügung stehen, egal was noch auf dem Bildschirm angezeigt wird. Zum Beispiel braucht man ein Dokument nicht zu schließen und zu einem Hauptmenübildschirm zurückzukehren, um aus einem Menü Befehle auszuwählen und zu erteilen. Die Menüs können lediglich dadurch aktiviert und Befehle ausgewählt bzw. aktiviert werden, daß auf sie mit der Maus gezeigt wird. Das heißt, die Befehle können erteilt werden, indem die Maus derart bedient wird, daß der Cursor auf oder in die Nähe der Befehlsauswahl bewegt wird und ein Schaltknopf auf der Maus gedrückt und losgelassen, d. h. "geklickt", wird.
Im allgemeinen haben diese Menüs die Gestalt von Direktzugriffsmenüs, die alle Wahlmöglichkeiten in einem Fenster zeigen, z. B. mit einer Leiste von Schaltflächen, oder von taxonomischen Menüs, die eine Gebietshierarchie klassifizieren und dem Benutzer erlauben, durch diese zu navigieren. In vielen Situationen ist es nicht notwendig, daß das Menü permanent auf dem Anzeigebildschirm sichtbar bleibt, und es kann daher auf dem Bildschirm "hochechnellen" ("popup"), wenn es benötigt wird. Typischerweise wird ein Schaltknopf auf der Maus gedrückt, um das Menü anzuzeigen, welches dann auf dem Bildschirm in der Nähe der Cursorposition gemalt wird. Wenn der Schalter losgelassen wird, verschwindet das Menü. Wiederum wird Menüauswahl dadurch erreicht, daß mit dem Cursor mithilfe der Maus auf das gewünschte Feld gezeigt wird, was das gewünschte Feld visuell schattiert.
Das Pop-up-Menü ist ein bequemer Weg, um häufig benutzte Befehle und Informationen zugänglich zu halten, ohne Platz auf dem Fenster einzunehmen. Alternativ können mehrere verschiedene Menüs durch Schalflächen auf dem Fenster bereitgestellt werden, die, wenn sie durch die Maus aktiviert werden, ihre Menüs anzeigen; diese werden Pull-down- Menüs genannt. Typischerweise bleiben diese Menüs nur so lange gezeichnet, wie die Maustaste gedrückt ist.
Befehle in den Pull-down- und Pop-up-Menüs wirken typischerweise ein oder mehrere Objekte. Wenn eine Anwendung mehr Informationen benötigt, um einen Befehl auszuführen, kann eine Dialogbox verwendet werden. Eine Dialogbox ist ein spezieller Fenstertyp, der dem Benutzer Informationen entlockt, z. B. vom Benutzer verlangt, daß er Felder überprüft oder Leerfelder ausfüllt.
Graphische Benutzeroberflächen werden durch das Finder Anwendungs-Softwaresystem veranschaulicht, das in der Macintosh-Reihe von Computern verwendet wird und von Apple Computer, Inc., Cupertino, CA hergestellt wird. Ein Aspekt dieses Softwaresystems ist im U. S. Patent 4,931,783 beschrieben. Dieses Patent beschreibt, wie die im Finder- System verfügbaren Funktionen durch die Verwendung von Menüs manipuliert und gesteuert werden können. Die Details, wie ein solches System implementiert werden kann, sowie andere Finder-Funktionen sind in einem Band der Veröffentlichung "Inside Macintosh", herausgegeben von Addison-Wesley, mit dem Titel "Macintosh Toolbox Essentials", beschrieben.
Ein weiteres Beispiel eines populären Softwaresystems, das eine graphische Benutzeroberfläche zur Verfügung stellt, ist das Windows Betriebssystem, welches im Handel von Microsoft Corporation erhältlich ist. Die vorliegende Erfindung ist auf alle solche Systeme anwendbar und beschäftigt sich primär mit dem Zugriff auf Informationen, die die Zustände von Objekten betreffen, die in Übereinstimmung mit objektorientierten Programmiertechniken entwickelt wurden.
Objektorientierte Programmierung ist ein Paradigma zum Entwerfen und Implementieren von Softwareprogrammen. Im allgemeinen definiert und verpackt objektorientierte Programmierung Objekte, wobei ein Objekt aus einer Datenstruktur zusammen mit den für diese Struktur verfügbaren Operationen besteht. Sobald solche Objekte definiert worden sind, ist es möglich, ein Programm als eine einfache Sequenz von Prozessen aufzubauen, die mit bestimmten Beispielen dieser Objekte ausgeführt werden. Ein wesentlicher Teil der Objektdefinition ist die Fähigkeit, neue, komplexere Objekte als Verbesserungen von bereits definierten Objekten zu schaffen.
Wenn man Softwareprogramme entwickelt, kann es ein oder mehrere zu diesen Objekte gehörende Attribute geben, die ein Benutzer, wie z. B. ein Programmierer, prüfen möchte, Diese Attribute können numerische Werte oder Informationen bezüglich des Status' eines Objektes betreffen, wie z. B., ob sein Quellcode modifiziert worden ist. Typischerweise werden die Attribute als zu dem Objekt gehörige Zustandsbits repräsentiert, und in vielen herkömmlichen graphischen Benutzeroberflächensystemen sind diese Zustandsattribute aus Menüs verfügbar, auf die aus einem Fenster zugegriffen werden kann. Der Programmierer ruft jedoch das Menü ab und greift auf jedes Attribut mit einer Steuerungsvorrichtung, wie einer Maus zu, um seine Inhalte zu prüfen, die typischerweise die Gestalt von Text aufweisen. Derartige Prozeduren können zeitaufwendig und ineffizient sein, insbesondere wenn viele verschiedene Zustandsattribute zu dem Objekt gehören.
Dementsprechend gehört es zu den Zielen der vorliegenden Erfindung, eine verbesserte graphische genutzeroberfläche zur Verfügung zu stellen, die die Fähigkeit hat, zu einem Objekt gehörende Zustandsattribute positionsmäßig darzustellen.
Ein weiteres Ziel der vorliegenden Erfindung ist es, eine interaktive graphische Benutzeroberfläche bereitzustellen, die die Fähigkeit hat, Zustandsattribute für mehr als ein Objekt gleichzeitig positionsmäßig anzuzeigen.

ZUSAMMENFASSUNG DER ERFINDUNG

Zu diesem Zweck stellt die vorliegende Erfindung eine graphische Benutzeroberfläche gemäß Anspruch 1 bereit, wobei bevorzugte aber nicht einschränkende Aspekte in den Ansprüchen 2 bis 7 definiert sind.
Eine Ausführungsform der vorliegenden Erfindung stellt ein Computersystem gemäß Anspruch 8 bereit, wobei bevorzugte, aber nicht einschränkende Merkmale in den Ansprüchen 9 bis 13 definiert sind.
Die vorliegende Erfindung stellt außerdem ein entsprechendes erfahren gemäß Anspruch 14 mit fakultativen Schritten in den Ansprüchen 15 und 16 bereit.
Kurz gesagt umfaßt eine verbesserte graphische Benutzeroberfläche gemäß der Erfindung neuartige Statusanzeiger, die Zustandsattribute betreffen, die zu auf einem Anzeigebildschirm eines Computersysteme angezeigten Objekten gehören. Diese Statusanzeiger werden vorzugsweise auf einem Teil eines Fensters, Unterfenster genannt, eines Anzeigebildschirms als unterscheidbare visuelle Zeichen dargestellt, die neben ihren dazugehörigen Objekten angeordnet sind und damit eine anpaßbare Browserstruktur für einen Benutzer, wie einen Programmierer, bereitstellen. Beispiele für durch die Statusanzeiger dargestellte objektbezogene Attribute sind u. a., ob der Quellcode eines Objektes gespeichert oder kompiliert wurde, und ein Hinweis auf seinen Benutzerzugriffs-/Schutzstatus, z. B. Nur-Lese.
Speziell wird eine Feldleiste entlang einer vorbestimmten Seite (d. h. recht/links, oben oder unten) von jedem Unterfenster zum Anzeigen der Statusanzeiger bereitgestellt. Gemäß eines Aspekts der Erfindung können sich die Statusanzeiger voneinander durch ihre Farbe, Form und/oder ihre relative räumliche Position entlang dieser seitlichen Feldleiste unterscheiden. In einer beispielhaften Ausführungsform hat jeder Anzeigertyp eine unterschiedliche Farbe und einen unterschiedlichen Platz entlang der Breite der Leiste, zeigt aber gleichzeitig eine rechteckige, "blip"- artige Form, die allen Anzeigertypen gemein ist.
Gemäß einem weiteren Aspekt der Erfindung erweitert/verengt sich die Breite der seitlichen Feldleiste dynamisch in Abhängigkeit von der Menge der zum Anzeigen ausgewählten Statusanzeiger. Die dynamisch anpaßbare Natur der seitlichen Feldleiste erlaubt es, wenn gewünscht, zahlreiche Statusanzeiger auf der Leiste anzuzeigen, und gleichzeitig Bildschirm-Immobilien zu sparen, wenn nur wenige Anzeiger zum Anzeigen ausgewählt sind.
Außerdem vermeidet die Verwendung von positionsmäßigen Statusanzeigern, die jeder eine unterschiedliche Farbe, Form und/oder räumliche Position innerhalb der seitlichen Feldleiste eines Unterfensters aufweisen, die Notwendigkeit für einen Benutzer, zu jedem Anzeiger gehörigen Text zu lesen. Lies ist insbesondere für einen Programmierer wichtig, der während der Softwareentwicklung in einer Programmierumgebung an dem Status von verschiedenen Objekten interessiert sein kann. Indem die Notwendigkeit, Text zu lesen, um den Status dieser Objekte festzustellen, beseitigt wird, kann der Programmierer nur einen kurzen Blick auf die visuellen Zeichen werfen und eine Interpretation ihrer Zustände an das Unterbewußtsein entladen und dadurch zeitaufwendige und ineffiziente computerbezogene Befehle beseitigen.
Operativ werden die Anzeigertypen, die auf dem Bildschirm für ein Objekt dargestellt werden, vorzugsweise auf einer Unterfenster-für-Unterfenster-Basis bestimmt, indem eine Statusanzeiger-Dialogbox für dieses Unterfenster von einem Pull-down-Menü oder durch andere Mittel, wie z. B. durch Doppelklicken der Maus in die Region der seitlichen Leiste eines Unterfensters, abgerufen wird. Die Dialogbox ist ein Benutzeroberflächenelement, das eine Liste von verfügbaren Statusanzeigereinträgen bereitstellt, einschließlich denen, die zur Zeit angezeigt werden; diese letzteren Anzeiger sind so durch Häkchen-Markierungen oder andere Beschriftungen neben den Einträgen gekennzeichnet. Ein Benutzer kann jeden der verfügbaren Statusanzeiger auf der Liste für ein Unterfenster auswählen bzw. aktivieren oder deaktivieren, indem er z. B. auf die Anzeigereinträge mit einer Maus "klickt".
Die ausgewählten Statusanzeiger werden in einer innerhalb eines Unterfensterobjektes angeordneten Datenstruktur gespeichert. Diese Inhalte der Datenstruktur bestimmen, welche Statusanzeiger in dem Unterfenster angezeigt werden, was wiederum die Breite der dynamisch anpaßbaren seitlichen Feldliste bestimmt, die zum Unterbringen der Anzeiger verwendet wird. Diese Inhalte werden auch dazu verwendet, die geeigneten Befehle zu bestimmen, die dem Fensterverwalter geschickt werden, der dann das Unterfenster anzeigt.

KURZBESCHREIBUNG DER ZEICHNUNGEN

Die obigen und weitere Vorteile der Erfindung können besser mit Bezug auf die folgende Beschreibung im Zusammenhang mit den beiliegenden Zeichnungen verstanden werden. In den Zeichnungen zeigen:
Fig. 1 ein Blockdiagramm eines Computersystems, wie z. B. ein PC-System, auf dem die Erfindung vorteilhaft ausgeführt werden kann;
Fig. 2 ein Blockdiagramm, das die Beziehung eines Betriebssystems, eines Anwendungsprogramms, eines Bildschirmpuffers und eines Anzeigebildechirms des Computersystems der Fig. 1 zeigt;
Fig. 3 die Wechselwirkung zwischen einem Anwendungsprogramm und einem Fensterverwalter gemäß der Erfindung;
Fig. 4 einen Anzeigebildschirm, der die neuen Statusanzeiger gemäß der Erfindung veranschaulicht;
Fig. 5 eine Statusanzeiger-Dialogbox zum Anzeigen einer Liste von verfügbaren Statusanzeigereinträgan gemäß der Erfindung;
Fig. 6A und 6B Unterfenster, die jeweils die dynamisch anpaßbare seitliche Feldleiste gemäß der Erfindung veranschaulichen;
Fig. 7 verschiedene Unterfenster eines Fensters, von denen jedes eine Ebene einer Containment Hierarchie darstellt, die vorteilhaft die Statusanzeiger der vorliegenden Erfindung verwenden kann;
Fig. 8 einen Statusanzeiger-Gruppeneintrag in einem Browse-Menü gemäß der Erfindung;
Fig. 9 ein beispielhaftes Flußdiagramm der Sequenz von Schritten, die beim Betrieb der verbesserten graphischen Benutzeroberfläche vorkommen, wenn die Statusanzeiger der vorliegenden Erfindung ausgewählt werden; und
Fig. 10 ein beispielhaftes Flußdiagramm der Sequenz von Schritten, die zur Anzeige eines Fensters und dazugehörigen Unterfenstern verwendet werden, wobei die Unterfenster Statusanzeiger gemäß der Erfindung enthalten.

DETAILLIERTE BESCHREIBUNG VON BEISPIELHAFTEN AUSFÜHRUNGSFORMEN

Fig. 1 veranschaulicht ein Computersystem 100, welches einen Prozessor (CPU) 110 umfaßt, der zwischen einen Speicher 114 und eine Eingabe/Ausgabe (I/O)-Schaltung 118 durch bidirektionale Busse 112 und 116 gekoppelt ist. Der Speicher 114 umfaßt typischerweise einen Direktzugriffsspeicher (RAM) zur kurzzeitigen Speicherung von Informationen, einschließlich eines Anwendungsprogramms (nicht gezeigt), und einen Nur-Lesespeicher (ROM) zur dauerhaften Speicherung der Konfiguration des Computers und grundlegender Betriebsbefehle, wie z. B. Teile eines Betriebssystems (nicht gezeigt). Wie im Folganden noch weiter beschrieben, wirken das Anwendungsprogramm und das Betriebssystem aufeinander, um die Operationen der CPU 110 und des Computersystems 100 zu steuern.
Die I/O-Schaltung 118 ist ihrerseits mit einer Massenspeichereinheit 120, wie z. B. einem Plattenlaufwerk, über einen bidirektionalen Bus 122 und eine Cursor- Steuerungsvorrichtung, wie z. B. eine Tastatur 124 (über ein Kabel 126) und eine Maus 130 (über Kabel 128) verbunden. Ein herkömmlicher Anzeigemonitor 132 mit einem Anzeigebildschirm 132 ist auch mit der I/O-Schaltung 118 über ein Kabel 138 verbunden. Speziell empfängt die I/O-Schaltung 118 Informationen, wie z. B. Steuerungs- und Datensignale, von der Maus 130 und der Tastatur 124, und stellt diese Informationen der CPU 110 zur Speicherung auf der Massenspeichereinheit 120 oder zur Anzeige auf dem Bildschirm 135 zur Verfügung. Es versteht sich von selbst, daß die I/O- Schaltung die notwendige Hardware, z. B. Puffer und Adapter, enthält, die als Schnittstellen mit der Maus, der Tastatur und dem Anzeigemonitor benötigt werden.
Die Maus 130 enthält typischerweise wenigstens einen Schaltknopf 134, der durch einen Benutzer des Systems bedient wird. Ein Cursor 140 wird auf dem Bildschirm 135 angezeigt und seine Position ist über die Maus 130 oder die Tastatur 124, wie allgemein bekannt steuerbar. Ein Beispiel der Maus 130 wird im U. S. Patent Nr. Re. 32, 32 gezeigt und beschrieben, welches hiermit durch Verweis in dieses Dokument aufgenommen wird, als ob es hier im Ganzen wiedergegeben wäre.
Das Computersystem 100 ist vorzugsweise ein PC der Macintosh-Reihe von Computern, die von Apple Computer, Inc. verkauft werden, obgleich die Erfindung im Kontext von jedem beliebigen Computer ausgeübt werden kann. Auf diesen Computern ist eine Betriebssystem-Software, wie z. B. das Appel® System/7® Betriebssystem, vorhanden, welches die Computer steuert und koordiniert.
Eine Fensterumgebung wird typischerweise auf dem Bildschirm 135 angezeigt. Gemäß einem Aspekt der hier beschriebenen Erfindung umfaßt die Fensterumgebung Fenster 142, von denen jedes Unterfenster 144 enthalten kann, wobei jedes Unterfenster einen Teil eines Fensters 142 abdeckt. Die Fensterumgebung ist im allgemeinen Teil der Betriebssystem- Software, die eine Sammlung von Hilfsprogrammen zur Steuerung des Betriebs des Computersysteme 100 umfaßt. Das Betriebssystem wirkt seinerseits auf das Anwendungsprogramm, um Funktionalität auf höherer Ebene einschließlich einer direkten Schnittstelle zu dem Benutzer bereitzustellen. Speziell verwendet das Anwendungsprogramm Funktionen des Betriebssystems, indem es eine Reihe von Task-Befehlen an das Betriebssystem erteilt, welches dann die angeforderte Task durchführt. Zum Beispiel kann das Anwendungsprogramm darum bitten, daß das Betriebssystem gewisse Informationen in den Unterfenstern 144 des Anzeigebildschirms 135 anzeigt, um sie dem Benutzer zu präsentieren.
Die hier beschriebene Erfindung stellt, zusammen mit diesen Fenstern und tinterfenstern, neue Benutzeroberflächenelemente, wie z. B. Menüs und ihre Einträge, bereit, die, wenn sie aufgerufen werden, bewirken, daß Aktionen stattfinden, die die Fähigkeit eines Benutzers verbessern, auf das Computersystem einzuwirken. Dieses neue Verhalten des Systems wird durch die Wechselwirkung dieser Elemente mit einer Reihe von zum Betriebssystem gehörigen Systemsoftware-Routinen herbeigeführt. Diese Eystemsoftware- Routinen wirken ihrerseits auf das Anwendungsprogramm, um die Fenster und Unterfenster zu erzeugen und die neuen Menüs zu verwalten, wie im Folgenden noch weiter beschrieben.
Fig. 2 ist eine schematische Illustration der Wechselwirkung eines Anwendungsprogramms 202 und eines Betriebssystems 204 eines Computersystems 200, welches dem Computersystem 100 der Fig. 1 ähnlich ist und äquivalente Elemente aufweist. Das Anwendungsprogramm 202 und das Betriebssystem 204 wirken aufeinander, um die Operationen des Computers 200 zu steuern und zu koordinieren, und ihre Wechselwirkung ist schematisch durch den Pfeil 206 dargestellt. Um Informationen auf einer Bildschirmanzeige 235 anzuzeigen, erzeugt und sendet das Anwendungsprogramm 202 Anzeigebefehle an ein Fensterverwaltungsprogramm 205 des Betriebssystems 204. Das Fensterverwaltungsprogramm 205 speichert die Informationen direkt (über den Pfeil 208) auf einen Bildschirmpuffer 210.
Der Fensterverwalter 205 ist eine Systemsoftware- Routine, die im allgemeinen verantwortlich für die Verwaltung von Fenstern ist, die der Benutzer während des Betriebs des Anwendungsprogramms ansieht das Anwendungsprogramm ist im allgemeinen für die Verwaltung der Unterfenster verantwortlich. Das heißt, es ist im allgemeinen die Aufgabe des Fensterverwalters, den Platz und die Größe des Fensters und der Fensterbereiche, die in Verbindung mit Elementen der verbesserten graphischen Benutzeroberfläche der vorliegenden Erfindung gezeichnet und wieder gezeichnet werden müssen, zu verfolgen. Weitere Details betreffend den Fensterverwalter werden in der oben genannten "Inside Macintosh"-Veröffentlichung "Macintosh Toolbox Essentials" bereitgestellt.
Unter der Steuerung von verschiedener Hardware und Software in dem System werden die Inhalte des Bildschirmpuffers 210 aus dem Puffer ausgelesen und, wie schematisch durch den Pfeil 212 dargestellt, an einen Anzeigeadapter 214 geliefert. Der Anzeigeadapter enthält Hardware und Software (manchmal in Form von Firmware), welche die Informationen im Bildschirmpuffer 210 in eine Form konvertiert, die dazu benutzt werden kann, einen Anzeigebildschirm 235 eines Monitors 232 anzusteuern, der mit dem Anzeigeadapter über das Kabel 218 verbunden ist.
In einer bevorzugten Ausführungsform ist die hier beschriebene Erfindung in einer objektorientierten dynamischen Programmiersprache, wie z. B. Common Lisp, unter Verwendung von objektorientierten Programmiertechniken (OOP) implementiert. Die Common Lisp Sprache ist wohlbekannt und viele Artikel und Texte sind verfügbar, die die Sprache im Detail beschreiben. Außerdem sind Common Lisp Compiler von mehreren Anbietern erhältlich. Dementsprechend werden aus Gründen der Klarheit die Details der Common Lisp Sprache und der Betrieb des Common Lisp Compilers im Folgenden nicht weiter im Detail beschrieben.
Wie sich für den Fachmann versteht, umfassen OOP- Techniken die Definition, Erzeugung, Verwendung und Löschung von "Objekten". Diese Objekte sind Softwareentitäten, die Datenelemente und Routinen oder Funktionen umfassen, die die Datenelemente manipulieren. Die Daten und dazugehörigen Funktionen werden von der Saftware als eine Einheit bzw. Entität behandelt, die erzeugt, verwendet und gelöscht werden kann, als wenn sie ein einzelnes Stück wäre. Zusammen erlauben die Daten und Funktionen den Objekten, so gut wie jedes Objekt der realen Welt von seinen Kenneichen her, die durch die Datenelemente repräsentiert sein können, und seinem Verhalten her, was durch seine Daten-Manipulierfunktionen repräsentiert sein kann, nachzubilden. Auf diese Weise können Objekte konkrete Dinge, wie Menschen und Computer, gleichzeitig aber auch abstrakte Konzepte, wie Zahlen oder geometrische Muster, nachbilden.
Objekte werden durch Erzeugung von "Klassen" definiert, die als Vorlagen wirken, die den Compiler instruieren, wie er ein tatsächliches Objekt zu konstruieren hat. Eine Klasse kann z. B. die Anzahl und den Typ von Datenvariablen und die Schritte spezifizieren, die in den Funktionen vorkommen, die die Daten manipulieren.
Die Hauptvorteile von OOP-Techniken ergeben sich aus drei grundlegenden Prinzipien: Verkapselung, Polymorphismus und Vererbung. Genauer gesagt, können Objekte so entwarfen werden, daß sie alle oder einen Teil ihrer internen Datenstruktur und ihrer internen Funktionen verstecken oder verkapseln. Polymorphismus ist ein Konzept, welches Objekten und Funktionen, die das gleiche Gesamtformat haben, aber mit unterschiedlichen Daten arbeiten, erlaubt, unterschiedlich zu funktionieren, um konsistente Ergebnisse zu liefern. Vererbung erlaubt andererseits Programmentwicklern, bereits existierende Programme leicht wiederzubenutzen und es zu vermeiden, Software aus dem Nichts zu schaffen. Das Prinzip der Vererbung erlaubt einem Softwareentwickler, Klassen (und die Objekte, die später aus ihnen erzeugt werden) als verwandt zu deklarieren. Speziell können Klassen als Unterklassen von anderen Basisklassen gekennzeichnet werden. Die Erzeugung einer neuen Unterklasse, die etwas von der Funktionalität (mit selektiver Modifikation) einer anderen Klasse aufweist, erlaubt Softwareentwicklern, existierenden Code einfach an ihre speziellen Bedürfnisse anzupassen.
Gemäß der Erfindung sind das Fenster und seine Unterfenster "Objekte", die von dem Anwendungsprogramm erzeugt werden, um mit dem Fensterverwalter zu kommunizieren, der vorzugsweise ein objektorientiertes Programm ist. Die Wechselwirkung zwischen einem Anwendungsprogramm und einem Fensterverwalter ist detaillierter in Fig. 3 veranschaulicht
Im allgemeinen ist ein Anwendungsprogramm 308 mit dem Fensterverwalter 310 dadurch verbunden, daß es Objekte erzeugt und manipuliert. Der Fensterverwalter ist selbst ein Objekt, das erzeugt wird, wenn das Betriebssystem gestartet wird. Speziell erzeugt das Anwendungsprogramm die Fensterobjekte 300, die den Fensterverwalter veranlassen, dazugehörige Fenster auf dem Anzeigebildschirm zu erzeugen. Dies ist schematisch durch einen Pfeil 302 dargestellt. Außerdem erzeugt das Anwendungsprogramm 30B einzelne Unterfensterobjekte 350, die in jedem Fensterobjekt 300 gespeichert werden, wie schematisch durch Pfeile 352 und 354 gezeigt.
Da viele Unterfensterobjekte erzeugt werden können, um viele Unterfenster auf dem Anzeigebildschirm anzuzeigen, kommuniziert das Fensterobjekt 300 mit dem Fensterverwalter 310 durch eine Sequenz von Zeichenbefehlen, die von dem Fensterobjekt 300 an den Fensterverwalter 310 erteilt werden, wie durch Pfeil 304 veranschaulicht. Die Anwendung 308 kommuniziert auch mit dem Fensterverwalter 310, indem sie Befehle an den Verwalter 310 schickt, wie durch Pfeil 316 gezeigt. Der Fensterverwalter 310 unterhält eine Fensterliste 312, die jedes zur Zeit im System befindliche Fenster enthält.
Obwohl objektorientierte Programmierung bedeutende Verbesserungen gegenüber anderen Programmierkonzepten bietet, benötigt die Programmentwicklung immer noch bedeutenden Aufwand an Zeit und Anstrengung, insbesondere wenn keine bereits existierenden Softwareprogramme zur Modifikation verfügbar sind. Folglich war ein Ansatz im Stand der Technik, einen Programmentwickler mit einem Satz von vordefinierten, untereinander verbundenen Klassen auszustatten, die einen Satz von Objekten und verschiedenen zusätzlichen Routinen erzeugen, die alle darauf gerichtet sind, häufig vorkommende Aufgaben in einer bestimmten Umgebung durchzuführen. Solche vordefinierten Klassen und Bibliotheken wer den typischerweise "Anwendungs-Grundstrukturen" ("application frameworks") genannt und stellen im wesentlichen eine vorgefertigte Struktur für eine funktionierende Anwendung bereit.
Zum Beispiel kann eine Anwendungs-Grundstruktur für eine herkömmliche graphische Benutzeroberfläche einen Satz von vordefinierten graphischen Oberflächenobjekten bereitstellen, die Fenster, Schiebeleisten, Menüs etc. erzeugen und Unterstützung und Standardverhalten ("default" behaviour) für diese Objekte einer graphischen Oberfläche bereitstellen. Da Anwendungs-Grundstrukturen auf objektorientierten Techniken basieren, können die vordefinierten Klassen als Basisklassen verwendet werden, und das eingebaute Standardverhalten kann von entwicklerdefinierten Unterklassen geerbt und entweder modifiziert oder außer Kraft gesetzt werden, um Entwicklern zu erlauben, die Grundstruktur zu erweitern und angepaßte Lösungen in einem bestimmten Spezialbereich zu schaffen. Dieser objektorientierte Ansatz bietet einen wesentlichen Vorteil gegenüber traditioneller Programmierung, da der Programmierer nicht das ursprüngliche Programm verändert, sondern vielmehr die Fähigkeiten des Programms erweitert. Außerdem arbeiten Entwickler nicht blind durch Codeschichten, da die Grundstruktur architekturale Leitung und Modellierung bereitstellt und gleichzeitig den Entwicklern freistellt, spezielle für den Eroblembereich einzigartige Aktionen zu liefern.
Viele Arten von Anwendungs-Grundstrukturen sind verfügbar, in Abhängigkeit von der Ebene des zugehörigen Systems und der Art des zu lösenden Problems. Die Grundstruktur-Typen reichen von Anwendungs-Grundstrukturen auf hoher Ebene, die dabei helfen, eine Benutzeroberfläche zu entwickeln, bis zu Grundstrukturen auf niedrigerer Ebene, die grundlegende Systemsoftwaredienste, wie z. B. Kommunikation, Drucken, Filesystemunterstützung, Graphiken etc., bereitstellen. Kommerzielle Beispiele von Anwendungs- Grundstrukturen beinhalten MacApp (Apple), OWL (Borlandi, NeXT Step App Kit (NeXT) und Smalltalk-80 NVC (ParcPlace). Obgleich der Ansatz mit Anwendungs-Grundstruktur all die Prinzipien von Verkapselung, Polymorphismus und Vererbung in der Objektschicht benützt, und eine wesentliche Verbesserung gegenüber anderen Programmiertechniken ist, treten Schwierigkeiten auf. Diese Schwierigkeiten werden durch die Tatsache verursacht, daß es für Entwickler leicht ist, ihre eigenen Objekte wiederzuverwenden, aber es ist schwierig für die Entwickler, von anderen Programmen erzeugte Objekte zu benutzen. Außerdem bestehen Anwendungs- Grundstrukturen im allgemeinen aus einer oder mehreren Objekt-"Schichten" ("layers") auf einem monolithischen Betriebssystem, und sogar bei Flexibilität der Objektschicht ist es immer nach oft notwendig, direkt mit dem darunterliegenden Betriebssystem durch umständliche Prozeduraufrufe (procedure calls) aufeinander zu wirken.
Auf die gleiche Weise, auf die eine Anwendungs- Grundstruktur den Benutzer mit vorgefertigter Funktionalität für ein Anwendungsprogramm ausstattet, kann eine System-Grundstruktur, wie z. B. das in der bevorzugten Ausführungsform enthaltene, eine vorgefertigte Funktionalität für Dienste auf Systemebene bereitstellen, die die Entwickler modifizieren oder außer Kraft setzen können, um angepaßte Lösungen zu schaffen und dabei die umständlichen Prozeduraufrufe zu vermeiden, die bei den Anwendungs- Grundstruktur-Programmen nach dem Stand der Technik notwendig sind. Man betrachte z. B. eine anpaßbares Browser- Grundstruktur, welches die Grundlage zum Browsen und die direkte Manipulation von Objekten bereitstellen kann. Ein Anwendungsprogrammentwickler, der diese Fähigkeiten braucht, würde normalerweise spezielle Routinen schreiben müssen, um sie bereitzustellen. Um dies mit einer Grundstruktur zu tun, braucht der Programmierer die fertige Ausgabe nur mit Charakteristika und Verhalten zu versorgen, während die Grundstruktur die eigentlichen Routinen bereitstellt, die die Aufgaben durchführen.
Eine bevorzugte Ausführungsform nimmt das Konzept der Grundstrukturen und wendet es im gesamten System, einschließlich der Anwendung und der Betriebssystems, an. Für den kommerziellen oder betrieblichen Entwickler oder Systemintegrator heißt das, daß alle die Vorteile, die für eine Grundstruktur, wie z. B. MacApp, veranschaulicht wurden, nicht nur auf der Systemebene für solche Dienste, wie Drucken, Graphiken, Multimedia, Dateisystem- und I/O- Operationen, ausgenützt werden, sondern auch auf der Anwendungsebene für Dinge wie Text und, wie im Folgenden beschrieben, graphische Benutzeroberflächen.
Wieder mit Bezug auf Fig. 3 sind das Fensterobjekt 300 und das Unterfensterobjekt 350 Elemente einer verbesserten graphischen Benutzeroberfläche mit einer anpaßbaren Browser-Grundstruktur, um die Fähigkeit eines Benutzers, durch viele verschiedene in dem Speicher 114 gespeicherte Objekte zu navigieren oder zu browsen, stark zu verbessern. Speziell klassifiziert und organisiert die anpaßbare Browser-Grundetruktur, wie im Folgenden noch weiter beschrieben, diese letzteren Objekte als Quellcode-Entitäten gemäß der Semantik der Programmiersprache. Dieser Typ von Browser ist ein besonders nützliches Tool für den Programmierer, der Software in einer Programmierumgebung entwickelt.
Während einer derartigen Entwicklung kann es jedoch zu den Objekten gehörige Zustandsattribute geben, die der Programmierer prüfen möchte. Diese Attribute sind z. B., ob der Quellcode eines Objektes gespeichert oder kompiliert worden ist, und der Benutzerzugriff-Status des Codes. Gemäß der vorliegenden Erfindung enthält die verbesserte graphische Benutzeroberfläche zu diesen Zustandsattributen gehörige Statusanzeiger.
Fig. 4 zeigt einen Anzeigebildschirm 400, der die neuen Statusanzeiger veranschaulicht, die kollektiv mit 450 bezeichnet sind, und zu verschiedenen Objekten eines Projekt "Tiles" gehören. Wie man sehen kann, werden die Anzeiger auf einem Unterfenster 404 eines Fensters 402 als unterscheidbare visuelle Zeichen neben ihren dazugehörigen Objekten angezeigt; speziell gibt es drei (3) neben dem Objekt "Tiles" angeordnete Statusanzeiger und einen (1) neben dem Objekt "README" angeordneten Anzeiger. Eine neuartige seitliche Feldleiste 406 ist innerhalb des Unterfensters 404 zum Anzeigen dieser Anzeiger vorgesehen.
Gemäß einem Aspekt der Erfindung unterscheiden sich die Statusanzeiger 450 voneinander durch ihre Farbe, ihre Form und/oder ihre relative räumliche Position entlang der seitlichen Feldleiste 406. Vorzugsweise hat jeder hier beschriebene Anzeigertyp eine unterschiedliche Farbe und einen unterschiedlichen relativen Platz entlang der Breite der Leiste; in der beispielhaften Ausführungsform hat jedoch jeder auch eine gemeinsame rechteckige, "blip"-artige, d. h. einfache geometrische, Form.
Fig. 5 zeigt eine Statusanzeiger-Dialogbox 500, die eine Liste von Statusanzeiger-Parametereinträgen 510 in Verbindung mit der vorliegenden Erfindung zeigt. Wie angemerkt, betreffen diese Einträge den Status eines Objektes und umfassen solche Zustandsattribute wie: (i) NICHT GESPEICHERT, (ii) NICHT KOMPILIERT, (iii) WARNUNGEN, (iv) NUR-LESE, (v) PFLEGER und (vi) ANDERE. Genauer zeigt das durch den Eintrag NICHT GESPEICHERT repräsentierte objektbezogene Attribut an, daß der Quellcode des Objektes seit einer Änderung nicht gespeichert wurde; der Eintrag NICHT KOMPILIERT zeigt an, daß der Quellcode des Objektes noch nicht kompiliert wurde; der Eintrag WARNUNGEN zeigt an, daß in dem Quellcode Fehler detektiert worden sind; der Eintrag NUR-LESE zeigt an, daß der Benutzer nur Lesezugriff (z. B. nicht Schreibzugriff) auf den Code des Objektes hat; und der Eintrag PFLEGER zeigt an, daß der Quellcode des Objektes nicht als ein Laufzeitobjekt zur Ausführung durch den Computer gekennzeichnet ist.
Der Eintrag ANDERE ist ein spezieller Eintrag, der nur dann aktiv ist, wenn einer oder mehrere Statusanzeiger nicht angezeigt werden. Die Statusanzeiger, die zur Zeit angezeigt werden, werden jedoch durch Häkchen-Markierungen 520 oder eine andere ähnliche Beschriftung neben den Anzeigern gekennzeichnet. Ein Benutzer kann jeden der verfügbaren Statusanzeiger auf der Liste für die Anzeige auf dem Bildschirm aktivieren oder deaktivieren, indem er z. B. auf die Anzeigereinträge mit einer Maus "klickt", was den Zustand des Eintrags umschaltet.
Die Dialogbox 500 ist vorzugsweise eine modale Dialogbox, weil sie den Benutzer in den "Modus" versetzt, in dem er nur innerhalb der Box 500 arbeiten kann. Das heißt, der Benutzer muß, ob er die angewählten/abgewählten Statusanzeiger-Einträge 510 akzeptiert/ablehnt, diese Wahl bestätigen, indem er entweder auf den im unteren Teil der Box angeordneten "OK"-Knopf 530 oder auf den daneben liegenden "Abbrechen"-Knopf 535 klickt, bevor er irgendwelche anderen Befehle an die Anwendung erteilt.
Gemäß der Erfindung können die Statusanzeiger entlang jeder beliebigen Seite eines Rahmens des Unterfensters erscheinen; das heißt, die Anzeiger können in einer auf der rechten oder linken Seite des Unterfensters angeordneten seitlichen Leiste oder in einer Titelleiste erscheinen, die entlang der oberen Seite von jedem Unterfenster angeordnet ist, oder, wenn passend, in einer entlang der unteren Seite des Unterfensters angeordneten Leiste. Vorzugsweise spezifiziert ein Positions-Pop-up 525, ob diese Anzeiger in der rechten/linken seitlichen Leiste, der Titelleiste, in beiden Bereichen oder in keinem der Bereiche erscheinen sollten. Wenn sie in der Titelleiste erscheinen, gelten die Statusanzeiger für das Objekt, das in dem Unterfenster angezeigt wird.
Der Text für jeden Anzeiger (i)-(vi) ist vorzugsweise in der Farbe dieses Anzeigers angezeigt. In der beispielhaften Ausführungsform ist die bevorzugte Farbe für jedes positionsmäßige Zeichen (und seinen dazugehörigen Text) für jeden Statusanzeiger wie folgt:
(i) NICHT GESPEICHERT - blau
(ii) NICHT KOMPILIERT - grün
(i ii) WARNUNGEN - orange
(iv) NUR-LESE - rosa
(v) PFLEGER - gelb
(vi) ANDERE - grau
Der gezeigte Satz an Statusanzeigern wird auf einer Unterfenster-für-Unterfenster-Basis bestimmt. Dementsprechend und noch einmal mit Bezug auf Fig. 3 weist jedes durch das Anwendungsprogramm 308 erzeugte Unterfensterobjekt 350 vorzugsweise eine interne Datenstruktur 356 auf, die eine Liste von jedem durch die Dialogbox 500 angezeigten Statusanzeiger enthält, zusammen mit dem Status jedes Anzeigers, d. h. aktiviert oder deaktiviert. Wie im Zusammenhang mit Fig. 5 beschrieben, wird der Status von jedem Anzeiger durch einen Benutzer bestimmt, der die Dialogbox 500 bedient. Zusätzlich enthält jedes Fensterobjekt 300 eine Liste von Unterfenstern 306 und jedes Unterfensterobjekt 350 enthält auch eine Liste von Objekten. Der Zustand von jedem in dem Unterfenster angezeigten Objekt bestimmt, ob jeder mögliche Statusanzeiger gezeichnet wird oder nicht.
Gemäß einem weiteren Aspekt der Erfindung erweitert/verengt sich die Breite der neuen seitlichen Feldleiste 406 (Fig. 4) dynamisch, in Abhängigkeit von der Menge der zum Anzeigen ausgewählten Statusanzeiger. Fig. 6A und GB zeigen dynamisch anpaßbare seitliche Feldleisten 620 a, b der Unterfenster 610 a, b. Die dynamisch anpaßbare Natur des seitlichen Felds 650 erlaubt es, zahlreiche Statusanzeiger, wenn gewünscht, auf dem Feld anzuzeigen und gleichzeitig Bildschirm-Immobilien zu sparen, wenn nur wenige Anzeiger zum Anzeigen ausgewählt sind.
Speziell hat jeder in einer rechten/linken seitlichen Feldleiste erscheinende Anzeiger (i)-(vi) vorzugsweise einen relativen räumlichen Platz entlang dieser Feldleiste, die auf einer Unterfenster-für-Unterfenster-Basis durch den Benutzer in Abhängigkeit von der Menge der zum Anzeigen ausgewählten Anzeiger bestimmt wird. Wenn z. B. die Statusanzeiger (i) (ii) und (vi) zum Anzeigen in einem bestimmten Unterfenster ausgewählt sind, würde die Breite der seitlichen Feldleiste aus drei (3) Spalten bestehen, wobei jede Spalte einem Statusanzeiger zugeordnet ist. Wenn andererseits die Anzeiger in einer Titel- (oder unteren) Feldleiste eines Unterfensters erscheinen, würde jeder Anzeiger eine analoge räumliche "Zeile" der bestimmten seitlichen Feldleiste einnehmen, die wiederum auf einer Unterfenster- für-Unterfenster-Basis in Abhängigkeit von der Menge der zum Anzeigen ausgewählten Statusanzeiger bestimmt würde. Das heißt, die relativen räumlichen Positionen der Anzeiger sind innerhalb eines Unterfensters konsistent und unbesetzte Spalten (oder Zeilen) werden eliminiert. Es versteht sich für den Fachmann jedoch, daß andere vorbestimmte Konfigurationen der räumlichen Positionen dieser Anzeiger, wie z. B. eine diagonale Konfiguration oder eine Konfiguration mit fester Anordnung, innerhalb der Lehre der Erfindung angewendet werden kann.
Als ein Beispiel der letzteren Konfiguration würde jeder Anzeiger (i)-(vi) einen festen räumliche Platz entlang der seitlichen Leiste aufweisen, wobei der Anzeiger (i) die erste räumliche "Spalte" am nächsten zu der Grenze des Unterfensters besetzt und der Anzeiger (vi) die letzte räumliche Spalte am weitesten weg von dieser Grenze besetzt. Wenn die Anzeiger in einer Titel- (oder unteren) Feldleiste des Unterfensters erscheinen, würde jeder Anzeiger eine analoge räumliche "Zeile" dieser bestimmten seitlichen Feldleiste besetzen. Gemäß dieser Ausführungsform wird die seitliche Feldleiste, wenn ein Anzeiger (vi) für irgendeines der in dem Unterfenster anwesenden Objekte angezeigt wird, auf ihre maximale Breite gezeichnet; wenn jedoch nur der Anzeiger (i) für jedes Objekt in dem Unterfenster angezeigt wird, ist die Breite der seitlichen Feldleiste 620 minimal.
Die Verwendung von Statusanzeigern der vorliegenden Erfindung kann besonders vorteilhaft hinsichtlich der hierin beschriebenen anpaßbaren Browser-Grundstruktur sein, wenn diese in einer Programmier-Entwicklungsumgebung mit einer Containment Hierarchie zum Entwickeln von Programmen verwendet wird. Fig. 7 zeigt verschiedene Unterfenster 720- 740 eines Fensters 700, wobei jedes Unterfenster eine Ebene der Containment Hierarchie darstellt, die vorteilhaft die Statusanzeiger der vorliegenden Erfindung verwendet. Im besonderen erlaubt die Containment Hierarchie Manipulationen und Operationen am Quellcode, wie z. B. "Speichern" des Codes, innerhalb den verschiedenen Ebenen der Hierarchie. Hier sind Objekte, z. B. Funktionen oder Klassendefinitionen, Einheiten des Programm-Quellcodes, die "Quellenentitäten" ("source entities") genannt werden und die unterste Ebene der Hierarchie umfassen. Ein "Quellencontainer" ("source container"), der sich auf der nächsten Ebene befindet, enthält eine geordnete Sammlung dieser Entitäten. Der Quelleneontainer ist analog einer Datei und jede Quellenentität befindet sich in wenigstens einem Quellencontainer. Ein Modul umfaßt wenigstens einen Quellencontainer und ist seinerseits in ein gesamtes Projekt integriert, Das Projekt ist das Zentrum der Quellcode- Verwaltung und enthält einen Arbeitssatz von Quellenentitäten.
In Fig. 7 stellt das Unterfenster 720 die Projektebene der Containment Hierarchie dar, wo verschiedene Module des Projektes "Online-Insultant" dargestellt werden. Ein zu dem Projekt Online-Insultant gehöriger Statusanzeiger 722 in der Leiste 725 zeigt an, daß die Projektebene die Basis des Unterfensters 720 ist. Ein Modul "Online-Insultant" ist aktiviert und hat seine Inhalte in einem Unterfenster 730 (die Modulebene der Hierarchie) dargestellt. Der Statusanzeiger 732 gehört zu dem Modul Online-Insultant in der Leiste 735. Verschiedene Quellencontainer sind in diesem Unterfenster 730 dargestellt, einschließlich einem ausgewählten Container "Engine".
Ein Unterfenster 730 zeigt diese Quellencontainer- Ebene "Engine" mit einem Statusanzeiger 742 in einer Leiste 745. Eine aktivierte Quellenentität "Zippy" ist unter den im Unterfenster 740 aufgelisteten Quellenentitäten (Ein Unterfenster 750, ähnlich dem Unterfenster 740, ist mit dem Unterfenster 740 überlappend gezeigt.)
Ein Merkmal der vorliegenden Erfindung ist, daß, wenn z. B. auf der Quellenentität-Ebene des Projekts eine Modifikation gemacht wird, die Statusanzeiger sich nach oben durch die Hierarchie bis zur Projektebene fortpflanzen und dabei den Programmierer informieren, daß jede dieser Ebenen eine Modifikation benötigt. Dementsprechend wird der Statusanzeiger 746 (vorzugsweise ein NICHT GESPEICHEET Anzeiger) für die Quellenentität "Zippy" dargestellt und zeigt an, daß sein Quellcode nicht gespeichert wurde. Da "Zippy" in dem Quellencontainer "Engine" enthalten ist, ist sein Statusanzeiger 742 im Unterfenster 740, sowie der Statusanzeiger 736 im Unterfenster 730 dargestellt. Das Modul "Online-Insultant", welches den Quellencontainer "Engine" umfaßt, hat auch seine Statusanzeiger 732 und 726 in den Unterfenstern 730 und 720 angezeigt, und schließlich, ist auch der Statusanzeiger 722 des Projekts "Online-Insultant" im Unterfenster 72 dargestellt. Derartige "Verknüpfung" (linking) zwischen den Unterfenstern 720-740 wird aufgrund der Inhalte der in dem Fensterobjekt 300 der Fig. 3 enthaltenen Datenstruktur 306 ermöglicht.
Fig. 8 zeigt einen Statusanzeiger-Gruppeneintrag 802, der auf einem Browse-Menü 800 dargestellt ist, das Browse- Menü ist vorzugsweise ein Pull-down-Menü, das von einer Menüleiste 810 verfügbar ist. Der "Statusanzeiger"-Eintrag 802 ist immer dann aktiv, wenn sich ein aktives Unterfenster im Fenster 820 befindet.
Auf Fig. 1-8 wird nun im Zusammenhang mit der im Flußdiagramm der Fig. 9 veranschaulichten Sequenz von Schritten Bezug genommen, um die Operation der verbesserten graphischen Benutzeroberfläche beim Aktivieren der Statusanzeiger zu beschreiben.
Um die in der seitlichen Feldleiste 620 eines aktiven Unterfensters dargestellten Statusanzeiger einzurichten (oder zu wechseln), beginnt die Sequenz bei Schritt 900 und fährt fort bis zu Schritt 902, wo ein Benutzer, der die Maus 130 zur Steuerung des Cursors 140 auf dem Anzeigebildschirm 135 bedient, mit dem Cursor auf das Browse-Menü 800 der Menüleiste 810 "zeigt". Der Benutzer "klickt" dann den Schalter 134 auf der Maus, um dieses Menü 800 anzuzeigen. Im Schritt g04 bedient der Benutzer die Maus so, daß der Cursor auf den "Statusanzeiger"-Gruppeneintrag 802 auf dem Menü 800 zeigt und klickt auf diesen Eintrag, um die Statusanzeiger-Dialogbox 500 anzuzeigen. Wie gesagt, werden die für ein bestimmtes Objekt abgebildeten Statusanzeiger vorzugsweise auf einer Unterfenster-für-Unterfenster-Basis bestimmt; dementsprechend bestimmt die durch den Benutzer getroffene Auswahl der Anzeiger, welche Anzeige in dem z. Zt. aktiven Unterfenster angezeigt werden.
Im schritt g06 aktiviert (oder deaktiviert) der Benutzer dann jeden der verfügbaren Statusanzeiger auf der Liste, indem er auf diese Anzeigerparametereinträge klickt. Die zum Anzeigen aktivierten Statusanzeiger-Parameter werden vorzugsweise durch die Anwesenheit von Häkchen- Markierungen 520 erkennbar. Der Benutzer klickt dann den "OK"-Knopf 530 unten in der Dialogbox 500 im Schritt 908, um das Anwendungsprogramm 308 dazu aufzurufen, auf die ausgewählten Parameter zu wirken. Als Reaktion führt im Schritt 91o die Anwendung 308 den vom Benutzer gelieferten spezifizierten Befehl aus und entfernt die Box 500 vom Bildschirm. Wenn der Benutzer jedoch den "Cancel"-Knopf 535 auswählt, verwirft die Anwendung jegliche durch den Benutzer seit der Anzeige der modalen Dialogbox vorgenommenen Änderungen, und entfernt dann die Box. Die Anwendung 308 modifiziert dann ein Unterfensterobjekt 350, das die ausgewählten Statusanzeiger-Parameter innerhalb der Inhalte seiner Datenstruktur 356 enthält, wie im Schritt 912 angezeigt. Die Routine endet dann im Schritt 914.
Wie vorstehend angemerkt, wirken ein Fensterobjekt und ein Unterfensterobjekt mit dem Fensterverwalter zusammen, um verschiedene Fensterverwaltungsfunktionen, wie z. B. Erzeugen eines Fensters und seiner Unterfenster, bereitzustellen. Eine beispielhafte Routine, die von einem Anwendungsprogramm verwendet wird, um ein Fenster und seine zugehörigen Unterfenster anzuzeigen, von denen die letzteren Statusanzeiger enthalten, ist in dem Flußdiagramm der Fig. 10 gezeigt. Die Routine beginnt im Schritt 1000 und fährt fort zu Schritt 1002, in welchem die das Fenster definierenden Parameter, z. B. seine Größe und Oberflächenelemente, zusammen mit einer Anfrage, ein neues Fenster zu erzeugen, vom Fensterobjekt an den Fensterverwalter geschickt werden (veranschaulicht als Pfeil 304 in Fig. 3). In Reaktion auf diese Anfrage erzeugt der Fensterverwalter ein Fenster (Schritt 1004) und fügt das neue Fenster zu der Fensterliste 310 hinzu. Uie Liste von erzeugten Fenstern erlaubt dem Fensterverwalter, die Positionen und Größen der Fenster zu verfolgen, die gezeichnet und wieder gezeichnet werden müssen, wenn Fenster in Verbindung mit Elementen der verbesserten graphischen Benutzeroberfläche der vorliegenden Erfindung erzeugt und gelöscht werden.
Im Schritt 1006 wird ein Unterfensterobjekt 350 in das Fensterobjekt 300 eingesetzt und im Schritt 1008 wartet das Fenstercbjekt auf ein Update-Ereignis von dem Fensterverwalter, das anzeigt, daß das Fenster und Unterfenster gezeichnet werden müssen. Der Fensterverwalter erzeugt derartige Update-Ereignisse, um die Anzeige der Fenster und Unterfenster zu koordinieren. Nach Empfang des Update- Ereignisses bestimmt das Fensterobjekt im Schritt 1010 die Breite der seitlichen Feldleiste, wobei es einen in der Liste 356 des Unterfensterobjekts gespeicherten Zählerstand von Statusanzeigeparametern verwendet, und schickt im Schritt 1012 entsprechende Zeichenbefehle an den Fensterverwalter, um das Unterfenster zu zeichnen und die seitliche Feldleiste anzuzeigen. Im Schritt 1014 bestimmt das Fensterobjekt 300 dann, welche Statusanzeiger für jedes in der Datenstruktur 356 des Unterfensterobjektes gespeicherte Objekt gezeigt werden soll und im Schritt 1016 sendet das Fensterobjekt entsprechende Zeichenbefehle an den Fensterverwalter, um diese Statusanzeiger anzuzeigen. Die Routine endet im Schritt 1018.
Ein Vorteil der vorliegenden Erfindung betrifft die Verwendung von visuellen positionsmäßigen Statusanzeigern, die jeder eine unterscheidbare Farbe, Form und/oder räumliche Position innerhalb der seitlichen Feldleiste aufweisen, um für den Benutzer die Notwendigkeit zu umgehen, zu jedem Anzeiger gehörigen Text zu lesen. Dies ist besonders wesentlich für einen Programmierer, der an dem Status von verschiedenen Objekten während der Softwareentwicklung in einer Programmierumgebung interessiert sein kann. Indem die Notwendigkeit, Text zu lesen, um den Status dieser Objekte zu bestimmen, beseitigt wird, kann der Programmierer nur einen kurzen Blick auf die visuellen Zeichen werfen und eine Interpretation ihrer Zustände an das Unterbewußtsein abladen, wobei zeitaufwendige und ineffiziente computerbezogene Befehle beseitigt werden.
Obgleich eine beispielhafte Ausführungsfarm für die Ausführung von Statusanzeigern auf einem Unterfenster eines Fensters als unterscheidbare visuelle Zeichen innerhalb einer Programmentwicklungsumgebung gezeigt und beschrieben wurden, versteht es sich von selbst, daß verschiedene andere Adaptionen und Modifikationen innerhalb des Geistes und des Schutzumfangs der Erfindung gemacht werden können. Zum Beispiel ist die Erfindung auch auf eine relationale Datenbankumgebung anwendbar, wo Benutzer sich Datensätze teilen müssen. In dieser Ausführungsform der Erfindung kann ein Benutzer durch Datensätze der Datenbasis durchscannen und einen Datensatz auf einem Bildschirm zum Editieren abrufen. Bevor das Editieren eingeleitet wird, können die hier beschriebenen Statusanzeiger so konfiguriert werden, daß sie sich auf alle Bildschirme von Benutzern fortpflanzen, die die Datenbasis benutzen, um sie von dem Datensatzzugriff zu informieren. Hier können die Statusanzeiger sich voneinander durch ihre Form, z. B. Quadrate, Dreiecke, Kreise etc., unterscheiden. In einer anderen Ausführungsform können diese Statusanzeiger in einer Netzwerkentwicklungsumgebung als ein Quellcode-Steuerungamechanismua verwendet werden, um Zugriff auf bestimmte Dateien zu steuern.

FIGURENLEGENDE

Fig. 1 MASS MEMORY (DISK) MASSENSPEICHER (PLATTE) I/O CIRCUITRY I/O-SCHALTUNG MEMORY SPEICHER
Fig. 2 OPERATING SYSTEM BETRIEBSSYSTEM APPLICATION PROGRAM ANWENDUNGSPROGRAMM WINDOW MANAGER FENSTERVERWALTER SCREEN BUFFER BILDSCHIRMPUFFER DISPLAY ADAPTER ANZEIGEADAPTER
Fig. 3 PANE OBJECT UNTERFENTEROBJEKT STATUS INDICATOR STATUSANZEIGER UND AND OBJECT LISTS OBJEKTLISTEN APPLICATION PROGRAM ANWENDUNGSPROGRAMM WINDOW OBJECT FENSTEROBJEKT PANE LIST UNTERFENSTERLISTE WINDOW MANAGER FENSTERVERWALTER WINDOW LIST FENSTERLISTE
Fig. 4 Project Browser Projekt-Browser Tiles Projekt Tiles-Projekt
Fig. 5 Status Indicators Statusanzeiger Shaw Zeige Unsaved Nicht gespeichert Uncompilad Nicht kompiliert Warnings Warnungen Read Only Nur-Lass Attendent Pfleger Other Andere Location Platz OK OK Header Kopf Body Hauptteil Cancel Abbrechen
Fig. 6 Untitled Unbenannt
Fig. 7 Active Projekt Aktives Projekt Untitled Unbenannt
Fig. 8 Hrowse Broween Debug Wind Fenster Debuggen New Browser Neuer Browser Save growser Broweer speichern Aspect Aspekt Pane Style Unterfenstereigensahaften Status Indicators Statusanzeiger Active Projekt Aktives Projekt Browsers Browser Duplicate Definitions Definitionen duplizieren Undefined Variables Undefinierte Variablen Unsaved Sourcas Nicht gespeicherte Quellen Warnings Warnungen Classes Klassen Functions Funktionen Project Projekt Variable Search Variierbare Suche Show Herne Zeige Home
Fig. 9
900 START START
902 USE CLICKS MOUSE TO DISPLAY BROWSE MENU BENUTZER KLICKT MAUS ZUM ANZEIGEN DES BROWSE-MENÜS
904 USER POINTS CURSOR AT "STATUS INDICATOR" GROUP ENTRY AND CLICKS MOUSE TO DISPLAY STATUS INDICATOR DIALOG BOX BENUTZER ZEIGT MIT DEM CURSOR AUF "STATUSANZEIGER" GRUPPENEINTRAG UND KLICKT MAUS ZUM ANZEIGEN DER STATUS-ANZEIGER-DIALOGBOX
906 USER SELECTS AVAILABLE STATUS INDICATOR PARAMETERS BY CLICKING MOUSE ON THOSE INDICATORS TO DISPLAY CHECK MARKS BENUTZER WELT VERFÜGBARE STATUSANZEIGER-PARANETER DURCH KLICKEN DER MAUS AUF DIESE ANZEIGER ZUM ANZEIGEN VON HÄKCHEN-MARKIERUNGEN AUS
908 USER CLICKS MOUSE ON "OK" BUTTON AT BOTTOM OF DIALOG BOX TO INVOKE APPLICATION PROGRAM TO ACT UPON THE SELECTED PARAMETERS BENUTZER KLICKT MIT DER MAUS AUF "OK"-KNOPF UNTEN IN DIALOGBOX, UM ANWENDUNGSPROGRAMM DAZU AUFZURUFEN, AUF DIE AUSGEWÄHLTEN PARAMETER ZU WIRKEN
910 THE APPLICATION PERFORMS THE SPECIFIED COMMANDS AND REMOVES THE DIALOG BOX ANWENDUNG FÜHRT DIE SPEZIFIZIERTEN BEFEHLE AUS UND ENTFERNT DIE DIALOGBOX
912 APPLICATION MODIFIES PANE OBJECT TRAT INCLUDES SELECTED STATUS INDICATOR WITHIN ITS DATAT STRUCTURE ANWENDUNG MODIFIZIERT UNTERFENSTEROBJEKT, DAS DIE AUSGEWÄHLTEN STATUSANZEIGER IN EINER DATENSTRUKTUR ENTHÄLT
914 FINISH ENDE
Fig. 10 10010 START START
1002
SEND WINDOW PARAMETERS AND REQUEST TO CREATE WINDOW FROM WINDOW OBJECT TO WINDOW MANAGER SENDE FENSTERPARAMETER UND ANFRAGE, FENSTER AUS FENSTEROBJEKT ZU ERZEUGEN, AN FENSTERVERWALTER
1004 WINDOW MANGER CREATES WINDOW AND ADDS IT TO WINDOW LIST FENSTERVERWALTER ERZEUGT FENSTER UND FÜGT ES ZUR FENSTERLISTE HINZU
1006 PANE OBJECT INSTALLED IN WINDOW OBJECT UNTERFENSTEROBJEKT WIRD IN FENSTEROBJEKT EINGESETZT
1005 WINDOW OBJECT WAITS FOR UPDATE EVENT FROM WINDOW MANAER FENSTEROBJEKT WARTET AUF UPDATE-EREIGNIS VON FENSTERVERWALTER
1010 WINDOW OBJECT DETERMINES WIDTH OF SIDE BAR PANEL FENSTEROBJEKT BESTIMMT DIE BREITE DER SEITLICHEN FELDLELISTE
1012 WINDOW OBJECT SENDS DRAWING COMMANDS TO WINDOW MANAGER TO DRAW PANE AND DISPLAY SIDE BE PANEL FENSTEROBJEKT SENDET ZEICHENBEFEHLE AN FENSTERVERWALTER, UM UNTERFENSTER ZU ZEICHNEN UND SEITLICHE FELDLEISTE ANZUZEIGEN
1014 WINDOW OBJECT DETERMINES STATUS INDICATORS FENSTEROBJEKT TO BE DISPLAYED BESTIMMT DIE ANZUZEIGENDEN STATUSANZEIGER
1016 WINDOW QBJECT SENDS DRAWING COMMANDS TO WINDOW MANAGER TO DISPLAY STATUS INDICATORS FENSTEROBJEKT SCHICKT ZEICHENBEFEHLE AN FENSTERVERWALTER, UM STATUSANZEIGER ANZUZEIGEN
1018 FINISH ENDE

Claims

1. Verbesserte graphische Benutzeroberfläche eines Computersystems (160) mit einem Anzeigemonitor (132) zum Anzeigen eines Cursors (140) auf einem Anzeigebildschirm (135), wobei zu dem Bildschirm eine Vorrichtung zum Steuern des Cursors (124,130) gehört und wobei die Oberfläche umfaßt:

ein Fenster (402) des Bildschirms (400), wobei das Fenster zur Aufteilung in wenigstens ein Unterfenster (404) zum Anzeigen von Objekten des Systems konfiguriert ist; und

Statusanzeigemittel (450) zum positionsmäßigen Anzeigen von zu den Objekten gehörenden Statusattributen, wobei das Statusanzeigemittel auf einer seitlichen Feldleiste (406) des Unterfensters angezeigt wird und wobei die seitliche Feldleiste eine dynamisch anpaßbare Breite aufweist, die dazu konfiguriert ist, sich in Reaktion auf die Menge der zum Anzeigen ausgewählten Statusattribute entweder zu erweitern oder zu verengen.

2. Verbesserte graphische Benutzeroberfläche nach Anspruch 1, wobei das Statusanzeigemittel unterscheidbare visuelle Zeichen umfaßt.

3. Verbesserte graphische Benutzeroberfläche nach Anspruch 2, wobei die visuellen Zeichen sich voneinander durch ihre Form unterscheiden.

4. Verbesserte graphische Benutzeroberfläche nach Anspruch 2, wobei die visuellen Zeichen sich voneinander durch ihre Farbe unterscheiden.

5. Verbesserte graphische Benutzeroberfläche Anspruch 4, welche weiterhin Mittel (500, 520,- 525, 535, 530) umfaßt, um das Statusanzeigemittel zum Anzeigen ausgewählter visueller Zeichen einzustellen.

6. Verbesserte graphische Benutzeroberfläche nach Anspruch 5, wobei das Statusanzeige-Einstellmittel (450) ein Statusanzeige-Dialogfeldelement (500) umfaßt, welches auf dem Anzeigebildschirm (135) angezeigt wird, wobei der Benutzer die Cursorsteuerungsvorrichtung (124, 130) bedient, um eine der Vielzahl von Statusanzeige-Parametereinträgen (510) auszuwählen, die in dem Dialogfeldelement angezeigt werden.

7. Verbesserte graphische Benutzeroberfläche nach Anspruch 6, wobei die visuellen Zeichen sich voneinander durch ihre relative räumliche Position entlang der dynamisch anpaßbaren seitlichen Feldleiste unterscheiden.

8. Computersystem (100) umfassend die verbesserte graphische Benutzeroberfläche nach Anspruch 1 zum Verbessern der Möglichkeit eines Benutzers, auf das System einzuwirken, wobei das Computersystem umfaßt: einen Prozessor (110);

ein Betriebssystem (204), welches mit dem Prozessor zusammenarbeitet, um den Anzeigebildschirm zu steuern;

ein von dem Betriebssystem erzeugtes Fensterverwaltungsobjekt (310), wobei das Fensterverwaltungsobjekt das Untertenster (404) zur Anzeige auf dem Anzeigebildschirm zeichnet;

ein Anwendungsprogramm (308) zum Erzeugen von Quellenentitäts-Objekten zur Anzeige in dem Unterfenster.

9. Computersystem nach Anspruch 8, wobei das Statusanzeigemittel Statusanzeiger (450) umfaßt, welche eine "blip"-artige Form aufweisen und sich von anderen Statusanzeigern durch ihre Farbe unterscheiden.

10. Computersystem nach Anspruch 8, wobei das Statusanzeigemittel Statusanzeiger (450) umfaßt, welche eine "blip"-artige Form aufweisen und sich von anderen Statusanzeigern durch ihre relative räumliche Position entlang der dynamisch anpaßbaren seitlichen Feldleiste unterscheiden.

11. Computersystem nach Anspruch 10, wobei das Statusanzeigemittel weiterhin ein Statusanzeige- Dialogfeldelement (500) zum Einstellen der Statusanzeiger in Reaktion auf die Bedienung der Cursorsteuerungsvorrichtung durch den Benutzer zum Auswählen eines einer Vielzahl von in dem Dialogfeldelement angezeigten Statusanzeige-Parametereinträgen umfaßt.

12. Computersystem nach Anspruch 11, welches weiterhin ein von dem Anwendungsprogramm (308) erzeugtes Fensterobjekt (300) umfaßt, wobei das Fensterobjekt mit dem Fensterverwaltungsobjekt (310) kommuniziert, indem es eine Folge von Zeichenbefehlen ausgibt, um das Unterfenster (404) anzuzeigen.

13. Computersystem nach Anspruch 12, welches weiterhin ein von dem Anwendungsprogramm (308) erzeugtes und in dem Fensterobjekt (350) gespeichertes Unterfensterobjekt (350) umfaßt, wobei das Unterfensterobjekt eine interne Datenstruktur (356) aufweist, welche eine Liste der ausgewählten Statusanzeige-Parametereinträge enthält.

14. Verfahren zum Verbessern der Möglichkeit eines Benutzers, auf ein Computersystem (100) mit einer verbesserten graphischen Benutzeroberfläche einzuwirken, wobei der Computer einen Anzeigemonitor (132) zum Anzeigen eines Cursors (140) auf einem Anzeigebiidschirm (135) umfaßt, zu dem eine Vorrichtung zum Steuern des Cursors (124, 130) gehört, wobei das Verfahren die folgenden Schritte umfaßt:

Erzeugen eines Fensterverwaltungsobjektes von einem Betriebssystem des Computers;

Zeichnen eines Unterfensters (404) zur Anzeige auf dem Anzeigebildschirm unter Verwendung des Fensterverwaltungsobjekts;

Erzeugen von Quellenentitäts-Objekten zur Anzeige in dem Unterfenster mit einem Anwendungsprogramm;

Auswählen von Statusanzeigeparametern von einem Statusanzeige-Dialogfeldelement (500) der verbesserten graphischen Benutzeroberfläche, das auf dem Anzeigebildschirm in Reaktion auf die Bedienung der Cursorsteuerungsvorrichtung durch den Benutzer angezeigt wird, wobei die Statusanzeigeparameter auf einer dynamisch anpaßbaren seitlichen Feldleiste (406) des Unterfensters positionsmäßig Statusattribute anzeigen, die zu den Quellenentitäts-Objekten gehören; und

entweder Erweitern oder Verengen der Breite der dynamisch anpaßbaren seitlichen Feldleiste in Reaktion auf die Menge der zur Anzeige ausgewählten Statusanzeigeparametern.

Verfahren nach Anspruch 14, welches weiterhin die folgenden Schritte umfaßt:

Erzeugen eines Fensterobjekts (300) von dem Anwendungsprogramm;

Ausgeben einer Folge von Zeichenbefehlen von dem Fensterobjekt an das Fensterverwaltungsobjekt, und

Anzeigen des Unterfensters (404) in Reaktion auf die Zeichenbefehle.

16. Verfahren nach Anspruch 15, welches weiterhin die folgenden Schritte umfaßt:

Erzeugen eines Unterfensterobjekts (350) von dem Anwendungsprogramm;

Speichern der ausgawählten Statusanzeigaparameter in einer Liste einer internen Datenstruktur (356) des Unterfensterobjekte;

Speichern des Unterfensterobjekts in dem Fensterobjekt; und

Übermitteln der Statusanzeigeparameter an das Fensterverwaltungsobjekt, wenn das Unterfenster angezeigt wird.