-
HINTERGRUND DER ERFINDUNG
-
Gebiet der Erfindung
-
Die
vorliegende Erfindung bezieht sich auf das Gebiet von Computeranwendungen
und insbesondere auf die Unterstützung
von Java Lightweight-Komponenten auf Settop-Boxen.
-
Sun,
Sun Microsystems, das Sun-Logo, Java, Java 3D und alle
Java-basierten Warenzeichen und Logos sind Warenzeichen oder eingetragene
Warenzeichen von Sun Microsystems, Inc. in den USA und anderen Ländern. Alle
SPARC-Warenzeichen werden in Lizenz verwendet und sind Warenzeichen
von SPARC International, Inc. in den USA und anderen Ländern. Produkte,
die SPARC-Warenzeichen tragen, basieren auf einer von Sun Microsystems,
Inc. entwickelten Architektur.
-
Stand der Technik
-
Computersysteme
mit Anzeigevorrichtungen (z.B. einem Bildschirm) bieten dem Benutzer
im Allgemeinen Möglichkeiten,
sich auf den Anzeigevorrichtungen zu bewegen (das heißt zu navigieren).
Gewöhnlich weist
eine Anzeigevorrichtung eine grafische Benutzeroberfläche (GUI)
auf, um den Benutzer Objekte von potenziellem Interesse in bildhafter
Darstellung zu präsentieren.
Diese Bildschirmobjekte, auch als Komponenten bezeichnet, können einen
Computer veranlassen, andere Funktionen auszuführen, oder sie können nur
ein einfaches Bild eines Objekts ohne Funktion darstellen.
-
Ein
für die
vorliegende Beschreibung interessanter Objekttyp sind die Heavyweight-Komponenten. Heavyweight-Komponenten
sind jene Komponenten, die eine eigene zugehörige native Bildschirmressource (im
Allgemeinen als Peer bezeichnet) aufweisen und daher in dem nativen
Fenstersystem (das heißt
dem zugrundeliegenden Engine, die die GUI steuert) registriert sind.
Heavyweight-Komponenten sind opak und mit jeder Art von auf dem
Computersystem verfügbarer
Navigationseinrichtung navigierbar. Zu den Navigationseinrichtungen
gehören
unter anderem das Benutzen von Zeigegeräten wie zum Beispiel einer
Maus, das Berühren
von Objekten auf einem be rührungsempfindlichen
Touchscreen, das Durchgehen der Objekte mit Hilfe von Tastaturelementen
und Fernbedieneinrichtungen. Das Navigieren auf einer Benutzeroberfläche mit Tastaturelementen
wie zum Beispiel den Cursor-Tasten und anderen Tasten auf der Tastatur
wird als Fokus-Navigation bezeichnet. Ein Benutzer kann zum Beispiel
mit der Tab-Taste und der Shift-Tab-Taste den Fokus auf unterschiedliche
Heavyweight-Objekte
auf einem Bildschirm legen. Ein Objekt, das den Fokus hat, ist hervorgehoben
und kann andere Tastaturereignisse empfangen – man sagt, das Objekt hat
Ereignis-Fokus. Betätigt der
Benutzer die Tab-Taste, wird ein anderes Objekt hervorgehoben bzw.
markiert. Auf dem Benutzeroberflächen-Bildschirm
könnten
jedoch Fensterobjekte vorliegen, die nicht hervorgehoben werden,
wenn der Benutzer mit den Tab-Taste oder anderen Tasten auf der
Tastatur navigiert. Diese Objekte werden als Lightweight-Komponenten bezeichnet.
-
Lightweight-Komponenten
sind Komponenten, mit denen keine nativen opaken Fenster (das heißt keine
Struktur oder Peer-Klassen in der nativen Fenstersystem-Engine) verbunden
sind, sondern die sich ihren Platz auf dem Bildschirm von einem
Heavyweight-Vorgänger
borgen. Im Gegensatz zu den Heavyweight-Komponenten ist eine Lightweight-Komponente
ein Bildschirmelement, das kein entsprechendes Peer-Element in der nativen
Schicht benötigt
und daher transparente Effekte unterstützt. Diese Elemente sehen auf
den verschiedenen Plattformen im Allgemeinen gleich aus, weil sie
in Java oder einer anderen geräteunabhängigen Sprache
implementiert sind. Weil es kein Element in der nativen Schicht
gibt, weiß die
native Schicht nicht zwangsläufig
von dem Lightweight-Element.
-
Auf
Benutzeroberflächen,
bei denen weder ein Touchscreen noch ein Zeigegerät verwendet
wird, navigieren die Benutzer oft zwischen Objekten und aktivieren
sie mit Hilfe einer Tastatur oder deren Entsprechung. Ein Benutzer
kann zum Beispiel eine Fernbedienung oder ein anderes nicht zeigendes
Eingabegerät zum
Navigieren zwischen verfügbaren
Objekten auf einem Benutzeroberflächen-Bildschirm verwendet.
Bei einem typischen Ansatz wird eine „Cursor"-Marke benutzt, um das aktuelle Objekt
(das heißt
den Benutzeroberflächen-Widget
oder -Link) anzugeben, das im Fokus ist. Sobald ein Objekt auf dem
Display im Fokus ist, kann das Objekt mit weiteren festgelegten
Tastenanschlägen
aktiviert/gesteuert werden. Mit einer „Auswahltaste" oder einer Entsprechung
kann der Benutzer zum Beispiel eine Aktion für das aktuell hervorgehobene
Objekt (das heißt
das Objekt mit dem Fokus) einleiten.
-
Mit
den Pfeiltasten (Cursor-Tasten) auf einer Tastatur, einer Fernbedienung
oder einem sonstigen Gerät
kann der Benutzer den Cursor nach oben, unten, rechts oder links
auf das „nächste" Objekt bringen.
Dies funktioniert gut mit den nativen Fenstersystem-Widgets und Hyperlinks
(zum Beispiel auf der lokalen Plattform). Das native Fenstersystem
verwaltet alle Informationen über
die nativen Widgets (das heißt
Heavyweight-Komponenten).
Dies erlaubt ein nahtloses Navigieren zwischen den nativen Widgets.
Die Java Lightweight-Komponenten sind Widgets, die für das zugrundeliegende
native Fenstersystem nicht sichtbar/zugänglich sind, und weil Java
kein eingebautes Fenstersystem zur Verwaltung der Lightweight-Komponenten
aufweist, ist ein Navigieren auf einem Benutzeroberflächen-Bildschirm
ohne Zeigegeräte
nicht möglich.
-
In
Java erhält
ein Lightweight-Widget den Ereignis-Fokus, wenn der Punkt (das heißt die Koordinaten auf
der GUI) des Ereignisses innerhalb der Grenzen (das heißt der Geometrie)
des Widgets liegt: Ein Navigationsereignis wird an das mit dem Lightweight-Widget
verbundene Heavyweight-Vorgänger-Widget
geliefert, das wiederum das Ereignis an alle seine Komponenten weiterleitet.
Das Lightweight-Widget entscheidet, ob das Ereignis innerhalb seiner
Geometrie eingetreten ist, und erfasst es, falls ja. Es ist jedoch
schwierig, den Punkt für
ein Navigationsereignis ohne ein Zeigegerät anzugeben. Daher ist eine
Lösung
für Lightweight-Komponenten
nötig,
die mit nativen Widgets in den Navigationsmodellen übereinstimmt.
-
Der
vorstehend beschriebene Cursor-Navigationsansatz wird typischerweise
in Settop-Boxen und anderen „Informationsgeräten" verwendet, bei denen
es als unerwünscht
angesehen wird, eine Maus oder ein anderes Zeigegerät bereitzustellen.
Das hier beschriebene grundlegende Navigationsproblem gilt jedoch
auch für
eine PC-Umgebung, in der der Benutzer mit einem Tastaturmechanismus
navigiert und es vorzieht, keine Maus zu benutzen.
-
In
allen diesen Fällen
besteht sowohl aus technischer Sicht als auch aus der Sicht des
Benutzers, der das System bedient, ein zu lösendes Problem darin, wie verschiedene
Fenster-Ereignisse (zum Beispiel Befehle) an Java Lightweight-Komponenten übermittelt
werden können,
so dass sie sich wie normale Fenstersystem-Widgets verhalten. So
ist es zum Beispiel nötig,
dass sich Lightweight-Widgets beim Navigieren genau wie die regulären Fenstersystem-Widgets
verhalten (das heißt
Lightweight-Komponenten sollten den Ereignis-Fokus mit allen verfügbaren Navigationsverfahren
annehmen).
-
Umgebungen
wie zum Beispiel Motif, Windows, Sun Webmail 3.x und WebTV sehen
Tastatur-Navigationsmodelle vor, die das Bewegen eines Cursors von
einem Objekt auf der Benutzeroberfläche auf ein anderes unterstützen. Diese
Umgebungen bieten derzeit jedoch keine gute Unterstützung für Lightweight-Komponenten.
Auf Desktop-Systemen
erhält
eine Lightweight-Komponente den Fokus, wenn ein Benutzer ein Ereignis
wie zum Beispiel ein Klicken in ihren Bounding-Regionen ausführt. Ein
natives Fenstersystem (Windows, Motif, DWL) leitet dieses Ereignis
an einen mit der Lightweight-Komponente verbundenen nativen Parent-Container
weiter. Der Container wiederum leitet dieses Ereignis an alle Lightweight-Komponenten
weiter, die er enthält.
Jede Lightweight-Komponente prüft,
ob das Ereignis innerhalb ihrer Bounding-Regionen (nicht unbedingt ihrem Bounding-Rechteck)
eingetreten ist; wenn ja, wird es übernommen und beansprucht.
-
In
den meisten Fällen
sind die mit Lightweight-Komponenten verbundenen nativen Container
keine „FocusTraversable"-Widgets. „Focus
Traversal" bzw.
Fokusverschiebung ist die Möglichkeit,
Tastenanschläge (nicht
die Maus) zu verwenden, um Komponenten zu durchlaufen, die den Tastatur-Fokus
annehmen können. Diese
Tastenanschläge
sind definiert als <Tab> zum Vorwärtsbewegen
und als <Shift-Tab> zum Rückwärtsbewegen.
Sobald eine Komponente den Fokus hat, sollte es möglich sein,
die betreffende Komponente mit weiteren festgelegten Tastenanschlägen zu aktivieren/zu
steuern (zum Beispiel <Leertaste> zum Drücken einer Taste).
Die Komponente ist dafür
verantwortlich, die richtige Aktivierung zu implementieren, sobald
sie den Fokus hat. Eine Komponente, die den Fokus auf diese Weise
annehmen kann, sollte immer eine bestimmte Form von visuellem Feedback
liefern, wenn sie den Fokus erhält,
damit der Benutzer leicht erkennen kann, welche Komponente den Fokus
hat, wenn er mit Tab/-Shift-Tab
navigiert. Typischerweise hat dieses Feedback die Form einer farbigen
Bounding-Box um die betreffende Komponente. Die nativen Toolkits
auf der jeweiligen Plattform sehen als Standard einen unterschiedlichen
Grad an Unterstützung
für diese
Fokusverschiebung vor. Eine ausdrückliche Unterstützung der
Fokusverschiebung ist jedoch im allgemeinen Java AWT-Code (Advanced
Windowing Toolkit) implementiert, so dass das Verhalten über Plattformen
hinweg einheitlicher ist.
-
In
einer Settop-Box/Informationsgeräte-Umgebung,
in der keine Zeigegeräte
für Benutzereingaben vorgesehen
sind, gibt es keine Möglichkeit,
den Fokus und Fokus- Ereignisse
an diese Java-Komponenten zu übermitteln.
Die vorliegende Erfindung wird für
den Benutzerdialog mit dem Produkt sogar noch wichtiger.
-
Image-Maps
-
Die
bestehende Lösung
unterstützt
Lightweight-Komponenten, die als Image-Maps gehandhabt werden. Image-Maps oder
verweissensitive Grafiken sind Bilder auf Web-Seiten mit aktiven
Regionen (das heißt Hotspots).
Eine Image-Map auf einer Web-Seite
besteht aus drei Elementen: einem Bild, einer Gruppe von Map-Daten
und einem HTML-Host-Eintrag. Das Bild ist ein normales Web-Bild,
das meist im GIF- oder JPEG-Format gespeichert ist. Die Gruppe von
Map-Daten enthält
eine Beschreibung der verweissensitiven Regionen in dem Bild. Der
Host-Eintrag enthält
den HTML-Code, der das Bild auf der Web-Seite platziert und es als
verweissensitiv kennzeichnet.
-
Eine
Image-Map weist ein spezielles Verhalten für die Widgets auf, die Maus-Ereignisse erwarten.
Ein mausartiges Pfeilbild erscheint, um Maus-Ereignisse für diese
Widgets zu simulieren. Die Simulation erzeugt Ereignisse für Maus nach
oben oder unten, klicken, bewegen und ziehen. Die Pfeilbewegung
ist sehr langsam und macht die Benutzeroberfläche (UI) unvereinbar mit dem übrigen UI-Modell
für eine
Settop-Box. Bei der bestehenden Lösung wird ein mit der (den)
Lightweight-Komponente(n) verbundener nativer Widget „focus
traversable" gemacht
und wie eine Image-Map gehandhabt, um Maus-Ereignisse zu simulieren.
Dies verursacht unerwünschte
Probleme in dem Benutzeroberflächenmodell.
-
Nach
der bekannten Technik wird der mit einer Lightweight-Komponente
verbundene native Container als eine Image-Map angesehen, weshalb
alle in diesem Container enthaltenen Komponenten wie eine Image-Map
behandelt werden. Dies ist auch der Fall, wenn die anderen Komponenten
keine Maus-Ereignisse erwarten und folglich nicht als Image-Map
angesehen werden sollten. Die Verarbeitung von Lightweight-Komponenten
als Image-Maps führt
zu unerwünschten
Benutzeroberflächenmodellen,
die den Benutzerdialog sehr verlangsamen, weil sie zum Beispiel
unnötig
komplizierte Benutzeroperationen erfordern, um eine einfache Navigationsaufgabe
auszuführen.
-
Außerdem kann
eine Lightweight-Komponente, die eine der P-Java-spezifischen Schnittstellen
wie zum Beispiel NoInputPreferred und KeyboardInputPreferred implementiert,
eventuell nie Fokus-Ereignisse erhalten, wenn die Lightweight-Komponente
als eine Image-Map behandelt wird. Dies liegt daran, dass das native
Fenstersystem nichts von den Lightweight-Komponenten weiß. Dadurch
kommt es zu Inkonsistenz zwischen Java-nativen Widgets und den Lightweight-Komponenten.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Bei
Computersystemen, bei denen es entweder nicht möglich oder nicht vorteilhaft
ist, ein Zeigegerät zu
verwenden, ist die Fokus-Navigation (das heißt das Liefern von Fokus-Ereignissen)
für Lightweight-Komponenten
im günstigsten
Fall schwierig. Bei einer Ausführungsform
der vorliegenden Erfindung wird eine Lightweight-Komponente „focus
traversable" gemacht,
indem für
jede einzelne Lightweight-Komponente ein pseudonativer Fenstersystem-Widget
erzeugt wird. Dieser pseudonative Widget ist mit keiner Geometrie
verbunden und bewirkt keine Darstellung der Komponente, denn die
Darstellung von Lightweight-Komponenten erfolgt in Java.
-
Der
pseudonative Widget existiert in der Widget-Liste des nativen Fenstersystems
und beansprucht einen Platz, wodurch das native Fenstersystem veranlasst
wird, mit jeder Lightweight-Komponente eine native Struktur zu verbinden,
um dadurch dem Fenstersystem den Zugriff auf die Lightweight-Komponenten
zu ermöglichen.
Weil die pseudonativen Widgets in der Liste der normalen Widgets
enthalten sind, stimmt die Fokus-Navigation für Lightweight-Komponenten mit
den normalen (das heißt
Heavyweight-Komponenten) Fenstersystem-Widgets überein, wodurch die Lightweight-Komponenten
für alle
Fokus-Navigationsereignisse sichtbar werden. Sobald ein Lightweight-Widget den Fokus
hat, können
alle nachfolgenden Ereignisse an ihn geliefert werden.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 zeigt
ein Ablaufdiagramm für
ein Verfahren zum Erzeugen von pseudonativen Komponenten für Lightweight-Komponenten
nach einer Ausführungsform
der vorliegenden Erfindung.
-
2 zeigt
ein Ablaufdiagramm dafür,
wie Lightweight-Komponenten Fokus-Ereignisse nach einer Ausführungsform
der vorliegenden Erfindung annehmen.
-
3 zeigt
eine Kompilier- und Laufzeitumgebung für ein Beispiel eines Verarbeitungssystems
für eine
Ausführungsform
der Erfindung.
-
4 zeigt
ein Blockdiagramm einer Ausführungsform
eines Computersystems, das eine geeignete Ausführungsumgebung für eine Ausführungsform
der Erfindung bereitstellen kann.
-
AUSFÜHRLICHE
BESCHREIBUNG DER ERFINDUNG
-
Die
Erfindung umfasst ein Verfahren und eine Vorrichtung zur Unterstützung von
Java Lightweight-Komponenten auf Settop-Boxen. In der nachstehenden
Beschreibung sind zahlreiche bestimmte Einzelheiten angegeben, um
eine ausführliche
Beschreibung der Ausführungsformen
der Erfindung zu geben. Für den
Fachmann ist jedoch ersichtlich, dass die Erfindung auch ohne diese
spezifischen Details angewandt werden kann. In anderen Fallen sind
bekannte Merkmale nicht ausführlich
beschrieben, um das Verständnis
der Erfindung nicht zu erschweren.
-
Lightweight-Komponenten
werden im Allgemeinen in geräteunabhängigen Programmiersprachen
geschrieben und als transparent für das native System ausgelegt.
Java Lightweight-Komponenten sind zum Beispiel in reinem Java-Code
geschrieben. Weil eine Lightweight-Komponente für das native System transparent ist,
ist keine native Komponente mit der Lightweight-Komponente verbunden.
Dadurch wird es schwierig, Lightweight-Komponenten ohne Verwendung
eines Zeigegeräts
den Fokus zu geben.
-
Auf
Desktop-Systemen mit einem Zeigegerät (zum Beispiel einer Maus)
klickt ein Benutzer auf die Lightweight-Komponente, um ihr den Fokus
zu geben. Sobald eine Komponente (Lightweight- oder Heavyweight-Komponente)
den Fokus hat (das heißt „focus
traversable" wird),
beginnt sie, Fokus- und andere Ereignisse anzunehmen. Verschiedene
Computersysteme haben entweder keine Zeigegeräte oder ein Benutzer kann es
vorziehen, ohne das Zeigegerät
zu navigieren. In bestimmten Fällen
ist es vorteilhaft, ohne Zeigegerät zu navigieren, zum Beispiel
wenn ein „Power
User" schneller
arbeiten möchte,
für den
Zugriff durch Menschen mit Behinderungen oder zur Vermeidung des
RSI-Syndroms („repetitive
stress injury").
In diesen Fällen
und bei Systemen ohne Zeigegeräte
ist es schwierig, die Fokus-Navigation (das heißt die Benutzung der Cursor-Tasten oder irgendeiner
anderen Tastenkombination auf der Tastatur) für Lightweight-Komponenten zu ermöglichen.
-
Bei
einer oder mehr Ausführungsformen
der vorliegenden Erfindung wird für jede Lightweight-Komponente
eine pseudonative Komponente erzeugt. Die pseudonative Komponente
macht die Fokus-Navigation mit Lightweight-Komponenten möglich. Eine
pseudonative Komponente fungiert als Platzhalter für die Position und
Größe einer
Komponente. Bei einer Ausführungsform
ist mit diesen pseudonativen Komponenten keine Geometrie verbunden,
und es erfolgt keine Darstellung der Lightweight-Komponenten. Das
Darstellen bzw. Rendern der Lightweight-Komponenten erfolgt in Java.
-
Das
native Fenstersystem verwaltet eine Liste seiner nativen Komponenten,
und jede neu erzeugte pseudonative Komponente wird in die Liste
der Komponenten aufgenommen und belegt einen Platz. Daher verbindet
das native Fenstersystem eine native Struktur mit der Lightweight-Komponente,
um dem Fenstersystem den Zugriff auf die Lightweight-Komponente
zu ermöglichen.
Weil die pseudonativen Komponenten in der Liste der regulären Komponenten
enthalten sind, entspricht die Fokus-Navigation den nativen Fenstersystem-Widgets,
wodurch die Lightweight-Komponenten für das native Fenstersystem
sichtbar werden, so dass diese pseudonativen Komponenten alle Ereignisse
sehen können.
Ereignisse, die zum Beispiel für
native Komponenten wie „focus" und „resize" verfügbar sind,
können
jetzt auch an diesen Lightweight-Komponenten ausgeführt werden.
-
1 zeigt
ein Ablaufdiagramm für
ein Verfahren zum Erzeugen von pseudonativen Komponenten für Lightweight-Komponenten
nach einer Ausführungsform
der vorliegenden Erfindung. Eine Liste aller Lightweight-Komponenten
wird zur Verarbeitung erzeugt (zum Beispiel in Schritt 100).
Diese Liste kann auf die Lightweight-Komponenten beschränkt sein,
die „focus
traversable" sein
müssen.
Bei der Verarbeitung wird eine Lightweight-Komponente aus der Liste
ausgewählt
(zum Beispiel in Schritt 102) und geprüft, ob sie „focus traversable" ist (in Schritt 103).
Ist die Lightweight-Komponente
nicht „focus
traversable", wird
eine pseudonative Komponente für
die ausgewählte
Lightweight-Komponente erzeugt (zum Beispiel in Schritt 104),
und die Verarbeitung wird in Schritt 105 fortgesetzt. Ist
die ausgewählte
Lightweight-Komponente jedoch „focus
traversable", wird
die Verarbeitung in Schritt 110 fortgesetzt, um festzustellen,
ob eine weitere Verarbeitung nötig ist.
-
In
Schritt 105 wird das Binding-Rechteck der ausgewählten Lightweight-Komponente
in der neu erzeugten pseudonativen Komponente (aus Schritt 104)
gespeichert, und der neu erzeugte Pseudo-Widget wird in die Liste
der nativen Widgets des nativen Fenstersystems aufgenommen (in Schritt 106).
Die Verarbeitung wird in Schritt 110 fortgesetzt. Liegen
in Schritt 110 weitere Lightweight-Komponenten zur Verarbeitung
vor, wird die Verarbeitung in Schritt 108 fortgesetzt,
um eine neue Lightweight-Komponente auszuwählen, die „focus traversable" gemacht werden soll.
Von Schritt 108 geht die Verarbeitung zurück zu Schritt 103,
um das Erzeugen von pseudonativen Komponenten fortzusetzen, bis
alle Lightweight-Komponenten verarbeitet sind (das heißt bis pseudonative
Komponenten für
alle Lightweight-Komponenten erzeugt worden sind).
-
Nachdem
alle Lightweight-Komponenten verarbeitet worden sind (zum Beispiel
in Schritt 110), endet die Verarbeitung. Diese pseudonativen
Komponenten verhalten sich wie (reguläre) Heavyweight-Komponenten,
die in dem nativen Fenstersystem „focus traversable" sind. Eine Heavyweight-Komponente
ist eine Komponente, die mit einer eigenen nativen Bildschirmressource
(im Allgemeinen als Peer bezeichnet) verbunden ist, während eine
Lightweight-Komponente eine Komponente ist, die die Bildschirmressource
eines Vorgängers „borgt" (was bedeutet, dass
sie keine eigene native Ressource aufweist und daher „leichter" ist).
-
Bei
einer Ausführungsform
der vorliegenden Erfindung werden Lightweight-Komponenten „focus traversable" gemacht, indem die
momentane Klasse awt java.Toolkit.LightweightPeer erweitert wird
und die Anwendungsprogrammschnittstellen (APIs) nach Bedarf geändert werden
(zum Beispiel setVisible, setBounds). So liefert zum Beispiel „createComponent()
for Lightweight" als
Ergebnis „CTGLightweightPeer" anstelle von „LightweightPeer", wobei CTGLightweight
eine plattformspezifische Implementierung ist. Je nach den in dem nativen
System implementierten APIs kann ein Ereignis-Mapping zwischen Java
und dem nativen System erforderlich sein. Eine Übersetzungstabelle kann zum
Beispiel erforderlich sein, um Fokus-Ereignisse zwischen dem nativen
System und den Java Komponenten zuzuordnen.
-
Die
nachstehende Code-Sequenz zeigt ein Beispiel für eine Ausführungsform nach der vorliegenden Erfindung
zur Erweiterung der Möglichkeiten
von Lightweight-Komponenten.
Sie implementiert die LightweightPeer-Schnittstelle zur Verwendung
in Lightweight-Komponenten, denen kein natives Fenster zugeordnet
ist. Dies wird standardmäßig in der
Komponente erzeugt, so dass die Komponente und der Container direkt erweitert
werden können,
um nützliche
Komponenten zu erzeugen, die vollständig in Java geschrieben sind. Diese
Komponenten müssen
an anderer Stelle weiter oben im Komponentenbaum mit einem nativen
Container wie zum Beispiel einem Rahmen („frame") als Host angesiedelt werden.
-
Diese
Implementierung liefert keine sinnvolle Semantik und dient nur als
Marker. Alternative Implementierungen in Java können vorgesehen werden, um
nützliche
Funktionen für
bestimmte der anderen Peer-Schnittstellen auszuführen, um den nativen Code auf
ein Minimum zu verringern.
-
-
-
-
Weil
die Deklaration
CTGLightweightPeer extends CTGComponentPeer
implements
java.awt.peer.LightweightPeer
besagt, dass „CTGComponentPeer" von „CTGLightweightPeer" erweitert wird,
kopiert sie daher das Verhalten einer Heavyweight-Komponente, soweit
dies erforderlich ist, zum Beispiel bei der Fokus-Navigation.
-
2 zeigt
ein Ablaufdiagramm dafür,
wie die Lightweight-Komponenten Fokus-Ereignisse nach einer Ausführungsform
der vorliegenden Erfindung annehmen. Wenn der Benutzer in Schritt 200 die
Fokus-Navigation benutzt (das heißt die Cursor-Tasten oder andere
Tasten auf der Tastatur), informiert die pseudonative Komponente,
wenn sie in Schritt 202 ein Fokus-Ereignis erhält, die
entsprechende Lightweight-Komponente, danach den Fokus anzunehmen,
und die Lightweight-Komponente beginnt in Schritt 206,
Fokus-Ereignisse anzunehmen.
-
Wie
schon zuvor in dieser Beschreibung ausgeführt, bewirken die pseudonativen
Komponenten, dass sich die Lightweight-Komponenten wie reguläre Heavyweight-Komponenten verhalten.
-
Ausführungsform einer Verarbeitungsumgebung
-
Eine
Ausführungsform
der Erfindung bezieht sich unter anderem darauf, Lightweight-Komponenten beim
Arbeiten ohne Maus „focus
traversable" zu
machen, so dass sie mit Heavyweight-Komponenten konsistent sind.
Solche Lightweight-Komponenten werden mit objektorientierten Programmierumgebungen
implementiert, die ausführbare
Software-Objekte erzeugen. Die Lightweight-Komponenten laufen in
einer virtuellen Maschinenumgebung, weil sie maschinenunabhängig sind,
und werden im Allgemeinen mit Bytecode-Class-Dateien implementiert.
Die nachstehende Beschreibung bezieht sich auf eine Ausführungsform
einer Laufzeitumgebung auf der Basis einer virtuellen Maschine,
obwohl offensichtlich ist, dass die Erfindung nicht hierauf beschränkt ist.
-
Anwendungen
weisen typischerweise eine oder mehr Objektklassen auf. Klassen,
die in einer Programmiersprache höherer Ordnung wie zum Beispiel
JavaTM geschrieben sind, können zu
maschinenunabhängigen
Bytecode-Class-Dateien kompiliert werden. Alternativ können Klassen
in maschinenabhängigen ausführbaren
Programmcode zur direkten Ausführung
auf einer bestimmten Hardware-Plattform kompiliert werden. In dem
maschinenunabhängigen
Fall enthält
jede Class-Datei Code und Daten in einem plattformunabhängigen Format,
das als Class-Dateiformat bezeichnet wird. Das als Ausführungsvehikel
dienende Computersystem enthält
ein als virtuelle Maschine bezeichnetes Programm, das für die Ausführung des
Codes in jeder Class-Datei zuständig
ist. (Ein Hardware-System, das den Bytecode von Class-Dateien direkt
ausführt, kann
ebenfalls verwendet werden.)
-
In
einer virtuellen Maschinenumgebung werden die Klassen einer Anwendung
auf Anforderung aus dem Netzwerk (gespeichert auf einem Server)
oder aus einem lokalen Dateisystem geladen, wenn sie erstmals bei
der Ausführung
der Anwendung angesprochen werden. Die virtuelle Maschine lokalisiert
und lädt
jede Class-Datei, analysiert das Class-Dateiformat, weist den Speicher
für die
verschiedenen Komponenten der Klasse zu und verknüpft die
Klasse mit anderen bereits geladenen Klassen. Dieser Prozess macht
den Code in der Klasse für
die virtuelle Maschine ohne weiteres ausführbar.
-
3 zeigt
die Kompilier- und Laufzeitumgebungen für ein Beispiel eines Verarbeitungssystems.
In der Kompilierumgebung erzeugt ein Software-Entwickler Quelldateien 300,
die die für
den Programmierer lesbaren Klassendefinitionen, geschrieben in der
Quellprogrammiersprache, einschließlich Datenstrukturen, Verfahrensimplementierungen
und Verweisen auf andere Klassen enthalten. Die Quelldateien 300 werden
an den Vorkompilierer 301 geliefert, der die Quelldateien 300 zu „.class"-Dateien 302 kompiliert,
die von einer virtuellen Maschine ausführbaren Bytecode enthalten.
Die Bytecode-Class-Dateien 302 werden auf einem Server (zum
Beispiel in einem temporären
oder permanenten Speicher) gespeichert und stehen zum Download über ein
Netzwerk zur Verfügung.
Alternativ können
die Bytecode-Class-Dateien 302 lokal in einem Verzeichnis
auf der Client-Plattform gespeichert werden.
-
Die
Laufzeitumgebung weist eine virtuelle Maschine (VM) 305 auf,
die Bytecode-Class-Dateien
und bei Bedarf während
der Ausführung
native Betriebssystemaufrufe („OS"-Aufrufe) an das
Betriebssystem 309 ausführen
kann. Die virtuelle Maschine 305 liefert eine Ebene der
Abstraktion zwischen der Maschinenunabhängigkeit der Bytecode-Klassen
und dem maschinenabhängigen
Befehlsvorrat der zugrundeliegenden Computer-Hardware 310 sowie
den plattformabhängigen
Aufrufen des Betriebssystems 309.
-
Der
Class-Loader und Bytecode-Verifizierer („Class-Loader") 303 ist
dafür zuständig, die
Bytecode-Class-Dateien 302 nach Bedarf in die virtuelle
Maschine 305 zu laden und die Class-Bibliotheken 304 zu unterstützen. Der
Class-Loader 303 verifiziert auch den Bytecode in jeder
Class-Datei, um für
die ordnungsgemäße Ausführung und
die Durchsetzung der Sicherheitsregeln zu sorgen. Innerhalb des
Kontexts des Laufzeitsystems 308 führt entweder ein Interpreter 306 den
Bytecode direkt aus, oder ein "justin-time"- oder JIT-Kompilierer 307 wandelt
den Bytecode in Maschinencode um, so dass dieser von dem Prozessor
(bzw. den Prozessoren) in der Hardware 310 ausgeführt werden
kann.
-
Das
Laufzeitsystem 308 der virtuellen Maschine 305 unterstützt eine
allgemeine Stapelarchitektur. Die An und Weise, wie diese allgemeine
Stapelarchitektur von der zugrundeliegenden Hardware 310 unterstützt wird,
richtet sich nach der speziellen Implementierung der virtuellen
Maschine und spiegelt sich in der An und Weise wider, wie der Bytecode
interpretiert oder JIT-kompiliert wird. Weitere Elemente des Laufzeit systems sind
unter anderem Mechanismen für
die Thread-Verwaltung (zum Beispiel die Ablaufplanung) und die Speicherbereinigung.
-
Ausführungsform einer Computer-Ausführungsumgebung
(Hardware)
-
Eine
Ausführungsform
der Erfindung kann als Computer-Software in Form von computerlesbarem Code
implementiert werden, der auf einer Computer-Verarbeitungsplattform
ausgeführt
wird, oder in Form von Software (zum Beispiel Bytecode-Class-Dateien), die in
einer Laufzeitumgebung auf einer solchen Verarbeitungsplattform
ausgeführt
werden kann. Eine Ausführungsform
der Erfindung kann in jeder An von Computersystem oder Programmier-
oder Verarbeitungsumgebung implementiert werden, einschließlich eingebetteter Geräte (zum
Beispiel Internet-Telefone, Settop-Boxen usw.) und „dünner" Client-Verarbeitungsumgebungen (z.B.
Netzwerkcomputer [NC] usw.). Ein Beispiel eines allgemeinen Computersystems
ist in 4 gezeigt. Das nachstehend beschriebene Computersystem
dient nur als Beispiel.
-
In 4 sind
die Tastatur 410 und die Maus 411 an einen Systembus 418 angeschlossen.
Die Tastatur und die Maus dienen zur Vornahme von Benutzereingaben
in das Computersystem und zur Weiterleitung dieser Benutzereingaben
an den Prozessor 413. Andere geeignete Eingabegeräte können zusätzlich oder
anstelle der Maus 411 und der Tastatur 410 verwendet
werden. Die an den Systembus 418 angeschlossene E/A-Einheit (Eingabe-/Ausgabeeinheit) 419 steht
für E/A-Komponenten
wie Drucker, AV-Geräte (Audio-Nideogeräte) usw.
-
Der
Computer 400 umfasst einen Videospeicher 414,
einen Hauptspeicher 415 und einen Massenspeicher 412,
die alle an den Systembus 418 angeschlossen sind, zusammen
mit der Tastatur 410, der Maus 411 und dem Prozessor 413.
Der Massenspeicher 412 kann sowohl feste als auch wechselbare
Datenträger umfassen,
zum Beispiel magnetische, optische oder magneto-optische Speichersysteme
oder andere verfügbare
Massenspeichertechnologie. Der Bus 418 kann zum Beispiel
Adressleitungen zum Adressieren des Videospeichers 414 oder
des Hauptspeichers 415 umfassen. Der Systembus 418 umfasst
zum Beispiel auch einen Datenbus zur Übertragung von Daten zwischen
den Komponenten wie zum Beispiel dem Prozessor 413, dem
Hauptspeicher 415, dem Videospeicher 414 und dem
Massenspeicher 412. Alternativ können Multiplex-Daten-/Adressleitungen
anstelle von getrennten Daten- und Adressleitungen verwendet werden.
-
Bei
einer Ausführungsform
der Erfindung ist der Prozessor 413 ein SPARCTM-Mikroprozessor von Sun
Microsystems, Inc. oder ein von Intel hergestellter Mikroprozessor,
zum Beispiel ein Prozessor 80X86 oder Pentium, oder ein von Motorola
hergestellter Mikroprozessor, zum Beispiel der Prozessor 680X0.
Jeder andere geeignete Mikroprozessor oder Mikrocomputer kann aber
ebenfalls verwendet werden. Der Hauptspeicher 415 besteht
aus dynamischen Direktzugriffsspeichermodulen (DRAM-Modulen). Der Videospeicher 414 ist
ein Direktzugriffs-Videospeicher mit zwei Ports. Ein Port des Videospeichers 414 ist
an den Videoverstärker 416 angeschlossen.
Der Videoverstärker 416 dient
zur Ansteuerung des Kathodenstrahlröhren- oder CRT-Rastermonitors 417.
Der Videoverstärker 416 ist
in der Technik bekannt und kann mit jeder geeigneten Vorrichtung
implementiert werden. Diese Schaltung wandelt die in dem Videospeicher 414 gespeicherten
Pixeldaten in ein für
den Monitor 417 geeignetes Rastersignal um. Der Monitor 417 ist
ein zum Anzeigen von Grafiken und Bildern geeigneter Monitor. Alternativ
könnte
der Videospeicher verwendet werden, um einen Flachbildschirm oder
ein Flüssigkristall-Display
(LCD) oder jedes andere geeignete Datenanzeigegerät anzusteuern.
-
Der
Computer 400 kann auch eine Kommunikationsschnittstelle 420 aufweisen,
die an den Bus 418 angeschlossen ist. Die Kommunikationsschnittstelle 420 ermöglicht eine
zweiseitige Datenkommunikationsverbindung über eine Netzwerkverbindung 421 zu
einem lokalen Netzwerk 422. Ist die Kommunikationsschnittstelle 420 zum
Beispiel eine ISDN-Karte („integrated
services digital network")
oder ein Modem, bietet die Kommunikationsschnittstelle 420 eine
Datenkommunikationsverbindung mit der entsprechenden Art von Telefonleitung,
die Teil der Netzwerkverbindung 421 ist. Ist die Kommunikationsschnittstelle 420 eine
LAN-Karte („local
area network"),
stellt die Kommunikationsschnittstelle 420 eine Datenkommunikationsverbindung über die
Netzwerkverbindung 421 zu einem kompatiblen LAN bereit.
Die Kommunikationsschnittstelle 420 könnte auch ein Kabelmodem oder
eine drahtlose Schnittstelle sein. Bei jeder derartigen Implementierung
sendet und empfängt
die Kommunikationsschnittstelle 420 elektrische, elektromagnetische
oder optische Signale, die digitale Datenströme für die verschiedenen Arten von
Informationen transportieren.
-
Die
Netzwerkverbindung 421 ermöglicht typischerweise die Datenkommunikation über ein
oder mehr Netzwerke zu anderen Datengeräten. Die Netzwerkverbindung 421 kann
zum Beispiel eine Verbindung über das
lokale Netzwerk 422 zu dem lokalen Ser ver 423 oder
zu den von einem Internet-Serviceprovider (ISP) 424 betriebenen
Datengeräten
bereitstellen. Der ISP 424 wiederum stellt Datenkommunikationsdienste über das weltweite
paketvermittelte Datenkommunikationsnetzwerk bereit, das heute allgemein
als das „Internet" 425 bezeichnet
wird. Das lokale Netzwerk 422 und das Internet 425 arbeiten
beide mit elektrischen, elektromagnetischen oder optischen Signalen,
die digitale Datenströme
transportieren. Die Signale in den verschiedenen Netzwerken und
die Signale auf der Netzwerkverbindung 421 und durch die
Kommunikationsschnittstelle 420, die die digitalen Daten
zu und von dem Computer 400 transportieren, sind beispielhafte
Formen von Trägerwellen,
die Informationen transportieren.
-
Über das
(die) Netzwerk(e), die Netzwerkverbindung 421 und die Kommunikationsschnittstelle 420 kann
der Computer 400 Meldungen senden und Daten einschließlich Programmcode
empfangen. Bei dem Internet-Beispiel kann der dezentrale Server 426 einen
angeforderten Code für
ein Anwendungsprogramm über das
Internet 425, den ISP 424, das lokale Netzwerk 422 und
die Kommunikationsschnittstelle 420 übermitteln.
-
Der
empfangene Code kann nach Empfang von einem Prozessor 413 ausgeführt und/oder
in dem Massenspeicher 412 oder einem anderen nicht flüchtigen
Speicher zur späteren
Ausführung
gespeichert werden. Auf diese Weise kann der Computer 400 Anwendungscode
in der Form von Trägerwellen
empfangen. Der Anwendungscode kann in einer beliebigen Form von
Computerprogrammerzeugnis ausgeführt
sein. Ein Computerprogrammerzeugnis umfasst ein Medium, das zum
Speichern oder Transportieren von computerlesbarem Code oder Daten
konfiguriert ist oder in dem computerlesbarer Code oder Daten eingebettet
sein können.
Einige Beispiele für
Computerprogrammerzeugnisse sind CD-ROMs, ROM-Karten, Disketten,
Magnetbänder,
Computerfestplatten, Server in einem Netzwerk und Trägerwellen.
-
Damit
sind ein Verfahren und eine Vorrichtung zur Unterstützung von
Java Lightweight-Komponenten auf Settop-Boxen in Zusammenhang mit
einer oder mehreren bestimmten Ausführungsformen beschrieben worden.
Die Erfindung ist durch die Ansprüche definiert.