FR2661525A1 - Procede et appareil destines a implanter une programmation orientee vers l'objet, utilisant c non modifie pour un systeme d'ordinateur a base de fenetre. - Google Patents
Procede et appareil destines a implanter une programmation orientee vers l'objet, utilisant c non modifie pour un systeme d'ordinateur a base de fenetre. Download PDFInfo
- Publication number
- FR2661525A1 FR2661525A1 FR9105113A FR9105113A FR2661525A1 FR 2661525 A1 FR2661525 A1 FR 2661525A1 FR 9105113 A FR9105113 A FR 9105113A FR 9105113 A FR9105113 A FR 9105113A FR 2661525 A1 FR2661525 A1 FR 2661525A1
- Authority
- FR
- France
- Prior art keywords
- window
- public
- library
- class
- new
- 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.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/76—Adapting program code to run in a different environment; Porting
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/38—Creation or generation of source code for implementing user interfaces
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Stored Programmes (AREA)
- Digital Computer Display Output (AREA)
Abstract
La présente invention décrit une interface d'utilisateur, orientée vers un objet, écrite en langage C non modifié. L'interface d'utilisateur comprend deux éléments, une couche au sommet de C et un jeu de composants d'interface d'utilisateur connus comme objets. La présente invention fournit, à une bibliothèque à fenêtre, à une bibliothèque à fenêtre une interface uniforme d'utilisateur orientée vers l'objet. La couche d'interface permet des applications pour créer les classes standard qui font partie de la bibliothèque à fenêtre. La couche d'interface utilise en outre les objets pour créer, de façon rapide et uniforme, un élément d'interface d'utilisateur de l'application à l'aide d'une abstraction de données. En outre, la présente invention prend en charge le développement de nouvelles classes par héritage.
Description
La présente invention concerne le domaine de l'implantation d'une programmation orientée vers un objet. De façon spécifique, la présente invention concerne le domaine de l'implantation d'une programmation orientée vers l'objet en utilisant, pour un système à base de fenêtre, un langage de programmation universel non modifié.
Il existe de nombreuses vues différentes concernant ce qu'est une programmation orientée vers l'objet, mais les scientifiques du domaine des ordinateurs et les programmeurs marquent leur accord sur un élément: les objets sont des composants qui combinent les propriétés d'une procédure et de données.
Tout l'effet d'une programmation orientée vers l'objet provient de l'envoi d'événements ou de messages entre objets. Même un envoi est une forme d'appel indirect de procédure. L'événement spécifie, entre autres choses, l'opération à effectuer sur un objet. Des objets répondent à un événement en utilisant leurs propres procédures (appelées "procédés") pour effectuer des opérations. Un jeu d'événements ou de messages définis comme interface uniforme pour des objets est appelé un protocole. Voir M. Stefik et D.G. Bobrow, "Object
Oriented Programming: Themes and Variations" (ou
Programmation Orientée vers l'Objet: Thèmes et
Variations) The AI Magazine, Vol. 6, N04, Hiver 1986, pages 40 à 62. Dans les termes de programmation orientée vers l'objet, la présente invention désigne une abstraction de données et un héritage.Une abstraction de données signifie qu'un objet présente une interface aux programmeurs d'application à l'aide d'un jeu de procédés. La manipulation des structures internes de données de l'objet et l'implantation de ces procédés sont complètement transparents pour les utilisateurs de l'objet. Ainsi, le programmeur d'application peut changer l'implantation sous-jacente d'une objection sans exiger que les utilisateurs de l'objet ne changent leurs appels de procédure.
Oriented Programming: Themes and Variations" (ou
Programmation Orientée vers l'Objet: Thèmes et
Variations) The AI Magazine, Vol. 6, N04, Hiver 1986, pages 40 à 62. Dans les termes de programmation orientée vers l'objet, la présente invention désigne une abstraction de données et un héritage.Une abstraction de données signifie qu'un objet présente une interface aux programmeurs d'application à l'aide d'un jeu de procédés. La manipulation des structures internes de données de l'objet et l'implantation de ces procédés sont complètement transparents pour les utilisateurs de l'objet. Ainsi, le programmeur d'application peut changer l'implantation sous-jacente d'une objection sans exiger que les utilisateurs de l'objet ne changent leurs appels de procédure.
Par héritage, on désigne une définition d'une nouvelle classe en tant que variation d'une classe existante. Une classe est une structure en arbre décrivant un ou plusieurs objets similaires. En tant que tel, l'héritage permet aux utilisateurs de réutiliser un logiciel existant pour construire un nouveau logiciel.
De nombreux environnements construits en utilisant C sont, de façon inhérente, orientés vers l'objet. Une interface graphique d'utilisateur construite sur un système à fenêtre en est un exemple.
Cependant, C ne prend pas en charge une programmation orientée vers l'objet. Voir L. Tesler, "Programming
Experiences" (ou Expériences de Programmation), Byte,
Août 1986.
Experiences" (ou Expériences de Programmation), Byte,
Août 1986.
Plusieurs approches ont été adaptées pour introduire en C des particularités de programmation orientée vers l'objet. Certaines ont exploré la possibilité de construire une structure modulaire dans
C. Voir D. Kalyan, "Modular Programming in C: An
Approach and Example" (ou "Programmation Modulaire en
C: Une Approche et un Exemple), SIGPLAN Notices, Volume 20, N03, Mars 1985, pages 9 à 15. L'approche modulaire est basée sur des variables statiques qui sont placées dans un fichier. Certaines approches exigent un processeur préalable comme objective-C. Voir par exemple S. Hook, Obzective-C Reference Manual, (ou
Manuel de Référence d'Objective-C), Version 3.0, (Productivity Products International: December 1984).
C. Voir D. Kalyan, "Modular Programming in C: An
Approach and Example" (ou "Programmation Modulaire en
C: Une Approche et un Exemple), SIGPLAN Notices, Volume 20, N03, Mars 1985, pages 9 à 15. L'approche modulaire est basée sur des variables statiques qui sont placées dans un fichier. Certaines approches exigent un processeur préalable comme objective-C. Voir par exemple S. Hook, Obzective-C Reference Manual, (ou
Manuel de Référence d'Objective-C), Version 3.0, (Productivity Products International: December 1984).
D'autres approches encore tentent de définir un langage entièrement différent comme C++ en implantant une programmation orientée vers l'objet. Voir B.
Stroustrup, The C++ Programming Langage, (ou "Le
Langage de Programmation C++), (Addison-Wesley: 1986).
Langage de Programmation C++), (Addison-Wesley: 1986).
La présente invention implante en C une programmation orientée vers l'objet sans modifier ni étendre celle-ci. L'environnement orienté vers l'objet et pris en charge par la présente invention inclut le
Système Window X( ou littéralement système fenêtre),
Version 11, qui supporte le protocole X11 (voir, R.W.
Système Window X( ou littéralement système fenêtre),
Version 11, qui supporte le protocole X11 (voir, R.W.
Scheifler et J. Gettys, "The X Window System" (ou Le Système Window X), ACM Transactions on Graphies, Volume
r 5, N 2, Avril 1986, pages 79 à 109) et la spécification
OPEN LOOK (ou, littéralement, consultation ouverte).
r 5, N 2, Avril 1986, pages 79 à 109) et la spécification
OPEN LOOK (ou, littéralement, consultation ouverte).
OPEN LOOK fournit une interface graphique de manipulation directe dans le système UNIX. (UNIX est une marque déposée de AT & ). Par exemple, il existe une application appelée "filemanager" (ou gestionnaire de fichier) qui constitue une interface visuelle dans le système de fichiers UNIX en donnant une représentation des fichiers par icones. Il existe différentes représentations par icônes pour des exécutables, des répertoires et des fichiers de données. En utilisant un dispositif d'entrée comme une souris, il est possible de cliqueter ou "cliquer" sur un fichier et interroger ses attributs ou propriétés comme le propriétaire et les droits d'accès. Sous "OPEN LOOK", il est également possible de cliquer deux fois sur une représentation par ic8nes du fichier et de le voir avec une application.Si l'objet est exécutable, le programme correspondant à l'icone est effectué. Voir "OPEN LOOK
Graphical User Interface Functional Specification" (ou
Spécification Fonctionnelle d'Interface Graphique d'Utilisateur OPEN LOOK) (AT & et Sun Microsystems,
Inc.: 1988).
Graphical User Interface Functional Specification" (ou
Spécification Fonctionnelle d'Interface Graphique d'Utilisateur OPEN LOOK) (AT & et Sun Microsystems,
Inc.: 1988).
Le système à fenêtre Xll définit un protocole réparti à fenêtre grâce auquel communiquent des serveurs à fenêtre et des processus d'application. Une bibliothèque accompagnatrice appelée la bibliothèque X fournit une interface de procédure au protocole. Une application amène une procédure de la bibliothèque X à envoyer, au serveur à fenêtre, des ordres concernant des ordres de gestion de fenêtre et de tracé. Le serveur à fenêtre envoie, à l'application, une notification d'événement en réponse aux actions de l'utilisateur comme le déplacement de la souris ou une frappe sur le clavier et des modifications géométriques sélectionnées. La bibliothèque à fenêtre met en file d'attente les événements et les assemble dans une structure d'enregistrement. Une application interroge périodiquement la bibliothèque X quant à l'événement suivant. Voir J. Gettys, R.Newman, R.W. Scheilfer,
Xlib-C Langage Interface (ou Interface de Langage
Xlib-C), Massachusetts Institute of Technology, 1987.
Xlib-C Langage Interface (ou Interface de Langage
Xlib-C), Massachusetts Institute of Technology, 1987.
Le système à fenêtre X ne définit pas de style particulier d'interface d'utilisateur mais fournit un mécanisme pour prendre en charge de nombreuses interfaces. Bien que des programmeurs puissent utiliser une bibliothèque X pour construire des applications, cette bibliothèque peut être ennuyeuse et difficile à utiliser correctement. Une simple manipulation des conventions de gestionnaire de fenêtre peut exiger des centaines de lignes de codes. La présente invention a pour but d'être utilisée avec un système à fenêtre X et avec la bibliothèque X pour implanter une interface d'utilisateur sur la base de la spécification OPEN
LOOK. La présente invention fournit des procédés pour compartimenter des structures de données et des procédures en divers fichiers En outre, la présente invention décrit des procédés pour définir de nouveaux objets (concrétiser , ou établir, 2 les classes standard à partir d'une partie de la bibliothèque X) pour créer rapidement une interface d'utilisateur en tant que partie de l'application.
LOOK. La présente invention fournit des procédés pour compartimenter des structures de données et des procédures en divers fichiers En outre, la présente invention décrit des procédés pour définir de nouveaux objets (concrétiser , ou établir, 2 les classes standard à partir d'une partie de la bibliothèque X) pour créer rapidement une interface d'utilisateur en tant que partie de l'application.
L'art le plus proche connu du demandeur est Xt
Intrinsics Toolkit de Digital Electronic Corporation.
Intrinsics Toolkit de Digital Electronic Corporation.
Voir J. McCormack, P. Asente, "An Overview of the X
Toolkit" (ou Vue Générale du Jeu d'Outil X),
Proceedings of the ACM SIGGRAPH Symposium on User
Interface Software, Octobre 1988, pages 46 à 55, et J.
Toolkit" (ou Vue Générale du Jeu d'Outil X),
Proceedings of the ACM SIGGRAPH Symposium on User
Interface Software, Octobre 1988, pages 46 à 55, et J.
McCormark et P. Asente, "Using the X Toolkit, or How to
Write a Widget" (ou Utilisation d'un Jeu d'Outil X ou
Comment Ecrire un Objet Elémentaire-ou"Widget"),
Proceedings of the Summer, 1988, USENIX Conference, pages 1 à 13. La présente invention diffère du Xt
Intrinsics sur les points suivants:
(1) la présente invention possède une interface uniforme pour tous les objets, ce qui n'est pas le cas de Xt Intrinsics,
(2) la présente invention comporte des pilotes d'événement enchainés, ce qui n'est pas le cas de Xt
Intrinsics, et
(3) la présente invention définit ses objets comme comprenant des attributs alors que Xt Intrinsics définit ses "widgets", comme ayant des ressources.Bien que les attributs et les ressources exercent des fonctions similaires, c'est-à-dire se référer à des éléments de données à l'intérieur d'un objet ou "gadget", les attributs ne se réfèrent pas nécessairement à des éléments de données à l'intérieur de l'objet. Des attributs d'un objet, selon la présente invention, pourraient être un appel de fonction, par exemple, alors qu'une ressource est par définition quelque chose qui est à l'intérieur du widget, et
(4) la présente invention permet au programmeurs de modifier la relation parent-enfant, ce qui n'est pas le cas de Xt Intrinsics.
Write a Widget" (ou Utilisation d'un Jeu d'Outil X ou
Comment Ecrire un Objet Elémentaire-ou"Widget"),
Proceedings of the Summer, 1988, USENIX Conference, pages 1 à 13. La présente invention diffère du Xt
Intrinsics sur les points suivants:
(1) la présente invention possède une interface uniforme pour tous les objets, ce qui n'est pas le cas de Xt Intrinsics,
(2) la présente invention comporte des pilotes d'événement enchainés, ce qui n'est pas le cas de Xt
Intrinsics, et
(3) la présente invention définit ses objets comme comprenant des attributs alors que Xt Intrinsics définit ses "widgets", comme ayant des ressources.Bien que les attributs et les ressources exercent des fonctions similaires, c'est-à-dire se référer à des éléments de données à l'intérieur d'un objet ou "gadget", les attributs ne se réfèrent pas nécessairement à des éléments de données à l'intérieur de l'objet. Des attributs d'un objet, selon la présente invention, pourraient être un appel de fonction, par exemple, alors qu'une ressource est par définition quelque chose qui est à l'intérieur du widget, et
(4) la présente invention permet au programmeurs de modifier la relation parent-enfant, ce qui n'est pas le cas de Xt Intrinsics.
C'est donc un but de la présente invention que de minimiser l'effort nécessaire pour écrire une application X en utilisant une interface uniforme d'utilisateur.
C'est un autre but de la présente invention que de réaliser une interface uniforme pour écrire une application X sans modifier ni étendre le langage C.
C'est encore un autre but de la présente invention que d'encourager une personnalisation de l'application X par abstraction de données.
C'est encore un autre but de la présente invention que de permettre à des utilisateurs de réutiliser des codes par héritage.
Pour atteindre ces buts, l'invention fournit un procédé destiné à implanter, sans modifier le language dans lequel la bibliothèque à fenêtre est écrite, une programmation orientée vers l'objet dans un système à base de fenêtre, comprenant au moins un processus d'application communiquant avec au moins un processus serveur par l'intermédiaire d'au moins un réseau d'ordinateur selon un protocole à fenêtre, ledit processus d'application étant pourvu d'une bibliothèque à fenêtre pour envoyer des demandes et des ordres audit serveur, ladite bibliothèque à fenêtre comprenant des pilotes d'événement pour déclencher lesdites commandes et lesdits ordres, ledit serveur renvoyant au moins à ladite bibliothèque à fenêtre au moins un pilote d'événement par demande, ladite bibliothèque à fenêtre comprenant un dispositif de notification pour répartir ledit pilote d'événement audit processus d'application, ladite bibliothèque à fenêtre comprenant en outre plusieurs classes standard à partir desquelles de nouveaux objets peuvent être créés, caractérisé en ce que ledit procédé comprend les étapes consistant à:
enchainer lesdits pilots d'événements pour compartimenter chaque demande dans plusieurs fichiers, ladite pluralité de fichiers comprenant au moins un début de fichier public, au moins un début de fichier privé, et au moins un fichier d'implantation;
relier ledit processus d'application à ladite bibliothèque à fenêtre à l'aide de cinq procédures publiques d'appel, lesdites procédures publiques d'appel invoquant plusieurs fonctions privées incorporées dans ladite file d'implantation; et
créer de nouveaux processus d'application en définissant de nouveaux objets, chacun desdits nouveaux objets comportant au moins une desdites procédures publiques d'appel, chacun desdits nouveaux objets se référant auxdites cinq procédures publiques d'appel.
enchainer lesdits pilots d'événements pour compartimenter chaque demande dans plusieurs fichiers, ladite pluralité de fichiers comprenant au moins un début de fichier public, au moins un début de fichier privé, et au moins un fichier d'implantation;
relier ledit processus d'application à ladite bibliothèque à fenêtre à l'aide de cinq procédures publiques d'appel, lesdites procédures publiques d'appel invoquant plusieurs fonctions privées incorporées dans ladite file d'implantation; et
créer de nouveaux processus d'application en définissant de nouveaux objets, chacun desdits nouveaux objets comportant au moins une desdites procédures publiques d'appel, chacun desdits nouveaux objets se référant auxdites cinq procédures publiques d'appel.
Selon des modalités avantageuses, ledit protocole de fenêtre peut être le protocole de fenêtre X, ladite bibliothèque à fenêtre peut être la bibliothèque X, ledit language peut être C.
De façon avantageuse, lesdites procédures publiques d'appel comprennent l'étape consistant à créer ledit nouvel objet à partir de ladite classe standard, ladite étape spécifiant un parent, une classe, et des paires de valeurs d'attributs, ladite étape ajoutant ledit pilote d'événement audit nouvel objet.
De préférence, ladite procédure publique d'appel comprend aussi l'étape consistant à accorder ledit nouvel objet avec un objet existant, lesdites étapes spécifiant un parent, une classe, et des paires de valeurs d'attributs, ladite étape ajoutant un pilote d'événement audit nouvel objet, ladite étape revenant vers ladite étape définie à la revendication 5 si ledit nouvel objet ne s'accorde pas audit objet existant.
Ladite procédure publique d'appel peut encore comprendre l'étape consistant à interroger les attributs dudit objet existant, ladite étape spécifiant un objet et une paire de valeurs d'attributs.
Ladite procédure publique d'appel peut comprendre en outre l'étape consistant à changer les attributs dudit objet existant, ladite étape spécifiant un objet et des paires de valeurs d'attributs.
Ladite procédure publique d'appel peut encore comprendre l'étape consistant à détruire ledit objet, ladite étape spécifiant un objet.
De préférence, ledit début de fichier public comprend des traitements opaques, lesdits traitements opaques se référant seulement aux définitions exigées par ledit processus d'application.
Ledit début de fichier privé comprend, de façon avantageuse, la définition complète utilisée de façon interne par ledit objet.
On va maintenant expliquer la présente invention à l'aide de modes de réalisation préférés représentés dans les dessins.
La FIGURE 1 représente l'architecture d'un système à fenêtre à base de serveur implantant la présente invention.
La FIGURE 2 est un schéma fonctionnel d'un dispositif de notification de fenêtre notant des événements provenant de multiples serveurs à fenêtre et de multiples applications en tant que partie du processus serveur-client dans un système à fenêtre à base de serveur.
La FIGURE 3 est la structure (hiérarchie des classes) d'un objet utilisé pour mettre en oeuvre l'héritage selon la présente invention.
La FIGURE 4 est un exemple de l'utilisation de la structure en arbre des objets selon la présente invention afin d'implanter une réutilisation de code.
La FIGURE 5 est un exemple d'utilisation d'un fichier privé et d'un fichier public pour implanter des abstractions de données selon la présente invention.
La FIGURE 6 est une déclaration uniforme de classe incorporant les cinq procédés publics spécifiques de la présente invention pour parvenir à une interface uniforme d'utilisateur.
La FIGURE 7 représente le code d'accès à la fonctionnalité de l'application à travers l'approche par traitement opaque selon la présente invention.
La FIGURE 8 est une implantation de la présente invention destinée à afficher une fenêtre à un utilisateur final.
Dans les descriptions détaillées qui suivent, on commencera par préciser la notation et la nomenclature selon l'invention. Les descriptions détaillées cidessous sont largement présentées en termes d'algorithmes et de représentations symboliques d'opérations sur des bits de données à l'intérieur d'une mémoire d'ordinateur. Ces descriptions et représentations par algorithmes sont le moyen utilisé par l'homme de l'art de traitement de données pour transmettre le plus efficacement possible la substance de son travail à d'autres hommes de l'art.
Un algorithme est conçu, ici et de façon générale, pour être une séquence, cohérente avec ellemême, d'étapes menant à un résultat souhaité. Ces étapes sont celles qui exigent des manipulations physiques de quantités physiques. Habituellement, mais non nécessairement, ces quantités prennent la forme de signaux électriques ou magnétiques susceptibles d'être mémorisés, transférés, combinés, comparés, et manipulés de tout autre manière. Il se révèle parfois commode, en particulier pour des raisons d'usage commun, de se référer à ces signaux comme bits, valeurs, éléments, objets, symboles, caractères, termes, nombres ou similaires. Il faut cependant garder à l'esprit le fait que tous ces termes et des termes semblables doivent être associés aux quantités physiques appropriées et sont simplement des intitulés commodes appliqués à ces quantités.
En outre, les manipulations effectuées sont souvent désignées en termes comme additionner ou comparer, qui sont associés de façon classique avec des opérations mentales effectuées par un opérateur humain.
Aucune telle capacité d'un opérateur humain n'est nécessaire, ni désirable dans la plupart des cas, dans aucune des opérations décrites ici qui font partie de la présente invention; les opérations sont des opérations de machines. Des machines utiles pour effectuer les opérations de la présente invention comprennent des ordinateurs numériques polyvalents ou d'autres dispositifs similaires. Dans tous les cas, il faut garder à l'esprit la distinction entre le procédé de fonctionnement de mise en oeuvre d'un ordinateur et le procédé de calcul lui-même. La présente invention concerne des étapes de procédé de mise en oeuvre d'un ordinateur pour traiter des signaux physiques électriques ou autres (par exemple mécaniques, chimiques) pour engendrer d'autres signaux physiques souhaités.
La présente invention concerne aussi un appareil de mise en oeuvre de ces opérations. Cet appareil peut, de façon spécifique, être construit pour le but souhaité ou il peut comprendre un ordinateur polyvalent, sélectivement activé ou nouvellement configuré par un programme d'ordinateur mémorisé dans l'ordinateur. Les algorithmes présentés ici ne sont pas, de façon inhérente, liés à un ordinateur particulier ou un autre appareil. En particulier, diverses machines polyvalentes pourraient être utilisées avec des programmes écrits conformément aux enseignements contenus ici, ou il peut se révéler plus commode de construire un appareil plus spécialisé pour effectuer les étapes souhaitées de procédé. La structure nécessaire pour une variété de ces machines ressortira de la description qui suit.
On décrira d'abord la configuration générale du système à l'aide de la Figure 1 qui représente un système typique à base de fenêtre à utiliser avec la présente invention. Il y est représenté un réseau d'ordinateur 10 comprenant 4 composants princlpaux.
Le premier de ceux-ci est constitué par les dispositifs d'entrée/sortie 12, 14 et 16 qui sont utilisés pour communiquer une information sous une forme structurée appropriée vers les autres éléments du réseau 10 d'ordinateur ou à partir de ceux-ci.
Le deuxième composant -- un serveur 18 comprenant un serveur à fenêtre 20 et une bibliothèque de dispositif 22 -- est également représenté en tant qu'élément du réseau 10 d'ordinateur. Le serveur 18 se trouve typiquement dans la plupart des ordinateurs polyvalents et dans presque tous les ordinateurs spécialisés. Des exemples particuliers de serveurs aptes à jouer le rôle de serveur 18 comprennent des machines fabriquées par Sun Microsystems, Inc.,
Mountain View, Californie. D'autres ordinateurs possédant des capacités similaires peuvent, évidemment, être adaptés d'une façon très directe pour effectuer les fonctions décrites ci-dessous. Il faut comprendre, cependant, qu'un seul serveur est représenté dans le réseau d'ordinateur 10. Dans la plupart des réseaux d'ordinateur, de multiples serveurs peuvent être couplés au réseau pour commander d'autres ordinateurs.
Mountain View, Californie. D'autres ordinateurs possédant des capacités similaires peuvent, évidemment, être adaptés d'une façon très directe pour effectuer les fonctions décrites ci-dessous. Il faut comprendre, cependant, qu'un seul serveur est représenté dans le réseau d'ordinateur 10. Dans la plupart des réseaux d'ordinateur, de multiples serveurs peuvent être couplés au réseau pour commander d'autres ordinateurs.
A la Figure 1 est également représenté le troisième composant du réseau 10 d'ordinateur, constitué par une liaison 24. Des exemples de liaisons typiques sont des cables, des lignes concédées, des connexions à fibres optiques, et autres.
Le quatrième composant du réseau d'ordinateur est une Interface de Programme d'Application (ou API) 26.
L'API 26 comprend en outre une bibliothèque à fenêtre 28, un jeu d'outils de fenêtre 30, et une application 32. La bibliothèque à fenêtre 28 procure une Interface de procédure au protocole de serveur de client du réseau d'ordinateur 10. L'application 32 appelle des procédures à l'intérieur de la bibliothèque à fenêtre 28 pour envoyer des ordres de gestion de fenêtre et de tracé au serveur 18. Un exemple d'une bibliothèque à fenêtre qui implante le système à fenêtre X11 est la bibliothèque X. Voir J. Gettys, R. Newman et R.W.
Scheifler, "X lib-C Language Interface" (ou "Interface de Langage X lib-C), Massachusetts Institute of
Technology, 1987. La présente invention comprend le jeu d'outils de fenêtre 30. Le jeu d'outils de fenêtre 30 est basé sur un jeu de directives qui permet de programmer d'une manière orientée vers l'objet. Le jeu d'outils de fenêtre 30 comprend des composants appelés objets. Un objet est un composant d'interface d'utilisateur implanté en utilisant des appels de procédure vers le jeu d'outils de fenêtre 30 et la bibliothèque à fenêtre 28. L'application 32 utilise le jeu d'outils de fenêtre 30 pour lier les objets entre eux en une interface d'utilisateur et pour relier cette interface d'utilisateur à des fonctions implantées par l'application. Selon la présente invention, le programmeur d'application spécifie des objets (comme des fenêtres, des menus, des barres de défilement, etc.) à créer en utilisant une liste de valeurs d'attributs de longueur variable. Voir "Varargs (3)",
SunOS Reference Manual, (ou Manuel de référence SunOS) (Sun Microsystems, Inc.: Révision A, 9 Mai 1988), (Part NO: 800 - 1751 - 10). La liste des valeurs d'attributs garantit que le comportement habituel de chaque objet est déjà prédéfini et donc que seules les écarts vis-àvis du comportement par défaut doivent être spécifiées.
Technology, 1987. La présente invention comprend le jeu d'outils de fenêtre 30. Le jeu d'outils de fenêtre 30 est basé sur un jeu de directives qui permet de programmer d'une manière orientée vers l'objet. Le jeu d'outils de fenêtre 30 comprend des composants appelés objets. Un objet est un composant d'interface d'utilisateur implanté en utilisant des appels de procédure vers le jeu d'outils de fenêtre 30 et la bibliothèque à fenêtre 28. L'application 32 utilise le jeu d'outils de fenêtre 30 pour lier les objets entre eux en une interface d'utilisateur et pour relier cette interface d'utilisateur à des fonctions implantées par l'application. Selon la présente invention, le programmeur d'application spécifie des objets (comme des fenêtres, des menus, des barres de défilement, etc.) à créer en utilisant une liste de valeurs d'attributs de longueur variable. Voir "Varargs (3)",
SunOS Reference Manual, (ou Manuel de référence SunOS) (Sun Microsystems, Inc.: Révision A, 9 Mai 1988), (Part NO: 800 - 1751 - 10). La liste des valeurs d'attributs garantit que le comportement habituel de chaque objet est déjà prédéfini et donc que seules les écarts vis-àvis du comportement par défaut doivent être spécifiées.
L'utilisation de composants d'interface d'utilisation assemblés au préalable, selon la présente invention, élimine ainsi le code d'immatriculation.
T e programmeur d'application définit ensuite des procédures de rappel que le jeu d'outil de fenêtre appelle pour notIfier l'appllcation d'événements ou d'actions d'utilisateur. Finalement, le code spécifique à l'application est enregistré ou connecté et permet au jeu d'outils de fenêtre de gérer l'application.
On va maintenant décrire le processus conforme à l'invention. La présente invention concerne un jeu d'outils d'interface d'utilisateur basé sur X11 qui est orienté vers l'objet, commandé par les événements, et qui implante l'Interface Graphique d'Utilisateur OPEN
LOOK. Voir "OPEN LOOK Graphical User Interface
Functlonal Specifications" (ou "Spécification
Fonctionnelle de l'interface Graphique d'Utilisateur
OPEN LOOK) (AT & , Sun MIcrosystems, Inc., 1988). La présente invention permet à des programmeurs d'application d'utiliser des objets afin de créer rapidement l'interface d'utilisation en tant qu'élément de l'application.
LOOK. Voir "OPEN LOOK Graphical User Interface
Functlonal Specifications" (ou "Spécification
Fonctionnelle de l'interface Graphique d'Utilisateur
OPEN LOOK) (AT & , Sun MIcrosystems, Inc., 1988). La présente invention permet à des programmeurs d'application d'utiliser des objets afin de créer rapidement l'interface d'utilisation en tant qu'élément de l'application.
La présente invention est un jeu d'outils commandé par événements. Dans le contexte d'un système à fenêtre réparti, les applications envoient des demandes au serveur et reçoivent des événements en provenance du serveur. La présente invention traite des événements de système à partir de l'extérieur du protocole application/serveur. Ceci est accompli en utilisant des pilotes spéciaux procédure de rappelévénement. A la Figure 1, la bibliothèque à fenêtre 28 fournit une interface de procédure au protocole.
L'application 32 appelle des pilotes d'événement dans le jeu d'outils de fenêtre 30 pour envoyer des ordres de gestion de fenêtre et de tracé au serveur 18. Le serveur 18 envoie une notification d'événement à l'application, en réponse aux actions de l'utilisateur (par exemple déplacer la souris 14 ou actionner le clavier 12).
la 1# FIgure 2, les pilotes d'événement concernant des objets sont enregistrés, à l'InitialIsation1 à l'aIde d'un dispositif central de notification 34. Voir
S. Evans, "The Notifier" (ou le Dispositif de Notification), Proceedinqs of Summer USENIX Conference, 1986. Lorsque des événements proviennent de serveurs de fenêtre 20 à 20' par l'intermédiaire de la liaison de réseau 24, les pilotes appropriés d'événements sont invoqués. Les pilotes d'événements affectent l'état des objets. On peut modifier l'état des objets en utilisant cinq procédés publics qui sont décrits de façon détaillé ci-dessous. Les pilotes d'événement sont traités sur une base cas par cas.Certaines classes comportent un pilote d'événement par défaut qui est installé à l'initialisation. De façon plus significative, les pilotes d'événement de la présente invention sont enchaînés. En revanche, les pilotes d'événement de procédés de l'art antérieur ne sont pas enchaînés. Des pilotes d'événement enchaînés prennent en charge les principes de la programmation orientée vers l'objet; ceci permet également à des classes de compartimenter le traitement d'événements reçus depuis le serveur 18.
S. Evans, "The Notifier" (ou le Dispositif de Notification), Proceedinqs of Summer USENIX Conference, 1986. Lorsque des événements proviennent de serveurs de fenêtre 20 à 20' par l'intermédiaire de la liaison de réseau 24, les pilotes appropriés d'événements sont invoqués. Les pilotes d'événements affectent l'état des objets. On peut modifier l'état des objets en utilisant cinq procédés publics qui sont décrits de façon détaillé ci-dessous. Les pilotes d'événement sont traités sur une base cas par cas.Certaines classes comportent un pilote d'événement par défaut qui est installé à l'initialisation. De façon plus significative, les pilotes d'événement de la présente invention sont enchaînés. En revanche, les pilotes d'événement de procédés de l'art antérieur ne sont pas enchaînés. Des pilotes d'événement enchaînés prennent en charge les principes de la programmation orientée vers l'objet; ceci permet également à des classes de compartimenter le traitement d'événements reçus depuis le serveur 18.
En se référant à nouveau à la Figure 2, le dispositif de notification 34 traduit ensuite l'événement en une étape 36 et détermine l'objet auquel l'événement sera réparti à l'étape 38 et, finalement, appelle les procédures appropriées de rappel aux étapes 40 à 40'. Un enchaînement des pilotes d'événements permet aussi aux objets d'enregistrer des rappels avec le dispositif de notification 34 pour une entrée sur des descripteurs de fichiers 35, des pseudo TTY et pour des signaux UNIX 37.
La présente invention implante aussi L'INTERFACE
GRAPHIQUE D'UTILISATEUR OPEN LOOK qui est une spécification fonctionnelle qui fournit un aspect et une impression standard concernant des applications.
GRAPHIQUE D'UTILISATEUR OPEN LOOK qui est une spécification fonctionnelle qui fournit un aspect et une impression standard concernant des applications.
Cette spécification décrit un large jeu d'images standard qui définissent les curseurs, menus, icônes, et déclarations de fenêtre.
La présente invention est un système orienté vers l'objet avec un sous-classement statique. Elle est orientée vers l'objet en ce qu'un programmeur d'application peut utiliser des unités modulaires ou des objets comme une fenêtre, un texte, des panneaux, des icônes etc. pour construire une application. Tous les objets de la présente invention partagent un jeu commun de fonctions mais retiennent, pour la liste d'attributs, la possibilité d'arguments de longueur variable.
La Figure 3 est une structure en arbre (hiérarchie des classes) des objets utilisés pour implanter l'héritage dans la présente invention. D'un point de vue d'un système orienté vers l'objet, il existe deux structures en arbre intéressantes dans un système à fenêtre. Le premier est la hiérarchie des types d'objets. L'arbre statique est une liste de tous les types d'objets qui peuvent être créés par le programmeur d'application en utilisant le jeu d'outils de fenêtre. Chaque type d'objet est connu comme une classe. Cette arbre statique représente la manière dont les diverses classes partagent des données et des fonctions. La seconde hiérarchie est l'arbre d'établissement. L'arbre d'établissement est créé quand des classes sont établies et reliées. L'arbre d'établissement est ce que l'utilisateur du système à fenêtre voit en fait sur l'écran.L'arbre d'établissement est une structure dynamique et est manipulé par l'utilisateur de l'objet. Une application consiste typiquement en un arbre d'établissement dont la racine est la fenêtre principale d'application.
Cette fenêtre, elle-même, est un essai de fenêtre de racine ou d'arrière plan.
En se référant à nouveau à la Figure 3, 11 y est représenté un arbre d'établissement d'un objet générique et les relations entre les classes. Par exemple1 12 panneau (ou Panel) 44 est une sous-classe de Canvas (ou canevas), qui est une sous-classe particulière de Window (ou fenêtre) qui, elle-même, est une sous-classe particulière de Generic Object (ou objet générique). Les classes représentées à la Figure 3 sont en outre subdivisées en classes composites et primitives. Des classes telles que Frame (ou Cadre) 41,
Menu 42, le Panel (ou Panneau) 44 et Terme (ou Terme) 52 sont des classes composites1 alors que toutes les autres classes sont primitives. Un exemple d'une classe composite peut être soit une feuille soit un noeud interne dans un arbre d'établissement.Comme un noeud interne, un établissement composite peut comporter plusieurs cas enfants. Des établissements composites sont responsables de la gestion de géométrie de leurs enfants et, dans certains cas, tous les tracés vers les enfants sont attachés aux limites du parent. Les établissements de bouton de menu d'une classe primitive sont des cas d'une classe composite.
Menu 42, le Panel (ou Panneau) 44 et Terme (ou Terme) 52 sont des classes composites1 alors que toutes les autres classes sont primitives. Un exemple d'une classe composite peut être soit une feuille soit un noeud interne dans un arbre d'établissement.Comme un noeud interne, un établissement composite peut comporter plusieurs cas enfants. Des établissements composites sont responsables de la gestion de géométrie de leurs enfants et, dans certains cas, tous les tracés vers les enfants sont attachés aux limites du parent. Les établissements de bouton de menu d'une classe primitive sont des cas d'une classe composite.
On va maintenant décrire l'abstraction de données selon la présente invention.
La présente invention implante un modèle statique de sous-classement. A l'instant de la compilation, la hiérarchie de classe et les compositions de la classe sont définies et ne peuvent pas être changées pendant toute la durée de l'opération. Ceci signifie qu'il n'est pas possible de créer de nouvelles classes ni d'ajouter de nouvelles propriétés à une classe en cours d'opération. Chaque fois qu'un objet est établi à partir d'une classe, l'appelant obtient un traitement opaque vers l'objet établi. Le traitement opaque est un traitement sur une structure d'obJet. mais l'utilIsateur du traitement ne connaît pas la définition des données qu'il représente. Ainsi donc, l'utilisateur de l'objet ne peut pas accéder aux données internes de l'objet.L'objet possède certains attributs qui définissent le comportement qu'il présentera aux utilisateurs de l'objet La présente invention ne fournit que 5 procédés publics d'accès aux attributs des objets: des objets sont créés en utilisant une fonction "create" (ou "créer") (xv~create) ; des objets sont situés et partagés en utilisant une fonction "find" (ou "trouver") (xv~find); si aucun objet commun n'est situé, (xv~find) revient à (xv~create). Les attributs d'un objet peuvent être interrogés en utilisant (xv~get), alors qu'ils peuvent être modifiés en utilisant (xv~set) . Lorsque l'objet n'est plus nécessaire, il est détruit en utilisant (xv~destroy) .Lorsqu'un programmeur d'application crtee un objet, il peut interroger l'objet pour déterminer l'état de ses attributs ou il peut modifier l'état d'un objet an définissant, ou changeant, les valeurs des attributs. Les utilisateurs de l'objet ne savent pas comment l'objet implante ou affecte le changement demandé. Les types exposés des attributs n'ont rien à voir avec les implantations réelles de ceux-ci. Ainsi, la présente invention cache aux utilisateurs finals les détails des manipulations et implantations des objets, en parvenant ainsi à une abstraction de données.
L'abstraction de données est renforcée en exposant, aux utilisateurs de l'objet, un début de fichier public.
Selon la présente invention, l'abstraction de données est implantée en maintenant à la fois une définition privée, complète, de chaque objet, et une définition publique, incomplète, comme représenté à la
Figure 5. Deux débuts de fichiers y sont représentés pour l'exemple Window. Le début de fichier privé de la fenêtre1 WindowPrivate.h1 contient la définition réelle utilise de façon interne par l'objet. Le début de fichier publIc, WindowPublic.h, ne contient que les défInitions nécessaires pour les applications qui utilisent l'objet.Dans le début de fichier public sont SitUeS divers traitements opaques -- des fenêtres opaques -- qui indiquent la structure de l'objet pour
Window mais qui n'accèdent pas à la définition réelle des données qu'elles représentent. Il s'ensuit que l'abstraction de données est atteinte parce que l'implantation d'un objet à partir de l'application qui utilise l'objet a été cachée a l'utilisateur de l'objet.
Figure 5. Deux débuts de fichiers y sont représentés pour l'exemple Window. Le début de fichier privé de la fenêtre1 WindowPrivate.h1 contient la définition réelle utilise de façon interne par l'objet. Le début de fichier publIc, WindowPublic.h, ne contient que les défInitions nécessaires pour les applications qui utilisent l'objet.Dans le début de fichier public sont SitUeS divers traitements opaques -- des fenêtres opaques -- qui indiquent la structure de l'objet pour
Window mais qui n'accèdent pas à la définition réelle des données qu'elles représentent. Il s'ensuit que l'abstraction de données est atteinte parce que l'implantation d'un objet à partir de l'application qui utilise l'objet a été cachée a l'utilisateur de l'objet.
On va maintenant décrire une définition d'une nouvelle classe. La définition d'une nouvelle classe exige au moins deux débuts de fichier.h et deux fichiers.c. Par exemple, pour créer une classe appelée
Window il faut un fichier WindowClass.c, Window.c,
WindowPrivate.h et WindowPublic.h. Le fichier
WindowClass.c contient les déclarations de classe représentées à la Figure 6. Les déclarations de classe représentées à la Figure 6 sont partagées par tous les cas de classe Window et tous les cas d'une sous-classe quelconque de Window.
Window il faut un fichier WindowClass.c, Window.c,
WindowPrivate.h et WindowPublic.h. Le fichier
WindowClass.c contient les déclarations de classe représentées à la Figure 6. Les déclarations de classe représentées à la Figure 6 sont partagées par tous les cas de classe Window et tous les cas d'une sous-classe quelconque de Window.
Les cinq procédés d'interface publics définis précédemment sont les seuls procédés publics d'un objet quelconque. Ces procédés appellent les jeux appropriés de fonctions internes privées dans la structure de classe de chaque classe. Plus d'une fonction interne peut être appelée lorsqu'un procédé public est invoque, puisque les procédés privés sont enchaînés dans une liste avec les fonctions correspondantes de sur-classe et de sous-classe privées. Cet enchaînement est automatique pour toutes les procédures de la définition de classe. Ceci est également désigné comme enchaînement de sur-classe. Il existe deux variantes de l'e-.~haînem2nt de sur-classe: les enchainements de surclasse ascendant et descendant.Dans un enchaînement ascendant de sur-classe, tous les procédés privés d'encha nemênt sont appelés dans un ordre depuis la sous-classe vers la sur-classe, et jusqu'à la classe de base. (Par exemple, à la Figure 3, l'enchaînement ascendant serait, dans l'ordre, panel -- canvas -- open in 'ou ouverture fenêtre) - window - drawable (ou trasable! - generic (ou générique). Dans l'enchaînement descendant de sur-classe, les procédés privés sont appels dans l'ordre depuis la sur-classe vers la sousclasse. (En se référant à nouveau à la Figure 3, l'enchaînement de sur-classe descendant serait, dans 1 'ordre, generic-drawable-window-open win-canvaspanel).
Une classe peut hériter de toutes les fonctions privées de sa sur-classe sans en ajouter aucune ellemême en Insérant un NULL (c'est-à-dire zéro) dans l'emplacement approprlé dans la structure de déclaration de classe. Voir, par exemple, la dernière lige du code des déclarations de classe représenté à la Figure 6. Une classe hérite automatiquement d'une conduite de sa sur-classe en ne traitant pas l'attribut dont la classe souhaite hériter le comportement. De plus, une classe peut prendre priorité sur le comportement d'un attribut en agissant sur lui et ensuite l'annuler de la liste d'attributs avant que sa sur-classe n'examine la liste d'attributs. Parmi les cinq procédés publics d'interface décrits plus haut, (xv~set) et (xv~get) sont en enchaînement descendant.
A la Figure 7 se trouve le fichier d'implantation de création d'un nouvel objet Window, Window.c. Le fichier d'implantation comprend cinq fichiers individuels. Une autre application peut ne pas être introduite sous un fichier unique. Les cinq tables d'implantation des procédé d'Interface sont reliés à des procédés privés comme indIqué ci-dessous.
1. Créer (ou create) en tant qu'objet de la classe type, avec le parent spécifié et avec ses attributs définis pour les valeurs indiques dans la liste de valeurs d'attributs. L'appel du procédé est: Xv~objet=xv~create (parent, classe, paires de valeurs d'attrIbuts)
Le parent est utilisé pour insérer l'objet établi à l'emplacement correct dans l'arbre d'objet. Toutes les procédures d'initialisatIon sont appelées dans l'ordre d'enchaînement descendant de sur-classe et les attributs de temps de création sont détaillés à cet
Instant. Les attributs de l'instant de créatlon sont les attributs qui n'ont de signification qu'à l'instant de création. Puis, tous les programmes définis sont appelés dans l'ordre d'enchaînement ascendant de surclasse pour détailler les attributs restants et, finalement, tous les programmes définis sont appelés avec le seul attribut XV~END~CREATE dans l'ordre descendant de sur-classe pour permettre un traitement après création.
Le parent est utilisé pour insérer l'objet établi à l'emplacement correct dans l'arbre d'objet. Toutes les procédures d'initialisatIon sont appelées dans l'ordre d'enchaînement descendant de sur-classe et les attributs de temps de création sont détaillés à cet
Instant. Les attributs de l'instant de créatlon sont les attributs qui n'ont de signification qu'à l'instant de création. Puis, tous les programmes définis sont appelés dans l'ordre d'enchaînement ascendant de surclasse pour détailler les attributs restants et, finalement, tous les programmes définis sont appelés avec le seul attribut XV~END~CREATE dans l'ordre descendant de sur-classe pour permettre un traitement après création.
2. Trouver ( ou find) un objet du type classe, avec parent "parent" et accorder la liste spécifiée de valeurs d'attributs. L'appel de procédé est:
Xv~object xv-find (parent, classe, paires valeurs d'attributs)
Les procédures find des objets sont appelées dans l'ordre d'enchaînement ascendant de sur-classe. Si l'appel trouver ne fonctionne pas, celui-ci revient à un appel créer.
Xv~object xv-find (parent, classe, paires valeurs d'attributs)
Les procédures find des objets sont appelées dans l'ordre d'enchaînement ascendant de sur-classe. Si l'appel trouver ne fonctionne pas, celui-ci revient à un appel créer.
3. Obtenir, ou comme précisé plus haut, interroger ( ou get) les valeurs des attributs et introduire les données dans les structures fournies ou renvoyer un indicateur de la structure. La présente invention prend en charge actuellement les deux modèles. L'appel de procédé est:
Xopaque xv~get (objet, paires valeurs d'attributs).
Xopaque xv~get (objet, paires valeurs d'attributs).
Les procédures de définition des objets sont appels dans l'ordre d'enchainement ascendant de surclasse.
4. Définir - ou changer comme précisé plus haut (ou set) les valeurs des attributs de l'objet aux valeurs spécifiées dans la liste d'attributs de valeurs. L'appel de procédé est:
Xvopaque xv~set (objet, paires valeurs d'attributs).
Xvopaque xv~set (objet, paires valeurs d'attributs).
Les valeurs définies des objets sont appelées dans l'ordre d'enchaînement ascendant de sur-classe
5. Détruire (ou destroy) l'objet. L'appel de procédé pour détruire un objet est: int xv~destroy (objet).
5. Détruire (ou destroy) l'objet. L'appel de procédé pour détruire un objet est: int xv~destroy (objet).
La valeur de retour indique si l'objet est effectivement détruit. Les procédures de destruction des classes sont appelées dans un ordre d'enchaînement ascendant de sur-classe.
Le fichier WindowPublic.h à la Figure 5 est le seul fichier qu'un utilisateur ou créateur d'une sousclasse de l'objet a effectivement besoin d'utiliser.
Cette approche expose le même fichier à la fois à de nouveaux programmeurs d'objet et à des utilisateurs d'objet. Ceci a pour résultat une interface uniforme d'utilisateur pour le système à base de fenêtre.
On va maintenant décrire l'application, dans la présente invention, du principe d'héritage.
Selon le principe d'héritage, lors de la programmation orientée vers l'objet, il est possible de définir une nouvelle classe en tant que variante d'une classe existante. La nouvelle classe peut être une spécialisation de la précédente ou étendre les caracterlstiques de la précédente. Le nouvel objet est appelé la sous-classe de l'ancienne, et l'ancien objet ast appelé la sur-classe de la nouvelle classe. Chaque classe ajoute des particularités en créant de nouveaux attributs ou, put prendre priorité sur des attributs de la sur-classe, en modifiant la liste de valeurs d'attributs avant qu'elle ne soit traitée par la surclasse.
Dans le mode de réalisation préféré de la présente invention, un héritage à classe unique a été mis en oeuvre. Dans le cas d'un héritage à classe unique, une classe unique ne possède qu'une sur-classe.
Ceci diffère du cas des héritages multiples de classes où une classe peut avoir plus d'une sur-classe. La structure de la hiérarchie à classe unique dans le mode de réalisation préféré de la présente invention est représente à la Figure 3.
L'avantage provenant de la réutilisation de code selon le principe de l'héritage est représenté à la
Figure 8. Celle-ci représente plusIeurs lignes de codes destinées à créer un objet de fenêtre sur un affichage d'une hauteur et d'une largeur de 20 pixels par 20 pixels. L'appel, xv~set () ajoute un pilote d'événement à l'objet Il faut également noter que la fenêtre de racine est le parent. La partie "..." désigne le début de fichier public, WindowPublic.h, comme représenté à la Figure 5. Par définition de la présente invention, le fichier public contient toutes les définitions nécessaires pour créer une application qui utilisera l'objet ainsi que toutes les informations nécessaires à qui souhaite créer une sous-classe.De cette manière, la création d'une nouvelle classe (ici un objet de fenêtre) exige de moins en moins de codes parce que les codes existants (ici le fichier public) sont réutilisés. Par conséquent, en introduisant le cadre des événements de compartimentage dans les divers fizh rs, on peut créer rapidement l'interface d'utIlIsateur en tant que partie d'une application ##elccnque.
Figure 8. Celle-ci représente plusIeurs lignes de codes destinées à créer un objet de fenêtre sur un affichage d'une hauteur et d'une largeur de 20 pixels par 20 pixels. L'appel, xv~set () ajoute un pilote d'événement à l'objet Il faut également noter que la fenêtre de racine est le parent. La partie "..." désigne le début de fichier public, WindowPublic.h, comme représenté à la Figure 5. Par définition de la présente invention, le fichier public contient toutes les définitions nécessaires pour créer une application qui utilisera l'objet ainsi que toutes les informations nécessaires à qui souhaite créer une sous-classe.De cette manière, la création d'une nouvelle classe (ici un objet de fenêtre) exige de moins en moins de codes parce que les codes existants (ici le fichier public) sont réutilisés. Par conséquent, en introduisant le cadre des événements de compartimentage dans les divers fizh rs, on peut créer rapidement l'interface d'utIlIsateur en tant que partie d'une application ##elccnque.
On va maintenant comparer l'invention avec l'art antérIeur le plus proche qui est Xt Instrinsics (Xt) qui est également un jeu d'outils prévu pour Implanter une interface d'utilIsateur en tant que système de fenêtre à base de Xll avec C non modifié. La présente Invention diffère de Xt sous plusieurs aspects significatifs:
(1) Xt ne comprend pas d'interface uniforme pour tous les objets, alors que la présente invention en dispose.Des programmeurs d'application sous Xt utilisent un jeu de débuts de fichiers différent de celui de l'utilisateur d'objet alors que, selon l'lnvention, le même jeu de fichier est utilisé, que l'utilisateur soit un programmeur d'application ou un utilisateur d'objet;
(2) Des utilisateurs d'objet sous Xt peuvent accéder à toute fonction que le concepteur d'objet rend publique, tandis que des utilisateurs d'objet selon la présente invention sont limités aux cinq procédés publics décrits ci-dessus;
(3) Xt ne dispose pas de pilotes d'événement enchaînés, alors que la présente invention en dispose;
(4) l'association d'objets sous Xt est prédéterminée et ne peut être modifiée En d'autres termes, une fois qu'une personne spécifie un parent, il ne peut être changé ultérieurement.En revanche, la présente invention permet à ses attributs de changer l'association parmi les objets parce que les attributs ne sont pas limités à des éléments à l'intérieur d'un objet. Par exemple, les attributs d'un objet dans le mode de réalisation préféré de la présente invention peuvent se référer à un appel de fonction.
(1) Xt ne comprend pas d'interface uniforme pour tous les objets, alors que la présente invention en dispose.Des programmeurs d'application sous Xt utilisent un jeu de débuts de fichiers différent de celui de l'utilisateur d'objet alors que, selon l'lnvention, le même jeu de fichier est utilisé, que l'utilisateur soit un programmeur d'application ou un utilisateur d'objet;
(2) Des utilisateurs d'objet sous Xt peuvent accéder à toute fonction que le concepteur d'objet rend publique, tandis que des utilisateurs d'objet selon la présente invention sont limités aux cinq procédés publics décrits ci-dessus;
(3) Xt ne dispose pas de pilotes d'événement enchaînés, alors que la présente invention en dispose;
(4) l'association d'objets sous Xt est prédéterminée et ne peut être modifiée En d'autres termes, une fois qu'une personne spécifie un parent, il ne peut être changé ultérieurement.En revanche, la présente invention permet à ses attributs de changer l'association parmi les objets parce que les attributs ne sont pas limités à des éléments à l'intérieur d'un objet. Par exemple, les attributs d'un objet dans le mode de réalisation préféré de la présente invention peuvent se référer à un appel de fonction.
On trouvera ci-dessous des fragments de code représentant la différence entre Xt et la présente nvention lorsque l'on souhaite appeler une procédure de modificatIon des dimensions d'un objet de fenêtre:
Xt: objet - > core.resize(); et
Présente invention: xv~set (objet, WIN~RESIZE~PROC,0);
Bien que la présente invention alt été décrite se référant aux exemples particuliers de fenêtre aux
Figures 1 à 8, l'homme de l'art comprendra que la présente invention peut être implantée dans l'un quelconque de nombreux systèmes variés à base de fenêtre. De même, l'objet particulier, la hiérarchie de classe ou le format des fichiers représentés dans les figures ne sont que représentatifs de l'une des nombreuses possibilités de configurations orientées vers l'objet qui peuvent utiliser la présente
Invention. En outre, on comprendra que les figures sont simplement données à titre d'illustration et ne doivent pas être prises comme limitations de l'invention. On peut envisager que de nombreuses variantes et modifications peuvent être apportées par l'homme de l'art aux matières et agencements des éléments de l'invention sans s'écarter de l'esprit et du cadre de l'invention tels que décrits ci-dessus.
Xt: objet - > core.resize(); et
Présente invention: xv~set (objet, WIN~RESIZE~PROC,0);
Bien que la présente invention alt été décrite se référant aux exemples particuliers de fenêtre aux
Figures 1 à 8, l'homme de l'art comprendra que la présente invention peut être implantée dans l'un quelconque de nombreux systèmes variés à base de fenêtre. De même, l'objet particulier, la hiérarchie de classe ou le format des fichiers représentés dans les figures ne sont que représentatifs de l'une des nombreuses possibilités de configurations orientées vers l'objet qui peuvent utiliser la présente
Invention. En outre, on comprendra que les figures sont simplement données à titre d'illustration et ne doivent pas être prises comme limitations de l'invention. On peut envisager que de nombreuses variantes et modifications peuvent être apportées par l'homme de l'art aux matières et agencements des éléments de l'invention sans s'écarter de l'esprit et du cadre de l'invention tels que décrits ci-dessus.
Claims (11)
1. Procédé destiné à Implanter, sans codifier le language dans lequel la bibliothèque à fenêtre est écrite, une programmation orientée vers l'objet dans un système à base de fenêtre, comprenant au moins un processus d'application communiquant avec au moins un processus serveur par l'intermédiaire d'au moins un réseau d'ordinateur selon un protocole à fenêtre, ledit processus d'application étant pourvu d'une bibliotheque à fenêtre pour envoyer des demandes et des ordres audit serveur, ladite bibliothèque à fenêtre comprenant des pilotes d'événement pour déclencher lesdites commandes et lesdits ordres, ledit serveur renvoyant au moins à ladite bibliothèque à fenêtre au moins un pilote d'événement par demande, ladite bibliothèque à fenêtre comprenant un dispositif de notification pour répartir ledit pilote d'événement audit processus d'application, ladite bibliothèque à fenêtre comprenant en outre plusieurs classes standard à partir desquelles de nouveaux objets peuvent être créés, caractérisé en ce que ledit procédé comprend les étapes consistant à:
enchaîner lesdits pilots d'événements pour compartimenter chaque demande dans plusieurs fichiers, ladite pluralité de fichiers comprenant au moins un début de fichier public, au moins un début de fichier privé, et au moins un fichier d'implantation;
relier ledit processus d'application à ladite bibliothèque à fenêtre à l'aide de cinq procédures publiques d'appel, lesdites procédures publiques d'appel invoquant plusieurs fonctions privées incorporées dans ladite file d'implantation; et
créer de nouveaux processus d'application en définissant de nouveaux objets, chacun desdits nouveaux objets comportant au moins une desdites procédures publiques d'appel, chacun desdits nouveaux objets se référant auxdites cinq procédures publiques d'appel.
2. Procédé selon la revendication 1, caractérisé en ce que ledit protocole de fenêtre est le protocole de fenêtre X.
3. Procédé selon la revendication 1, caractérisé en ce que ladite bibliothèque à fenêtre est la bibliothèque 2.
4. Procédé selon la revendication 1, caractérisé en ce que ledit language est C.
5. Procédé selon la revendication 1, caractérisé en ce que lesdites procédures publiques d'appel comprennent l'étape consistant à créer ledit nouvel objet à partir de ladite classe standard, ladite étape spécifiant un parent, une classe, et des paires de valeurs d'attributs, ladite étape ajoutant ledit pilote d'événement audit nouvel objet.
6. Procédé selon la revendication 1, caractérisé en ce que lesdites procédures publiques d'appel comprennent l'étape consistant à accorder ledit nouvel objet avec un objet existant, lesdites étapes spécifiant un parent, une classe, et des paires de valeurs d'attributs, ladite étape ajoutant un pilote d'événement audit nouvel objet, ladite étape revenant vers ladite étape définie à la revendication 5 si ledit nouvel objet ne s'accorde pas audit objet existant.
7. Procédé selon la revendication 1, caractérisé en ce que ladite procédure publique d'appel comprend l'étape consistant à interroger les attributs dudit objet existant, ladite étape spécifiant un objet et une paire de valeurs d'attributs.
8. Procédé selon la revendication 1, caracterisé en ce que ladite procédure publique d'appel comprend l'étape consistant à changer les attributs dudit objet existant, ladite étape spécifiant un objet et des paires de valeurs d'attributs.
9. Procédé selon la revendication 1, caractérisé en ce que ladite procédure publique d'appel comprend l'étape consistant à détruire ledit objet, ladite étape spécifiant un bjt.
10. Procédé selon la revendication 1, caractérisé en ce que ledit début de fichier public comprend des traitements opaques, lesdits traitements opaques se référant seulement aux définitions exigées par ledit processus d'application.
11. Procédé selon la revendication 1, caractérisé en ce que ledit début de fichier privé comprend la définition complète utilisée de façon interne par ledit objet.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US51542790A | 1990-04-27 | 1990-04-27 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2661525A1 true FR2661525A1 (fr) | 1991-10-31 |
Family
ID=24051312
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR9105113A Pending FR2661525A1 (fr) | 1990-04-27 | 1991-04-25 | Procede et appareil destines a implanter une programmation orientee vers l'objet, utilisant c non modifie pour un systeme d'ordinateur a base de fenetre. |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5446902A (fr) |
| JP (1) | JPH0628168A (fr) |
| FR (1) | FR2661525A1 (fr) |
| GB (1) | GB9105278D0 (fr) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0696770A1 (fr) * | 1994-06-15 | 1996-02-14 | AT&T Corp. | Bibliothèque de classe à utiliser pour programmation graphique |
| US5551030A (en) * | 1992-12-08 | 1996-08-27 | International Business Machines Corporation | Method and apparatus for integrating applications in a graphical user interface environment with a rules database |
Families Citing this family (77)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5860010A (en) * | 1992-03-12 | 1999-01-12 | Bull S.A. | Use of language with similar representation for programs and data in distributed data processing |
| US5896532A (en) * | 1992-06-15 | 1999-04-20 | Lucent Technologies Inc. | Objects with run-time classes and methods of making them |
| JPH08505721A (ja) | 1992-12-23 | 1996-06-18 | タリジェント インコーポレイテッド | オブジェクト指向フレームワーク・システム |
| US6259446B1 (en) | 1992-12-23 | 2001-07-10 | Object Technology Licensing Corporation | Menu state system |
| US5835713A (en) * | 1993-03-19 | 1998-11-10 | Ncr Corporation | Remote collaboration system for selectively locking the display at remote computers to prevent annotation of the display by users of the remote computers |
| US5649104A (en) * | 1993-03-19 | 1997-07-15 | Ncr Corporation | System for allowing user of any computer to draw image over that generated by the host computer and replicating the drawn image to other computers |
| US5819283A (en) * | 1993-05-11 | 1998-10-06 | Apple Computer, Inc. | Method and system for the extensibility of objects |
| US6684261B1 (en) * | 1993-07-19 | 2004-01-27 | Object Technology Licensing Corporation | Object-oriented operating system |
| US5379432A (en) * | 1993-07-19 | 1995-01-03 | Taligent, Inc. | Object-oriented interface for a procedural operating system |
| US5689700A (en) * | 1993-12-29 | 1997-11-18 | Microsoft Corporation | Unification of directory service with file system services |
| AU1323395A (en) * | 1993-12-30 | 1995-07-17 | Raymond Obin | Method for compiling a procedural program to an object class definition |
| US5875331A (en) * | 1994-09-30 | 1999-02-23 | International Business Machines Corp. | System and method for generating target language code utilizing an object oriented code generator |
| US5724532A (en) * | 1994-10-27 | 1998-03-03 | Bay Networks, Inc. | Method and apparatus for exchanging information between application programs according to a drag and drop operation |
| US5911068A (en) * | 1995-03-30 | 1999-06-08 | Microsoft Corporation | Container independent control architecture |
| US6640255B1 (en) * | 1995-03-31 | 2003-10-28 | Sun Microsystems, Inc. | Method and apparatus for generation and installation of distributed objects on a distributed object system |
| US5732263A (en) * | 1995-10-03 | 1998-03-24 | International Business Machines Corporation | Systems, methods and computer program products for generating and validating user defined object classes in an object oriented programming environment after build time |
| US5870587A (en) * | 1996-03-20 | 1999-02-09 | International Business Machines Corporation | Information-handling system, method, and article of manufacture including a mechanism for providing an improved application binary interface |
| US5867175A (en) * | 1996-05-24 | 1999-02-02 | Microsoft Corporation | Method and apparatus for scriping animation |
| US6412017B1 (en) * | 1996-07-01 | 2002-06-25 | Microsoft Corporation | Urgent replication facility |
| US5949998A (en) * | 1996-07-03 | 1999-09-07 | Sun Microsystems, Inc. | Filtering an object interface definition to determine services needed and provided |
| US5991535A (en) | 1996-07-03 | 1999-11-23 | Sun Microsystems, Inc. | Visual composition tool for constructing application programs using distributed objects on a distributed object network |
| US5860004A (en) * | 1996-07-03 | 1999-01-12 | Sun Microsystems, Inc. | Code generator for applications in distributed object systems |
| US5920868A (en) * | 1996-07-03 | 1999-07-06 | Sun Microsystems, Inc. | Cataloging apparatus for facilitating the re-use of distributed objects in a distributed object system |
| US5999728A (en) * | 1996-07-30 | 1999-12-07 | Sun Microsystems, Inc. | Method and apparatus for enhancing the portability of an object oriented interface among multiple platforms |
| CH690973A5 (fr) * | 1996-12-19 | 2001-03-15 | Asulab Sa | Pièce d'horlogerie dont le mécanisme est entraîné par des moyens mécaniques et comprenant un dispositif d'indication de réserve de marche. |
| US6023582A (en) * | 1996-12-23 | 2000-02-08 | Z-World, Inc. | Function code chaining method |
| US6662210B1 (en) | 1997-03-31 | 2003-12-09 | Ncr Corporation | Method of remote collaboration system |
| US6715147B1 (en) * | 1997-03-31 | 2004-03-30 | International Business Machines Corporation | Method and system for interfacing a plurality of applications conforming to a standard |
| US6003038A (en) * | 1997-03-31 | 1999-12-14 | Sun Microsystems, Inc. | Object-oriented processor architecture and operating method |
| US6960133B1 (en) | 2000-08-28 | 2005-11-01 | Igt | Slot machine game having a plurality of ways for a user to obtain payouts based on selection of one or more symbols (power pays) |
| KR100512157B1 (ko) * | 1997-09-04 | 2005-11-01 | 삼성전자주식회사 | 오오피 기반의 마이크로컨트롤러 응용 개발 시스템 |
| US6272673B1 (en) | 1997-11-25 | 2001-08-07 | Alphablox Corporation | Mechanism for automatically establishing connections between executable components of a hypertext-based application |
| US6049664A (en) * | 1997-11-25 | 2000-04-11 | Alphablox Corporation | Tier-neutral development mechanism for hypertext based applications |
| US6002874A (en) * | 1997-12-22 | 1999-12-14 | International Business Machines Corporation | Method and system for translating goto-oriented procedural languages into goto-free object oriented languages |
| US6014517A (en) * | 1998-01-06 | 2000-01-11 | Emc Corporation | Automatic creation of C to assembler interface |
| US6003040A (en) * | 1998-01-23 | 1999-12-14 | Mital; Vijay | Apparatus and method for storing, navigating among and adding links between data items in computer databases |
| AU3106099A (en) * | 1998-03-27 | 1999-10-18 | Infoimage Incorporated | Methods and apparatus for network applications using object tools |
| US6385769B1 (en) * | 1999-02-03 | 2002-05-07 | International Business Machines Corporation | Text based object oriented program code with a visual program builder and parser support for predetermined and not predetermined formats |
| US6366921B1 (en) | 1999-02-09 | 2002-04-02 | International Business Machines Corporation | System and method for data manipulation in a dynamic object-based format |
| US6681240B1 (en) | 1999-05-19 | 2004-01-20 | International Business Machines Corporation | Apparatus and method for specifying maximum interactive performance in a logical partition of a computer system independently from the maximum interactive performance in other partitions |
| US6279046B1 (en) * | 1999-05-19 | 2001-08-21 | International Business Machines Corporation | Event-driven communications interface for logically-partitioned computer |
| US6691146B1 (en) | 1999-05-19 | 2004-02-10 | International Business Machines Corporation | Logical partition manager and method |
| US6959291B1 (en) | 1999-05-19 | 2005-10-25 | International Business Machines Corporation | Management of a concurrent use license in a logically-partitioned computer |
| US6467007B1 (en) | 1999-05-19 | 2002-10-15 | International Business Machines Corporation | Processor reset generated via memory access interrupt |
| US6769985B1 (en) | 2000-05-31 | 2004-08-03 | Igt | Gaming device and method for enhancing the issuance or transfer of an award |
| US6731313B1 (en) | 2000-06-23 | 2004-05-04 | Igt | Gaming device having touch activated alternating or changing symbol |
| US7699699B2 (en) | 2000-06-23 | 2010-04-20 | Igt | Gaming device having multiple selectable display interfaces based on player's wagers |
| US7695363B2 (en) | 2000-06-23 | 2010-04-13 | Igt | Gaming device having multiple display interfaces |
| US6935955B1 (en) | 2000-09-07 | 2005-08-30 | Igt | Gaming device with award and deduction proximity-based sound effect feature |
| US6739973B1 (en) | 2000-10-11 | 2004-05-25 | Igt | Gaming device having changed or generated player stimuli |
| US6749502B2 (en) | 2001-03-21 | 2004-06-15 | Igt | Gaming device having a multi-characteristic matching game |
| US7040983B2 (en) | 2001-03-21 | 2006-05-09 | Igt | Gaming device having a multi-round, multi-characteristic matching game |
| US7901291B2 (en) | 2001-09-28 | 2011-03-08 | Igt | Gaming device operable with platform independent code and method |
| US7666098B2 (en) * | 2001-10-15 | 2010-02-23 | Igt | Gaming device having modified reel spin sounds to highlight and enhance positive player outcomes |
| US6848996B2 (en) * | 2001-10-15 | 2005-02-01 | Igt | Gaming device with sound recording changes associated with player inputs |
| US7708642B2 (en) | 2001-10-15 | 2010-05-04 | Igt | Gaming device having pitch-shifted sound and music |
| GB0212308D0 (en) * | 2002-05-28 | 2002-07-10 | Symbian Ltd | Trusted user interface for a secure mobile wireless device |
| US7789748B2 (en) * | 2003-09-04 | 2010-09-07 | Igt | Gaming device having player-selectable music |
| US7105736B2 (en) | 2003-09-09 | 2006-09-12 | Igt | Gaming device having a system for dynamically aligning background music with play session events |
| US7585219B2 (en) * | 2004-09-30 | 2009-09-08 | Igt | Gaming device having a matching symbol game |
| US8043155B2 (en) | 2004-10-18 | 2011-10-25 | Igt | Gaming device having a plurality of wildcard symbol patterns |
| US8250528B2 (en) * | 2004-12-15 | 2012-08-21 | Microsoft Corporation | Static inheritance systems and methods |
| US7818755B1 (en) * | 2004-12-22 | 2010-10-19 | Apple Inc. | Window server event taps |
| US20080086700A1 (en) * | 2006-10-06 | 2008-04-10 | Rodriguez Robert A | Systems and Methods for Isolating On-Screen Textual Data |
| US8750490B2 (en) * | 2007-08-22 | 2014-06-10 | Citrix Systems, Inc. | Systems and methods for establishing a communication session among end-points |
| US8315362B2 (en) * | 2007-08-22 | 2012-11-20 | Citrix Systems, Inc. | Systems and methods for voicemail avoidance |
| US9137377B2 (en) | 2007-08-22 | 2015-09-15 | Citrix Systems, Inc. | Systems and methods for at least partially releasing an appliance from a private branch exchange |
| US20090183110A1 (en) * | 2007-12-21 | 2009-07-16 | Richard Leo Murtagh | Systems and Methods for Efficient Processing of Data Displayed by a Window |
| US20090183160A1 (en) * | 2008-01-16 | 2009-07-16 | Morinville Paul V | Automated Execution of Business Processes Using Dual Element Events |
| US8612614B2 (en) * | 2008-07-17 | 2013-12-17 | Citrix Systems, Inc. | Method and system for establishing a dedicated session for a member of a common frame buffer group |
| US8591308B2 (en) | 2008-09-10 | 2013-11-26 | Igt | Gaming system and method providing indication of notable symbols including audible indication |
| US8533689B2 (en) * | 2008-10-10 | 2013-09-10 | The Boeing Company | Method, apparatus and computer program product for creating inter-language interface |
| US8460090B1 (en) | 2012-01-20 | 2013-06-11 | Igt | Gaming system, gaming device, and method providing an estimated emotional state of a player based on the occurrence of one or more designated events |
| US8740689B2 (en) | 2012-07-06 | 2014-06-03 | Igt | Gaming system and method configured to operate a game associated with a reflector symbol |
| US9245407B2 (en) | 2012-07-06 | 2016-01-26 | Igt | Gaming system and method that determines awards based on quantities of symbols included in one or more strings of related symbols displayed along one or more paylines |
| US9192857B2 (en) | 2013-07-23 | 2015-11-24 | Igt | Beat synchronization in a game |
| US9947170B2 (en) | 2015-09-28 | 2018-04-17 | Igt | Time synchronization of gaming machines |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4791550A (en) * | 1985-02-13 | 1988-12-13 | Rational | Higher order language-directed computer |
| US4766534A (en) * | 1986-10-16 | 1988-08-23 | American Telephone And Telegraph Company, At&T Bell Laboratories | Parallel processing network and method |
| JPS647231A (en) * | 1987-06-30 | 1989-01-11 | Toshiba Corp | Parallel processing device for object directional system |
| US5133070A (en) * | 1988-06-30 | 1992-07-21 | International Business Machines Corporation | Method of nesting and processing mixed data objects within a data stream utilizing selective environment inheritance |
| EP0360387B1 (fr) * | 1988-09-23 | 1996-05-08 | International Business Machines Corporation | Système de gestion de base de données |
| US5133075A (en) * | 1988-12-19 | 1992-07-21 | Hewlett-Packard Company | Method of monitoring changes in attribute values of object in an object-oriented database |
| US5057996A (en) * | 1989-06-29 | 1991-10-15 | Digital Equipment Corporation | Waitable object creation system and method in an object based computer operating system |
| US5119475A (en) * | 1991-03-13 | 1992-06-02 | Schlumberger Technology Corporation | Object-oriented framework for menu definition |
-
1991
- 1991-03-13 GB GB919105278A patent/GB9105278D0/en active Pending
- 1991-04-25 FR FR9105113A patent/FR2661525A1/fr active Pending
- 1991-04-30 JP JP3124589A patent/JPH0628168A/ja active Pending
-
1993
- 1993-07-14 US US08/091,536 patent/US5446902A/en not_active Expired - Lifetime
Non-Patent Citations (4)
| Title |
|---|
| PROCEEDINGS OF THE ACM SIGGRAPH SYMPOSIUM ON USER INTERFACE SOFTWARE. 17 Octobre 1988, BANFF, ALBERTA, CANADA pages 66 - 76 T. HAUGE ET AL. 'EVENT-DRIVEN USER INTERFACES BASED ON QUASI-PARALLELISM' * |
| PROCEEDINGS OF THE SPRING EUUG CONFERENCE. 23-27 Avril 1990, MUNICH, ALLEMAGNE pages 139 - 150 N. ISLAM 'THE XVIEW USER INTERFACE TOOLKIT OBJECT MODEL' * |
| PROCEEDINGS, SUMMMER USENIX '88. 20 Juin 1988, SAN FRANCISCO, CA, US pages 1 - 13 J. MCCORMACK ET AL. 'USING THE X TOOLKIT OR HOW TO WRITE A WIDGET' * |
| USENIX WINTER CONFERENCE. 9 Février 1988, DALLAS, TEXAS, US pages 9 - 21 A.J. PALAY ET AL. 'THE ANDREW TOOLKIT - AN OVERVIEW' * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5551030A (en) * | 1992-12-08 | 1996-08-27 | International Business Machines Corporation | Method and apparatus for integrating applications in a graphical user interface environment with a rules database |
| EP0696770A1 (fr) * | 1994-06-15 | 1996-02-14 | AT&T Corp. | Bibliothèque de classe à utiliser pour programmation graphique |
| US5564048A (en) * | 1994-06-15 | 1996-10-08 | Lucent Technologies Inc. | Object-oriented functionality class library for use in graphics programming |
Also Published As
| Publication number | Publication date |
|---|---|
| GB9105278D0 (en) | 1991-04-24 |
| JPH0628168A (ja) | 1994-02-04 |
| US5446902A (en) | 1995-08-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2661525A1 (fr) | Procede et appareil destines a implanter une programmation orientee vers l'objet, utilisant c non modifie pour un systeme d'ordinateur a base de fenetre. | |
| EP0793171B1 (fr) | Système de configuration de logiciels préconfigurés sur des systèmes ouverts en réseau dans un environnement distribué et procédé mis en oeuvre par un tel système | |
| US8046754B2 (en) | Methods and apparatus for customizing user-interface control in existing application | |
| Horstmann et al. | Core Java 2: Fundamentals | |
| US6469714B2 (en) | Infocenter user interface for applets and components | |
| US7577909B2 (en) | Flexible management user interface from management models | |
| US8296720B2 (en) | Framework to access a remote system from an integrated development environment | |
| US7992128B2 (en) | Computer software adaptation method and system | |
| US6532471B1 (en) | Interface repository browser and editor | |
| US20080120593A1 (en) | GUI modeling of deep hierarchical data | |
| WO1994002895A1 (fr) | Utilisation d'un langage a interprete embarque pour la realisation d'un outil interactif de definition d'interface utilisateurs | |
| FR2688611A1 (fr) | Utilisation d'un langage dont le typage porte sur le contenu des variables et permettant de manipuler des constructions complexes. | |
| CA2391756A1 (fr) | Acces a un systeme informatique iseries ou as/400 eloigne a partir d'un environnement de developpement integre eclipse | |
| JPH09500465A (ja) | ダイナミック・リンク・システム | |
| US20070006121A1 (en) | Development activity recipe | |
| US20040216088A1 (en) | Method and apparatus for attaching an informational dialog to a Java bean | |
| CA2131632C (fr) | Utilisation d'un langage ayant une representation similaire pour les programmes et les donnees en informatique distribuee | |
| Cheung et al. | Wcomp: Rapid application development toolkit for wearable computer based on java | |
| Johnsson et al. | Live GUI development for service-based systems | |
| EP0790553B1 (fr) | Outil de génération et d'exécution de commandes à interface graphique | |
| Kao | Experience in undergraduate research in communications | |
| Haddad | X/Motif Programming | |
| Jain | Vsh: a Multiparadigm Framework for Graphical User Interfaces | |
| Stenzoski | X Window application extension with the Andrew Toolkit | |
| Powers et al. | Visual Basic programmer's guide to the. NET Framework class library |