DE69620301T2

DE69620301T2 - Fensterverwaltung

Info

Publication number: DE69620301T2
Application number: DE69620301T
Authority: DE
Inventors: John Warren Trueblood
Original assignee: Sony Electronics Inc
Current assignee: Sony Electronics Inc
Priority date: 1995-06-07
Filing date: 1996-06-04
Publication date: 2002-11-21
Anticipated expiration: 2016-06-05
Also published as: EP0747805A1; US6031530A; JPH09146751A; US5675755A; CA2177801C; EP0747805B1; DE69620301D1; JP4076239B2; CA2177801A1

Description

Die vorliegende Erfindung betrifft Fensterverwaltung bzw. Fenstermanagement bei Computersystemen. Eine bevorzugte Ausführungsform der Erfindung betrifft ein Verfahren und Gerät zur Anzeige einer Klasse immer sichtbarer Fenster bei einem X-Windows-System.
Ein Fenster ist ein Benutzerschnittstellenobjekt, das eine Korrelation zwischen einem speziellen Datensatz und einem speziellen Schirmbereich herstellt. Wenn das Fenster nicht verborgen oder durch ein anderes Benutzerschnittstellenobjekt bedeckt ist, wird der Datensatz typischerweise im korrespondierenden Schirmbereich angezeigt. Es hat sich erwiesen, dass die Verwendung von Fenstern eine effektive Art und Weise der Informationskommunikation zu einem Computerbenutzer ist. Beispielsweise kann ein Wortverarbeitungssystem, das einem Benutzer das Öffnen mehrerer Dokumente erlaubt, ein separates Fenster zur Anzeige der Inhalte jeder der geöffneten Dokumente bereitstellen.
Zwecks zusätzlicher Flexibilität erlauben viele Fenstermanagementsysteme, dass sich Fenster zueinander überlappen. Zwei Fenster überlappen sich, wenn es eine Überschneidung zwischen Schirmbereichen, die den Fenstern zugeordnet sind, gibt. Werden die Inhalte zweier oder mehr sich überlappenden Fenstern im gemeinsamen Schirmbereich angezeigt, kann die Information verstümmelt und schwer lesbar erscheinen. Folglich muss das Fenstermanagementsystem festlegen, was in dem Bereich, der den sich überlappenden Fenstern gemeinsam ist, angezeigt werden soll.
Um dieses durch sich überlappende Fenster hervorgerufene Problem anzugehen, ordnen die meisten Fenstermanagementsysteme jedem Fenster eine Position in einer "Stapelordnung" zu. Wenn sich mehrere Fenster den gleichen Schirmbereich teilen, wird nur die Information aus dem Fenster, das die höhere Position in der Stapelordnung aufweist, im Schirmbereich angezeigt. Infolgedessen wird der mit dem gemeinsamen Schirmbereich korrespondierende Abschnitt des niedriger angeordneten Fensters von dem mit dem Schirmbereich korrespondierenden Abschnitt des höher angeordneten Fensters "bedeckt". Dies bewirkt, dass einem Benutzer das niedriger angeordnete Fenster so erscheint, als wäre es körperlich unter dem höher angeordneten Fenster.
Die meisten Fenstermanagementsysteme erlauben Benutzern, individuelle Fenster zu bewegen, in der Größe zu ändern bzw. zu skalieren und deren Stapelordnung zu ändern oder wechseln. Beispielsweise nimmt bei dem von Apple Computer Inc. erhältlichen System-7-Betriebssystem ein Fenster die höchste Position in der Stapelordnung ein, wenn ein Benutzer unter Verwendung einer Eingabeeinrichtung wie beispielsweise einer Maus oder einer Rollkugel bzw. einem Trackball auf einen Abschnitt des Fensters klickt. Ein Fenster wird durch Ziehen einer Ecke am Boden des Fensters, bis das Fenster die gewünschten Dimensionen hat, skaliert. Ein Fenster wird durch Ziehen der Titelleiste des Fensters zu einer neuen Position auf dem Anzeigeschirm bewegt.
Bei manchen Anwendungen kann es wichtig sein, sicherzustellen, dass eine gewisse Information für den Benutzer immer sichtbar ist. Wird jedoch die Information in einem Fenster bei einem System angezeigt, das ein Überlappen von Fenstern erlaubt, kann die wesentliche Information vor dem Benutzer verborgen werden. Beispielsweise kann die Information verdeckt werden, wenn der Benutzer eine gewisse Tätigkeit ausführt, die bewirkt, dass ein Fenster, das in der Stapelordnung höher ist, sich mit dem gegebenen Fenster überlappt. Es können viele Arten von Benutzertätigkeiten bewirken, dass diese Situation auftritt. Beispielsweise kann der Benutzer bewirken, dass ein sich schon überlappendes Fenster eine Position in der Stapelordnung einnimmt, die höher ist, als die Position des gegebenen Fensters. Alternativ dazu kann der Benutzer ein Fenster, das in der Stapelordnung schon höher ist, zu einer Schirmposition bewegen, die sich mit dem gegebenen Fenster überlappt.
Es sind verschiedene Versuche gemacht worden, um zu verhindern, dass in einem Fenster angezeigte wichtige Information vor dem Benutzer verborgen wird. Beispielsweise stellt PC Tools for Windows ein fensterbasiertes grafisches Desktop bereit, durch das ein Benutzer spezifizieren kann, dass ein Fenster immer oben bzw. "always on top" bleibt. Dem immer oben bleibenden Fenster bzw. "Always-on-top"- Fenster ist eine Position in der Stapelordnung zugeordnet, die höher als die gewöhnlichen Fenstern zugeordnete höchste Position ist. Wenn folglich ein beliebiges Fenster derart manipuliert wird, dass es sich mit dem "Always-on-top"- Fenster überlappt, bedeckt der Überlappungsabschnitt des "Always-on-top"-Fensters das andere Fenster im gemeinsamen Schirmbereich.
Diese Vorgehensweise arbeitet gut, solange es nur ein Fenster gibt, das kritische Information enthält. Ein Problem tritt jedoch auf, wenn mehr als ein "Always-on-top"- Fenster benötigt werden. Werden bei PC Tools for Windows zwei Fenster als "Always-on-top"-Fenster bezeichnet, verhalten sie sich zueinander so, wie es normale Fenster zueinander tun. Das heißt, ein "Always-on-top"-Fenster weist eine höhere Stapelordnungsposition als das andere auf. Wird bewirkt, dass sich die zwei "Always-on-top"-Fenster überlappen, deckt im gemeinsamen Schirmbereich das höher angeordnete Fenster das niedriger angeordnete Fenster ab. Die im abgedeckten Abschnitt enthaltene Information des niedriger angeordneten Fensters ist für den Benutzer nicht länger sichtbar. Werden infolgedessen mehr als ein "Always-on- top"-Fenster angezeigt, kann nicht sichergestellt werden, dass für den Benutzer kritische Information immer sichtbar ist.
Ein Weg zur Vermeidung dieses Problems ist, jedes Mal nur ein "Always-on-top"-Fenster zuzulassen. Beispielsweise beschreibt die französische Patentveröffentlichung Nr. 2 693 810 ein Fenstermanagementsystem, das nur ein Fenster erzeugt, welches von anderen Fenstern nicht verborgen werden kann. Wenn ein Benutzer ein zweites Fenster als ein nicht verbergbares Fenster bezeichnet, hört das erste nicht verbergbare Fenster auf, nicht verbergbar zu sein. Da dieses System nicht für mehrere nicht verbergbare Fenster sorgt, ist seine Anwendbarkeit beschränkt.
Ein in Research Disclosure, Dezember 1992/1993, Nr. 344, Emsworth, GB veröffentlichter Artikel mit dem Titel "Automatic Tiling of Arbitrary Objects" lehrt eine Methodologie, die ein Freigeben oder Sperren eines automatischen Verfliesungsmodus erlaubt. Bei Freigabe wird eine konfigurierbare Klasse von Objekten (beispielsweise Icons, Tafeln, Fenster usw.) automatisch derart bemessen, dass sich kein Objekt überlappt und eine vernünftige maximale Größe des Objekts erreicht wird.
Aus dem US Patent Nr. 4 783 548 geht ein Multifenstersystem hervor, bei dem mehrere Fenster auf einem Anzeigeschirm eingestellt sind. Wird nach einer Änderung der Anzeigepriorität der Fenster detektiert, dass bei Ausführung der Anzeigepriorität ein Fenster existiert, das von anderen Fenstern mit höherer Priorität vollständig bedeckt ist und vollständig vom Schirm verschwindet, wird das Fenster, das vollständig bedeckt würde, automatisch zu einer Position verschoben, bei der ein Teil dieses Fensters auf dem Schirm gesehen werden kann, wonach das Fenster auf dem Schirm angezeigt wird.
Die Erfindung ist in den unabhängigen Ansprüchen 1 und 14 dargelegt, wobei verschiedene spezifische Ausführungsformen in den abhängigen Ansprüchen definiert sind.
Ausführungsformen der vorliegenden Erfindung können ein Verfahren und Gerät zur Herstellung einer immer sichtbaren Klasse von Fenstern bzw. Klasse von Immersichtbarfenstern in einer Computerimplementierten Fenstertechnik bzw. Fensterumgebung herstellen. Ein Benutzer kann ein oder mehrere Fenster als immer sichtbare Fenster bzw. Immersichtbarfenster bezeichnen. Wenn ein Immersichtbarfenster und ein nicht immer sichtbares Fenster bzw. Nichtimmersichtbarfenster einander überlappen, wird das Immersichtbarfenster oben auf dem Nichtimmersichtbarfenster angezeigt. Es wird verhindert, dass Immersichtbarfenster einander überlappen. Es sind Techniken bereitgestellt, um die Klasse der Immersichtbarfenster derart zu implementieren, dass sie mit dem X-Windows-System verträglich ist. Gemäß einer Technik wird das Vorrangumleitungsattribut als ein Kennzeichen zum Bezeichnen, welche Fenster Immersichtbarfenster sind, benutzt. Gemäß einer alternativen Technik wird eine Liste aus Immersichtbarfenstern als eine an einem Wurzel- bzw. Grundfenster angebrachte Eigenschaft beibehalten.
Ausführungsformen der Erfindung können auch ein Verfahren zum Anzeigen von Information auf einer Anzeigeeinrichtung eines Computersystems bereitstellen. Gemäß dem Verfahren wird Information in mehreren Fenstern auf der Anzeigeeinrichtung gleichzeitig angezeigt. Die mehreren Fenster enthalten ein erstes Immersichtbarfenster. Mehrere Konfigurationen, die mit den mehreren Fenstern korrespondieren, werden beibehalten. Insbesondere wird die Konfiguration für jedes Fenster beibehalten, um die Stelle und die Abmessungen bzw. Dimensionen des Fensters auf der Anzeigeeinrichtung zu reflektieren.
Es wird ein Ereignis detektiert, das einen Abschnitt eines zweiten Fensters veranlasst, einen gemeinsamen Bereich auf der Anzeigeeinrichtung mit einem Abschnitt des ersten Immersichtbarfensters einzunehmen. Beim Detektieren eines solchen Ereignisses wird festgestellt, ob das zweite Fenster ebenfalls ein Immersichtbarfenster ist. Ist das zweite Fenster ein Immersichtbarfenster, wird die Konfiguration eines oder beider Fenster geändert, um ein Überlappen zwischen den Fenstern zu verhindern. Wenn das zweite Fenster kein Immersichtbarfenster ist, wird das erste Fenster über dem zweiten Fenster angezeigt.
Ausführungsformen der vorliegenden Erfindung können auch eine Stapelordnung bereitstellen, die für die mehreren Fenster beibehalten wird. Es wird eine Benutzereingabe empfangen, die das zweite Fenster veranlasst, eine höhere Position in der Stapelordnung zu haben als das erste Immersichtbarfenster. Ist das zweite Fenster kein Immersichtbarfenster, wird die Stapelordnung geändert, um das erste Immersichtbarfenster zu veranlassen, eine höhere Position in der Stapelordnung als das zweite Fenster zu haben.
Es können verschiedene Techniken zum Bezeichnen eines Fensters als ein Immersichtbarfenster verwendet werden. Gemäß einer Ausführungsform wird das beim X-Windows-System verwendete Vorrangumleitungsattribut als ein Kennzeichen zum Bezeichnen von Immersichtbarfenstern benutzt. Gemäß einer anderen Ausführungsform wird eine an dem Grundfenster angebrachte Eigenschaft als eine Immersichtbarfensterliste definiert. Zum Bezeichnen eines Fensters als Immersichtbarfenster wird zur Immersichtbarfensterliste ein Eingang bzw. eine Eingabe addiert, der bzw. die das Fenster identifiziert. Jede dieser beiden Techniken kann ohne Abweichung vom X-Windows-Standard verwendet werden.
Nachfolgend beschriebene bevorzugte Ausführungsformen der Erfindung stellen bereit:
Ein Fenstertechniksystem, das erlaubt, dass Information gleichzeitig in mehreren Immersichtbarfenstern angezeigt wird,
eine immer sichtbare Klasse von Fenstern in einem Fenstermanagementsystem, das mit den derzeitigen X-Windows- Standards konsistent ist, und
ein Fenstermanagementsystem, das Benutzern erlaubt, Fensterattribute einschließlich eines Immersichtbarattributs und eines Transparenthintergrundattributs zu kombinieren.
Die vorliegende Erfindung ist beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen dargestellt, in denen gleiche Bezugszeichen gleiche Elemente bezeichnen und in denen:
Fig. 1 ein Computersystem darstellt, auf das die bevorzugte Ausführungsform der vorliegenden Erfindung angewendet werden kann;
Fig. 2 eine Anzeigeeinrichtung darstellt, die gleichzeitig zwei Immersichtbarfenster und zwei normale Fenster auf einem Schirm gemäß einer Ausführungsform der Erfindung anzeigt;
Fig. 3 den Schirm nach Fig. 2 darstellt, nachdem der Benutzer ein normales Fenster, das sich mit einem Immersichtbarfenster überlappt, gewählt hat;
Fig. 4 den Schirm nach Fig. 2 darstellt, wenn der Benutzer sich im Prozess des Wählens und Vergrößerns eines normalen Fensters befindet, um das normale Fenster zu veranlassen, sich mit einem Immersichtbarfenster zu überlappen;
Fig. 5 den Schirm nach Fig. 2 darstellt, wenn die in Fig. 4 dargestellte Größenänderungs- bzw. Skalierungsoperation beendet ist;
Fig. 6 den Schirm nach Fig. 2 darstellt, wenn ein Benutzer versucht hat, ein Immersichtbarfenster in eine neue Position zu bewegen, die das Fenster veranlassen würde, ein anderes Immersichtbarfenster zu überlappen;
Fig. 7 den Schirm nach Fig. 2 nach der in Fig. 6 gezeigten Operation darstellt, zeigend, wie das bewegte Fenster nicht ein anderes Immersichtbarfenster überlappen darf;
Fig. 8 den Schirm nach Fig. 2 darstellt, wenn ein Benutzer versucht, ein Immersichtbarfenster derart zu skalieren, um das Immersichtbarfenster zu veranlassen, sich mit einem anderen Immersichtbarfenster zu überlappen;
Fig. 9 den Schirm nach Fig. 2 nach der in Fig. 8 gezeigten Operation darstellt;
Fig. 10 ein funktionelles Blockschaltbild eines Systems darstellt, das Immersichtbarfenster gemäß einer Ausführungsform der Erfindung implementiert;
Fig. 11 ein funktionelles Blockschaltbild eines Systems darstellt, das Immersichtbarfenster gemäß einer alternativen Ausführungsform der Erfindung implementiert;
Fig. 12a die Operation eines X-Client gemäß einer Ausführungsform der Erfindung darstellt;
Fig. 12b die Schritte zum Bezeichnen eines Immersichtbarfensters gemäß einer Ausführungsform der Erfindung darstellt;
Fig. 12c Schritte zum Bezeichnen eines Immersichtbarfensters gemäß einer alternativen Ausführungsform der Erfindung darstellt;
Fig. 13a die Operation eines Hilfsspeicher- bzw. Bump-Fenstermanagers gemäß einer Ausführungsform der Erfindung darstellt;
Fig. 13b die vom Bump-Fenstermanager ausgeführten Schritte zum Initialisieren einer Immersichtbarfensterliste darstellt;
Fig. 13c die vom Bump-Fenstermanager ausgeführten Schritte zum Bearbeiten der immer Sichtbarfensterliste zur Vermeidung einer Überlappung zwischen Immersichtbarfenstern darstellt;
Fig. 13d die vom Bump-Fenstermanager ausgeführten Schritte in Abhängigkeit von einer Detektion eines ein Fenster beeinflussenden Ereignisses darstellt; und
Fig. 13e eine Fortsetzung des in Fig. 13d dargestellten Flussdiagramms ist.
Es werden ein Verfahren und Gerät zum gleichzeitigen Anzeigen mehrerer Immersichtbarfenster beschrieben. In der folgenden Beschreibung sind zu Erläuterungszwecken zahlreiche spezielle Details dargelegt, um ein vollständiges Verständnis der vorliegenden Erfindung zu erzeugen. Es ist jedoch für den Fachmann einleuchtend, dass die vorliegende Erfindung ohne diese speziellen Details ausgeführt werden kann. In anderen Fällen sind wohlbekannte Strukturen und Einrichtungen in Blockschaltbildform gezeigt, um ein unnötiges Verundeutlichen der vorliegenden Erfindung zu vermeiden.
Bezugnehmend auf die Fig. 1 ist das Computersystem, bei dem die bevorzugte Ausführungsform der vorliegenden Erfindung implementiert werden kann, mit 100 bezeichnet. Das Computersystem 100 weist ein Bus oder eine andere Kommunikationseinrichtung 101 zur Informationskommunikation und eine an den Bus 101 gekoppelte Verarbeitungseinrichtung 102 zum Verarbeiten von Information auf. Das System 100 weist außerdem einen Direktzugriffsspeicher (RAM) oder eine andere dynamische Speichereinrichtung 104 (als Hauptspeicher bezeichnet) auf, der bzw. die an den Bus 101 zum Speichern von Information und von vom Prozessor 102 auszuführenden Befehlen auf. Der Hauptspeicher 104 kann auch zum zeitweiligen Speichern von Variablen oder Zwischeninformation während der Ausführung von Befehlen durch den Prozessor 102 verwendet werden. Das Computersystem 100 weist auch einen Nur-Lese-Speicher (ROM) und/oder eine statische Speichereinrichtung 106 auf, der bzw. die an den Bus 101 gekoppelt ist zum Speichern statischer Information und von Befehlen für den Prozessor 102 dient. An den Bus 101 ist zum Speichern von Information und Befehlen eine Datenspeichereinrichtung 107 gekoppelt.
Außerdem kann an das Computersystem 100 eine Datenspeichereinrichtung 107, beispielsweise eine Magnetplatte oder optische Platte und ihr korrespondierender Plattenantrieb gekoppelt sein. Das Computersystem 100 kann auch über den Bus 101 an eine Anzeigeeinrichtung 121 zur Anzeige von Information für einen Computerbenutzer, beispielsweise eine Kathodenstrahlröhre (CRT), gekoppelt sein. An den Bus 101 ist typischerweise eine alphanumerische Eingabeeinrichtung 122, die alphanumerische oder andere Tasten aufweist, gekoppelt, Information und Befehlsauswahlen zum Prozessor 102 zu übertragen. Eine andere Art Benutzereingabeeinrichtung ist eine Cursorsteuerung 123, beispielsweise eine Maus, ein Trackball oder Cursorrichtungstasten, um Richtungsinformation und Befehlsauswahlen zum Prozessor 102 zu übertragen und um eine Cursorbewegung auf dem Display bzw. der Anzeige 121 zu steuern. Diese Eingabeeinrichtung hat typischerweise zwei Freiheitsgrade auf zwei Achsen, einer ersten Achse (beispielsweise x) und einer zweiten Achse (beispielsweise y), die es der Einrichtung erlauben, Positionen in einer Ebene zu spezifizieren.
Alternativ dazu können andere Eingabeeinrichtungen wie beispielsweise ein Schreiber bzw. Schreibstift bzw. Stylus oder eine Schreibfeder bzw. Pen zum Zusammenwirken mit der Anzeige verwendet werden. Ein auf einem Computerschirm angezeigtes Objekt kann durch Verwendung eines Stylus oder einer Pen zum Berühren des angezeigten Objekts gewählt werden. Der Computer detektiert die Wahl durch Implementieren eines berührungsempfindlichen Schirms. Ähnlich können ein Lichtgriffel bzw. -schreiber bzw. eine Lichtpen und ein lichtempfindlicher Schirm zum Wählen eines angezeigten Objekts verwendet werden. Solche Einrichtungen können dementsprechend eine Wählposition und die Wahl mit einer einzigen Operation anstelle des "Zeigens und Klickens" wie bei einem eine Maus oder einen Trackball inkorporierenden System detektieren. Auf Stylus und Pen basierende Eingabeeinrichtungen sind ebenso wie berührungs- und lichtempfindliche Schirme im Stand der Technik wohlbekannt. Bei einem solchen System kann auch eine Tastatur wie beispielsweise die Tastatur 122 fehlen, wobei die gesamte Schnittstelle über den Stylus als Schreibinstrument (so wie eine Pen) bereitgestellt ist und der geschriebene Text unter Verwendung von optischen Zeichenerkennungstechniken (OCR-Techniken) interpretiert wird.
Die vorliegende Ausführungsform betrifft die Verwendung von Computersystemen 100 als einer Plattform zum Ausführen von Anwendungsprogrammen, welche die Anzeige mehrerer Immersichtbarfenster unterstützen. Die bevorzugte Ausführungsform der vorliegenden Erfindung ist zur Verwendung mit dem X-Windows-System entwickelt worden. Das X-Windows- System wurde ursprünglich von der MIT's Projekt Athena and Digital Equipment Corporation entwickelt und wird jetzt vom X-Consortium gemanagt. Das X-Windows-System ist detailliert in Xlib Referenz Manual, Volumes 1 and 2, O'Reilly & Associates, Inc. (1995) beschrieben.
Beim X-Windows-System ist Funktionalität zwischen Clientanwendungen und einer Serveranwendung verteilt. Die Client- und Serveranwendungen können auf einem einzelnen Prozessor oder einer einzelnen Arbeitsstation ausgeführt werden, oder sie können zwischen mehreren Prozessoren auf mehreren Arbeitsstationen, die über ein Netzwerk verbunden sind, verteilt sein.

Clientanwendungen

Die Clientanwendungen übertragen Anfragen bzw. Anforderungen zur Serveranwendung. Die Anforderungen können Anforderungen für die Ausführung einer spezifizierten Operation oder Anforderungen für Information enthalten. Die Serveranwendung reagiert auf die Anforderungen durch Ausführen der spezifizierten Operation oder durch Senden einer Antwort zur Clientanwendung, welche die angeforderte Information enthält.

Serveranwendungen

Zusätzlich zu Serveranforderungen sendet die Serveranwendung Ereignismeldungen und Fehlermeldungen zu den Clientanwendungen. Ereignismeldungen informieren die Clientanwendungen darüber, dass ein gewisses Ereignis aufgetreten ist. Typischerweise sind die Clientanwendungen so ausgebildet, dass sie bei Empfang gewisser Ereignismeldungen eine gewisse Aktion ausführen. Fehlermeldungen teilen dem Client mit, dass eine vorhergehende Anforderung des Client ungültig war.
Die Serveranwendung erhält komplexe Abstraktionen von Ressourcen aufrecht. Solche Ressourcen können beispielsweise Fenster, Bild- bzw. Pixkarten, Farbkarten, Cursor, Schriftarten bzw. Fonts und Grafikkontexte enthalten. Die Abstraktionen für eine Ressource enthält Attribute für die Ressource. Beispielsweise enthält die Abstraktion für ein Fenster Information über die Größe, Position, Randbreite und Stapelordnung des Fensters (die "Konfiguration" des Fensters).
Da die Abstraktionen mit dem Server aufrecht erhalten werden, ist nur eine Kopie der Abstraktionen erforderlich, ungeachtet dessen, wie viele Clients die Ressourcen benutzen. Da Clients keinen Zugriff auf die Abstraktionen selbst haben, müssen die Clients Anforderungen an die Serveranwendung übertragen, um Information über die Ressourcen wiederzugewinnen. Wenn ein Client eine Anforderung überträgt, die eine Ressource betrifft, identifiziert der Client die Ressource mit einer ganzzahligen Kennung bzw. ID, die mit der Ressource korrespondiert. Da nur eine ganzzahlige ID und nicht eine komplexe Abstraktion gesendet wird, ist der Verkehr zwischen den Clients und dem Server reduziert.

Der Fenstermanager

Eine Speziellzweck-Clientanwendung betrifft den Fenstermanager. Der Fenstermanager ist eine Clientanwendung, die gewisse spezielle Zuständigkeiten aufweist. Insbesondere vermittelt der Fenstermanager konkurrierende Befehle für die physikalischen Ressourcen einer den Schirmraum und die Farbtabelle bzw. Farbkarte enthaltenden Anzeige. Typischerweise veranlasst der Fenstermanager die Serveranwendung, eine Benutzerschnittstelle zu erzeugen, die es einem Benutzer erlaubt, Fenster auf dem Schirm herumzubewegen, Fenster zu skalieren und neue Anwendungen zu starten.
Fordert eine Clientanwendung eine Änderung der Konfiguration eines Fensters an, so sendet die Clientanwendung eine Anforderung an den Server. Da jedoch die Anforderung eine vom Fenstermanager gesteuerte Zuständigkeit betrifft, bedient die Serveranwendung die Anforderung nicht. Anstelle dessen beseitigt die Serveranwendung die Anforderung und überträgt eine die Argumente der Rekonfigurationsanforderung enthaltende Ereignismeldung zum Fenstermanager, um den Fenstermanager von der Rekonfigurationsanforderung zu informieren. Der Fenstermanager bestimmt dann, ob die in der Rekonfigurationsanforderung spezifizierten Modifikationen ausgeführt, modifiziert oder verweigert werden sollen. Bestimmt der Fenstermanager, dass die Modifikationen ausgeführt werden sollen, sendet der Fenstermanager die Rekonfigurationsanforderung an den Server. Da die Rekonfigurationsanforderung vom Fenstermanager stammt, bedient der Server die Rekonfigurationsanforderung. Bestimmt der Fenstermanager, dass die Rekonfigurationsanforderung modifiziert werden soll, sendet der Fenstermanager eine modifizierte Rekonfigurationsanforderung an die Serveranwendung. Der Prozess des Sendens von Rekonfigurationsanforderungen an den Fenstermanager zur Genehmigung bevor der Server auf die Rekonfigurationsanforderungen einwirkt, wird als Substrukturumleitung bezeichnet.

Fensterattribute

Wie oben erwähnt hält die Serveranwendung komplexe Datenstrukturen aufrecht, die Information über Ressourcen enthalten. Zusätzlich zu einer Fensterkonfiguration enthält die Datenstruktur für ein Fenster Information darüber, wie das Fenster auszusehen und zu agieren hat. Diese Information wird als Fensterattribute bezeichnet. Ein Attribut eines Fensters wird als Substrukturumleitungs-Aufhebung bzw. Substructure Redirect Override bezeichnet. Das Substructure-Redirect-Override-Attribut bestimmt, ob ein Fenster ohne Intervention durch den Fenstermanager auf dem Schirm abgebildet werden darf.

Immersichtbarfenster

Die vorliegende Ausführungsform erlaubt es einer Clientanwendung, Immersichtbarfenster, d.h. Fenster, die immer sichtbar sind, zu erzeugen und anzuzeigen. Es können mehrere Immersichtbarfenster gleichzeitig existieren, ohne dass die Eigenschaft des Immersichtbarseins des Fensters aufgehoben wird. Die Immersichtbarfenster können auch mit einer beliebigen Zahl normaler Fenster gleichzeitig existieren. In diesem Zusammenhang betreffen normale Fenster alle Fenster, die nicht Immersichtbarfenster sind. Das generelle Verhalten von Immersichtbarfenstern wird nun unter Bezugnahme auf die Fig. 2 bis 8 beschrieben.

Fensterverhalten

Gemäß der bevorzugten Ausführungsform der Erfindung wird das Fensterverhalten durch zwei einfache Regeln beherrscht. Erstens werden normalen Fenstern niemals höhere Positionen in der Stapelordnung gegeben als Immersichtbarfenstern. Dies hat zur Folge, dass kein Abschnitt eines Immersichtbarfensters jemals von einem normalen Fenster bedeckt oder verborgen wird. Zweitens werden Immersichtbarfenster daran gehindert, einander zu überlappen. Dies hat zur Folge, dass kein Abschnitt eines Immersichtbarfensters jemals von irgendeinem anderen Immersichtbarfenster bedeckt oder verborgen wird.
Diese Regeln sind in den Fig. 2 bis 9 dargestellt. Bezugnehmend auf die Fig. 2 stellt diese ein Anzeigeeinrichtung 200 dar, die gleichzeitig zwei Immersichtbarfenster 204 und 206 und zwei normale Fenster 208 und 210 auf einem Schirm 202 anzeigt. Auf dem Schirm 202 ist auch ein visueller Zeiger 212 gezeigt. Der visuelle Zeiger 212 wird von einem Benutzer zum Zeigen auf eine Stelle auf dem Schirm 202 verwendet. Der visuelle Zeiger 212 bewegt sich in Abhängigkeit von einer Benutzermanipulation einer Benutzereingabeeinrichtung, beispielsweise eine Maus oder ein Trackball, über den Schirm 202.
In dem in Fig. 2 gezeigten Zustand des Schirms 202 überlappen sich das Fenster 210 und das Fenster 208 und das Fenster 210 deckt einen Abschnitt des Fensters 208 ab. Die Fenster 204 und 206 überlappen Abdeckungsabschnitte des Fensters 210. Von den Fenstern 204 und 206 werden keine Abschnitte von irgendwelchen anderen Fenstern abgedeckt.
Wie oben erwähnt, hängt die Feststellung, welches Fenster das andere überlappt, von der laufenden Position der Fenster in der Stapelordnung ab. Das Fenster, das in der Stapelordnung höher ist, wird im Überlappungsbereich angezeigt, wobei die Fenster abgedeckt werden, die in der Stapelordnung niedriger sind. Folglich zeigt der Zustand des Schirms 202 in Fig. 2 an, dass das Fenster 210 in der Stapelordnung derzeit bzw. laufend höher ist als das Fenster 208, und dass die Fenster 204 und 206 in der Stapelordnung laufend höher sind als das Fenster 210.
Es können zahlreiche Fenstermanipulationsoperationen bewirken, dass sich zwei Fenster überlappen. Beispielsweise kann ein Fenster von einer Stelle auf dem Schirm 202 zu einer anderen Stelle 202 bewegt werden. Außerdem kann ein Fenster in der Größe verändert bzw. skaliert werden, um einen größeren Abschnitt des Schirms 202 zu bedecken. Andere Fenstermanipulationsoperationen ändern die Stapelordnung. Wird die Stapelordnung geändert, um ein Fenster, das von einem anderen Fenster bedeckt ist, in der Stapelordnung höher zu platzieren als das Fenster, das es bedeckt, wird das Fenster neu aufgebaut, um das andere Fenster zu bedecken. Bei typischen Fenstertechniksystemen muss ein Fenster gewählt werden, bevor es manipuliert werden kann. Der Wählprozess kann beispielsweise das Betätigen einer Benutzereingabeeinrichtung zum Positionieren des visuellen Zeigers 212 über einem visuellen Abschnitt eines Fensters und das Ausführen einer vordefinierten Benutzereingabeoperation (beispielsweise ein Klicken einer Maustaste) umfassen. Bei typischen Fenstertechniksystemen platziert die Wahl eines Fensters automatisch das Fenster in der Stapelordnung ganz oben. Wie nun unter Bezugnahme auf die Fig. 3 bis 8 beschrieben wird, modifiziert jedoch die vorliegende Erfindung dieses Standardfenstertechnikverhalten, um Immersichtbarfenster zu erhalten oder unterstützen.
Fig. 3 stellt einen Schirm 202 dar, nachdem ein Benutzer das Fenster 210 gewählt hat. Die derzeit abgedeckten Ränder des Fensters 210 sind durch gestrichelte Linien dargestellt. Wie oben erwähnt würde bei einem typischen Fenstertechniksystem die Wahl des Fensters 210 das Fenster 210 veranlassen, sich in der Stapelordnung in die höchste Position zu bewegen. Deshalb würde das Fenster 219 neu aufgebaut, um die Abschnitte der anderen Fenster, mit denen es sich überlappt, abzudecken. Gemäß der vorliegenden Ausführungsform jedoch wird ein normales Fenster wie beispielsweise das Fenster 210 in der Stapelordnung niemals in eine höhere Position bewegt, als irgendein derzeit existierendes Immersichtbarfenster. Folglich würde die Wahl des Fensters 210 nicht das Fenster 210 veranlassen, sich in der Stapelordnung über die Fenster 204 und 206 zu bewegen. Deshalb würde nach der Wahl des Fensters 210 der Schirm 202 noch wie in der Fig. 2 dargestellt mit den von Abschnitten der Fenster 204 und 206 bedeckten Abschnitten des Fensters 210 erscheinen. Infolgedessen veranlasst die Wahl eines normalen Fensters, das sich mit einem oder mehreren Immersichtbarfenstern überlappt, das Normalfenster nicht, in der Stapelordnung höher als die Immersichtbarfenster bewegt zu werden.
Bezugnehmend auf die Fig. 4 stellt diese eine Situation dar, bei der ein Benutzer das Fenster 208 gewählt und vergrößert hat. Normalerweise würde die Wahl von 208 das Fenster 208 veranlassen, sich in der Stapelordnung in die höchste Position zu bewegen. Jedoch auf der Basis der bei der vorliegenden Ausführungsform implementierten Fensterverhaltensregeln wird das Fenster 208 in der Stapelordnung relativ zu anderen normalen Fenstern in der höchsten Position platziert, bleibt jedoch in der Stapelordnung relativ zu allen existierenden Immersichtbarfenstern niedriger. Folglich würde nach der Skalierung des Fensters 208 wie in Fig. 4 dargestellt der Schirm 202 wie in Fig. 5 dargestellt erscheinen. Insbesondere würde das Fenster 208 in der Stapelordnung höher platziert als das Fenster 210, jedoch noch niedriger als die Fenster 204 und 206. Infolgedessen würden die Fenster 204 und 206 das Fenster 208 noch bedecken, jedoch würde das Fenster 208 jetzt das Fenster 210 bedecken.
Fig. 6 stellt einen Versuch dar, zwei Immersichtbarfenster zu veranlassen, sich zu überlappen. Insbesondere stellt Fig. 6 die Situation dar, bei der ein Benutzer versucht hat, das Fenster 206 in eine neue Position auf dem Schirm 202 zu bewegen, die das Fenster 206 veranlassen würde, sich mit dem Fenster 204 zu überlappen. Wie oben erwähnt hindert die vorliegende Ausführungsform zwei Immersichtbarfenster daran, sich zu überlappen. Folglich wird das vom Benutzer manipulierte Immersichtbarfenster anders als das Anzeigefenster 206 in der vom Benutzer angezeigten Position in die nächste nicht überlappende vorhergehende Position zurückbewegt. Der Effekt dieses Verhaltens ist, dass zwei Immersichtbarfenster so erscheinen, dass sie anstelle sich zu überlappen aneinander stoßen. Fig. 7 stellt die Position des Fensters 206 nach der bei Fig. 6 ausgeführten Operation dar. Insbesondere ist das Fenster 206 jetzt neben dem Fenster 204, überlappt es jedoch nicht. Es sei darauf hingewiesen, dass in der Stapelordnung die Position eines Immersichtbarfensters in Bezug auf andere Immersichtbarfenster irrelevant ist, da sich Immersichtbarfenster niemals überlappen dürfen.
Fig. 8 stellt einen Versuch dar, ein Immersichtbarfenster derart zu skalieren, dass das Immersichtbarfenster veranlasst wird, sich mit einem anderen Immersichtbarfenster zu überlappen. Insbesondere ist das Fenster 206 skaliert worden, um sich mit dem Fenster 204 zu überlappen. Wie bei dem vorherigen Beispiel reagiert die vorliegende Ausführungsform durch Begrenzung der Skalierungsoperation des Fensters 206 auf die nächste nicht überlappende vorherige Position. Dies könnte beispielsweise in den in Fig. 9 dargestellten Fensterpositionen resultieren.
Es sei darauf hingewiesen, dass ein Bewegen des bearbeiteten Immersichtbarfensters zurück in die nächste nicht überlappende vorherige Position nur eine von mehreren möglichen Techniken zum Implementieren der vorliegenden Erfindung ist. Beispielsweise können Überlappungen zwischen Immersichtbarfenstern auch dadurch verhindert werden, dass das bearbeitete Immersichtbarfenster nach jeder Operation, die andernfalls das Immersichtbarfenster veranlassen würde, sich mit einem anderen Immersichtbarfenster zu überlappen, in seinen Anfangszustand zurückgebracht wird.
Alternativ dazu kann ein Überlappen zwischen Immersichtbarfenstern dadurch verhindert werden, dass die Bewegung eines Immersichtbarfensters zum "Stoßen" anderer Immersichtbarfenster aus ihren derzeitigen Positionen erlaubt wird. Versucht infolgedessen ein Benutzer, das Fenster 206 in Fig. 9 aufwärts zu bewegen, würde sich das Fenster 204 zusammen mit ihm aufwärts bewegen. Vorzugsweise würde diese Repositionierung der Fenster 204 und 206 nach oben angehalten, sobald das Fenster 204 den Rand des Schirms 202 erreichte. Die "Stoß"-Technik zur Verhinderung einer Überlappung zwischen den Immersichtbarfenstern erfordert Fenstermanagementroutinen, die komplexer sind, als sie bei anderen Überlappungsverhinderungstechniken erforderlich sind. Diese Komplexität hat den Grund in der Tatsache, dass die Bewegung eines Immersichtbarfensters die Bewegung einer beliebigen Zahl anderer Immersichtbarfenster benötigt (beispielsweise stößt das Fenster A das Fenster B, welches die Fenster C und D usw. stößt). Die vorliegende Erfindung ist nicht auf eine spezielle Art und Weise der Implementierung der oben beschriebenen Fensterverhaltensregeln beschränkt.

Allgemeine Systembeschreibung

Fig. 10 stellt ein funktionelles Blockschaltbild eines Computersystems 1000 zur Implementierung des oben beschriebenen Fensterverhaltens dar. Das Computersystem 1000 weist eine Anzeigeeinrichtung 1002, eine Eingabeeinrichtung 1004 und ein Fenstermanagementsystem 1006 auf. Das Fenstermanagementsystem 1006 managt die auf der Anzeigeeinrichtung 1002 angezeigten Fenster. Bei dem dargestellten Beispiel sind auf der Anzeigeeinrichtung 1002 drei Fenster 1008, 1010 und 1012 laufend angezeigt.
Das Fenstermanagementsystem 1006 enthält generell einen Speicher 1014, eine Fensteranzeigeeinheit 1018 und eine Eingabeempfangseinheit 1020. Der Speicher 1014 enthält mehrere Attribute 1022, 1024 und 1026 der auf der Anzeigeeinrichtung 1002 angezeigten Fenster. Die im Speicher 1014 gespeicherten Attribute 1022, 1024 und 1026 zeigen für jedes Fenster eine Stapelordnungposition, eine Schirmposition, eine Größe (enthaltend die vertikale und horizontale Abmessung) und, ob das Fenster ein Immersichtbarfenster ist, an.
Ein "Always-visible"- bzw. "Immersichtbar"-Attribut ist keines der normalen Fensterattribute, die in der X- Windows-Spezifikation definiert und unterstützt sind. Folglich würde ein System, das ein separat definiertes Immersichtbar-Attribut enthält, eine Erweiterung des X-Windows- Systems bilden, welches das System zu anderen Systemen inkompatibel macht. Deshalb existiert das Immersichtbar- Attribut bei der bevorzugten Ausführungsform nicht als ein separat definiertes Fensterattribut. Vielmehr werden Attribute und/oder Eigenschaften, die im X-Windows-System vorhanden sind, zum Speichern des Wertes des Immersichtbar- Attributs verwendet. Gemäß einer Ausführungsform wird das "Override-redirect"- bzw. "Überlagerungsumleitungs"- Attribut, das bei der X-Windows-Spezifikation definiert ist, als ein "Immersichtbar"-Kennzeichen verwendet. Bei einer alternativen Ausführungsform wird eine Liste als eine Eigenschaft eines Grundfensters angebracht und zum Identifizieren von Immersichtbarfenstern verwendet. Diese Ausführungsformen werden unten detaillierter beschrieben.
Fig. 10 stellt die Ausführungsform dar, bei der das Überlagerungsumleitungsattribut als ein Immersichtbarfensterkennzeichen verwendet ist. Bei dem dargestellten Beispiel enthalten die Attribute 1022 Daten, die anzeigen, dass das Fenster 1008 kein Immersichtbarfenster ist und dass das Fenster 1008 in der Stapelordnung das dritte ist. Die Attribute 1024 enthalten Daten, die anzeigen, dass das Fenster 1010 kein Immersichtbarfenster ist und dass das Fenster 1010 in der Stapelordnung das zweite ist. Die Attribute 1026 enthalten Daten, die anzeigen, dass das Fenster 1012 ein Immersichtbarfenster ist und dass das Fenster 1012 in der Stapelordnung das erste ist.
Die Fensteranzeigeeinheit 1018 veranlasst die Anzeigeeinrichtung 1002, die Fenster 1008, 1010 und 1012 auf der Basis der im Speicher 1014 gespeicherten Attribute 1022, 1024 und 1026 anzuzeigen. Wenn Abschnitte von zwei oder mehr Fenstern auf der Anzeigeeinrichtung 1002 sich einen gemeinsamen Schirmbereich teilen, veranlasst die Fensteranzeigeeinheit 1018 die Anzeigeeinrichtung 1002, den gemeinsamen Schirmbereich des Abschnitts desjenigen Fensters der zwei oder mehreren Fenster anzuzeigen, das in der Stapelordnung eine höhere Position als die anderen Fenster hat. Beispielsweise überlappen sich die Fenster 1008 und 1010. Da das Fenster 1010 in der Stapelordnung höher ist als das Fenster 1008, wird das Fenster 1010 im Überlappungsbereich angezeigt.
Die Eingabeempfangseinheit 1020 ist mit der Eingabeeinrichtung 1004 verbunden und empfängt eine Eingabe von einem Benutzer. Die Eingabe kann beispielsweise eine Eingabe sein, die Änderungen der im Speicher 1014 gespeicherten Attribute anzeigt. Die Fensteranzeigeeinheit 1018 enthält mehrere Einheiten zur Verarbeitung der Attributänderungen. Insbesondere enthält die Fensteranzeigeeinheit 1018 eine Überlappungsverarbeitungseinheit 1028, eine Überlappungskorrektureinheit 1030, eine Stapelordnungsverarbeitungseinheit 1032 und eine Stapelordnungskorrektureinheit 1034.
Die Überlappungsverarbeitungseinheit 1028 bestimmt, ob die Änderungen zwei oder mehr Immersichtbarfenster veranlassen, sich zu überlappen. Die Überlappungskorrektureinheit 1030 ändert die mehreren Attribute 1022, 1024 und 1026 so, wie sie zum Verhindern einer Überlappung zwischen Immersichtbarfenstern notwendig sind. Die Stapelordnungsverarbeitungseinheit 1032 bestimmt, ob die Änderungen ein Immersichtbarfenster veranlassen, eine niedrigere Position in der Stapelordnung als jedes Fenster, das kein Immersichtbarfenster ist, zu haben. Die Stapelordnungskorrektureinheit 1034 ändert die Attribute 1022, 1024 und 1026 so, wie sie zum Verhindern, dass das Immersichtbarfenster in der Stapelordnung eine niedrigere Position als jedes Fenster, das kein Immersichtbarfenster ist, notwendig ist.
Wie oben beschrieben kooperieren die Überlappungsverarbeitungseinheit 1028 und die Überlappungskorrektureinheit 1030, um sicherzustellen, dass Immersichtbarfenster niemals durch andere Immersichtbarfenster verborgen werden. Ähnlich kooperieren die Stapelordnungsverarbeitungseinheit 1032 und die Stapelordnungskorrektureinheit 1034, um sicherzustellen, dass Immersichtbarfenster nie durch irgendein Fenster, das kein Immersichtbarfenster ist, verborgen werden. Folglich werden auf der Anzeigeeinrichtung 1002 angezeigte Immersichtbarfenster nie durch irgendwelche andere Fenster verdeckt.

Client-basierte Implementierung

Wie oben erläutert steuern beim X-Windows-System Fenstermanager-Clients typischerweise die Regeln, welche die Benutzerschnittstellenaktivität regieren. Alle Anforderungen zum Beeinflussen des Verhaltens oder Aussehens von Fenstern gehen vom Fenstermanager zuerst durch die Substrukturumleitung. Derzeitige Fenstermanager unterstützen das Verhalten von oben beschriebenen Immersichtbarfenstern nicht. Folglich überlagert eine Ausführungsform der vorliegenden Erfindung eine Substrukturumleitung für Immersichtbarfenster durch Setzen des Substructur-Override-Redirect- Attributs von Immersichtbarfenstern. Da das Substructur- Override-Redirect-Attribut nur für Immersichtbarfenster gesetzt wird, dient der Wert des Substructur-Override- Redirect-Attributs auch als ein Kennzeichen zum Unterscheiden von Immersichtbarfenstern von normalen Fenstern.
Wenn einmal eine die vorliegende Erfindung implementierende Clientanwendung die Immersichtbarfenster wie oben beschrieben identifiziert hat, behält der Client seine eigene Liste von Immersichtbarfenstern bei. Die Liste enthält Information über jedes Immersichtbarfenster, darunter die Fenster-ID, den Ort und die Dimensionen des Fensters.
Der Client verfolgt dann alle Grafikereignisse, welche die Sichtbarkeit der Immersichtbarfenster beeinflusst. Würde irgendein Grafikereignis veranlassen, dass irgendein Abschnitt eines Immersichtbarfensters verborgen wird, modifizierte der Client das Ereignis, um die oben beschrieben Fensterverhaltensregeln zu erzwingen. Insbesondere detektiert der Client, wenn ein normales Fenster ganz oben in der Stapelordnung platziert ist und überträgt unmittelbar Anforderungen, die veranlassen, dass alle Immersichtbarfenster in der Stapelordnung höher platziert sind als das normale Fenster. Der Client detektiert auch, wenn ein Immersichtbarfenster bewegt oder skaliert wird. Die neue Position und Größe werden mit allen anderen Immersichtbarfenstern verglichen. Wenn die Fensterbewegung oder -größenänderung das Immersichtbarfenster veranlasst, sich mit einem oder mehreren anderen Immersichtbarfenstern zu überlappen, überträgt der Client eine Anforderung zum Repositionieren oder Skalieren des Immersichtbarfensters bei der nächsten Nichtüberlappungsposition.

Fenstermanager-basierte Implementierung

Eher als die vorliegenden Erfindung bei einer Clientanwendung zu implementieren, die den Fenstermanager, um Immersichtbarfenster zu implementieren, umgeht, kann die vorliegende Erfindung in einem Fenstermanager implementiert werden. Ähnlich wie bei der Clientimplementierung würde der Fenstermanager eine Liste der Immersichtbarfenster und entgegenwirkenden Ereignisse, die jeden Abschnitt eines Immersichtbarfensters veranlassen würden, abgedeckt oder verborgen zu werden, aufrechterhalten. Um jedoch zu andere Clients an der Ausführung von Operationen zu hindern, die einen Abschnitt eines Immersichtbarfensters verbergen, würde ein von der Substructur-Override-Redirect verschiedenes Kennzeichen zum Identifizieren von Immersichtbarfenstern verwendet werden. Beispielsweise kann eine Liste von Immersichtbarfenstern (eine "Immersichtbarfensterliste") definiert und als eine an dem Grundfenster angebrachte Eigenschaft definiert und erzeugt werden.
Bezugnehmend auf die Fig. 11 stellt diese eine Ausführungsform dar, bei der eine Immersichtbarfensterliste 1102 zum Identifizieren von Immersichtbarfenstern verwendet wird. Die Immersichtbarfensterliste 1102 enthält einen Fensteridentifizierer für jedes existierende Immersichtbarfenster. Insbesondere enthält die Immersichtbarfensterliste 1102 einen Eingang 1104, der mit dem Fenster 1012 korrespondiert, welches auf der Anzeigeeinrichtung 1102 das einzige Immersichtbarfenster ist. Während einer Fensterskalier-, Fensterwähl- oder Fensterbewegungsoperation greift die Fensteranzeigeeinheit 1018 auf die Immersichtbarfensterliste 1102 zu, um zu bestimmen, ob spezielle Fenster Immersichtbarfenster sind. Die Verwendung einer Immersichtbarfensterliste zum Identifizieren von Immersichtbarfenstern erlaubt eine gemeinsame Steuerung von Immersichtbarfenstern durch die Fensteranzeigeeinheit 1018 und einem normalen X-System-Fenstermanager.

X-Client-Anwendungsoperation

Bezugnehmend auf die Fig. 12a ist diese ein Flussdiagramm, das die Operation einer X-Client-Anwendung gemäß einer Ausführungsform der Erfindung darstellt. Der X-Client ist zum Bezeichnen eines oder mehrerer Fenster als "immer sichtbar" gekennzeichnet. Wie oben beschrieben gibt es verschiedene mögliche Verfahren zum Bezeichnen eines Fensters als ein Immersichtbarfenster. Zur Beschreibung zweier solcher Verfahren wird auf die Fig. 12b und 12c Bezug genommen. Gemäß dieser Technik sind alle Fenster, welche das "Überlagerungsumleitungs"-Attribut aufweisen, als "Immersichtbar"-Fenster gesetzt. Gemäß der zweiten Technik wird eine Fensterliste IDS für alle Immersichtbarfenster in Form einer an das Grundfenster angebrachten Eigenschaft beibehalten. Bei Verwendung dieser Technik spricht jede Anwendung, die ein Immersichtbarfenster erzeugt, auf ein Addieren der Fenster-ID zur Immersichtbarfensterliste zum Zeitpunkt der Erzeugng des Fensters an. Ein nachfolgend beschriebener Bump-Fenstermanager entfernt die ID von einem Immersichtbarfenster aus der Immersichtbarfensterliste automatisch zu dem Zeitpunkt, bei dem das Immersichtbarfenster gelöscht wird.
Unter nunmehriger Bezugnahme auf die Fig. 12a verbindet sich beim Schritt 1202 ein X-Client mit einem X-Server. Der X-Client verbindet sich mit dem X-Server, indem er einen Xlib-Ruf erzeugt, der einen Kommunikationspfad zwischen dem X-Client und einem bezeichneten X-Server herstellt. Beim Schritt 1204 erzeugt der X-Client ein Fenster.
Beim Schritt 1208 kennzeichnet der X-Client, dass das beim Schritt 1204 erzeugte Fenster ein Immersichtbarfenster ist. Wie oben erläutert kann das Fenster entsprechend einer aus jeder Menge von Techniken als Immersichtbarfenster gekennzeichnet werden. Nur eine Technik ist in der Fig. 12b bezeichnet. Gemäß dieser Technik wird beim Schritt 1216 das "Überlagerungsumleitungs"-Attribut des Fensters gesetzt.
Eine alternative Technik zum Kennzeichnen eines Fensters als ein Immersichtbarfenster ist in der Fig. 12c dargestellt. Gemäß der in Fig. 12c dargestellten Technik weist das Grundfenster eine Eigenschaft, die als eine Immersichtbarfensterliste definiert ist, auf. Beim Schritt 1218 wird die Immersichtbarfensterlisteneigenschaft wiedergewonnen. Beim Schritt 1220 wird ein mit dem neu erzeugten Fenster korrespondierendes Fenster-ID als eine Eingabe in die Immersichtbarfensterliste addiert. Beim Schritt 1222 wird die Eigenschaft des mit der Immersichtbarfensterliste korrespondierenden Grundfensters aktualisiert, um die revidierte Immersichtbarfensterliste zu reflektieren.
Unter Bezugnahme auf die Fig. 12a wiederum wird das Fenster beim Schritt 1210 abgebildet. Die Abbildung des Fensters bewirkt, dass das Fenster auf der geeigneten Anzeige angezeigt wird. Beim Schritt 1212 führt der Client die ganze Clientverarbeitung aus. Dieser Schritt stellt generell die Operation des Client dar. Die während dieses Schrittes tatsächlich ausgeführten Schritten variieren auf der Basis des X-Client und der Interaktion zwischen dem X- Client, dem Benutzer und anderen Anwendungen. Während der X-Client-Operation können verschiedene Ereignisse auftreten, die das Immersichtbarfenster beeinflussen. Beispielsweise können andere Fenster (sowohl Immersichtbarfenster als auch nicht immer sichtbare Fenster) erzeugt, abgebildet, bewegt, skaliert verändert und gelöscht werden. Wenn der X-Client durch die ganze Verarbeitung ist, löscht der X-Client das Fenster beim Schritt 1214.

Bump-Fenstermanageroperation

Gemäß einer Ausführungsform der Erfindung wird zum Erzeugen des oben beschriebenen Fensterverhaltens ein Bump- Fenstermanager verwendet. Ein Bump-Fenstermananger kann eine Komponente eines X-Windows-Managers sein oder kann zu einem X-Windows-Manager separat koexistieren. Der Zweck des Bump-Fenstermanagers ist, Fenster zu identifizieren und zu überwachen, die als Immersichtbarfenster gekennzeichnet sind. Bei einer Änderung der Stapelordnung stellt der Bump- Fenstermanager sicher, dass alle Immersichtbarfenster über allen anderen Fenstern gestapelt sind. Wird ein Immersichtbarfenster bewegt oder skaliert, prüft der Bump-Fenstermanager auf Überlappungszustände mit anderen Immersichtbarfenstern. Tritt ein solcher Überlappungszustand auf, gibt der Bump-Fenstermanager eine Bewegungs- oder Skalierungsoperation aus, um das Immersichtbarfenster, an dem die Operation ausgeführt wurde, bei einer vorherigen Position und/oder Größe, die kein anderes Immersichtbarfenster überlappt, zu platzieren. Die Operation des Bump-Fenstermanagers wird in Bezug auf die Fig. 13a, 13b, 13c, 13d und 13e detaillierter beschrieben.
Fig. 13a ist ein Flussdiagramm, das die Operation eines Bump-Fenstermanagers darstellt. Beim Schritt 1302 verbindet sich der Bump-Fenstermanager mit dem X-Server. Dies stellt einen Kommunikationsweg zwischen dem Bump-Fenstermanager und einem spezifizierten X-Server her.
Beim Schritt 1304 initialisiert der Bump-Fenstermanager eine Immersichtbarfensterliste. Bezugnehmend auf die Fig. 13b zeigt diese die während des Schrittes 1304 vom Bump-Fenstermanager ausgeführten Schritte detaillierter. Insbesondere frägt der Bump-Fenstermanager beim Schritt 1314 den X-Server nach einer Fensterliste ab. Beim Schritt 1316 identifiziert der Bump-Fenstermanager die Immersichtbarfenster in der Fensterliste und erzeugt eine Immersichtbarfensterliste. Vorzugsweise sind alle Immersichtbarfenster Abgeleitete des Grundfensters.
Das vom Bump-Fenstermanager verwendete Verfahren zum Identifizieren; welche der vom X-Server identifizierten Fenster Immersichtbarfenster sind, hängt von der zum Kennzeichnen von Immersichtbarfenstern verwendeten Technik ab. Wenn beispielsweise das Überlagerungsumleitungs-Attribut als ein Kennzeichen zum Bezeichnen von Immersichtbarfenstern verwendet wird, inspiziert der Bump-Fenstermanager das Überlagerungsumleitungs-Attribut aller vom X-Server identifizierten Fenster. Wenn eine an ein Grundfenster angebrachte Eigenschaft verwendet wird, um die Immersichtbarfenster aufzulisten, inspiziert der Bump-Fenstermanager die zugehörige Eigenschaft des Grundfensters.
Beim Schritt 1318 frägt der Bump-Fenstermanager den X- Server nach der Größe und Position aller Immersichtbarfenster ab. Beim Schritt 1320 speichert der Bump-Fenstermanager in einer Immersichtbarfensterliste die Größen, Positionen und den Fensterstatus jedes der Immersichtbarfenster. Folglich enthält die Eingabe für jedes Immersichtbarfenster in der Immersichtbarfensterliste die Fenster-ID, die Stelle, die Größe, den Status (abgebildet/nicht abgebildet) und die Stapelordnung des Immersichtbarfensters.
Beim Schritt 1322 verarbeitet der Bump-Fenstermanager die neue Liste. Die vom Bump-Fenstermanager ausgeführten Operationen zum Verarbeiten der neuen Immersichtbarfensterliste sind in der Fig. 13c dargestellt. Bezugnehmend auf die Fig. 13c bilden die Schritte 1326, 1338 und 1340 eine Schleife, die wiederholt wird, bis einer Überlappung zwischen abgebildeten Immersichtbarfenstern begegnet wird oder bis Eingaben für alle Immersichtbarfenster verarbeitet sind. Die Information in einem nicht abgebildeten Fenster kann nicht durch ein anderes Fenster verborgen werden, da die Information nicht selbst angezeigt wird. Deshalb wird bei der bevorzugten Ausführungsform ein Überlappen zwischen einem nicht abgebildeten Immersichtbarfenster und irgendeinem anderen Immersichtbarfenster ignoriert.
Wird einem Überlappen zwischen einem speziellen abgebildeten Immersichtbarfenster und einem oder mehreren anderen abgebildeten Immersichtbarfenstern begegnet, geht die Steuerung vom Schritt 1326 zum Schritt 1328. Beim Schritt 1328 bestimmt der Bump-Fenstermanager eine neue Position für das spezielle Immersichtbarfenster, die ein Überlappen zwischen dem Immersichtbarfenster und allen anderen abgebildeten Immersichtbarfenstern vermeidet. Beim Schritt 1330 wird festgestellt, ob eine solche Position existiert. Existiert eine solche Position, wird das Immersichtbarfenster zur Position beim Schritt 1336 bewegt. Existiert eine solche Position nicht, geht die Steuerung zum Schritt 1332.
Beim Schritt 1332 stellt der Bump-Fenstermanager fest, ob die Größengrenze des Immersichtbarfensters erreicht ist. In diesem Zusammenhang ist die Größengrenze die minimale Größe, die das Immersichtbarfenster annehmen darf. Ist die Größengrenze für das Immersichtbarfenster erreicht, geht die Steuerung zum Schritt 1338 und es wird die nächste Immersichtbarfenstereingabe in die Liste verarbeitet. Ist die Größengrenze für das Immersichtbarfenster nicht erreicht, wird die Größe des Immersichtbarfensters reduziert. Die Schritte 1326, 1328, 1330, 1332 und 1334 bilden eine Schleife derart, dass die Größe eines Immersichtbarfensters reduziert wird, bis jedes Fenster zu einer Nichtüberlappungsposition bewegt werden kann oder seine Größengrenze erreicht ist.
Bezugnehmend auf die Fig. 13a wiederum wartet nach dem Initialisieren der Immersichtbarfensterliste der Bump- Fenstermanager auf ein Fensterereignis (Schritt 1306). Tritt ein Fensterereignis auf, geht die Steuerung zum Schritt 1308, bei dem das Fensterereignis verarbeitet wird. Der Schritt 1308 wird unter Bezugnahme auf die Fig. 13d und 13e detaillierter beschrieben.
Bezugnehmend auf die Fig. 13d und 13e stellen diese ein Flussdiagramm der vom Bump-Fenstermanager beim Auftreten eines Fensterereignisses ausgeführten Schritte dar. Beim Schritt 1342 empfängt der Bump-Fenstermanager Daten, die das aufgetretene Ereignis identifizieren. Bei den Schritten 1344 bis 1358 identifiziert der Bump- Fenstermanager den Typ des aufgetretenen Ereignisses.
Spezifiziert das Ereignis, dass ein spezielles Fenster zu bewegen ist, geht die Steuerung vom Schritt 1344 zum Schritt 1360. Beim Schritt 1360 stellt der Bump-Fenstermanager fest, ob das Fenster, an dem die Operation auszuführen ist, ein Immersichtbarfenster ist. Ist das Fenster kein Immersichtbarfenster, muss der Bump-Fenstermanager keine weitere Verarbeitung in Abhängigkeit vom Fensterereignis ausführen. Ist das Fenster ein Immersichtbarfenster, geht die Steuerung zum Schritt 1376. Beim Schritt 1376 stellt der Bump-Fenstermanager fest, ob die Bewegung das Immersichtbarfenster veranlasst, sich mit einem anderen Immersichtbarfenster zu überlappen. Wenn nicht, muss der Bump- Fenstermanager keine weitere Verarbeitung in Abhängigkeit vom Fensterereignis ausführen. Andernfalls wird das Immersichtbarfenster beim Schritt 1384 zu einer Nichtüberlappungsstelle bewegt. Die Nichtüberlappungsstelle kann beispielsweise neben einem anderen Immersichtbarfenster sein, sich aber nicht mit diesem überlappen. Beim Schritt 1390 wird die Eingabe in die Immersichtbarfensterliste, die mit dem Fenster, das bewegt wurde, korrespondiert, aktualisiert, um die neue Stelle des Fensters, das bewegt wurde, zu reflektieren.
Spezifiziert das Ereignis, dass ein spezielles Fenster zu skalieren ist, geht die Steuerung vom Schritt 1346 zum Schritt 1362. Beim Schritt 1362 stellt der Bump-Fenstermanager fest, ob das Fenster, an dem die Operation auszuführen ist, ein Immersichtbarfenster ist. Ist das Fenster kein Immersichtbarfenster, muss der Bump-Fenstermanager keine weitere Verarbeitung in Abhängigkeit vom Fensterereignis ausführen. Ist das Fenster ein Immersichtbarfenster, geht die Steuerung zum Schritt 1378. Beim Schritt 1378 stellt der Bump-Fenstermanager fest, ob die Skalierungsoperation das Immersichtbarfenster veranlasst, sich mit einem anderen Immersichtbarfenster zu überlappen. Wenn nicht, muss der Bump-Fenstermanager keine weitere Verarbeitung in Abhängigkeit von dem Fensterereignis ausführen. Andernfalls wird das Immersichtbarfenster beim Schritt 1386 auf eine Größe skaliert, bei der das Immersichtbarfenster sich nicht mit irgendeinem anderen Immersichtbarfenster überlappt. Die neue Größe des Fensters ist kleiner als die beim Skalierungsereignis spezifizierte Größe. Beispielsweise kann die Größe eine Größe sein, die den Rand des skalierten Fensters veranlasst, neben dem Rand eines anderen Immersichtbarfensters zu sein, sich aber nicht mit diesem Rand zu überlappen. Beim Schritt 1392 wird die Eingabe in die Immersichtbarfensterliste, die mit dem Fenster, das skaliert wurde, korrespondiert, aktualisiert, um die neue Größe des Fensters, das skaliert wurde, zu reflektieren.
Ist das Ereignis eine Änderung der Stapelordnung spezifiziert, geht die Steuerung vom Schritt 1348 zum Schritt 1364. Beim Schritt 1364 stellt der Bump-Fenstermanager fest, ob in der neuen Stapelordnung irgendein nicht immer sichtbares Fenster über irgendeinem Immersichtbarfenster ist. Ist in der neuen Stapelordnung kein nicht immer sichtbares Fenster über irgendeinem Immersichtbarfenster, muss der Bump-Fenstermanager keine weitere Verarbeitung in Abhängigkeit vom Fensterereignis ausführen. Ist in der neuen Stapelordnung irgend ein nicht immer sichtbares Fenster über irgendeinem Immersichtbarfenster, geht die Steuerung zum Schritt 1380. Beim Schritt 1380 stellt der Bump-Fenstermanager die neue Stapelordnung ein, um sicherzustellen, dass in der Stapelordnung alle Immersichtbarfenster über allen nicht immer sichtbaren Fenstern sind.
Spezifiziert das Ereignis, dass ein spezielles Fenster zu erzeugen ist, geht die Steuerung vom Schritt 1350 zum Schritt 1366. Beim Schritt 1366 stellt der Bump-Fenstermanager fest, ob das neu erzeugte Fenster ein Immersichtbarfenster ist. Ist das Fenster kein Immersichtbarfenster, stellt der Bump-Fenstermanager beim Schritt 1382 die Stapelordnung ein, um sicherzustellen, dass in der Stapelordnung alle Immersichtbarfenster über allen nicht immer sichtbaren Fenstern sind. Ist das Fenster ein Immersichtbarfenster, geht die Steuerung zum Schritt 1388. Beim Schritt 1388 wird zu der Immersichtbarfensterliste eine Eingabe für das neu erzeugte Immersichtbarfenster addiert.
Spezifiziert das Ereignis, dass ein spezielles Fenster zu löschen ist, geht die Steuerung vom Schritt 1352 zum Schritt 1368. Beim Schritt 1368 stellt der Bump-Fenstermanager fest, ob das Fenster, an dem die Operation auszuführen ist, ein Immersichtbarfenster ist. Ist das Fenster kein Immersichtbarfenster, muss der Bump-Fenstermanager keine weitere Verarbeitung in Abhängigkeit von dem Fensterereignis ausführen. Ist das Fenster ein Immersichtbarfenster, geht die Steuerung zum Schritt 1396. Beim Schritt 1396 wird die Immersichtbarfensterliste aktualisiert. Insbesondere wird die Eingabe des zu löschenden Immersichtbarfensters aus der Immersichtbarfensterliste entfernt.
Spezifiziert das Ereignis, dass ein spezielles Fenster abzubilden ist, geht die Steuerung vom Schritt 1354 zum Schritt 1370. Beim Schritt 1370 stellt der Bump-Fenstermanager fest, ob das Fenster, an dem die Operation auszuführen ist, ein Immersichtbarfenster ist. Ist das Fenster kein Immersichtbarfenster, muss der Bump-Fenstermanager keine weitere Verarbeitung in Abhängigkeit von dem Fensterereignis ausführen. Ist das Fenster ein Immersichtbarfenster, geht die Steuerung zum Schritt 1398. Beim Schritt 1398 wird die Immersichtbarfensterliste aktualisiert. Insbesondere wird der Abbildungs/Nichtabbildungs-Status in der Eingabe für das Immersichtbarfenster revidiert, um zu reflektieren, dass das Immersichtbarfenster abgebildet wird. Ist die Eingabe einmal revidiert, wird beim Schritt 1394 die Immersichtbarfensterliste verarbeitet, um sicherzustellen, dass kein abgebildetes Immersichtbarfenster sich mit irgendeinem anderen abgebildeten Immersichtbarfenster überlappt. Die bei der Verarbeitung der Immersichtbarfensterliste involvierten Schritte sind oben in Bezug auf die Fig. 13c beschrieben.
Spezifiziert das Ereignis, dass ein spezielles Fenster abzubilden ist, geht die Steuerung vom Schritt 1356 zum Schritt 1372. Beim Schritt 1372 stellt der Bump-Fenstermanager fest, ob das Fenster, an dem die Operation auszuführen ist, ein Immersichtbarfenster ist. Ist das Fenster kein Immersichtbarfenster, muss der Bump-Fenstermanager keine weitere Verarbeitung in Abhängigkeit vom Fensterereignis ausführen. Ist das Fenster ein Immersichtbarfenster, geht die Steuerung zum Schritt 1400. Beim Schritt 1400 wird die Immersichtbarfensterliste aktualisiert. Insbesondere wird der Abbildungs/Nichtabbildungs-Status in der Eingabe für das Immersichtbarfenster revidiert, um zu reflektieren, dass das Immersichtbarfenster nicht länger abgebildet wird.
Spezifiziert das Ereignis spezifiziert, dass eine Eigenschaft eines speziellen Fenster zu ändern ist, geht die Steuerung vom Schritt 1358 zum Schritt 1374. Beim Schritt 1374 stellt der Bump-Fenstermanager fest, ob die zu ändernde Eigenschaft eine Immersichtbarfensterliste ist. Ist die zu ändernde Eigenschaft keine Immersichtbarfensterliste, muss der Bump-Fenstermanager keine weitere Verarbeitung in Abhängigkeit von dem Fensterereignis ausführen. Ist die zu ändernde Eigenschaft eine Immersichtbarfensterliste, geht die Steuerung zum Schritt 1402. Beim Schritt 1402 wird die Immersichtbarfensterliste revidiert wie es im Ereignis spezifiziert ist. Ist die Immersichtbarfensterliste einmal revidiert, wird die Immersichtbarfensterliste beim Schritt 1404 verarbeitet, um sicherzustellen, dass keine abgebildeten Immersichtbarfenster sich mit irgendwelchen anderen abgebildeten Immersichtbarfenstern überlappen. Die bei der Verarbeitung der Immersichtbarfensterliste involvierten Schritte sind oben in Bezug auf die Fig. 13c beschrieben.
Bezugnehmend auf die Fig. 13a wiederum definieren die Schritte 1306, 1308 und 1300 eine Schleife, in der Fensterereignisse wie oben beschrieben verarbeitet werden, bis ein Zustand eintritt, der ein den Bump-Fenstermanager veranlasst, zu abzuschließen. Beim Eintreten eines solchen Zustandes geht die Steuerung vom Schritt 1310 zum Schritt 1312. Beim Schritt 1312 schließt der Bump-Fenstermanager die zwischen dem Bump-Fenstermanager und dem X-Server hergestellte Verbindung.

Transparente Hintergründe

Gemäß einem bevorzugten Aspekt der Erfindung ist es wünschenswert, Immersichtbarfenster bereitzustellen, die einen transparenten Hintergrund aufweisen. Durch einen transparenten Hintergrund kann ein Benutzer die vom Fenster abgedeckten Schirmbereiche sehen. Nur die Vordergrunddaten im Fenster sind nicht transparent. Durch Bereitstellen von Immersichtbarfenstern mit transparentem Hintergrund kann sichergestellt werden, dass gewisse Daten immer sichtbar sind und dazu noch die von Immersichtbarfenster abgedeckte Informationsmenge minimiert ist.

Mögliche Anwendungen

Die durch die Ausführungsformen der Erfindung bereitgestellten Immersichtbarfenster sind ideal zur Verwendung bei jeder Computeranwendung, welche die konstante Anzeige kritischer Information erfordert. Beispielsweise dürfen bei einer Luftverkehrskontrolle gewisse Daten, die zu einem Flugzeug gehören, nicht von irgendeiner anderen Information abgedeckt werden. Bisher erlaubte dieser Zwang Luftverkehrskontrollanwendungen nicht, Vorteil von fensterbasierten Umgebungen zu haben. Jedoch können durch Anzeigen der kritischen Daten in Immersichtbarfenstern Luftverkehrskontrollanwendungen Vorteil von dem durch fensterbasierte Grafikumgebungen bereitgestellten Komfort haben. Luftverkehrskontrolle ist nur ein Beispiel eines Gebiets, das beträchtlichen Vorteil von der vorliegenden Erfindung haben kann. Jedoch ist die vorliegende Erfindung nicht auf irgendein spezielles Anwendungsgebiet beschränkt.

Claims

1. Verfahren zur Anzeige von Information in einer fensterbasierten Schnittstelle auf einem Schirm einer Anzeigeeinrichtung in einem Computersystem, wobei das Verfahren die Schritte aufweist:

Anzeigen mehrerer Fenster auf dem Schirm, wobei die mehreren Fenster ein oder mehrere immer sichtbare Fenster (204, 206) aufweisen,

Anzeigen einer ersten Information in einem immer sichtbaren Fenster (204, 206) der mehreren Fenster,

Empfangen eines Ereignisses, das ein gewähltes Fenster der mehreren Fenster veranlassen würde, einen Abschnitt des immer sichtbaren Fensters (204, 206) zu bedecken,

Verhindern eines Überlappens des gewählten Fensters mit dem immer sichtbaren Fenster, wenn das gewählte Fenster ein immer sichtbares Fenster (204, 206) ist, und

Anzeigen des immer sichtbare Fensters auf dem Schirm oben auf dem gewählten Fenster, wenn das gewählte Fenster kein immer sichtbares Fenster (208, 210) ist.

2. Verfahren nach Anspruch 1, mit dem Schritt eines Detektierens, wenn ein Ereignis das gewählte Fenster veranlassen würde, das eine oder eines der mehreren immer sichtbaren Fenster (204, 206) zu überlappen, durch Ausführen der Schritte:

Speichern von Orientierungsdaten, die einen mit dem einen oder jedem der mehreren immer sichtbaren Fenster (204, 206) korrespondierenden Bereich des Schirms anzeigen,

Detektieren, wenn ein Versuch gemacht wird, das gewählte Fenster in einem neuen Bereich des Schirms anzuzeigen, und

Vergleichen des neuen Bereiches mit den Orientierungsdaten, um zu bestimmen, ob der neue Bereich sich mit dem mit dem einen oder einem der mehreren immer sichtbaren Fenster (204, 206) korrespondierenden Bereich des Schirms schneidet.

3. Verfahren nach Anspruch 2, mit einem Ändern entweder der Konfiguration des ersten immer sichtbaren Fensters oder der Konfiguration des zweiten Fensters oder Ändern der Konfigurationen sowohl des ersten immer sichtbaren Fensters als auch des zweiten Fensters, so dass kein Abschnitt des zweiten Fensters einen gemeinsamen Bereich auf der Anzeigeeinrichtung mit einem Abschnitt des ersten immer sichtbaren Fensters einnimmt, wenn das zweite Fenster ein immer sichtbares Fenster ist.

4. Verfahren nach Anspruch 2, mit einem Anzeigen des Abschnitts des ersten Fensters im gemeinsamen Bereich, wenn das zweite Fenster kein immer sichtbares Fenster ist.

5. Verfahren nach Anspruch 2, wobei das erste Fenster einen transparenten Hintergrund aufweist, und

der Schritt des Anzeigens des Abschnitts des ersten Fensters im gemeinsamen Bereich die Schritte eines Anzeigens von Information aus dem ersten Fenster im gemeinsamen Bereich und Anzeigens von Information aus einem das erste Fenster überlappenden nicht transparenten Fenster im gemeinsamen Bereich aufweist.

Verfahren nach Anspruch 1, mit den Schritten:

Aufrechterhalten einer Stapelordnung der mehreren Fenster,

Anzeigen der mehreren Fenster auf dem Schirm in Abhängigkeit von der Stapelordnung, wobei bei einem Überlappen eines Fensters der mehreren Fenster das Fenster mit einer höheren Position in der Stapelordnung oberhalb des Fensters, mit dem es sich überlappt, angezeigt wird,

Detektieren, wenn ein Ereignis ein Fenster, das nicht ein immer sichtbares Fenster ist, veranlasst, eine höhere Position in einer Stapelordnung als das eine oder eines der mehreren immer sichtbaren Fenster einnimmt, und

Bewirken, dass ein Fenster eine Position in der Stapelordnung einnimmt, die niedriger als das eine oder jedes der mehreren immer sichtbaren Fenster ist.

7. Verfahren nach Anspruch 1, mit dem Schritt eines Bestimmens des immer sichtbaren Fenster als ein immer sichtbares Fenster durch Ausführen des Schritts eines Einstellens eines vorrangigen Umleitungsattributs des immer sichtbaren Fensters.

3. Verfahren nach Anspruch 1, mit dem Schritt eines Bestimnens des immer sichtbaren Fensters als ein immer sichtbares Fenster durch Ausführen der Schritte:

Erzeugen einer Immersichtbarfensterliste und

Addieren zur Immersichtbarfensterliste einen Eingang, der mit dem immer sichtbaren Fenster korrespondiert.

9. Verfahren nach Anspruch 8, wobei der Schritt des Erzeugens einer Immersichtbarfensterliste eine Herstellung der Immersichtbarfensterliste als eine Eigenschaft eines Wurzelfensters enthält.

10. Verfahren nach Anspruch 8, wobei der Eingang einen Fensteridentifizierer, einen Ortsindikator, einen Größenindikator und einen Stapelordnungsindikator für das immer sichtbare Fenster aufweist.

11. Verfahren nach Anspruch 10, wobei der Eingang Daten aufweist, die anzeigen, ob das immer sichtbare Fenster abgebildet wird.

12. Verfahren nach Anspruch 8, mit:

Detektieren eines Ereignisses, welches das erste immer sichtbare Fenster zerstört, und

Entfernen eines Eingangs, der mit dem ersten Immersichtbarfenster aus der Immersichtbarfensterliste korrespondiert.

13. Verfahren nach Anspruch 1, mit:

Detektieren eines Ereignisses, das ein neues immer sichtbares Fenster erzeugt,

Addieren eines Eingangs,

Feststellen, ob das neue immer sichtbare Fenster und ein anderes immer sichtbares Fenster einander überlappen, und,

wenn das neue immer sichtbare Fenster und ein anderes immer sichtbares Fenster einander überlappen,

Ändern entweder von Orientierungsdaten des neuen immer sichtbaren Fensters, die einen Bereich des Schirms anzeigen, der mit dem neuen Fenster korrespondiert, oder von Orientierungsdaten des anderen immer sichtbaren Fensters, oder Ändern der Orientierungsdaten sowohl des neuen immer sichtbaren Fensters als auch des anderen immer sichtbaren Fensters, so dass kein Abschnitt des neuen immer sichtbaren Fensters das andere Immersichtbarfenster überlappt.

14. Fensterbasiertes Computersystem, das Fenster aus mehreren Fensterklassen (204, 206, 208, 210) unterstützt, wobei eine spezielle Fensterklasse (204, 208) der mehreren Fensterklassen mit Fenstern korrespondiert, die nicht mit anderen Fenstern überlappt werden können.

15. Fensterbasiertes Computersystem nach Anspruch 1, mit einer Fensteranzeigeeinheit (200, 1000, 1006) die so konfiguriert ist, dass eine Überlappung zwischen zwei Fenstern der speziellen Fensterklasse (204, 206) verhindert ist.

16. Fensterbasiertes Computersystem nach Anspruch 15, wobei die Fensteranzeigeeinheit außerdem so konfiguriert ist, dass eine Überlappung zwischen einem Fenster der speziellen Fensterklasse (204, 206) und einem Fenster, das nicht von der speziellen Fensterklasse (208, 210) ist, ermöglicht ist.

17. Fensterbasiertes Computersystem nach Anspruch 16, wobei die Fensteranzeigeeinheit (200, 1000, 1006) außerdem so konfiguriert ist, dass eine Überlappung zwischen dem Fenster der speziellen Fensterklasse (204, 206) und dem Fenster, das nicht von der speziellen Fensterklasse (208, 210) ist, detektiert und das Fenster der speziellen Fensterklasse oben auf dem Fenster, das nicht von der speziellen Fensterklasse ist, angezeigt wird.

18. Fensterbasiertes Computersystem nach Anspruch 15, wobei die Fensteranzeigeeinheit (200, 1000, 1006) eine Überlappung zwischen zwei Fenstern der speziellen Fensterklasse verhindert, indem sie bewirkt, dass die Fenster so erscheinen, als wenn die zwei Fenster aneinander stoßen würden, wenn ein Benutzer versucht, eine Operation auszuführen, die andernfalls bewirken würde, dass die zwei Fenster sich überlappen.

19. Fensterbasiertes Computersystem nach Anspruch 15, mit:

einem Speicher (100) der mehrere Attribute mehrerer Fenster enthält, wobei die mehreren Attribute anzeigen, ob jedes Fenster der mehreren Fenster ein immer sichtbares Fenster ist, wobei die mehreren Attribute eine Stapelordnungsposition für jedes Fenster der mehreren Fenster anzeigen,

einer Eingabeempfangseinheit, die ein Eingangsereignis empfängt, wobei die Eingabe Änderungen in den mehreren Attributen bestimmt,

einer Fensteranzeigeeinheit zur Anzeige der mehreren Fenster auf der Anzeigeeinrichtung auf der Basis der mehreren Attribute,

wobei in dem Fall, dass Abschnitte zweier oder mehrerer Fenster der mehreren Fenster sich einen gemeinsamen Schirmbereich teilen, die Fensteranzeigeeinheit im gemeinsamen Schirmbereich den Abschnitt desjenigen Fensters der zwei oder mehreren Fenster anzeigt, das in der Stapelordnung eine höhere Position als die anderen der zwei oder mehreren Fenster aufweist, wobei die Fensteranzeigeeinheit eine Überlappungsverarbeitungseinheit zur Bestimmung, ob die Änderungen zwei oder mehrere immer sichtbare Fenster veranlassen, sich zwischen zwei oder mehreren immer sichtbaren Fenstern zu überlappen, und eine Stapelordnungskorrektureinheit zur Änderung der mehreren Attribute, um zu verhindern, dass das immer sichtbare Fenster in der Stapelordnung eine niedrigere Position als jedes andere Fenster, das kein immer sichtbares Fenster ist, aufweist.

20. Fenstermanagementsystem nach Anspruch 14, mit einem Mechanismus (1000, 1006) zur Aufrechterhaltung einer Aufzeichnung darüber, welche der mehreren Fenster immer sichtbare Fenster sind.

21. Fenstermanagementsystem nach Anspruch 20, wobei die mehreren Attribute ein vorrangiges Umleitungsattribut aufweist, und

der Mechanismus die Aufzeichnung durch Einstellung des vorrangen Umleitungsattributs jedes der mehreren Fenster aufrechterhält, um zu reflektieren, ob das Fenster ein immer sichtbares Fenster ist.