Lutz Hoeger, Aoûtt 2003

Table des matières

1 Introduction	3

2 Sommaire Exécutif	3

3 Aperçu du concept	4

3.1 Clé dominante (P2)	4

3.1.1 Interopérabilité avec Microsoft Office	4

3.1.2 Utilisation	5

3.1.3 Performance	5

3.1.4 Programmabilité	6

3.1.5 Intégration dans Gnome Desktop et Microsoft Windows	6

3.2 Améliorations générales (P3)	6

3.2.1 Stabilité and Qualité	6

3.2.2 Administration et Déploiement	6

3.2.3 Apparence moderne (Look & Feel)	7

3.2.4 Intégration (Plugins, applications tierces)	7

3.3 Opportunités futures (P4 et P5)	8

3.3.1 Langages CTL et Asiatiques	8

3.3.2 Signatures Digitales	8

3.3.3 Mise à jour de fonctionnalités intéressantes (e.x. multi media, OCR, DB)	9

3.3.4 Drapeaux pour des documents intelligents	9

3.3.5 Collaboration	9

4 Détails du Concept	10

4.1 Clés dominantes	10

4.1.1 Améliorer l'interopérabilité avec Microsoft Office	10

4.1.1.1 SO/OOo Writer	10

4.1.1.3 SO/OOo Impress	12

4.1.1.4 SO/OOo Base de données (Formulaires)	13

4.1.1.5 SO/OOo Diagramme	15

4.1.2 Utilisation	16

4.1.2.1 Structure des menus	16

4.1.2.2 Barre d'outils	16

4.1.2.3 Terminologie	16

4.1.2.4 Affichage des fenêtres	16

4.1.2.5 Séparations des applications	16

4.1.2.6 Interaction Générale	16

4.1.2.7 Usage de l'application de base de données	17

4.1.3 Performances	18

4.1.3.1 Temps au démarrage	19

4.1.3.2 Temps d'ouverture et d'enregistrement des documents	19

4.1.3.3 Déploiement	19

4.1.4 Programmabilité	20

4.1.4.1 Amélioration des APIs UNO/Office	20

4.1.4.2 IDE intégré pour de multiples langages de script.	20

4.1.4.3 Type de cycle de vie	20

4.1.4.4 Pont .NET	21

4.1.4.5 Déploiement et Interface générale utilisateur	21

4.1.4.6 Scripting Framework	22

4.1.5 Intégration dans l'environnement de bureau Gnome, et Microsoft Windows	22

4.1.5.1 Look and Feel	22

4.1.5.2 Impression	23

4.1.5.3 Intégration de voisinage réseau	23

4.1.5.4 Intégration du bureau	24

4.1.5.5 Interopérabilité des applications	24

4.1.5.6 Installation	24

4.1.5.7 Configuration	24

4.2 Améliorations générales	24

4.2.1 Stabilité et Qualité	24

4.2.1.1 Restauration des documents	24

4.2.1.2 Rapports d'erreurs	25

4.2.2 Administration et Déploiement	25

4.2.2.1 Déploiement	25

4.2.2.2 SO/OOo Configuration	25

4.2.3 Apparence Moderne	26

4.2.3.1 Barres d'outils	26

4.2.3.2 Widget style	26

4.2.3.3 Tool Pane	27

4.2.3.4 Apparence des dialogues en général	27

4.2.3.5 AutoPilotes (Wizards)	27

4.2.3.6 Intégration Système	27

4.2.4 Intégration (Plug-ins, applications tierces)	28

4.2.4.1 Support de l'OLE	28

4.2.4.2 Intégration du Navigateur	29

4.2.4.3 Intégration de parties tierces UNO	29

4.2.4.4 Intégration avec les clients mail	30

4.2.4.5 Intégration de fichiers multi-média dans SO/OOo	30

4.2.4.6 Support pour le développement de filtres	30

4.3 Opportunités à venir	30

4.3.1 Langues CTL et Asiatiques	30

4.3.1.1 CJK Requirements	30

4.3.1.2 CTL Requirements	31

4.3.1.3 Generic I18N Requirements	31

4.3.1.4 Intégration d'outils	32

4.3.2 Signatures Digitales	32

4.3.3 Compelling upgrade features (e.g. multi media, OCR, DB)	33

4.3.4 Web Services	33

4.3.4.1 SO/OOo Web-Services Client (WebServices-1)	33

4.3.4.2 Navigateur UDDI SO/OOo (WebServices-2)	34

4.3.4.3 SO/OOo Fournisseur de service Web (non couvert actuellement)	34

4.3.5 Drapeaux pour les documents intelligents	34

4.3.5.1 Utilisateur	34

4.3.5.2 SO/OOo	35

4.3.5.3 Composant	35

1 Introduction

(Lutz Hoeger, Juillet 2003)

Ce document vous donne un haut niveau d'aperçu du concept des fonctionnalités de la prochaine version de StarOffice/OpenOffice.org (SO/OOo) actuellement en phase prévisionnelle.

Les spécifications pour un projet aussi important couvrent de nombreux secteurs et comportent de nombreux détails. En conséquence, ce document ne fournira pas une liste exhaustive des détails, mais occasionnellement inclura quelques détails afin d'apporter de la clarté à la discussion. Beaucoup de ces détails ont déjà été et seront bientôt soumis comme fonctionnalités dans IssueZilla afin de compléter l'aperçu.

En compilant ce document, nous avons collecté le retour des utilisateurs, des développeurs, des clients existants ou potentiels, soit par communication directe lors de manifestations comme Linux World ou encore lors d'événements comme la conférence OpenOffice.org, en utilisant les enquêtes et enfin les discussions sur les mailings listes d'OOo. Nous avons ensuite mises ensemble ces idées afin de répondre à ces requêtes, les avons priorisées et finalement assemblées dans ce Concept Produit.

Lors de la définition des priorités pour cette version, nous avons dû établir un équilibre entre l'importance de chaque requête et le but d'un cycle de 18 mois pour chaque nouvelle version. Nous avons appris à travers les discussions, particulièrement avec les entreprises clientes, que cela correspondait à leur rythme dans la délivrance de nouvelles versions d'une suite bureautique.

La structure de ce document fournit différents niveaux de détail du concept:

Le Sommaire Exécutif (0.5 page) est idéal pour les lecteurs « qui n'ont que 5 minutes - très pressés ! » et qui veulent avoir un aperçu global de la direction prise dans le développement. C'est une brève description de nos réponses aux requêtes prioritaires. Cette section ne contient aucun détail, ni liste des secteurs sur lesquels nous projetons de travailler.

La section Aperçu du Concept (5 pages) explique les priorités et discute de tous les secteurs de requêtes. Cette section fournira un bon aperçu, d'une trentaine de minutes, des réponses aux requêtes. Quoique laissant de côté pas mal de détails, elle couvre toutes les sections.

Et finalement, la section Concept Détaillé (environ 20 pages) complète la section précédente par une vue très détaillée de tous les aspects des requêtes, avec quelques informations complémentaires si disponibles, et certaines parties du concept illustrées par des détails plus en profondeur.

Avant de commencer, permettez-moi de vous signaler une convention utilisée tout au long de ce document. Le nom de code « Geordi » correspond à SO/OOo 1.1 et « Q » correspond à la prochaine version majeure après la 1.1.

Enfin, vous trouverez les noms de différents auteurs pour chaque chapitre, montrant que beaucoup de personnes ont contribué à ce document. Nous serions tous très heureux d'avoir votre retour. Aussi, si vous souhaitez notifier quelque chose que nous aurions pu mieux faire, quelque chose que nous aurions pu oublier ou simplement si vous souhaitez nous poser une question, merci de référer, dans vos commentaires, à la section concernée. Cela nous aidera à identifier la personne qui sera à même de mieux vous répondre.

2 Sommaire Exécutif

(Lutz Hoeger, Juillet 2003)

“Q” sera la prochaine version majeure de StarOffice / OpenOffice.org (SO/OOo). Listés ci-dessous, vous trouverez les concepts qui constituent les requêtes clés de nos clients existants ou potentiels. Ces Critiques de Qualité sont toutes centrées autour du même thème : la migration vers “Q”.

Un moindre coût d'interopérabilité avec Microsoft Office. En fournissant une meilleure interopérabilité avec Microsoft Office, “Q” devrait diminuer conséquemment le coût d'une conversion entre les deux applications.

Des coûts de formations moindres
“Q” devrait baisser les coûts de besoins de formation pour les utilisateurs moyens par l'amélioration de ses fonctionnalités, par de meilleurs standards d'interactions. Cela rendrait la migration vers SO/OOo moins onéreuse.

Meilleure Performance
“Q” devrait voir une amélioration notable de ses performances au démarrage tout autant que dans ses temps d'ouverture ou d'enregistrement d'un document

Amélioration générale de l'ergonomie
Redessiner des parties de “Q” pour accroître l'ergonomie permettra d'améliorer la productivité de l'utilisateur moyen et le niveau de satisfaction général lors de l'utilisation du produit.

Améliorer la programmabilité
“Q” facilitera l'automatisation de tâches typiquement bureautiques. En améliorant son extensibilité “Q” sera plus personnalisable face aux besoins des clients.

Meilleure intégration dans le système de bureau.
Particulièrement pour le système de bureau de Gnome “Q” s'intégrera mieux avec l'infrastructure existante. Cela conduira à un usage plus intuitif de “Q” pour les utilisateurs qui sont déjà familiarisés avec le système de bureau et fournira une meilleure interopérabilité entre SO/OOo et les autres applications de bureau.

3 Aperçu du concept

Cette section explique la priorisation et fournit un aperçu général du concept dans tous les secteurs. La section 4, Détails du Concept fourni plus de détails

Les priorités déterminées dans ce concept l'ont été en regard du guide général de priorité issu de différents systèmes de suivi de bugs dont IssueZilla. Cependant ce dernier n'exclut pas spécifiquement des fonctionnalités ayant une priorité 1, une issue de priorité 1 signifie que cette zone est inutilisable. Typiquement P1 est uniquement réservée à des bugs. C'est pourquoi le barème pour les priorités commence à P2 (la plus haute) jusqu'à P5 (la plus basse). Nous les classons de la façon suivante :

3.1 Clé dominante (P2)

La devise stratégique de cette version est de diminuer les contraintes de migrations vers StarOffice/OpenOffice. Notre concept répond à cela à différents niveaux et dans différentes parties du produit. Les axes ci-dessous décrivent les clés dominantes pour « Q » – les axes pour lesquels nous avons eu un retour lors de nos recherches auprès de nos clients. Ces axes sont prioritaires et demandent souvent un important effort d'ingénierie de développement.

3.1.1 Interopérabilité avec Microsoft Office

(Dieter Loeschky, Avril 2003)

L'interopérabilité entre Microsoft Office et SO/OOo est généralement influencée par trois facteurs. Le premier facteur est la qualité des filtres, ce qui signifie la qualité du composant qui traduit le contenu et la structure d'un document Microsoft Office dans le contenu et la structure d'un document SO/OOo. Le second facteur est la compatibilité du choix de fonctions des applications dans Microsoft Office par rapport aux fonctions correspondantes dans l'application SO/OOo. Le troisième facteur est le comportement et l'interprétation des fonctions qui existent dans chaque application. Même si certaines fonctions sont supportées à la fois par une autre application et SO/OOo, il peut y avoir des différences dans la manière dont la fonction est actuellement appliquée, ce qui fera que le document aura un rendu différent alors que les mêmes valeurs sont entrées/stockées pour cette fonction à travers leur moteur de texte

Par exemple (actuellement résolu), la marge du paragraphe supérieur qui existe dans Microsoft Word et SO/OOo Writer. Ce dernier, comme beaucoup de logiciels de PAO et de traitement de textes professionnels, ignore cette valeur pour le premier paragraphe d'une page. Microsoft Word ne le fait pas. Le résultat en est que l'apparence du document sera différente alors qu'exactement les mêmes valeurs sont prises en compte par chaque moteur de texte.

3.1.2 Utilisation

(Matthias Mueller-Prove, May 2003)

L'apparence de « Q » va changer de façon à s'adapter aux habitudes de la majorité des personnes qui n'utilisent pas SO/OOo. Ces changements affecteront la structure des menus, l'interface utilisateurs des barres d'outils, la terminologie et finalement l'ensemble de la fenêtre d'affichage.

En général cette utilisation concerne la conformité des tâches, la familiarité, l'intuitivité, la flexibilité la résistance, l'adaptabilité et la mémorisation. Certaines améliorations mineures de cette utilisation permettent à SO/OOo d'atteindre ces qualités d'usage/utilisation. Toutes les nouvelles fonctions seront évaluées en fonction de cette exigence de qualité par l'équipe d'utilisateurs expérimentés de Sun StarOffice.

La conformité des tâches nous pousse à reconsidérer les étapes nécessaires pour accomplir une action et ainsi de réduire au maximum le nombre de clics pour « Q ». Le travail prévisionnel exige que nous essayions d'obtenir une interface utilisateur cohérente. Nous fournirons un modèle conceptuel qui est prévisible et conforme à toutes les applications de SO/OOo au lieu de se conformer à la majorité des applications de la concurrence. D'autre part, ce travail prévisionnel réclame la mise en conformité avec les guides de styles des plateformes ciblées.

3.1.3 Performance

(Matthias Huetsch, Mai 2003)

SO/OOo améliorera ses performances dans quatre secteurs qui sont particulièrement importants pour les utilisateurs. Les deux domaines les plus évidents de cette amélioration concernent le temps de démarrage et le temps d'ouverture/enregistrement du document. Le troisième domaine d'amélioration sera la capacité de réponses des objets complexes comme ils le sont par exemple dans les présentations. Le quatrième secteur concerne la capacité d'adaptation à des déploiements à grande échelle dans des environnements multi-utilisateurs comme sur des serveurs Citrix, Tarantella, et SunRay.

Les améliorations de performances dans les trois premiers secteurs ont été identifiées comme étant de nature architecturale principalement. Une amélioration significative de n'importe lequel de ces secteurs peut être réalisée soit en réaménageant l'architecture courante, ou encore en remplaçant cette architecture. Le quatrième secteur d'amélioration des performances provient d'un certain nombre de secteurs qui peuvent être solutionnés individuellement

3.1.4 Programmabilité

(Kay Ramme, Mai 2003)

La programmabilité décrit la possibilité d'utilisation de tout ou parties de SO/OOo, à travers des solutions de programmation personnalisées. La technologie fondamentale pour la programmabilité de SO/OOo est le modèle de composant SO/OOo UNO (objets universels de réseau) et les APIs SO/OOo. « Q » facilitera à des niveaux multiples la création de solutions utilisant UNO et les APIs SO/OOo. Ceci sera réalisé à travers un support amélioré des langages, l'intégration d'IDE, le déploiement facilité des add-ons dans une installation SO/OOo, et un nouveau cadre de scripts qui permet l'utilisation d'autres langages en plus du BASIC pour l'utilisation des scripts

3.1.5 Intégration dans Gnome Desktop et Microsoft Windows

(Christof Pintaske, Juin 2003)

Le concept général est de fournir un environnement de bureau facile à utiliser, attrayant, moderne et harmonieux à travers toutes les applications.

Pour réaliser une meilleure intégration système, « Q » utilisera de façon accrue l'information et l'infrastructure utilisée par Gnome au lieu de créer des solutions indépendantes des plateformes.

3.2 Améliorations générales (P3)

Les prochains secteurs représentent également des améliorations obligatoires. Ils concernent des améliorations générales qui faciliteront un déploiement réussi de SO/OOo

3.2.1 Stabilité and Qualité

(Matthias Huetsch, Juin 2003)

« Q » améliore la stabilité et la qualité en remédiant à la perte de document SO/OOo non enregistré, qui peut également induire une perte de données. Actuellement, SO/OOo exécute une copie de secours de ces documents seulement. Au prochain démarrage, une boîte de dialogue de restauration du document offre alors de restaurer ces documents dans un état antérieurement reconnu comme correct.

La probabilité de la perte de données due à un accident sera réduite en augmentant la protection courante par des copies de sauvegarde régulières des documents. La boîte de dialogue de restauration de documents sera améliorée en affichant plus de conseils et de rétroaction tout en reconstituant les documents. Un outil de rapport d'erreurs, disponible dans « Geordi », devrait fournir des données permettant d'identifier et d'éliminer des causes d'accident.

3.2.2 Administration et Déploiement

(Dirk Grobler, Christof Pintaske, Mai 2003)

En ce qui concerne le déploiement, « Geordi » permet une installation indépendante de la plateforme qui ne peut pas facilement être contrôlée par des logiciels de gestion. Au lieu d'ajouter des possibilités supplémentaires de gestion dans ce secteur, SO/OOo « Q » change de procédé d'installation. L'installation indépendante des plateformes est remplacée par le support de la norme, des routines d'installation dépendantes de plateforme – appelés installateurs natifs - et de leurs paquets natifs d'installation. Ce sont l'installation de paquet Solaris (pkg), l'installation de paquet Linux RPM (rpm), et l'installation à l'aide l'installateur de Microsoft (MSI)

L'avantage de cette approche doit influencer la technologie de déploiement déjà existante basée sur ces formats natifs. Avec « Q », les administrateurs pourront installer « Q » avec leur outillage existant.

3.2.3 Apparence moderne (Look & Feel)

(Christian Jansen, Mai 2003)

Les utilisateurs sont demandeurs de différentes apparences (look&feel) , qui correspondent principalement à trois catégories.

Les thèmes de SO/OOo devraient être plus intuitifs

L'interface utilisateur devrait être mieux organisée et faire ressortir les informations importantes.

SO/OOo doit fournir plus de rétroaction et de réponses utilisateur

Pour SO/OOo « Q » nous améliorerons ce secteur pour apporter une réponse aux personnes qui n'utilisent pas encore SO/OOo tout en respectant les attentes des utilisateurs courants de SO/OOo.

3.2.4 Intégration (Plugins, applications tierces)

(Mathias Bauer, Mai 2003)

L'intégration SO/OOo avec des applications tierces peut être faite à plusieurs niveaux :

Créer des filtres d'import et d'export pour convertir les formats de fichiers entre eux

Utiliser le presse-papier du système pour l'échange de données

Employer les moyens externes de communication comme des pipes, des fichiers, les paramètres en ligne de commande etc. pour permettre un flux de travail entre SO/OOo et les autres applications,

Lier ou incorporer les données ou les fichiers d'autres applications dans les documents SO/OOo et vice versa.

Employer l'API SO/OOo ou l'API d'autres applications pour intégrer un niveau fonctionnel.

Les deux premières options sont déjà largement répandues dans SO/OOo. Ajouter un support vers plus d'applications tierces signifie simplement fournir les routines de conversion nécessaires et ne sera pas discuté ici en détail.

Les moyens externes de communication sont habituellement travaillés au cas par cas. Un exemple de genre d'intégration est le client externe de mail.

L'intégration de parties tierces au niveau des APIs peut être faite de deux façons :

Cette application utilise UNO pour se connecter à SO/OOo et utilise ses propres APIs pour accéder aux fonctionnalités.

SO/OOo crée un adaptateur pour utiliser la technologie middleware de la partie tierce (comme Com, .NET ou SOAP).

Ce document s'attache plus au premier concept. Le second ayant une réponse à travers le pont UNO comme celui que nous avons (ou développerons) pour les automations OLE, .NET ou SOAP

3.3 Opportunités futures (P4 et P5)

La partie finale du concept contient des perfectionnements facultatifs dans le secteur des opportunités futures que nous pouvons prévoir aujourd'hui.

3.3.1 Langages CTL et Asiatiques

(Falko Tesch, Juillet 2003)

L'internationalisation (I18N) décrit les capacités et la disponibilité d'un produit pour les marchés internationaux. Ceci signifie que le produit doit être conforme à 3 points importants :

Il doit répondre aux dispositions et aux habitudes spécifiques du lieu.

Il nécessite une interface utilisateur complète et documentée.

Il nécessite des outils localisés et le support pour des outils locaux, tels qu'IME (moteur de méthode d'entrée) et autres.

Le support IME de StarOffice 6.0 et de « Geordi » autorise l'utilisation de scripts Est-Asiatique comme le Chinois, le Coréen et le Japonais. En outre, « Geordi » rend accessibles les dispositifs incontournables pour le traitement de textes en Asie, comme la disposition verticale des textes, le support de la fonction Ruby, les effets spécifiques de police et autres. Alors que « Geordi » répond aux besoins spécifiques des marchés CJK, il aborde seulement les caractéristiques spécifiques des marchés CTL (affichage de textes complexes) (Arabe, Hébreu, Thaï, Hindi etc.). « Q » répondra à l'ensemble des dispositifs nécessaires CJK (Chinois, Japonais, Coréen) et au CTL commencés par « Geordi » :

Affinement des dispositifs CJK déjà existants et ajout des dispositifs concurrentiels pour correspondre à l'offre CJK d'autres suites bureautiques, comme les outils locaux de bureautique, tel que Hangul (Corée), Ichitaro (Japon) et bureautique WPS (R.P de Chine).

Introduction d'un support complet de localisation CTL de l'Arabe et des pays parlant Hébreu ainsi que pour l'Inde (Hindi plus 6 autres langues principales).

Avec « Geordi », SO/OOo démontre sa parfaite adaptation aux marchés CTL (par exemple les régions Arabes et parlant Hébreu)

3.3.2 Signatures Digitales

(Michael Brauer, Mai 2003)

La sécurisation du contenu des documents bureautiques peut être divisée en deux dispositifs, signatures numériques et chiffrage. Les signatures digitales elles-mêmes sont un sujet relativement nouveau pour les applications bureautiques. Cependant, protéger des données contre les modifications existe depuis de nombreuses années. Dans le passé, cela a été résolu par des dispositifs qui empêchaient d'éditer les documents à travers les applications bureautiques. Avec les signatures numériques, ces dispositifs seront optimisés pour offrir une protection bloquant le contenu du document, tant à travers SO/OOo, que dans des applications externes.

3.3.3 Mise à jour de fonctionnalités intéressantes (e.x. multimédia, OCR, DB)

Le chiffrage est un dispositif qui a longtemps été utilisé pour les applications bureautiques. Le perfectionnement dans ce secteur a principalement affecté l'algorithme de chiffrage lui-même, afin de le rendre plus sécurisé. Cependant, puisqu'il n'y avait aucune normalisation dans l'application des algorithmes de chiffrage aux documents, le traitement de tels documents en dehors de l'application bureautique restait complexe. En supportant de nouvelles normes de chiffrage du XML, et de par le format de fichier XMLde SO/OOo, ceci deviendra beaucoup plus facile.

Puisque ces conditions nécessitent beaucoup d'améliorations et de nouveaux dispositifs pour SO/OOo, elles seront réservées à la mise à niveau de fonctionnalités pour lesquelles les utilisateurs pourraient avoir des contraintes. Dans la mesure où, à l'heure actuelle, nous n'avons aucune exigence particulière de la part de nos utilisateurs quant à cette section, son contenu sera déterminé ultérieurement.

Services Web

(Kai Sommerfeld, Mai 2003)

Les services Web deviennent de plus en plus plus importants dans la mesure où ils facilitent l'établissement de communication B2B indépendamment de la plateforme. Il y a pas mal d'offres disponibles à partir des services Web de Google et qui fournissent une large gamme de fonctionnalités, par exemple le service de recherche sur Internet.

Il serait intéressant que SO/OOo puisse agir tel un client de service Web, le rendant accessible et utilisable pour des services Web arbitraires.

De plus il y a un intérêt réel à offrir cette fonctionnalité de service Web SO/OOo. Un exemple d'un tel service Web serait un service de transformation de document, qui serait basée sur l'importation et l'exportation de document SO/OOo's.

3.3.4 Drapeaux pour des documents intelligents

(Andreas Martens, Mai 2003)

SO/OOo soutiendra une interface pour les tags intelligents et extensibles des documents. Cette interface permettra à des fournisseurs tiers d'offrir des informations/services additionnels sur la base de l'analyse textuelle. C'est une solution donnant-donnant. SO/OOo dispose d'une fonctionnalité sans avoir à réinventer la roue. Pour des fournisseurs tiers, il crée un débouché autour de SO/OOo.

Originellement, tous les mots/phrases qui sont identifiés par des mots-clés seront soulignés. L'utilisateur a accès à des menus contextuels via ces mots marqués et choisit des actions supplémentaires. Exemple : un fournisseur offre un composant avec différents dictionnaires (technique, légal, médical). Le document de SO/OOo sera balayé en fonction des entrées de ces dictionnaires. Pour des mots marqués, le menu contextuel contiendra le nom du dictionnaire dans lequel le mot a été trouvé. L'utilisateur choisit alors un dictionnaire et celui-ci montre l'entrée complète

Exemple : le composant supporté est basé sur une liste de clients. Si le nom d'un client est présent dans un document de SO/OOo, il sera souligné. Le menu contextuel peut offrir des actions comme des adresses, email, montrer le volume d'affaires, le dernier ordre, etc... L'information choisie sera affichée ou un autre programme comme un client mail s'ouvrira.

3.3.5 Collaboration

Sera complété ultérieurement.

4 Détails du Concept

Cette section contient des détails au sujet du Concept Produit.

4.1 Clés dominantes

4.1.1 Améliorer l'interopérabilité avec Microsoft Office

(Dieter Loeschky, Avril 2003)

Dans le passé, l'interopérabilité entre Microsoft Office et le SO/OOo a été réalisée par la mise en place de filtres d'importation et d'exportation. Dans « Geordi » l'interopérabilité entre Microsoft Office et SO/OOo a été améliorée en ajoutant également des fonctions à SO/OOo, en changeant le comportement de SO/OOo et l'interprétation des fonctions simples. Pour « Q », l'interopérabilité sera améliorée à grande échelle en continuant à ajouter des fonctions à SO/OOo. Des changements dans les filtres seront naturellement nécessaires pour supporter les nouvelles fonctions ou le comportement général.

L'effort vers le développement de filtres à travers le développement de l'application est en fait un processus naturel. À un certain stade, l'interopérabilité d'une certaine fonction ne peut pas être améliorée plus longtemps par l'utilisation d'un filtre, parce qu'elle convertit déjà toutes les données qui sont supportées d'une application à l'autre. A ce moment, si la fonction se comporte toujours différemment, cela veut dire que l'application SO/OOo elle-même doit être améliorée.

4.1.1.1 SO/OOo Writer

Pour SO/OOo Writer, il y a quatre domaines principaux dans lesquels l'interopérabilité avec Microsoft Office sera améliorée : tableaux, objets de dessin, puces/numérotations et espacements. Dans ces domaines principaux, les améliorations seront complétées par l'apport de beaucoup d'autres petits perfectionnements dépendant d'autres secteurs qui soulèvent également ces questions d'interopérabilité.

Tableaux

L'amélioration la plus importante sera le support des sauts de page automatiques dans les cellules. Actuellement, ceci peut causer des différences significatives dans la disposition d'un même document entre une application non-SO/OOo et SO/OOo Writer, si le document contient des tableaux qui ne s'adaptent pas à une page simple. Deux autres améliorations importantes seront le support des tableaux dans des tableaux, et des tableaux où le texte s'organise autour. L'interopérabilité des tableaux sera améliorée par un modèle de bordures qui fournit une meilleure interopérabilité vers d'autres applications, incluant Microsoft Word. Les améliorations d'interopérabilité mentionnées ci-dessus sont considérées avec une priorité beaucoup plus élevée que celles qui peuvent être réalisées en introduisant un modèle de tableaux différent.

Objets de Dessin

Le second domaine important où l'interopérabilité sera améliorée réside dans les objets de dessin de SO/OOo. L'amélioration la plus importante se fera par le support des objets de dessin d'autres applications dans les en-têtes et les pieds de page. En plus de ceci, des modes manquants d'alignement, d'ancrage et de positionnement seront ajoutés. En conclusion, il y aura une unification des objets de dessin et des cadres flottants de SO/OOo Writer, c.-à-d. graphiques, cadres de texte et objets OLE. Beaucoup des options disponibles pour les cadres le seront également pour les objets . De même, l'interface utilisateur sera unifiée pour les deux styles d'objet.

Puces et numérotation

L'interopérabilité des puces et de la numérotation - le troisième domaine principal mentionné ci-dessus - sera également obtenue par de multiples petits perfectionnements. Les retraits négatifs seront supportés et il sera possible de changer les valeurs de retraits pour chaque paragraphe individuellement. Il sera possible de placer des tabulations dans les nombres. Enfin, le calcul des numéros de chapitre et la table des matières seront améliorés.

Espacement

Le quatrième domaine important pour l'amélioration peut être résumé par le mot « espacement ». Bien que les différences soient très minimes (typiquement moins de la moitié d'un point) et qu'elles soient à peine notées par l'utilisateur, le résultat final serait qu'une page importée contienne deux lignes de texte de moins sur une page SO/OOo Writer. Ceci peut également avoir comme conséquence que les images et les cadres de texte apparaissent sur des pages différentes, le document peut alors prendre une apparence complètement différente sous SO/OOo Writer

4.1.1.2 SO/OOo Calc

La plupart des problèmes d'interopérabilité entre Microsoft Excel et SO/OOo Calc qui subsistent aujourd'hui résultent d'un ensemble de fonctions incompatibles. La plus grande avancée dans l'interopérabilité sera réalisée par l'ajout de nouvelles fonctions dans Calc et le changement d'autres existantes.

Rompre la limite du nombre ligne

Actuellement, 32 000 est le nombre maximum de lignes d'une feuille Calc. Le contenu des cellules au delà de la ligne 32 000 est perdu si un fichier contenant un nombre de lignes supérieur est importé dans SO/OOo. Si plus de 32 000 lignes sont nécessaires pour une feuille spécifique, il n'y a aucune manière d'obtenir facilement des résultats équivalents en utilisant seulement les 32 000 lignes de SO/OOo. Il nous est donc apparu important d'augmenter ce nombre de lignes. Celui-ci sera donc augmenté jusqu'à 65 536 pour une feuille de calcul, avec la possibilité de permettre un accroissement ultérieur sur des versions futures.

Calcul

La deuxième question importante est le calcul. Bien que l'ensemble des fonctions de formules soit très semblable à travers la plupart des applications de tableur, quelques fonctions spéciales de calcul ne sont pas supportées par SO/OOo. Actuellement, lorsque des documents qui utilisent ces fonctionnalités additionnelles sont ouverts dans SO/OOo, les cellules montreront des valeurs d'erreur ou même des résultats différents de ceux produits par le document original. Pour obtenir les mêmes résultats que dans l'original, la feuille de calcul devra être modifiée manuellement. Particulièrement dans le cas de formules matricielles, les modifications exigées seraient assez importantes, rendant difficile la création d'un calcul équivalent sous SO/OOo. Nous avons identifié un ensemble de fonctions qui posent des problèmes. Elles seront modifiées dans "Q".

Contrôle de formulaire

Une autre fonctionnalité importante qui sera ajoutée à SO/OOo est la capacité de créer des contrôles de formulaire (listes, boîtes de contrôle, etc...) qui seront connectés aux feuilles de calcul. Ces contrôles obtiennent leurs valeurs à partir des cellules, et mettent à jour les cellules en fonction de la sélection. Avec la flexibilité accrue nécessitée par l'affichage de nouvelles fonctionnalités de formulaire, nous pourrons mettre en application également cette connexion aux cellules de feuille de calculs.

Attributs de cellule

SO/OOo supporte des attributs légèrement différents de cellules par rapport à des applications concurrentes. Ceci conduit à des différences dans l'aspect ou le comportement des documents importés contenant ces attributs. Nous ajouterons des fonctions correspondantes à SO/OOo pour éliminer les différences dans les documents importés. Nous prolongerons les fonctions, les annotations, les scénarios, les plages et les hyperliens, ainsi quelques attributs de formatage de cellules.

Pilote de données

Actuellement, la fonction de base et l'interopérabilité sont assurées par le pilote de données SO/OOo. Dans « Q », nous prolongerons le pilote de données pour l'adapter au dernier cri en matière de rapports basés sur les données des feuilles de calcul. Les plus importantes de ces fonctions sont les champs de page, le formatage des champs et d'éléments individuels, et les options de formatage de table.

Tri

Enfin, il est commun parmi les applications concurrentes de conserver le plus possible l'ordre de tri original lorsque l'on tri une feuille de calcul en fonction de certains critères. Dans SO/OOo, ils finissent dans un ordre aléatoire. Nous pouvons changer l'ordre d'exécution de façon à ce que l'ordre original soit préservé lorsque les critères de tri sont égaux.

4.1.1.3 SO/OOo Impress

« Geordi » a amélioré l'interopérabilité avec Microsoft PowerPoint sous beaucoup d'aspects. Pour aller encore plus loin dans l'interopérabilité des fonctions, de nouvelles fonctions doivent être ajoutées à l'application et à la couche de dessin.

Intégration d'effets

Le système courant d'animation de SO/OOo Impress supporte un effet par forme avec tous les types d'effets mis en application individuellement. L'exécution de tous les effets se fait automatiquement ou manuellement par diapo. La demande des utilisateurs est d'avoir un ensemble équivalent d'effets et de préserver l'ordre de l'exécution des effets lors des échanges de présentations entre SO/OOo Impress et les applications non-SO/OOo.

Au lieu de mettre en application manuellement chaque nouvel effet, il est nécessaire de supporter un noyau d'animation qui soit flexible et permette de manipuler de nouveaux effets qui puissent être ajoutés par la suite. La première étape est d'ajouter un composant au noyau qui puisse entièrement charger et stocker des effets d'une application autre que SO/OOo pour une amélioration de l'interopérabilité. En raison d'une demande élevée au niveau hardware pour supporter ce rendu, cette première étape ne sera pas visuellement reproduite pour tous les effets. En outre, jouer les effets en temps réel ne sera pas résolu par ceci.

Temporisation

Pour soutenir le concept de temporisation, il y aura une fonctionnalité de temporisation pour SO/OOo Impress. Avec cette temporisation, l'interopérabilité sera accrue en préservant l'ordre et la synchronisation lors de l'exécution des effets de forme. Les utilisateurs pourront ajouter plus d'un effet à chaque forme et pourront avoir des effets qui soient partiellement automatiques ou en partie déclenchés par un clic de souris. Il y aura également une interface utilisateur permettant de définir les nouvelles fonctions de temporisation et d'effet.

« Q » fournira également un raccourci, permettant à l'utilisateur de choisir un thème d'animation par diapo, de sorte que les effets de diapos et de formes soient automatiquement adaptés au thème choisi.

Collaboration

L'interopérabilité avec d'autres logiciels de présentation, y compris Microsoft PowerPoint, sera améliorée en ajoutant la possibilité d'inclure des notes comme les commentaires dans Impress. Actuellement, lors de l'import, SO/OOo Impress ignore cette information. Cette amélioration augmentera l'interopérabilité en préservant le contenu du document et en donnant, aux utilisateurs de SO/OOo Impress qui ont ce besoin d'interopérabilité avec d'autres applications, la capacité d'échanger des commentaires sur leur travail.

En-têtes et pieds de page

Parfois les en-têtes et les pieds de page Impress disparaissent des diapos lors d'un export/import de Microsoft PowePoint à SO/OOo. La raison en est que les en-têtes et les pieds de page sont interprétés différemment dans Microsoft PowerPoint et SO/OOo Impress. La méthode de SO/OOo Impress pour l'utilisation des en-têtes et des pieds de page est beaucoup plus flexible que celle de Microsoft PowerPoint.

Pour répondre à cette exigence et pour faciliter l'utilisation, SO/OOo Impress fournira un accès facilité aux en-têtes et pieds de page. Ceci augmentera non seulement l'interopérabilité en gardant l'information d'en-tête et de pied de page persistante, mais fournira également à l'utilisateur une interface plus facile pour les créer dans SO/OOo Impress. Il y aura également une boîte dialogue facile à utiliser pour changer l'en-tête et le pied de page pour la page courante ou pour toutes les pages.

Formes de dessins étendues

Souvent des formes de dessins telles que les formes automatiques de Microsoft PowerPoint, sont présentes dans des applications concurrentes de présentation. Elles permettent d'ajouter facilement des schémas aux présentations. Par conséquent un ensemble de formes prédéfinies de différentes catégories comme des 'connecteurs', 'des organigrammes', des 'étoiles et des bannières, 'des légendes' et des 'boutons d'action' seront fournis.

Par exemple, dans la version en cours de SO/OOo, les documents importés de Microsoft Office qui contiennent des formes automatiques sont la plupart du temps affichés correctement. Il n'existe pas, cependant, la possibilité d'éditer des objets WordArt ou de modifier des objets 3D. Échanger des documents entre SO/OOo et Microsoft Office mène à la perte de fonctionnalité de ces objets de dessin.

Pour répondre à cette exigence, une implémentation étendue pour les objets de dessin dans SO/OOo sera conçue, y compris de nouvelles boîtes de dialogues pour éditer les objets WordArt importés et pour modifier les objets 3D importés. Ceci augmentera non seulement l'interopérabilité au travers du support de toutes les formes automatiques Microsoft Office, mais les rendra entièrement éditable et permettra aux utilisateurs SO/OOo Impress de créer eux-mêmes des fonctionnalités de dessin équivalents.

4.1.1.4 SO/OOo Base de données (Formulaires)

Une des normes d'évolution pour les applications de saisie de données est XForms W3C. Des commandes XForm peuvent être incluses dans n'importe quel format de fichier basé sur le XML comme le XHTML, et elles supportent les entrées de données supplémentaires basées sur le schéma XML. Il est probable que XForms remplace au moins des formes de HTML/HTTP dans un futur proche. En ajoutant le support XForms à SO/OOo, nous suivrons non seulement la tendance des développements récents, mais en combinaison avec le format de fichier XML OpenOffice OASIS, ce devient également une alternative puissante à XHTML/XForms. Ce qui rend intéressant le fait d'employer le XML OpenOffice OASIS et SO/OOo basé sur XForms comme client d'entrée de données, est qu'il offre beaucoup plus de possibilités d'affichage que les clients basés sur XHTML/XForms, et emploie exactement les mêmes protocoles ouverts que les clients basés sur XHTML/XForms du côté de serveur. D'ailleurs, puisque SO/OOo est également un outil puissant pour créer des formulaires, même la création de formulaire devient plus facile et n'exige pas d'outils additionnels.

Si XForms représente déjà une amélioration pour des applications de saisie de données, il est imaginable que les applications de saisie de données s'amélioreront encore. Dans certaines des applications récemment développées, la saisie de données n'est pas limitée par les contrôles classiques de formulaire, mais des textes arbitraires ou tout autre contenu peut être inclus dans les formulaires de données. De plus, quelques applications ont la capacité d'étendre les formulaires au temps d'exécution. Par exemple, le procès-verbal de réunion, où un point de l'ordre du jour pourrait être reproduit chaque fois. Ces possibilités permettent d'employer des applications de saisie de données non seulement pour les formulaires statiques et simples, mais également sous des formes plus complexes telles que des minutes, des factures ou des lettres. De toute façon, les données réelles du formulaire resteront dans un schéma XML. Ce schéma pourrait être un schéma défini par l'utilisateur ou un schéma normalisé par des organismes comme OASIS. Dans d'autres catégories, il y a les schémas UBL qui sont actuellement développés par un comité technique d'OASIS.

Dans de tels scénarios, l'utilisateur crée de nouveaux documents basés sur des modèles de documents existants. Dans le nouveau document, des données peuvent être saisies seulement aux endroits prédéfinis, par exemple dans certains champs, contrôles ou cadres de texte. D'ailleurs seulement très peu de fonctions d'édition seront disponibles. Par exemple, des sections de texte pourraient être reproduites, mais non insérées à n'importe quel endroit. De cette façon, on peut s'assurer que le document a toujours une structure définie. Ceci permet encore de lier chaque donnée éditable aux éléments d'un schéma XML et de les soumettre ainsi comme des données de formulaire XML.

Les possibilités de SO/OOo pour une telle forme de flux de travail seront améliorées. Le point de départ réside dans le perfectionnement de XForm décrit ci-dessus. D'autres étapes permettront par exemple l'inclusion de champ ou le contenu de paragraphe dans un formulaire de données XML et la possibilité de saisir des données dans Writer en mode lecture seule. Les possibilités pour spécifier le comportement de l'application à travers les modèles seront améliorées. Enfin, certaines opérations d'édition complexes seront permises, comme reproduire une section en mode lecture seule dans Writer. En ajoutant des capacités de saisie de données à SO/OOo point par point, de plus en plus de flux de travail peuvent être implémentés avec SO/OOo.

SO/OOo améliorera également son interopérabilité avec les fonctions de formulaire de Microsoft Office, en particulier de Microsoft Word. Microsoft Word comporte deux concepts complètement différents pour les fonctions de formulaire : les champs de formulaire et les contrôles de champs. Les champs de formulaire sont d'un concept plus ancien et ne sont pas supportés par « Geordi », mais néanmoins sont fréquemment employés par des utilisateurs de Microsoft Word. SO/OOo corrigera cela en mettant en application des équivalents pour ces champs de formulaire.

Les contrôles de formulaires offrent une fonctionnalité semblable à ceux de SO/OOo. Pour « Q », nous mettrons en application certains types de contrôle nouveaux comme des barres défilantes, des boutons à bascule, et un contrôle de texte enrichi, et augmenterons les types de contrôles existants avec des fonctions non présentes actuellement, par exemple des listes déroulantes multi-colonnes, et la correction orthographique dans des contrôles de texte.

4.1.1.5 SO/OOo Diagramme

Des capacités supplémentaires seront ajoutées au noyau de diagramme. Elles permettront de corriger des bugs ainsi que l'intégration de nouvelles fonctionnalités.

La fonction la plus importante qui sera ajoutée permettra à des séries de données d'être entrées à partir de différentes plages de cellules pour des valeurs x, des valeurs y, des étiquettes, etc... Sans cela, certains imports de feuilles de calcul non SO/OOo ne produisent qu'un résultat vide. Techniquement, ceci exige de nouvelles interfaces pour la communication entre le diagramme de SO/OOo et SO/OOo Calc ou SO/OOo Writer. De plus, le concept de base de données dans les diagrammes de SO/OOo doit être remodelé complètement.

Quelques nouveaux types de diagramme doivent également être intégrés – notamment des diagrammes à bulles et à surfaces. Un diagramme à bulles exige une plage d'entrée additionnelle pour la taille des bulles. Dans la mesure où cette plage d'entrée additionnelle ne s'adapte pas à la structure de la source de base de données, le nouveau concept de base de données mentionné ci-dessus est un pré requis pour permettre l'utilisation de diagrammes à bulles.

D'ailleurs, l'intégration d'un nouveau type de diagramme dans le vieux noyau de diagramme de SO/OOo pourrait compromettre la fonctionnalité existante, dans la mesure où le type de code dépendant des diagrammes est réparti sur le projet entier. Pour éliminer ce problème fondamental, un nouveau noyau de diagramme SO/OOo encapsulera le code dépendant du type de diagramme dans un composant UNO séparé, avec des interfaces bien définies.

La réimplémentation du noyau de diagramme de SO/OOo est une tâche nécessaire et longue qui doit être achevée avant que n'importe quel nouveau dispositif requis puisse être mis en oeuvre. Nous pensons que la réimplémentation de cette fonctionnalité prendra au moins jusqu'à la fin de l'année civile.

Les fonctions absentes permettant l'interopérabilité avec des applications concurrentielles comprennent :

flexibilité de la sélection de la plage source pour différentes séries de données (valeurs x, valeurs y, étiquettes etc...),

flexibilité de combinaison de diagrammes différents (la plupart du temps diagrammes en ligne et en barre),

un positionnement libre des étiquettes sur les points du nuage (souvent demandé pour les diagrammes circulaires),

formater les étiquettes des points d'après la cellule correspondante dans Calc,

éclater les segments 3D d'un diagramme camembert (souvent demandé),

apparence pseudo 3d des segments (ce type de diagramme 3d est souvent employé dans les magasines),

diagrammes à bulles,

diagrammes à surfaces,

légendes plus flexibles (redimensionnable, possibilité d'enlever des entrées),

Contenu quelconque pour les étiquettes des points du nuage,

X error bars (NDT : je n'ai pas réussi à le traduire)

diagrammes en radar,

retirer le segment à la périphérie d'un diagramme 2D en anneau.

L'ordre des articles reflète la priorisation proposée. Les priorités les plus élevées sont accordées à ces fonctions absentes et qui causent la plus grande perte de l'information alors qu'elles sont souvent employées.

4.1.2 Utilisation

(Matthias Mueller-Prove, Mai 2003)

4.1.2.1 Structure des menus

La nouvelle conception de la structure des menus tiendra compte des concepts généraux des applications concurrentes. Deux exemples remarquables des changements intervenant dans les menus de « Q » sont l'organisation des options du menu Affichage et un nouveau menu Tableau pour Writer.

4.1.2.2 Barre d'outils

L'interface utilisateur des barres d'outils sera complètement remodelée. « Q » prévoit des petites barres d'outils qui peuvent être réorganisées à l'aide d'un glisser/déposer. La nouvelle conception gère mieux l'espace écran en l'employant plus efficacement. L'échange dynamique du contenu des barres d'outils sera supprimé.

4.1.2.3 Terminologie

La terminologie utilisée dans l'interface utilisateur pour les menus, les boîtes de dialogues importantes, les messages d'alerte sera mise à jour afin d'utiliser la connaissance existante des utilisateurs de suite bureautiques.

4.1.2.4 Affichage des fenêtres

Impress aura une nouvelle fenêtre qui offrira un panneau d'outils pour SO/OOo. Ce panneau d'outils comportera des commandes spécifiques pour permettre à l'utilisateur d'éditer et de modifier facilement ses diapos, d'importer des styles et des diapos à partir d'autres fichiers et les activer dans la présentation.

4.1.2.5 Séparations des applications

Pour les utilisateurs, « Q » ressemblera plus à des applications séparées. Le menu d'ouverture de Microsoft Windows/panneau de bureau de Linux, les menus « Fichier » et « Fenêtre »de SO/OOo, les titres de fenêtre de document, et les options de boîtes de dialogue refléteront ce changement. Avec ce nouveau concept nous éliminerons les paramétrages désuets des options des boîtes de dialogue et indiquerons clairement quels paramétrages ont des effets dans quelle partie de l'application.

4.1.2.6 Interaction Générale

Le modèle d'interaction pour les textes, les tableaux et les images dans Writer et pour des objets dans Draw et Impress mettra en application des techniques dernier cri.

Pour « Q » nous mettrons à jour les concepts d'interaction pour des tâches composées comme la fusion (publipostage) de courriers et la création de diagrammes.

Enfin, l'amélioration de la fonction Annuler (undo) augmentera de manière significative la robustesse du produit.

4.1.2.7 Usage de l'application de base de données

(Frank Schoenheit, Mai 2003)

Actuellement, la fonction d'accès aux bases de données (DBA) dans SO/OOo montre des différences diverses par rapport à d'autres applications de base de données. Ces différences peuvent être réparties en deux groupes : rentabilité et interopérabilité. Elles sont prédominantes lorsque les utilisateurs ne peuvent localiser la fonctionnalité dont ils ont besoin (alors que souvent elle est présente). Ils se sentent alors mal à l'aise avec l'interface utilisateur de SO/OOo qui suit une philosophie différente dans ce secteur.

De plus, disposer d'une application concurrentielle de base de données, au lieu d'un ensemble de composants d'accès aux bases de données, est clairement une fonctionnalité importante pour les utilisateurs et les clients potentiels.

Nous répondrons à ceci par une nouvelle conception de l'application de base de données dans SO/OOo. En premier lieu, cela lui permettra d'être reconnue comme application de base de données orientée utilisateur, et permettra à d'anciens utilisateurs d'autres produits de base de données, comme Microsoft Access, de se sentir plus à l'aise. Dans un second temps, elle répondra à la plupart des problèmes que les clients rencontrent avec l'interface utilisateur courante.

Une nouvelle application de base de données

Le DBA de SO/OOo (avec un nouveau nom qui doit être discuté) sera une application indépendante au lieu d'être cachée à travers les documents Writer, CALC ou Impress. Elle sera alors perçue comme une application concurrentielle de base de données, qui sera égale aux autres applications principales dans SO/OOo.

Cette nouvelle application sera accessible à partir du menu principal. Fichier | Nouveau est l'endroit où les utilisateurs se rendent pour créer une nouvelle base de données, ainsi nous ajouterons une option de base de données, qui ouvre l'application et offre à l'utilisateur un ensemble raisonnable de choix sur la façon de procéder (par exemple créer une base de données dBase, se connecter à une base de données externe existante par l'intermédiaire d'un autopilote).

Nous n'abandonnerons pas le concept de sources de données. Ce, non seulement pour des raisons pratiques (un moteur de base de données est un projet très lourd), mais également pour des raisons d'ouverture : nous poursuivons la philosophie de SO/OOo qui est de permettre à l'utilisateur de travailler avec toute base de données qui est déjà présente dans son environnement de travail, depuis les bases de données côté client simple utilisateur basées sur un système de fichiers jusqu'aux bases de données côté serveur participant à un flux de travail collaboratif.

La disposition et l'interface utilisateur de cette nouvelle application, au premier regard, apparaîtront comme relativement semblables à ce que les utilisateurs typiques d'applications de base de données connaissent déjà. Là où cela aura un sens, l'application fournira une apparence (look & feel), comprenant des concepts fonctionnels intuitifs.

Dans la mesure où cela sera une nouvelle application d'accès aux bases de données, nous lui donnerons sa propre entrée dans le système d'aide de SO/OOo. Ceci permettra à l'utilisateur de trouver l'aide requise pour les bases de données. La boîte de dialogue courante d'administration de sources de données, et de grandes parties du navigateur courant de sources de données, seront fusionnées dans la nouvelle application, fournissant un seul point d'entrée pour la fonction de base de données dans SO/OOo

Sources de données

Nous réimplémenterons l'interface utilisateur du DBA de SO/OOo. Nous nous éloignerons de l'interface utilisateur courante orientée technicien pour allers vers un flux de travail et une terminologie orientée utilisateur.

En outre, plusieurs mesures seront prises pour faire que le concept de sources de données se rapproche davantage du concept de base de données auquel l'utilisateur est habitué lorsqu'il vient d'une autre suite bureautique. Bien que les concepts fondamentaux ne soient pas modifiés, les utilisateurs de SO/OOo auront alors moins de problèmes lorsqu'ils migreront d'autres applications de base de données.

Nous modifierons la manière d'administrer les sources de données SO/OOo - nous mettrons l'accent sur la rencontre avec le vocabulaire conceptuel de l'utilisateur, en créant une interface utilisateur plus intuitive, et en exposant la plupart des détails techniques aux utilisateurs avancés seulement.

Un pilote automatique sera créé qui permettra l'import/export des sources de données (basé sur les fichiers) et la migration entre les installations. Ceci soulagera non seulement l'utilisateur du travail manuel qui est actuellement exigé, mais soutient également l'impression d'une base de données en opposition à une source de données que l'utilisateur ne peut pas vraiment manipuler.

Formulaires

Les formulaires permettent une importante personnalisation des données émanant de base de données, ainsi ils constituent le choix premier de l'utilisateur lorsqu'il travaille de telles données.

L'amélioration principale souhaitée par les utilisateurs de SO/OOo dans le secteur des formulaires est la rentabilité. Ainsi, nous effectuerons des changements affectant l'interface utilisateur de SO/OOo de différentes manières. L'utilisateur identifiera les formulaires de SO/OOo (qui couvre la conception de formulaire comme leur utilisation) comme solution consacrée, à l'opposé de la situation actuelle, où la fonction de formulaire est identifiée comme un petit add-on caché au travers des documents textes de SO/OOo.

Cette liste s'étend à des petites modifications, et plutôt cosmétiques, qui aboutiront à une bien meilleure expérience des utilisateurs, à de plus grands projets tels qu'un mode simple dédié au navigateur de propriété, qui se compose de vues spécialisées pour les différents types d'objet, et présente à l'utilisateur seulement les aspects le plus souvent utilisés de ces objets, exposant ainsi la pleine puissance du navigateur de propriété uniquement aux utilisateurs avancés.

De plus, des perfectionnements de fonctionnalités seront appliqués aux formulaires de SO/OOo. Seront incluses ici, les fonctionnalités de contrôles de formulaire qui sont exigées dans le chapitre d'interopérabilité avec Microsoft, mais également de nouvelles réalisations (telles que des commandes de filtre en temps réel) qui rapprocheront SO/OOo des exigences actuelles.

Tâches courantes

Nous fournirons à l'utilisateur plus de pilotes automatiques pour les tâches les plus courantes dans le secteur de bases de données, et améliorerons respectivement les pilotes automatiques existants. Dans « Q »SO/OOo, nous disposerons d'une fonction de rapport améliorée et d'un pilote automatique de formulaire, ainsi que de nouveaux pilotes pour concevoir de nouvelles tables, et concevoir des questionnaires adaptés aux besoins du client comme les vues de données.

4.1.3 Performances

(Matthias Huetsch, Mai 2003)

4.1.3.1 Temps au démarrage

L'amélioration des performances la plus évidente de SO/OOo sera la diminution substantielle du temps requis pour le premier démarrage, en particulier quand le système n'a pas été appelé pendant un certain temps ou après une réinitialisation du système. La première amélioration du temps de démarrage correspondra au temps employé par des applications concurrentes.

Généralement, la diminution du temps au démarrage sera améliorée en retravaillant le code et en supprimant les interdépendances fortes entre :

Le noyau de l'application, l'interface utilisateur et le code du filtre

le code d'application et le code de l'interface générale utilisateur se répartissent dans plusieurs bibliothèques partagées

le code d'application et le code de l'aide d'accessibilité se répartissent dans plusieurs bibliothèques partagées

plusieurs importantes bibliothèques partagées restent liées en raison de l'utilisation d'un modèle global d'initialisation

En association, cette action de retravail aboutira au chargement d'un cadre relativement léger en plus des codes de filtres nécessaires au document lors du démarrage, et non seulement, réduira le temps de démarrage, aussi bien que la consommation de mémoire initiale.

4.1.3.2 Temps d'ouverture et d'enregistrement des documents

La deuxième amélioration évidente des performances de SO/OOo consistera en une diminution du temps nécessaire à l'ouverture et à l'enregistrement de documents importants, en particulier pour des documents au format natif XML. Ce gain de temps sera comparable aux applications concurrentes.

SO/OOo mettra en application ce gain de temps par le perfectionnement des APIs SO/OOo qui sont optimisées pour l'import/export XML et sont pleinement supportées par les implémentations internes de l'application. Les optimisations du code au travers de la chaîne entière de la composante import/export seront évaluées pour identifier et éliminer des goulots d'étranglement.

Temps réponse

« Q » accélérera l'affichage graphique et diminuera le temps de réponse dans le rendu des objets de dessin complexes. Cette amélioration sera réalisée par une nouvelle conception du kit d'outils graphiques, en ajoutant par exemple, le support de matériel d'accélération moderne, et du moteur de présentation, en se servant du double-buffering et d'autres techniques de cache.

4.1.3.3 Déploiement

Les déploiements multi-utilisateurs à grande échelle dans lesquels probablement des centaines d'instances de SO/OOo fonctionnent sur un serveur à simple multiprocesseur seront améliorés au delà de ce que « Geordi » sait déjà faire. Les questions de variabilité peuvent être récapitulées et abordées comme suit :

Charge système

Un nombre important de swich contextuels par seconde est provoqué par des instances de Ooo/So rapportant temporairement les contrôles à d'autres processus ou fils. Ce comportement induit une charge élevée sur le planificateur du système, et peut aussi bien compromettre la réponse de SO/OOo elle-même.

Cela sera résolu en abandonnant le concept actuel basé sur l'interrogation coopérative et temporisée en faveur d'un concept conduit par la prévention et l'événementiel.

Consommation mémoire

La quantité de mémoire non partagée par les processus SO/OOo détermine pour une grande part le nombre d'instances qui peuvent tourner simultanément sur un serveur donné.

Ceci sera réglé en réduisant la taille des segments de données inscriptibles dans les bibliothèques partagées et des allocateurs spéciaux de mémoire pour le stockage de masse compacte d'objets.

4.1.4 Programmabilité

4.1.4.1 Amélioration des APIs UNO/Office

(Stephan Bergmann, Daniel Boelzle, Kai Sommerfeld, Mai 2003)

L'interface API UNO s'intègre finement. Bien que cela offre une flexibilité maximum, les programmeurs préfèrent souvent avoir des interfaces UNO de haut niveau simplifiées. Ceci permet le développement rapide d'applications et aide même les développeurs qui ont de moindres compétences à atteindre leurs buts rapidement. Pour répondre à ce problème, nous devons fournir un nouvel ensemble de services de haut niveau adapté à UNO.

UNO définit des concepts de langages indépendants comme des services, des interfaces ou n'importe quel type de données. Le lien vers ces langages concrets rejoint toujours ces concepts de manière univoque. Ce n'est pas toujours optimum parce qu'il peut exiger du développeur l'apprentissage de constructions qui sont peu communes ou même étranges pour un certain langage de programmation. Un exemple populaire est l'appel de queryInterface, qui devrait être un simple cast en Java. Pour la prochaine version, nous fournirons de nouvelles fonctionnalités UNO qui simplifieront son utilisation générale ou encore le lien vers des langages particuliers.

4.1.4.2 IDE intégré pour de multiples langages de script.

(Thomas Benisch, Mai 2003)

Avec le scripting framework indépendant du langage, il sera possible d'exécuter un script SO/OOo en n'importe quel langage de script supporté. Ceci pointe le besoin d'un IDE de script léger, qui soit intégré dans SO/OOo et supporte des langages de script multiples incluant le BASIC SO/OOo, Java et le Javascript.

L'IDE de script sera basé sur un concept obligatoirement indépendant du langage. Un langage de script peut seulement être intégré dans l'IDE, si les interfaces correspondantes sont supportées par le scripting runtime.

Nous planifions que le Basic IDE et sa boîte de dialogue d'édition seront retravaillés et modularisés, et qu'ils deviendront la base du nouvel IDE de script.

4.1.4.3 Type de cycle de vie

(Daniel Boelzle, Mai 2003)

Le modèle objets UNO supportant différents langages gagne en popularité. UNO prépare le terrain pour accéder aux APIs SO/OOo et le développement d'extension par des développeurs de parties tierces.

Ainsi les développeurs doivent faire face à certains problèmes quant à l'utilisation et l'introduction des types UNO. Si cela est faisable, il est souhaitable que les types UNO aient un cycle de vie contrôlé.

4.1.4.4 Pont .NET

(Joachim Lingner, Mai 2003)

SO/OOo utilise des logiciels ponts afin d'avoir accès à des parties de code, qui peuvent être soumis pour certains langages - à des conditions et à des restrictions spécifiques d'exécution, interactifs l'un avec l'autre. Par exemple, le code Java ou le code C++ ne peuvent agir l'un avec l'autre naturellement. Il en va de même pour le code C++ compilé avec différents compilateurs.

Toutes ces conditions particulières à une partie de code font référence à un environnement et il est dit qu'une partie de code vit (ou s'exécute) dans un environnement. Maintenant, pour qu'un code puisse avoir accès à un autre environnement, on doit réaliser un pont. En raison de la multitude de combinaisons possibles des environnements, les ponts emploient un environnement intermédiaire, à savoir l'environnement UNO.

Si un nouveau compilateur doit être employé ou un nouveau logiciel écrit dans un nouveau langage, le seul besoin est alors de créer un pont entre l'environnement UNO et tous les autres environnements pour lesquels il y a également un pont UNO qui permet d'interagir avec le nouvel environnement.

Le pont CLI-UNO permet à des programmeurs de se servir des langages qui produisent le code compatible CLI (infrastructure de langage commun). Ceci inclut des langues comme C #, C++, .NET et Visual Basic.NET

4.1.4.5 Déploiement et Interface générale utilisateur

(Daniel Boelzle, Mai 2003)

Le développement d'extensions tierces pour OpenOffice.org utilisant l'API OpenOffice.org gagne en popularité. L'outil commun pour déployer ces extensions dans une installation bureautique est pkgchk. L'utilisateur appelle l'outil de déploiement pkgchk indiquant un package à installer. L'outil balaye alors le contenu du fichier et manipule les différents types contenus en fonction de leurs extensions :

Librairies partagées UNO (.dll, fichiers .so)

composants Java UNO (fichiers .jar)

composants Python (fichiers .py)

fichiers typelibrary UNO (fichiers .rdb)

scripts et dialogues SO/OOo Basic (fichiers script.xlb et dialog.xlb)

schéma et données de configuration (fichiers .xcs et .xcu)

Actuellement les utilisateurs doivent arrêter le process courant avant d'exécuter l'outil de déploiement pkgchk ajoutant ou enlevant des paquets. Il serait souhaitable que les utilisateurs puissent déployer des paquets tout en continuant d'exécuter leur process avec déplacement de déclenchement des paquets existants. D'ailleurs, l'outil de déploiement pkgchk actuellement utilisé est une ligne de commande. Si le déploiement peut être effectué tout en exécutant le process, une interface utilisateur appropriée serait intéressante (par exemple une barre de menu).

La nécessité d'arrêter le process dans le cas d'une installation partagée est encore plus mauvaise, par exemple imaginons une installation partagée par mille utilisateurs, avant que quelque chose puisse être déployé dans cette installation partagée, on doit s'être assuré que chaque process courant commencé hors de cette installation a été terminé. Autrement cette instance risque de travailler avec des données contradictoires, qui peuvent mener à la perte de données ou à un crash.

Différents types de contenus sont déployés différemment. Ainsi les problèmes qui se produisent sur l'insertion/suppression d'un paquet ont un temps d'exécution différent.

4.1.4.6 Scripting Framework

(Noel Power, April 2003)

Actuellement le support de script de SO/OOo existe pour un langage seulement, le Basic SO/OOo. Les utilisateurs, les développeurs et les fournisseurs indépendants de logiciels qui souhaitent prolonger SO/OOo en utilisant les scripts sont bloqués par cette offre unique.

Il serait avantageux du point de vue stratégique de supporter Java et des dérivés de Java tels que le Javascript et le BeanShell. D'autres langages de script tels que Python pourraient également être ajoutés suivant ce que dicte le marché.

Un cadre (framework) est nécessaire pour permettre à de nouveaux langages de script d'être ajoutés et supportés. Il devrait être possible d'exécuter facilement d'autres langages. Le Framework doit fournir un environnement pour permettre aux utilisateurs de facilement et rapidement développer, déployer et exécuter des scripts. Exécuter un script devrait être facile. Un développeur de scripts devrait pouvoir écrire et examiner un script à travers un ensemble minimal d'étapes. Il devrait pouvoir expérimenter et apprendre dans l'environnement de script, icelui lui permettant d'exécuter ses scripts facilement et rapidement.

L'exécution de scripts dans SO/OOo sera facilitée, plus intuitive et d'un coût réduit. C'est principalement dû à la complexité et au bas niveau de l'API SO/OOo courante. Afin de permettre l'exécution de scripts de façon aisée, intuitive et à coût réduit, l'API SO/OOo doit être simplifiée. Une API si simplifiée devra être bien documentée, focalisée sur les scripts et d'un niveau élevé. Ceci permettra aux utilisateurs de découvrir intuitivement les objets et interfaces nécessaires pour programmer une tâche spécifique plutôt que de devoir travailler sur une montagne de documentation.

4.1.5 Intégration dans l'environnement de bureau Gnome, et Microsoft Windows

(Christof Pintaske, Juin 2003)

Les exigences nécessaires à l'intégration dans Microsoft Windows seront déterminées ultérieurement.

4.1.5.1 Look and Feel

« Geordi » émule le système de couleurs et le système de base de polices de l'environnement de bureau Gnome-2.x. « Q » doit collecter le modèle de tous les éléments de base (boutons, barres de défilement, texte fixe, case à cocher et ainsi de suite) de façon à refléter exactement le thème courant de widget GTK. La majorité des dialogues ne devrait montrer aucune différence évidente par rapport à un dialogue mis en application dans l'ensemble widget GTK. Le focus, la modalité, et les guides pour le placement des widget ne seront pas adaptés.

« Geordi » utilise un moteur propriétaire pour installer, appeler, et choisir des polices. Les noms des polices système peuvent être invalides dans SO/OOo, ou se rapporter à une police complètement différente et vice versa. Le schéma de manipulation des polices de « Q » doit être cohérent avec l'environnement de bureau et les applications principales. Le nom des polices embarquées avec « Geordi » ou les versions plus anciennes de SO/OOo ne doit pas changer. Les paramètres explicites pour le remplacement de polices doivent demeurer intact également

Ceci sera résolu en utilisant la configuration de police système (Fontconfig2). Agir ainsi sera salutaire également pour les performances au démarrage, « Q » n'aura alors pas besoin d'examiner les polices lors du démarrage.

« Geordi » emploie un mélange de X11/cursorfont mouse pointer, le pointeur spécifiquement conçu pour SO/OOo, et des pointeurs qui sont semblables à ceux trouvés sur d'autres plateformes, comme Microsoft Windows. C'est contradictoire avec d'autres applications de l'environnement bureau Gnome et cela empêche les paramétrages appropriés des pointeurs pour des thèmes de bureau accessibles (paramétrages de grands curseurs, thèmes de contraste élevé...). « Q » devrait utiliser les curseurs conformes de Gnome le cas échéant.

Le paramétrage de Hotkey/Accelerator devrait être aligné avec l'environnement de bureau Gnome. Les tâches communes devraient se refléter dans des clefs égales. Des clefs déjà utilisées par le window manager ne devraient pas être offertes ou employées pour lier les applications.

Il serait bien d'avoir des méthodes d'entrée Gnome disponibles dans SO/OOo (actuellement sont seulement disponibles Gnome-edit et Gnome-terminal).

4.1.5.2 Impression

« Q » doit pouvoir fournir la même expérience pour l'impression que celle de « Geordi » sans avoir besoin des fonctionnalités de configuration propre à l'imprimante, ni des données de configuration de l'imprimante dans l'environnement Gnome. Il pourra par la suite posséder sa propre interface utilisateur pour le système de configuration si l'interface utilisateur système est insuffisante ou encore inutilisable.

Le système CUPS encapsule et fournit un accès à l'imprimante connectée localement, et l'imprimante distante est consultée par IPP, LPD, SMB et beaucoup d'autres protocoles.

CUPS fournit une couche qui permet à « Geordi » de choisir à partir de toutes les imprimantes, et d'imprimer également, configurées à travers CUPS. Cependant « Q » sera amélioré pour questionner les capacités des imprimantes à travers CUPS et pour se conformer aux paramètres de configuration CUPS, rendant de ce fait l'outil d'administration propriétaire de SO/OOo obsolète et se mettant en accord avec les solutions systèmes.

Actuellement il n'y a aucun système d'impression disponible. S'il y avait une interface utilisateur partagée disponible dans le laps de temps de développement de « Q » il devrait être intégré au lieu de mettre en application une interface utilisateur propriétaire..

4.1.5.3 Intégration de voisinage réseau

"Q" doit pouvoir charger et stocker des dossiers sur des partages SMB pour tenir compte de l'interopérabilité dans un réseau d'ordinateurs Microsoft Windows. L'interface utilisateur doit être étendue pour permettre un accès à cette fonctionnalité. Il est prévu de pouvoir manipuler toutes les URLs qui sont valides dans le gestionnaire de fichiers Gnome (Nautilus) .

Gnome fournit un service virtuel de système de fichiers (GnomeVFS). Il rend divers systèmes de fichiers transparents à l'utilisateur. Entre autres, il peut faire face aux protocoles comme HTTP, FTP, NFS, SMB, les fichiers locaux, WebDAV. De plus, il fournit des informations MIME et maintient un registre d'application correspondant.

« Q » pourra utiliser GnomeVFS. L'avantage principal sera d'améliorer l'interopérabilité avec des partages de Windows SMB. GnomeVFS améliorera aussi bien l'interopérabilité avec le gestionnaire de Nautilus puisque le contenu sera disponible dans les deux applications par la même URI. De plus, SO/OOo pourra manipuler des données externes conformément aux paramétrages du système MIME.

4.1.5.4 Intégration du bureau

Un utilisateur de Microsoft Windows peut créer de nouveaux documents vides SO/OOo sur le bureau. Le bureau Gnome offrira un dispositif concurrentiel. Ceci se fera en créant un composant Bonobo pour Nautilus.

Les applications les plus importantes sur le bureau Gnome seront immédiatement fournies par le menu de démarrage de Gnome. Une entrée de niveau supérieure pour les besoins de SO/OOo sera ajoutée.

Il est nécessaire de renseigner toute application sur le bureau Gnome sur la façon de manipuler les dossiers de SO/OOo. Particulièrement le navigateur et le gestionnaire doivent pouvoir être en mesure de les manipuler convenablement et montrer une icône appropriée. Ceci sera réalisé en enregistrant le type MIME de SO/OOo dans le registre système correspondant.

4.1.5.5 Interopérabilité des applications

Des plugins de navigateurs seront rendus disponibles à partir du menu Insertion | Objet {Plugin | Son | Vidéo}. Le carnet d'adresses d'Evolution de Ximian sera importé dans SO/OOo.

4.1.5.6 Installation

Le système de bureau Gnome sera fourni comme ensemble de paquets au format RPM. Il est nécessaire de déployer et de mettre à jour SO/OOo ainsi que d'autres parties du système d'exploitation.

Actuellement la plupart des distributions Linux fournissent des RPMs qui correspondent à une installation complète en réseau de « Geordi ». « Q » sera fourni dans une intégration plus fine des paquets qui permettent l'installation, la mise à jour et le patch individuel d'entités fonctionnelles. Des fichiers communs pour l'intégration système seront installés dans le système et non dans chaque répertoire local utilisateur comme dans « Geordi ».

4.1.5.7 Configuration

SO/OOo se sert d'un ensemble d'applications d'aide. Application qui peut être employée comme application d'aide pour les besoins de SO/OOo, utilisable sans davantage d'administration. « Q » se servira de la configuration de bureau Gnome si possible. Les exemples ici sont le navigateur par défaut, le maileur par défaut, et les paramétrages de proxy. Le composant de Configuration SO/OOo fournira un accès transparent aux paramétrages système, qui sera résolu par l'intermédiaire d'une architecture principale plugable

4.2 Améliorations générales

4.2.1 Stabilité et Qualité

(Matthias Huetsch, Juin 2003)

4.2.1.1 Restauration des documents

N'importe quel crash potentiel de SO/OOo qui pourrait avoir comme conséquence des données perdues sera corrigé par défaut par un nouveau mécanisme automatique de restauration exécutant une protection régulière des documents et des paramétrages. Ce mécanisme automatique de restauration reconstituera un environnement de travail utilisateurs à l'état précédant la fermeture de SO/OOo.

Le dialogue de restauration du document sera amélioré pour guider l'utilisateur dans ce processus automatique de restauration et de reconstitution des documents et fournira un retour détaillé de ce processus de restauration.

4.2.1.2 Rapports d'erreurs

Des améliorations dans la stabilité de SO/OOo doivent être menées pour être quantifiables. Afin de pouvoir caractériser le niveau courant de stabilité, cette fonction a été implémentée dans « Geordi » SO/OOo et a été corrigée par une application de rapport d'erreurs, enregistrant des données de crash et le retour d'utilisateurs au sujet de la perte ou de la conservation des documents.

Ce rapport d'erreurs aidera à identifier et éliminer des causes de crash, et fournira des mesures permettant de montrer les améliorations du niveau de stabilité pour SO/OOo « Q » et les autres versions.

4.2.2 Administration et Déploiement

(Dirk Grobler, Christof Pintaske, Mai 2003)

4.2.2.1 Déploiement

Le paradigme d'installation change d'être principalement orienté simple utilisateur à être orienté administrateur. Il recherche des installations et des administrations à grande échelle. Cette question sera abordée en se conformant au procédé d'installation des services respectifs d'installateurs systèmes, puisque ces services fournissent déjà ou permettent un outillage d'installation existant.

L'installation utilisateur de « Geordi » comme étape nécessaire à une installation réseau cessera d'exister. Les applications de bureau seront entièrement fonctionnelles dès le premier démarrage. La collecte des données spécifiques d'utilisateurs sera remise au premier démarrage de l'application ou questionnée plus tard directement à partir du système. Le document et les paramétrages par défaut seront produits à la volée pendant le premier démarrage ou sur demande.

Le mode réparation de l'installation sera abandonné. La réparation des fichiers installés est déjà manipulée par le mécanisme natif de paquets (habituellement par une réinstallation). Ceci n'affecte pas les changements réalisés par l'utilisateur puisque les fichiers utilisateur et les fichiers systèmes sont strictement séparés.

L'évolution et les patchs seront exécutés par le biais de l'installateur respectif du système.

Puisque Solaris et Linux ne fournissent pas nécessairement une interface utilisateur graphique pour l'installation nous fournirons un frontal graphique pour guider l'utilisateur dans le procédé d'installation des paquets. Néanmoins les paquets respectifs peuvent être installés complètement indépendamment de ce frontal.

4.2.2.2 SO/OOo Configuration

Des améliorations pour la manipulation des données de configuration sont prévues qui affectent l'application entière. Ce sont des additions à la technologie de configuration existante :

Reset des paramètres de configuration dans le dialogue d'options
Actuellement, il n'est pas possible qu'un utilisateur restaure ses paramètres initiaux fournis pendant le procédé d'installation. Ce manque sera corrigé avec l'introduction d'une fonction 'restaurer les choix par défaut' à travers une boîte de dialogue SO/OOo. Un utilisateur peut choisir une page spécifique de paramétrage dans le dialogue d'options et peut appuyer sur le bouton de restauration, les paramétrages respectifs seront remis à leur installation par défaut. Quitter le dialogue avec le bouton OK rendra les paramètres persistants.

Protection des paramètres de configuration.
Les administrateurs ont la possibilité de protéger des paramètres de configuration contre des modifications effectuées par l'utilisateur, de sorte que les paramètres soient effectivement en lecture seule. « Geordi » reflète le statut de lecture seule pour quelques paramètres sélectionnés dans la boîte de dialogue d'options. Des paramètres non protégés peuvent être écrasés par l'utilisateur et appliqués pour la durée de vie de la session de SO/OOo. Pour « Q » ce manque est comblé et tous les paramètres en lecture seule sont reflétés comme tels dans le dialogue d'options.

Notification de manipulation
Les changements de paramètres de configuration sont actuellement très rarement notifiés à l'utilisateur. Seulement quelques composants dans SO/OOo peuvent écouter et notifier des avis des changements de configuration. Dans quelques scénarios spécifiques de déploiement, comme des déploiements SunRay, il est très commun que les applications aient un long fonctionnement. Par conséquent il est important que SO/OOo puisse réagir et appliquer des changements de configuration quand ils se produisent, au lieu d'exiger un redémarrage. « Q » remédie à ce comportement par une manipulation cohérente d'avis de configuration.

4.2.3 Apparence Moderne

(Christian Jansen, Mai 2003)

Puisque nous avons commencé à améliorer l'apparence dans « Geordi », nous continuerons ce travail avec « Q ». Ce chapitre donne une vue d'ensemble de ce qui sera fait pour obtenir une interface utilisateur plus actuelle avec laquelle il est plus agréable de travailler.

4.2.3.1 Barres d'outils

L'apparence des barres d'outils sera améliorée par l'introduction d'une technologie complètement réactualisée dans la manipulation des barres d'outils. Elles auront une apparence moderne et intuitive et une rentabilité accrue. Par exemple, la possibilité de glisser une barre d'outils sera indiquée par l'ajout d'un secteur qui indiquera que l'on peut glisser la barre d'outils. Les barres d'outils seront également améliorées en ajoutant plus de rétroaction pendant les interactions de glisser/déposer. Ceci signifie par exemple que les barres d'outils seront « magnétiques » de sorte qu'elles sautent automatiquement à leur position correcte. D'autre part, les barres d'outils dans « Q » n'occuperont plus la largeur entière de l'application quand elles sont couplées. Les barres d'outils auront un aspect visuel plus aplati.

4.2.3.2 Widget style

Un autre domaine très important où apporter des améliorations concerne l'apparence des widgets (les widgets dans les interfaces graphiques utilisateur, sont la combinaison d'un symbole graphique et d'un certain code de programme afin d'exécuter une fonction spécifique. Par exemple un ascenseur ou un bouton). Selon le niveau de l'intégration système, SO/OOo emploiera le modèle de widget du bureau. Si ce n'est pas possible pour « Q » le modèle courant de widget sera amélioré de façon à ce que SO/OOo soit assez attrayant dans les environnements comme Gnome 2.x /3.x ou Longhorn de Microsoft Windows (le successeur de Microsoft Windows XP).

4.2.3.3 Tool Pane (traduction provisoire : Panneau d'outils)

Avec SO/OOo « Q » un nouveau type de dialogue sera introduit. Nous appelons cette boîte de dialogue Tool Pane (Panneau d'outils), puisqu'on la lie aux fenêtres d'outils, par exemple le Styliste. Cela fonctionne comme des dialogues indépendants du mode. Le Tool Pane par défaut sera ancré verticalement et placé à la gauche ou à la droite du document. Les Tool Pane seront introduits dans SO/OOo Impress en premier lieu, parce que SO/OOo Impres est une application où introduire des interfaces indépendantes du mode est le plus sensé.

Les Tool Pane peuvent contenir par exemple une liste de mises en page prédéfinies de présentation qui peuvent être facilement appliquées à la présentation en glissant l'onglet d'une mise en page sur la diapo. Pour donner aux Tool Pane un aspect moderne, ils seront dans le style Web. Les Tool Pane auront des aspects moins complexes que les dialogues standards, cela permettra une manipulation plus aisée et gagera du temps lors de la création de la présentation.

4.2.3.4 Apparence des dialogues en général

Les dialogues de SO/OOo « Q » seront améliorés dans les secteurs suivants :

les options désactivées n'auront pas un style 3D, l'état désactivé sera seulement grisé,

les outils Windows, comme la palette de couleurs, seront modernisés grâce à la suppression de l'ancienne bordure 3d,

les sélections, comme telles qu'affichées dans la Gallery par exemple, seront remplacées par une apparence plus actuelle.

4.2.3.5 AutoPilotes (Wizards)

Actuellement, beaucoup de pilotes automatiques dans « Geordi » sont conçus différemment les uns des autres. Certains d'entre eux ont plus de cinq ans et leur aspect n'a jamais été modifié. Pour SO/OOo « Q » l'apparence des pilotes automatiques sera unifiée et orientée vers une conception typique de Wizards employée par Mozilla ou d'autres applications comme un installateur. Avoir une cohérence à travers tous les pilotes automatiques de SO/OOo en améliore la rentabilité et donne une meilleure satisfaction globale, les utilisateurs arrivant plus rapidement à un résultat. Les pilotes automatiques remplacés viendront également avec un minimum d'expressions techniques, les utilisateurs seront aidés dans les étapes par l'ajout de notes ou d'explications courtes dans le dialogue.

4.2.3.6 Intégration Système

Avoir un comportement conforme dans un environnement de bureau est très important. L'intégration système de SO/OOo sera améliorée pour les bureaux basés sur le système Gnome. L'intégration système de l'apparence signifie que les comportements typiques d'un bureau doivent être respectés également par SO/OOo, par exemple, le pointeur de souris doit avoir la même apparence dans SO/OOo que sur le bureau.

Une bonne intégration système inclut également un ensemble de documents et des icônes d'application qui s'adaptent au style du bureau sur lequel SO/OOo fonctionne. Pour « Q » nous aurons des ensembles d'icônes qui prendront en compte le style typique des environnements de bureau.

4.2.4 Intégration (Plug-ins, applications tierces)

(Mathias Bauer, May 2003)

Le sujet principal de ce chapitre concerne la liaison et l'inclusion des données dans ou de SO/OOo. Pour mieux comprendre, voici une description courte de la fonctionnalité courante et de l'histoire de son développement.

Dans le passé SO/OOo était constitué de simples applications qui supportaient l'architecture de document composée OLE et permettaient ainsi d'inclure et de lier des objets d'autres applications qui supportaient également cette architecture. La même technologie a été employée pour inclure des objets des différentes applications de SO/OOo l'une dans l'autre.

Le grand inconvénient de cette approche était que cela fonctionnait seulement pour Microsoft Windows. Les versions de SO/OOo sur d'autres plateformes pouvaient seulement montrer une représentation du cache de l'objet inclus (habituellement un métafichier de GDI).

Quand SO/OOo a été remodelé pour suivre une approche indépendante des plateformes pour son GUI, le support OLE a été retiré excepté la capacité d'inclure des objets de parties tierces dans SO/OOo et de les activer dans une fenêtre externe sur Microsoft Windows (appelé « activation hors place »). L'activation plus avancée « En place » des objets de parties tierces (éditer les objets dans une fenêtre propre à l'intérieur d'un container inclus dans le document) a été abandonnée et également la capacité d'inclure des objets de SO/OOo dans des applications tierces a été complètement supprimée. Un autre dispositif abandonné était la capacité de lier aux dossiers externes au lieu de les intégrer.

La fonctionnalité interne d'intégration (intégration des documents SO/OOo l'un dans l'autre) utilise toujours l'ancien code autrefois écrit pour envelopper les interfaces OLE, mais la plupart des parties relatives à l'implémentation OLE ont été retirées. Puisque nous n'avions rien en remplacement de OLE, tous les modules SO/OOo ont dû être mis dans une application simple, autrement nous aurions perdu la capacité d'activer la fonction « En place » de SO/OOo même dans nos propres applications.

Dans le même temps, les utilisateurs ont fait plusieurs suggestions d'amélioration. Ces suggestions inclues ce qui suit :

l'activation « En place » est perçue comme une fonctionnalité indispensable dans les applications modernes de Microsoft Windows.

l'incapacité d'inclure des objets SO/OOo dans d'autres applications est un désavantage concurrentiel fort vis-à-vis des autres applications du marché, si le client emploie de telles techniques d'application dans ses propres solutions IT.

4.2.4.1 Support de l'OLE

Le concept suivant montrera comment SO/OOo peut obtenir la fonctionnalité nécessaire et comment nous pouvons développer ceci à travers une procédure en plusieurs étapes.

SO/OOo peut intégrer ses propres formats sur toutes les plateformes et également intégrer des objets OLE d'autres applications sur Microsoft Windows. « Geordi » ajoute une nouvelle fonction permettant à des objets SO/OOo d'être intégrés par l'intermédiaire d'OLE dans des documents d'autres applications sur Microsoft Windows. Dans ce cas-ci et également dans le cas des objets d'applications tierces intégrés dans SO/OOo, la seule activation de l'objet est « Hors place », aucune activation « En place » n'est possible.

« Q » permettra l'activation « En place » dans les deux cas et ajoutera également la fonction actuellement manquante de liaison des objets.

En dehors du fait que l'ensemble de cette fonction d'intégration et l'API (actuellement C++, à l'avenir basée sur UNO) seront remodelées pour supporter des techniques d'intégrations arbitraires, des objets et des modèles persistants. La bascule vers une solution API améliorera également rigoureusement la maintenance, la stabilité et l'extensibilité du code.

Quelques exemples de fonctions que permettront ces modifications :

Il sera possible de supporter des procédures comparables d'intégration et d'activation venant d'autres plateformes comme Bonobo sur Gnome (s'il y a une demande pour cela). Ceci peut être fait sans changer le code existant, on doit seulement mettre en application quelques services nouveaux qui emploient les mêmes interfaces que les services qui sont employés pour supporter OLE. Puisque les interfaces OLE et Bonobo sont tout à fait semblables, ceci semble être un but accessible pour des étapes postérieures.

Intégration, persistance et activation seront traitées en tant que fonctionnalité orthogonale, ce qui signifie que les objets intégrés ne sont pas obligés de supporter la persistance ou l'activation. Ainsi nous pourrons obtenir des objets intégrés et activables sans les données propres de persistance (objets légers) comme les diagrammes intégrés qui obtiennent leurs données d'un container intégré. C'est un dispositif qui rend nos propres diagrammes plus utilisables et comparables aux solutions de pointe.

L'amélioration des capacités d'intégration offre également une meilleure interopérabilité de Microsoft Office avec StarOffice au niveau des fichiers. Dans StarOffice 6.0 les objets SO/OOo intégrés dans des documents exportés de Microsoft Office sont stockés dans le format de fichier de Microsoft Office ou dans notre ancien format binaire. La première alternative présente l'inconvénient que l'objet doit être exporté et réimporté lors du rechargement et ce cycle d'export/import peut causer la perte de quelques données. La dernière alternative présente l'inconvénient qu'il n'y a aucune manière d'activer l'objet inclus dans le document s'il est chargé dans l'application Microsoft Office, et naturellement l'ancien format binaire peut également présenter un danger et provoquer la perte de données (par exemple nous perdrons tous les attributs CJK).

Depuis « Geordi » ces objets peuvent être stockés en tant qu'objets OLE complets en utilisant notre format de fichier XML, avec le support total de l'activation dans un container Microsoft Office sans aucune perte de données possible. « Q » ajoutera l'activation « En place » de ces objets dans le container Microsoft Office et ainsi améliorera l'expérience utilisateur et l'interopérabilité.

4.2.4.2 Intégration du Navigateur

Une première implémentation de connexion avec Mozilla/Netscape pour Windows existe déjà, ainsi que la commande activeX pour Microsoft Internet Explorer, et un applet Java signé. Tous ces objets une fois incorporés dans un navigateur, utilisent une installation locale de SO/OOo pour afficher les documents SO/OOo à l'intérieur d'un Navigateur.

Dans « Q » la connexion sera complétée et prolongée à d'autres plateformes. Tous les objets subiront quelques perfectionnements et optimisations, parce que même la commande activeX et l'applet Java souffrent de quelques problèmes de rentabilité.

Nous intégrerons des fonctions d'éditions pour les documents chargés à partir de l'objet navigateur incorporé.

4.2.4.3 Intégration de parties tierces UNO

Dans « Geordi » nous avons développé le concept très puissant d'Addon qui permet déjà à des utilisateurs d'employer notre ODK pour développer des composants qui peuvent être facilement intégrés dans SO/OOo et le GUI de SO/OOo. Particulièrement, l'intégration de GUI dans « Q » sera améliorée en même temps que des changements seront apportés au code du Framework GUI.

4.2.4.4 Intégration avec les clients mail

Sera déterminée plus tard.

4.2.4.5 Intégration de fichiers multimédias dans SO/OOo

Actuellement SO/OOo peut seulement employer des plug-ins de navigateur pour jouer des vidéos dans une présentation par exemple, et malheureusement ces plug-ins ne fonctionnent pas dans SO/OOo sur Linux ou Solaris. Ainsi il est nécessaire de trouver une manière différente et plus puissante de travailler avec des fichiers multimédias. Ceci peut probablement être combiné avec la nouvelle API d'incorporation mentionnée dans la section à propos d'OLE.

4.2.4.6 Support pour le développement de filtres

SO/OOo suit déjà un concept en ce qui concerne le développement des composants de filtre. Dans le passé très souvent les fichiers de configuration nécessaires pour les filtres ont posé quelques problèmes, ainsi la configuration de filtre sera modifiée pour aller vers une meilleure administration. De plus, tous les filtres internes seront convertis en vrais composants de filtre pour rendre leur remplacement plus aisé.

4.3 Opportunités à venir

4.3.1 Langues CTL et Asiatiques

(Falko Tesch, Juillet 2003)

4.3.1.1 Conditions pour le CJK

Puisque SO/OOo supporte déjà les langues CJK et comporte beaucoup de fonctions spéciales au CJK, la version « Q » mise plus sur une sophistication et une amélioration des fonctions existantes.

Ceci s'applique à toutes les applications telles que le Calc, Writer et Impress/Draw.

Des améliorations doivent être faites dans les secteurs suivants :

Grille de Texte

Pour les utilisateurs asiatiques, la grille de textes est une aide importante pour apprendre l'écriture à l'école aussi bien qu'une manière traditionnelle d'écrire dans un style et d'une façon corrects. Les capacités de grilles de texte de SO/OOo seront améliorées par des options d'impression plus souples, par plus de modèles permettant de choisir des ajustements additionnels qui pourront s'appliquer au comportement du texte occidental à travers la grille de texte.

Agir ainsi alignera SO/OOo avec ou devant ses concurrents et l'amélioration de notre grille de textes représente également une façon d'être accepté par des utilisateurs plus traditionnels.

Amélioration du support IME

L'IME est l'instrument le plus crucial pour tous les utilisateurs Est-Asiatiques. Il leur permet de saisir leurs caractères. Tandis que Sun Solaris fournit des IMEs standards, la communauté Linux en fournit des variés.

Les clients ont demandé que SO/OOo supporte autant d'IMEs que possible. Cela aidera SO/OOo à consolider sa position dans le monde asiatique Linux de la même façon que cela existe déjà dans le monde occidental.

En outre, nous aurons une lecture plus sophistiquée d'IMEs. Puisque les IMEs qui viennent avec Microsoft Windows emploient tous une interface unifiée étendue (contrairement à Linux par exemple) les utilisateurs sont habitués à certains agréments, tels que la détection automatique de langue pendant la frappe. Malheureusement, la variété d'IMEs différents à travers Microsoft Windows, Sun Solaris et Linux nous a amenés à choisir le plus petit dénominateur commun. Cela changera.

« Q » AutoComplétion et autres

« Q » supportera l'AutoComplétion et la correction automatique pour toutes les langues Est-Asiatiques.

4.3.1.2 Conditions pour le CTL

Puces et numérotations.

Dans les régions Arabes et Hébreu, les personnes écrivent de droite à gauche (RTL). Par conséquent elles emploient également des numérotations et des puces du bon côté avec le bon alignement.

Dans la mesure où « Geordi » prend en compte les fonctions basiques d'alignement des puces, « Q » fournira une automatisation plus intelligente comme d'autres produits bien connus sur le marché.

En outre, une plus grande variété des symboles de numérotation localisés attirera plus d'utilisateurs.

Le formatage spécial

Comme les utilisateurs Est-Asiatiques, les utilisateurs CTL sont également accoutumés à varier la manière de composer leurs textes. Ce sont la plupart du temps des problèmes mineurs mais les résoudre apportera à SO/OOo une évaluation plus complète et plus respectable.

En outre apporter une réponse par certaines fonctions, spécifiques non seulement aux utilisateurs de CTL en général mais s'adressant également à un groupe d'utilisateurs spécifiques (comme l'arabe), sera un plus indéniable.

Interface Utilisateur RTL

Tandis qu'un bon nombre de personnes écrivant Arabe et Hébreu sont habituées à travailler dans un environnement anglais écrivant de gauche à droite (LTR) en anglais pour accomplir leur travail (RTL), ils évaluent fortement un produit également disponible dans leur mode d'écriture (RTL) local. Même si une interface utilisateur RTL n'est pas parfaite et que les utilisateurs peuvent à nouveau migrer vers une interface utilisateur LTR anglaise, l'interface utilisateur RTL doit cependant être considérée comme une porte ouverte vers ces personnes.

« Geordi » fournit déjà un framework dédié à l'interface utilisateur RTL. Les premiers à l'avoir adopté tels que Tk Open System en Israël ont montré des premiers prototypes prometteurs. « Q » représentera un important bond en avant en fournissant des outils pour permettre à ces personnes de générer une interface utilisateur RTL complète pour le marché Arabe et Hébreu.

4.3.1.3 Nécessités I18N

Documentation et Style d'interface utilisateur

La plupart des utilisateurs d'Asie de l'Est et dans les pays CTL sont habitués à un ensemble existant de termes et de nomenclature. SO/OOo emploiera ceci pour soulager le transfert et l'apprentissage des utilisateurs. Cela leur permettra également de se familiariser plus vite avec notre produit.

Une attention particulière doit être apportée aux questions et aux désaccords culturels possibles sur les termes de l'interface utilisateur, de même avec la documentation localisée (voir la RP de Chine - l'exemple de Taïwan dans la section de vue d'ensemble).

Pour atteindre ce but « Q » fournira à l'utilisateur une aide en ligne accessible et facile à lire ainsi qu'une documentation imprimée dans sa langue maternelle. L'autre question importante concerne la documentation technique qui donnera aux ingénieurs de ces pays le sentiment d'être pris en considération et valorisés (même s'ils se sentent finalement mieux avec des originaux en anglais).

Problèmes Impress et Calc

Alors qu'il y a une interface utilisateur et qu'il y a un secteur de document, il y a-t-il également une couche qui existe « entre » l'affichage du document et l'interface utilisateur de l'application.

Même dans les interfaces utilisateur non-RTL, un document RTL et un canevas RTL sont communs aux clients de langue Arabe et Hébreu. « Geordi » le prend déjà en compte et reflète automatiquement des outils du canevas tels que les règles, les barres de défilement etc...

Dans « Q » Impress/Draw et Calc suivront.

Les utilisateurs de RTL ont l'habitude de commencer à lire de la partie supérieure droite vers la partie inférieure gauche. Cela signifie pour Calc et Impress que les colonnes et les en-têtes de ligne doivent être en miroir (dans Calc) et l'organisation des modèles de diapositives dans Impress doit également être reflétée.

4.3.1.4 Intégration d'outils

Chaque pays a ses propres cas et règles spéciaux. Et tout ne peut pas être réglé par un produit simple tel que SO/OOo.

Mais le lancement sur ces marchés de produits ayant des fonctions supportant en interne les outils les plus importants pour les fournisseurs est envisageable

Exemples :

des pays utilisant des scripts multiples pour des langues multiples comme l'Inde (7 langues et scripts principaux) sont habitués à utiliser des claviers à l'écran pour visualiser les diverses dispositions de claviers.

Les pays Est-Asiatiques comme la Corée utilisant les caractères chinois (Hanja) dans leurs travaux quotidiens ont besoin de dictionnaires et de méthodes d'entrée spéciales.

Le monde Arabe qui emploie un modèle très sophistiqué d'Arabe pour créer et éditer les textes saints (Koran).

Tous ces pays ont une chose en commun :

Ils ont tous des fournisseurs locaux qui créent, programment et vendent des logiciels à valeur ajoutée pour les suites bureautiques.

Supporter ces outils et/ou fournir aux développeurs de ces entreprises une documentation qui leur permette de développer ces outils également pour SO/OOo peut faciliter une réelle pénétration. (À nouveau, cela montre quelle importance peut revêtir une documentation technique localisée).

4.3.2 Signatures Digitales

(Michael Brauer, May 2003)

Comme dit ci-dessus, les signatures numériques elles-mêmes sont un fait relativement nouveau pour des applications bureautiques, mais la nécessité de protéger des données contre les modifications a toujours existé. Dans SO/OOo, comme dans d'autres suites bureautiques, il y a été remédié par la protection en édition des documents et des parties de document, comme les sections dans Writer ou les tables dans CALC. Parfois la protection est une simple option. Parfois la protection est combinée avec un mot de passe. Dans les deux cas, ces dispositifs ne sont rien qu'une protection contre l'édition établie dans SO/OOo. Ils n'apportent aucune sécurité réelle au document, parce qu'ils ne peuvent pas empêcher le document d'être modifié à l'extérieur de SO/OOo . Et ceci est en fait devenu encore plus facile avec l'introduction des formats de fichiers XML, cela a même enlevé une part de la sécurité que les formats de fichiers binaires propriétaire et non documentés possèdent encore.

Bien que les dispositifs existants de protection n'offrent pas de sécurité, ils montrent où se situe la demande et l'avantage des signatures numériques semble être l'un des plus importants. Par conséquent, ajouter ces signatures numériques à SO/OOo pour « Q » consistera à commencer par ajouter des signatures numériques aux fonctions de protection existantes. Ceci non seulement sécurise ces fonctions, mais permet également à des clients d'employer des signatures à travers un effort d'apprentissage très restreint. Le plus important demeure cependant que les clients, de cette façon, obtiennent un ensemble complet de fonctions de signatures numériques qu'ils peuvent employer dans leur environnement et dans leur flux de travail. En améliorant le support pour la signature numérique basée sur le flux de travail dès le démarrage, les signatures multiples indépendantes seront supportées pour une et une seule partie de document. Basé sur l'expérience de client utilisant ces dispositifs, le support de signature hiérarchique ou d'autres genres de signatures imbriquées pourrait être également ajouté dans des versions postérieures de SO/OOo.

Pour enregistrer réellement les signatures numériques dans les fichiers SO/OOo, la recommandation de signature XML W3C sera utilisée. C'est non seulement une norme qui s'adapte très bien dans la stratégie des normes existantes de réutilisation pour le format de fichiers SO/OOo, mais on peut également supposer que cette norme sera largement supportée dans un avenir proche.

Les dispositifs de signature SO/OOo pour les documents utiliseront le même cadre de sécurité qui est utilisé pour d'autres dispositifs de sécurité dans SO/OOo, comme pour des macros en basic. C'est-à-dire, il y aura une gestion principale et un ensemble commun de méthodes de signature dans SO/OOo.

Contrairement aux signatures, le chiffrage est un dispositif qui a été supporté pendant longtemps dans les applications bureautiques. Dans « Geordi », le chiffrage est possible sur les documents entiers. Dans la mesure où il n'y avait aucune norme de chiffrage disponible lorsque le format de fichiers XML a été introduit, le chiffrage actuellement est exécuté comme une extension spécifique des paquets ZIP SO/OOo qui contiennent les fichiers XML. Dès que le chiffrage basé sur la recommandation récemment définie de chiffrage XML W3C sera répandue, ce sera peut-être le cas pour « Q » ou de futures versions, elle sera de toute façon supportée par SO/OOo. Elle se servira encore du cadre commun de sécurité de SO/OOo pour les méthodes principales de gestion et de chiffrage.

Puisque les spécifications de chiffrage du W3C supportent non seulement le chiffrage des documents entiers mais également des parties de document, les futures versions de SO/OOo pourraient également supporter le chiffrage pour des parties de document seulement, comme ce sera déjà le cas pour les signatures dans « Q ».

4.3.3 Mises à jour de fonctionnalités intéressantes (ex. multimédia, OCR, DB)

A déterminer plus tard.

4.3.4 Services

(Kai Sommerfeld, Mai 2003)

4.3.4.1 SO/OOo Web-Services Client (WebServices-1)

Fondamentalement, dans l'état actuel, il y a trois approches pour couvrir en partie ou complètement les services de Web. Les différentes approches sont :

Accès à des services Web par l'intermédiaire des mécanismes de Java pour Java.

Utiliser une approche basée sur l'invocation.

Avoir une fonction complète liée par UNO

A : Puisque des composants UNO pour SO/OOo peuvent déjà être écrits en Java, il y a actuellement la possibilité d'accéder à des services Web. L'utilisation des services Web par l'intermédiaire de Java est limitée à Java et ne permet pas d'exporter les APIs bureaux comme service Web.

B : Une thèse de diplôme a été écrite pour obtenir un support UNO plus direct. Avec ce composant UNO, il est possible d'accéder à des services Web à partir de Star Basic (voir svp http://udk.openoffice.org/java/examples/wsproxy/component_description.html pour plus de détails). L'implémentation de ce composant n'est pas encore complètement fonctionnelle. La plupart des services Web peuvent être consultés, mais certains, qui emploient des fonctions spécifiques ne peuvent pas actuellement être accédés. Pour l'utiliser dans un emploi universel, il est nécessaire d'étendre le composant pour supporter ces fonctions. Étant un service UNO, ce composant peut être principalement utilisé par n'importe quel langage supporté par UNO, par exemple SO/OOo Basic, C++ ou Java. Mais l'accès continue aux services Web est seulement pour ces langages qui supportent XInvocation et XPropertySet pour appeler des méthodes accédant respectivement à des propriétés. Le seul langage faisant actuellement ceci est SO/OOo Basic. Pour tous les autres langages c'est plutôt difficile et incommode.

C : L'approche la plus générale et la plus coûteuse de support de services Web dans SO/OOo respectivement UNO est une liaison vers un langage de service Web. Ceci permet à des services Web d'être entièrement accessibles par UNO et permet l'exportation des objets UNO comme des services Web aussi bien que l'importation de n'importe quel service Web. Les services Web sont alors directement programmables en n'importe quel langage supporté par UNO, sans charge additionnelle.

4.3.4.2 Navigateur UDDI SO/OOo (WebServices-2)

[NDT : UDDI est un annuaire mondial d'entreprises]

Il y a plusieurs navigateurs libres UDDI fournis par des tiers. Un bon exemple http://www.soapclient.com/uddisearch.html. Ce navigateur inclut un client générique SOAP, qui supporte même l'essai de phase des services Web. Les navigateurs UDDI peuvent être utilisés pour obtenir l'URL de fichiers WSDL(Web Service Description Language) pour certains services Web. Le fichier WSDL peut alors être utilisé pour créer une instance de composant UNO représentant le service de Web, comme décrit ci-dessus. Il semble qu'il n'y ait pas de besoin réel de navigateur SO/OOo UDDI, dans la mesure où la valeur ajoutée reste très minime. L'effort de développement serait de moyen à élevé.

Une autre approche serait l'intégration des services de Web dans le prochain Scripting Framework. Des services de Web pourraient alors, progressivement, être offerts par l'intermédiaire du dialogue de sélection de macro. Davantage de recherches sont nécessaires, pour clarifier les détails.

4.3.4.3 SO/OOo Fournisseur de service Web (non couvert actuellement)

Les services Web utilisent SOAP pour l'invocation de méthodes à distance. Un lien de langage UNO-SOAP pourrait être mis en application pour rendre chaque fonctionnalité SO/OOo qui est disponible par un service UNO comme service Web. Voir également SO/OOo client de service Web. L'effort pour mettre en application un lien vers un langage UNO-SOAP est très important (évaluation brute : au moins 3 mois).

4.3.5 Drapeaux pour les documents intelligents

(Andreas Martens, Mai 2003)

4.3.5.1 Utilisateur

Si un composant de drapeau de document intelligent est installé, l'utilisateur peut l'activer ou le désactiver. S'il est activé, les mots-clés identifiés sont soulignés. Le curseur de souris change d'aspect s'il survole un tel mot-clé. Un menu contextuel s'affiche si l'utilisateur clique sur le bouton droit de souris. La teneur du menu représente les actions possibles pour ce mot-clé, typiquement les noms des dictionnaires qui contiennent le mot-clé. L'utilisateur choisit une action et le composant réagit en conséquence.

4.3.5.2 SO/OOo

SO/OOo doit séparer le contenu du document en phrases. Ces phrases seront passées au composant. Si une phrase est modifiée par l'utilisateur elle doit être de nouveau analysée.

SO/OOo contrôle le soulignement et l'aspect du curseur de la souris pour les mots-clés. Si l'utilisateur appelle le menu contextuel, SO/OOo doit lui appeler le composant les entrées de menu. Si l'utilisateur choisit une entrée, SO/OOo appelle le composant avec l'entrée choisie (sous la forme d'un nombre, d'une ID).

4.3.5.3 Composant

Le composant doit supporter trois interfaces.

Si une phrase a été passée le composant doit fournir toutes les positions de début et de fin des mots-clés dans cette phrase.

Si une phrase et la position d'un caractère ont été passées, le composant doit fournir les actions disponibles comme entrées de menu contextuelles et les ID correspondantes.

Si le composant est appelé avec une telle ID, il doit réagir en conséquence (voir les exemples ci-dessus).

Copyright Sun Microsystem © 2003 Traduction Sophie Gautier © 2003

35

Sophie Gautier

2003-08-09T12:36:40

Sophie Gautier