DE60213969T2 - Vorrichtung und verfahren für lightweight unterstützung in einer set top box - Google Patents

Vorrichtung und verfahren für lightweight unterstützung in einer set top box Download PDF

Info

Publication number
DE60213969T2
DE60213969T2 DE60213969T DE60213969T DE60213969T2 DE 60213969 T2 DE60213969 T2 DE 60213969T2 DE 60213969 T DE60213969 T DE 60213969T DE 60213969 T DE60213969 T DE 60213969T DE 60213969 T2 DE60213969 T2 DE 60213969T2
Authority
DE
Germany
Prior art keywords
native
lightweight
window
focus
widget
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60213969T
Other languages
English (en)
Other versions
DE60213969D1 (de
Inventor
Kuldipsingh Santa Clara PABLA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Application granted granted Critical
Publication of DE60213969D1 publication Critical patent/DE60213969D1/de
Publication of DE60213969T2 publication Critical patent/DE60213969T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0487Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser
    • G06F3/0489Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser using dedicated keyboard keys or combinations thereof
    • G06F3/04892Arrangements for controlling cursor position based on codes indicative of cursor displacements from one discrete location to another, e.g. using cursor control keys associated to different directions or using the tab key
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance

Description

  • 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.
  • CTGLightweightPeer.iava
    Figure 00100001
  • Figure 00110001
  • Figure 00120001
  • 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.

Claims (21)

  1. Verfahren in einem Computersystem, um Lightweight-Komponenten Fokus-Ereignisse anzubieten, mit folgenden Schritten: Wählen einer Lightweight-Komponente, die eine Komponente ohne native opake Fensterzuordnung ist (102), und Erzeugen eines pseudonativen Fenstersystem-Widgets für die Lightweight-Komponente, so daß das native Fenstersystem mit der Lightweight-Komponente eine native Struktur verbindet (103).
  2. Verfahren nach Anspruch 1, wobei der pseudonative Fenster-Widget in die Widget-Liste des nativen Fenstersystems aufgenommen wird (106).
  3. Verfahren nach Anspruch 1, wobei dem pseudonativen Fenster-Widget Fokus-Ereignisse geliefert werden (206).
  4. Verfahren nach Anspruch 3, wobei der pseudonative Fenster-Widget der Lightweight-Komponente mitteilt, die Fokus-Ereignisse anzunehmen.
  5. Verfahren nach Anspruch 3, wobei die Fokus-Ereignisse durch Cursor-Tasten auf der Tastatur eines Computersystems geliefert werden.
  6. Verfahren nach Anspruch 3, wobei die Fokus-Ereignisse durch irgendeine Tastenkombination auf der Tastatur eines Computersystems geliefert werden.
  7. Verfahren nach Anspruch 1, wobei die Lightweight-Komponente geräteunabhängig ist.
  8. Computerprogrammerzeugnis, aufweisend ein computerlesbares Medium mit darin ausgestaltetem Computerprogrammcode, um Lightweight-Komponenten Fokus-Ereignisse anzubieten, wobei das computerlesbare Medium einen Computerprogrammcode enthält, der einen Computer veranlassen kann, eine Lightweight-Komponente zu wählen, die eine Komponente ohne native opake Fensterzuordnung ist (102), und für die Lightweight-Komponente einen pseudonativen Fenstersystem-Widget zu erzeugen, so daß das native Fenstersystem mit der Lightweight-Komponente eine native Struktur verbindet (103).
  9. Computerprogrammprodukt nach Anspruch 8, wobei der pseudonative Fenster-Widget in die Widget-Liste des nativen Fenstersystems aufgenommen wird (106).
  10. Computerprogrammprodukt nach Anspruch 8, wobei dem pseudonativen Fenster-Widget Fokus-Ereignisse geliefert werden (206).
  11. Computerprogrammprodukt nach Anspruch 10, wobei der pseudonative Fenster-Widget der Lightweight-Komponente mitteilt, die Fokus-Ereignisse anzunehmen (204).
  12. Computerprogrammprodukt nach Anspruch 10, wobei die Fokus-Ereignisse von Cursor-Tasten auf der Tastatur eines Computersystems geliefert werden.
  13. Computerprogrammprodukt nach Anspruch 10, wobei die Fokus-Ereignisse von irgendeiner Tastenkombination auf der Tastatur eines Computersystems geliefert werden.
  14. Computerprogrammprodukt nach Anspruch 8, wobei Lightweight-Komponente geräteunabhängig ist.
  15. Vorrichtung zur Fokus-Navigation bei Lightweight-Komponenten, aufweisend einen Client-Computer, eine virtuelle Maschine auf dem Client-Computer, ein Fenster-System auf dem Client-Computer mit Lightweight-Komponenten, die auf der virtuellen Maschine laufen, und einen Mechanismus zur Erzeugung von pseudonativen Fenstersystem-Widgets für die Lightweight-Komponenten, so daß das native Fenstersystem mit einer Lightweight-Komponente eine native Struktur verbindet.
  16. Vorrichtung nach Anspruch 15, wobei die pseudonativen Fenster-Widgets in die Widget-Liste des nativen Fenstersystems aufgenommen werden (106).
  17. Vorrichtung nach Anspruch 15, wobei dem pseudonativen Fenster-Widget Fokus-Ereignisse geliefert werden (206).
  18. Vorrichtung nach Anspruch 17, wobei der pseudonative Fenster-Widget der Lightweight-Komponente mitteilt, die Fokus-Ereignisse anzunehmen (204).
  19. Vorrichtung nach Anspruch 17, wobei die Fokus-Ereignisse von Cursor-Tasten auf der Tastatur eines Computersystems geliefert werden.
  20. Vorrichtung nach Anspruch 17, wobei die Fokus-Ereignisse von irgendeiner Tastenkombination auf der Tastatur eines Computersystems geliefert werden.
  21. Vorrichtung nach Anspruch 15, wobei die Lightweight-Komponente geräteunabhängig ist.
DE60213969T 2001-03-14 2002-03-13 Vorrichtung und verfahren für lightweight unterstützung in einer set top box Expired - Lifetime DE60213969T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US809392 1991-12-17
US09/809,392 US7219331B2 (en) 2001-03-14 2001-03-14 Method and apparatus for lightweight support on set top box
PCT/US2002/007762 WO2002073399A2 (en) 2001-03-14 2002-03-13 Method and apparatus for lightweight support on set top box

Publications (2)

Publication Number Publication Date
DE60213969D1 DE60213969D1 (de) 2006-09-28
DE60213969T2 true DE60213969T2 (de) 2007-04-12

Family

ID=25201239

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60213969T Expired - Lifetime DE60213969T2 (de) 2001-03-14 2002-03-13 Vorrichtung und verfahren für lightweight unterstützung in einer set top box

Country Status (5)

Country Link
US (1) US7219331B2 (de)
EP (1) EP1388040B1 (de)
AU (1) AU2002244292A1 (de)
DE (1) DE60213969T2 (de)
WO (1) WO2002073399A2 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7415480B2 (en) * 2003-12-10 2008-08-19 Symantec Operating Corporation System and method for providing programming-language-independent access to file system content
AU2005239421B2 (en) * 2004-04-26 2012-04-12 Google Inc. Methods and systems for dynamically composing distributed interactive applications from high-level programming languages
EP1596291A1 (de) * 2004-05-10 2005-11-16 Deutsche Thomson-Brandt Gmbh Verfahren und Vorrichtung zur automatischen Auswahl von Software Anwendungen
US7962552B2 (en) * 2005-11-14 2011-06-14 Red Hat, Inc. Borrow and give back of windows
CN101944017B (zh) * 2009-07-09 2014-03-12 华为技术有限公司 一种Widget的制作方法及其制作装置
US8528005B2 (en) * 2010-04-09 2013-09-03 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement in an IPTV terminal
US10089159B2 (en) 2016-11-03 2018-10-02 Microsoft Technology Licensing, Llc Processing non-spatial input by multiple program elements of a computer program executed on a computer
US11809839B2 (en) 2022-01-18 2023-11-07 Robert Lyden Computer language and code for application development and electronic and optical communication

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5721848A (en) * 1994-02-04 1998-02-24 Oracle Corporation Method and apparatus for building efficient and flexible geometry management widget classes
US6930695B1 (en) 1998-11-30 2005-08-16 Sun Microsystems, Inc. Method and apparatus for detecting device support in a graphical user interface
US6429882B1 (en) * 1999-03-15 2002-08-06 Sun Microsystems, Inc. User interface component
US6601233B1 (en) * 1999-07-30 2003-07-29 Accenture Llp Business components framework
US6718535B1 (en) * 1999-07-30 2004-04-06 Accenture Llp System, method and article of manufacture for an activity framework design in an e-commerce based environment
US6636242B2 (en) * 1999-08-31 2003-10-21 Accenture Llp View configurer in a presentation services patterns environment
US6442748B1 (en) * 1999-08-31 2002-08-27 Accenture Llp System, method and article of manufacture for a persistent state and persistent object separator in an information services patterns environment
US6701514B1 (en) * 2000-03-27 2004-03-02 Accenture Llp System, method, and article of manufacture for test maintenance in an automated scripting framework
US20030212987A1 (en) * 2001-02-28 2003-11-13 Demuth Steven J. Client container for building EJB-hosted java applications

Also Published As

Publication number Publication date
WO2002073399A2 (en) 2002-09-19
DE60213969D1 (de) 2006-09-28
EP1388040B1 (de) 2006-08-16
US7219331B2 (en) 2007-05-15
EP1388040A2 (de) 2004-02-11
WO2002073399A3 (en) 2003-11-27
US20020184608A1 (en) 2002-12-05
AU2002244292A1 (en) 2002-09-24

Similar Documents

Publication Publication Date Title
DE69635337T2 (de) Erweiterbares und austauschbares system von netzwerkkomponenten
DE60319229T2 (de) Verfahren und system zur erweiterung der api eines dateisystems
DE69533568T2 (de) Virtuelles Desk-Top-System und Verfahren dafür
Florins et al. Graceful degradation of user interfaces as a design method for multiplatform systems
US5973702A (en) Oriented view system having a common window manager for defining application window areas in a screen buffer and application specific view objects for writing into the screen buffer
DE69936162T2 (de) Verfahren und Gerät für ein objektorientiertes Unterbrechungssystem
DE60314563T2 (de) Überlagerung mit elektronischer Tinte
EP0734552B1 (de) Objektorientiertes aufgabensicheres rahmenwerk
DE102006012976A1 (de) Systeme und Verfahren zur Überführung von Daten zwischen Rechnern
DE10135445A1 (de) Integriertes Verfahren für das Schaffen einer aktualisierbaren Netzabfrage
DE112011105933T5 (de) Verfahren und Vorrichtungen zum dynamischen Anpassen einer virtuellen Tastatur
US5737559A (en) Object-oriented view hierarchy framework
DE112009000293T5 (de) Automatische Verbindungen zwischen Anwendungskomponenten
DE202014010906U1 (de) Vorrichtung für zweidimensionale Dokumentennavigation
DE112008003965T5 (de) Kombinieren von Schnittstellen von Shell-Anwendungen und Unteranwendungen
AU2018279309C1 (en) System and method for smart interaction between website components
DE112011103173T5 (de) Übergangsansicht auf einer tragbaren elektronischen Vorrichtung
DE60213969T2 (de) Vorrichtung und verfahren für lightweight unterstützung in einer set top box
DE202014010899U1 (de) Unterstützung von Benutzerinteraktionen mit wiedergegebenen Grafikobjekten
US5524200A (en) Object-oriented non-rectilinear viewing framework
DE69930352T2 (de) Verfahren und Vorrichtung zur Animierung von Videospezialeffekten
DE60015967T2 (de) System und verfahren zur änderung der drehlage von anzeigedaten
Beaudoux et al. DPI: A conceptual model based on documents and interaction instruments
US5796969A (en) Object-oriented view coordinate space system
DE10332492B4 (de) Verfahren und Anordnung zum visuellen Darstellen von Inhalten auf einem Darstellungsmittel

Legal Events

Date Code Title Description
8364 No opposition during term of opposition