Projet ESSI2

Transcription

Projet ESSI2

Longhorn Project – Building an application for Windows Longhorn
Projet ESSI2
Lundi 6 juin 2005 – Vendredi 24 juin 2005
Stéphane BLANC
Nicolas BOUSQUET
Alban CAMPO
Gilles RÉANT
Tuteur de projet : M. Johny BOND
Stéphane Blanc, Alban Campo, Nicolas Bousquet, Gilles Réant
ESSI2 – Juin 2005
1
Remerciements
Nous tenons à remercier tout d’abord M. Jean-Paul Stromboni qui a accepté
notre proposition de projet dans le cadre des projets de fin d’année ESSI2.
Qu’il nous soit également permis de remercier notre encadreur de projet, M.
Johny Bond, pour ses conseils et son enthousiasme.
Merci également à M. Peter Sanders pour nous avoir permis d’utiliser sa
machine de l’E.S.S.I. afin de nous permettre de gérer nos versions de code avec le
logiciel SVN.
Nous désirons également gratifier Mme Blandine Berg et M. Pierre Lagarde
pour leurs aides apportées tout au long de ces trois semaines de projet et
notamment M. Pierre Lagarde pour sa disponibilité, sa présence à notre soutenance
et à ses nombreuses recherches spontanées sur Longhorn et les différents
Runtimes.
Nous remercions de plus toutes les personnes qui, de près ou de loin ont
contribué à une partie du projet.
ESSI2 – Juin 2005
2
Table des matières
Remerciements................................................................................................... 2
Table des matières ............................................................................................. 3
Résumé................................................................................................................ 5
I.
But et composition du projet .................................................................... 6
II.
Longhorn (Avalon, Indigo, WinFS et les autres) ..................................... 6
III.
Étude de l’existant...................................................................................... 9
IV. Description des fonctionnalités de base et avancées souhaitées ........ 10
V.
Outils utilisés ............................................................................................. 11
1. RunTimes + SDK ...................................................................................... 11
2. Développement ......................................................................................... 12
A.
B.
Visual Studio 2005 beta 2 ........................................................................................... 12
C# ................................................................................................................................ 13
3. Moyens de communication ....................................................................... 14
A. Forum .................................................................................................... 14
B. SVN ou la gestion de version ...................................................................... 15
C. Direct ..................................................................................................... 16
D. Rapports quotidiens ..................................................................................................... 16
E. Mail .............................................................................................................................. 16
VI. Diagramme de classes ............................................................................... 17
VII.
1.
2.
3.
4.
Description détaillée................................................................................ 18
Contrôleur .................................................................................................. 18
Interfaces graphiques ............................................................................... 18
A. XP ......................................................................................................... 18
B. Longhorn ................................................................................................. 20
a. Version 2D............................................................................................................. 20
b. Version 3D............................................................................................................. 21
« ScreenMaker »........................................................................................ 22
Autres ........................................................................................................ 23
A. IOFileSystem .......................................................................................... 23
B. ElementFavori et ses filles........................................................................... 24
VIII. Difficultés de compatibilité
.................................................................... 25
ESSI2 – Juin 2005
3
IX. Recherches de solutions ........................................................................... 27
1. Le Web ...................................................................................................... 27
2. Contact avec Microsoft France .................................................................. 27
3. Rencontre avec un ingénieur Microsoft...................................................... 28
X.
Planning des journées et ordonnancement du travail ........................... 28
XI. Résultats obtenus ...................................................................................... 29
1. XP .............................................................................................................. 29
2. Longhorn 2D .............................................................................................. 30
3. Longhorn 3D .............................................................................................. 34
XII.
Expériences acquises ............................................................................ 35
1. Les points positifs ...................................................................................... 35
2. Les points négatifs ..................................................................................... 35
3. Conclusion ................................................................................................. 35
Références .......................................................................................................... 36
Annexes............................................................................................................... 37
ESSI2 – Juin 2005
4
Résumé
Projet Longhorn : découvrir le nouveau système d’exploitation de Microsoft :
Windows Longhorn, en étudiant les nouvelles technologies qu’il renferme et
pouvoir développer un logiciel utile voire innovant bénéficiant de ces techniques.
Le logiciel en question consiste en une application qui scanne les favoris Internet
Explorer de l’utilisateur courant pour en faire des « screenshots » (captures
d’écran) de façon automatique et quasi-instantanée. L’utilisateur peut naviguer
parmi les miniatures affichées pour ensuite ouvrir s’il le souhaite le site web
associé. Le sujet a été présenté de façon spontanée à M. Jean-Paul Stromboni
vers la fin mai et fût accepté ; nous n’avons eu aucun problème à convaincre M.
Johny Bond de nous encadrer pour mener à bien notre projet.
Ce nouveau système d’exploitation renferme trois nouvelles technologies : Avalon
(nouvel aspect graphique), Indigo (nouvelle gestion de la communication) et
WinFS (nouveau système de gestion de fichiers supportant une base de données
SQL server destiné à remplacer le NTFS actuel). Nous nous sommes
principalement basé sur Avalon pour les interfaces graphiques de notre
programme. En effet, il y a deux interfaces graphiques pour montrer les
possibilités 2D et 3D du moteur graphique de Longhorn. Une interface XP a
également été réalisée pour montrer les différences entre les deux systèmes.
Nous n’avons utilisé, pour développer, que des outils en version bêta car la sortie
commerciale de Longhorn n’étant prévu que vers mi-2006, aucun outil adapté ne
se trouve en version finale (nouveau Visual Studio, Kit de développement et
Avalon pour ne citer qu’eux). Le langage de nos applications est le C#, langage
de programmation orienté objet proche du Java. Celui-ci est couplé avec le
langage de programmation d’Avalon : le XAML (« zammel »). Pour garder une
certaine cohérence, C# a également été utilisé pour la version XP. Nous avons
choisi un système de gestion de version afin de pouvoir effectuer des
sauvegardes de notre code en évitant le plus possible les conflits d’édition.
Notre avons divisé nos programmes en quatre parties fondamentales : les
interfaces graphiques (au nombre de 3), le contrôleur (partie centrale et relais de
communication), le ScreenMaker (qui s’occupe de prendre les captures), et
IOFileSystem qui s’occupe les lectures/écritures sur le disque.
Nous avons rencontré quelques difficultés tout au long des trois semaines du
projet. En effet, plusieurs incompatibilités se sont révélées entre les différents kits
de développement et les outils de Avalon. Le développement des applications
s’est déroulé sous XP et non pas sous Longhorn car la dernière version bêta
publique ne le permettait pas. Nous avons heureusement eu l’aide bénéfique de
M. Pierre Lagarde de Microsoft France qui nous a aidé à faire fonctionner nos
programmes sous Longhorn et sans qui cela n’aurait jamais été possible.
Les programmes tournent correctement. Aucun bug majeur n'
est présent dans les
différentes éditions. Nous avons réussi à mener à bien nos objectifs en utilisant
Avalon et ses possibilités ; pas complètement malheureusement du fait du
manque d’outils et du manque de documentation. Les captures sont d’excellente
qualité et quasi-instantanées pour l’utilisateur. Nous avons également beaucoup
appris au niveau logiciel et langage car tout était nouveau pour nous mais
également au niveau équipe ou l’entente était présente et où régnait une bonne
humeur malgré le stress permanent des incompatibilités et des erreurs
incompréhensibles. Ce fut une véritable aventure humaine !
ESSI2 – Juin 2005
5
I. But et composition du projet
Le projet consiste à se familiariser avec le nouveau système d’exploitation de
Microsoft nommé Longhorn et de voir la différence entre XP et ce dernier.
Pour cela, le logiciel devra avoir une interface pour XP (Winform classique) et une
interface Longhorn (Avalon).
Nous avons décidé de faire un logiciel permettant de naviguer et d’ouvrir les sites
rattachés aux captures d’écran faites des favoris d’Internet Explorer de
l’utilisateur. L’interface permettant de naviguer devra être la plus intuitive et
agréable pour l’utilisateur final.
Le sujet du projet a été pensé et proposé par le groupe composé par :
Stéphane Blanc,
Nicolas Bousquet,
Alban Campo,
Et Gilles Réant,
à Monsieur Johny Bond. Il s’inscrit dans le projet de fin du second semestre de la
2ème année de l’E.S.S.I. (Promotion 2004/2005).
Le projet s’étend sur 3 semaines et se conclut par une soutenance en anglais et
la remise des différents livrables (Annexe C).
II. Longhorn (Avalon, Indigo, WinFS et les autres)
Microsoft Codename Longhorn est le prochain système d’exploitation de la firme
de Redmond. Il devrait, d’ici sa commercialisation prévue au premier semestre
2006, remplacer peu à peu le système d’exploitation courant à savoir Windows
XP.
Pour le moment, Longhorn se situe en version bêta (dernière build connue est la
5060, présentée par Bill Gates lors du WinHEC 2005).
Screenshot du bureau de la build 5048 (http://www.winsupersite.com)
ESSI2 – Juin 2005
6
Néanmoins, lors de notre présentation, M. Lagarde nous as gentiment prêté la
version 5089, très proche de la future Beta1 qui sortira début juillet. Longhorn
constitue en un système d’exploitation unifié qui exploitera le plus possible les
capacités 3D de l’ordinateur. Les applications qui seront développées
bénéficieront du système Win32 actuel offert par XP et mais également de WinFX
qui, couplé avec le nouveau .NET Framework v2, constitue le modèle de
développement pour la plate-forme Longhorn (celui-ci sera détaillé plus tard).
Longhorn possède beaucoup de nouveautés par rapport à son aîné d’XP qui
peuvent être résumées grâce au schéma suivant :
Architecture de Longhorn
Bien sûr Longhorn contiendra les « fondamentaux » qui permettront de faire
tourner l’essentiel du système mais l’intérêt réside en trois nouveaux piliers
essentiels :
Avalon pour la couche de présentation
WinFS pour manipuler les données (Base de données sur le FileSystem)
Indigo pour gérer les communications
Initialement, Longhorn devait sortir avec tous ses composants mais cela ne sera
pas le cas et Microsoft a décidé qu'
Avalon et Indigo sortiraient tout d’abord pour
XP afin que les développeurs puissent découvrir ces technologies et puissent dès
à présent développer pour le futur système d’exploitation. Nous avons décidé de
faire partie de ces développeurs. Ces deux
piliers de Longhorn étant sortis au préalable,
WinFS sera donc reporté et sortira plus tard que
l’OS lui-même.
Nous allons donc voir plus en détail Avalon, car
c’est cette partie que nous avons voulu exploiter
pour notre programme. Avalon est un outil pour
manipuler une nouvelle interface graphique
fournie par Longhorn avec de la 3D pouvant être
affichée sur le bureau.
ESSI2 – Juin 2005
7
Avalon contient un moteur de rendu
vectoriel mais également un moteur 3D
(nommé Aero, gérant l’affichage du
bureau).
Aero Screenshot (build 5089)
Afin d’utiliser Avalon, les développeurs de Microsoft ont introduit un nouveau
langage de programmation basé sur XML qui se nomme XAML (eXtensible
Application Markup Language).
Exemple de code source XAML affichant une fenêtre vide
Le but de XAML se veut d’être facile à apprendre, à écrire, et à relire. On conçoit
une application par description. Le code de présentation est séparé du code
applicatif (en C#) pour une meilleure séparation du graphiste et du développeur.
ESSI2 – Juin 2005
8
III. Etude de l’existant
Il existe énormément de programmes ayant de près ou de loin attrait aux favoris
des navigateurs Internet (au moins une cinquantaine, rien que pour les logiciels
gratuits). Néanmoins, il n'
existe à notre connaissance qu'
un seul logiciel (sous la
forme d'
un plug-in pour Internet Explorer) permettant d'
afficher une capture
d'
écran d'
un site donné, en utilisant le principe du moteur de recherche :
(http://www.girafa.com)
La toolbar Girafa (gratuite, pour Internet Explorer uniquement, version 2.12.05)
permet de faire une recherche sur le web, & d'
afficher des miniatures des pages
d'
accueil des sites proposés.
Fenêtre d'
Internet Explorer 6 SP2 avec la toolbar Girafa (recherche sur "lemonde")
Cependant, comme on peut le voir sur la capture ci-dessus, les miniatures
proposées ne sont pas synchronisées avec le site web réel (les captures ont
parfois plus d'
un an). De plus, les pages sont proposées la plupart du temps
plusieurs fois (comme le ferait un mauvais moteur de recherche). Enfin, le site
web exact demandé n'
est quasiment jamais affiché (excepté les sites web
mondialement connus), car ce logiciel se base sur une base de données finie &
rarement rafraîchie. Nous avons donc considéré que ce logiciel était
suffisamment éloigné de nos besoins pour justifier le codage d'
un nouveau
logiciel.
Nous avons également à un certain moment durant la période de codage basé
notre programme sur le nouveau moteur de recherche d'
AOL
(http://www.recherche.aol.fr/rech?q=longhorn) (basé sur une technologie
développée
par
une
entreprise
française
nommée
Exalead
(http://beta.exalead.fr/search), permettant d'
afficher également une miniature des
sites web visités, la fréquence de rafraîchissement étant sensiblement plus
élevée pour les sites très visités. Néanmoins, ces solutions présentent les mêmes
ESSI2 – Juin 2005
9
limitations que la solution Girafa. Nous avons très rapidement abandonné l'
idée
d'
utiliser les images stockées sur leur serveur.
Moteurs de recherche d'
AOL & d'
Exalead (mot recherché : "Longhorn")
IV. Description des fonctionnalités de base et avancées
souhaitées
Nous avons réfléchi sur les fonctionnalités de notre logiciel qui permettent de
gérer les favoris de l’utilisateur. Au cours de plusieurs brainstormings effectués
avant le début et au premier jour du projet, nous en avons déduit que notre
programme aurait les trois fonctionnalités de base suivantes :
La possibilité de scanner les favoris depuis le dossier de l’utilisateur courant
en regardant dans la base de registre la clé HKEY_USERSS-1-519\Software\Microsoft\Windows\CurrentVersion\Explorer\Us
er Shell Folders\Favorites qui correspond au chemin pointé par
%USERPROFILE%\Favori dans les versions francophones de Windows;
%USERPROFILE% étant une variable d’environnement.
La possibilité de prendre une capture d’écran d’un site des favoris de façon
totalement transparente à l’utilisateur en utilisant le moteur de rendu de
Internet Explorer.
La possibilité d’ouvrir dans le navigateur par défaut (Firefox, Opera,
Netscape, IE, …) le site Internet correspondant au favori sélectionné.
Nous avons également réfléchi sur les diverses optimisations que nous pouvions
apporter à notre logiciel de façon à ce qu’il soit le plus agréable pour l’utilisateur.
Ces options sont importantes mais pas indispensables et sont implémentées sur
certaines versions du programme :
La possibilité d’ajouter/modifier/supprimer un favori depuis l’interface
L’affichage de captures en 3D en utilisant XAML
La mise en forme en « roue de moulin » (mise en forme abandonnée depuis)
La mise à jour automatique d’un screenshot en détectant une modification
de la page à distance.
ESSI2 – Juin 2005
10
V. Outils utilisés
1. RunTimes + SDK
Lorsque nous avons voulu coder pour Microsoft Windows Longhorn, nous
avons commencé à installer les outils nécessaires pour programmer sur ce
système d'
exploitation. À ce jour, pour pouvoir faire tourner un programme
Longhorn (basé sur les technologies Avalon & Indigo), il faut installer quelques
librairies : la dernière version du .NET Framework (.NET Framework 2.0
Redistribuable Package Bêta 2 (x86), 22,4 Mo, gratuit, disponible sur
http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=7a
bd8c8f-287e-4c7e-9a4a-a4ecff40fc8e), ainsi que les version Bêta 1 RC
d'
Avalon
& d'
Indigo (Microsoft® Pre-Release Software Code Named
“Avalon” and “Indigo” Beta1 Release Candidate, souvent appelées May Beta1
RC, 2,16 Mo + quelques Mo téléchargés durant l'
installation, gratuits,
disponibles sur :
http://www.microsoft.com/downloads/details.aspx?familyid=b789bc8d-4f254823-b6aa-c5edf432d0c1&displaylang=en).
Le .NET Framework est l'
évolution de la version courante de l'
environnement
managé de Microsoft (1.1) couramment utilisée de nos jours, & qui sera partie
intégrante de Longhorn. Avalon & Indigo ont été décrits plus haut.
Ces librairies permettent uniquement de lancer le programme. Or, elles ne
sont pas suffisantes pour programmer en XAML. Pour cela, il est nécessaire
d'
installer un SDK (Software Development Kit) nommé WinFX SDK (version
Mai 2005 (associé aux RunTimes Avalon & Indigo de même version), gratuit,
351 Mo, disponible sur :
http://download.microsoft.com/download/5/4/0/5407D6E4-740E-413E-8E91EF7AC53A478A/en_winfx_sdk_beta1_RC.iso). Cet outil nous propose
quelques exemples de programmes (quelques-uns étant, soit-dit en passant,
syntaxiquement incorrects & ne compilant pas), plus un outil nommé
MSBUILD permettant, en se situant dans le dossier contenant les sources du
programme via une invite de commandes DOS, de compiler le programme &
de générer le fichier .exe associé. Il est à noter que nous n'
avons évidemment
que très rarement utilisé cette commande (uniquement en cas de débogage
avancé), nous lui avons préféré l'
environnement de développement intégré
Visual Studio. Nous avons néanmoins installé le WinFX SDK car il est
indispensable à VS pour programmer pour Longhorn. Il est évident que
l'
intégralité des outils susnommés est en version Bêta, & intégralement en
anglais, que ce soit les programmes ou leur documentation en anglais. Nous
n'
avons installé l'
intégralité de ces programmes que vers la fin du projet, Gilles
ayant été le seul à coder pour Longhorn pendant les 2 premières semaines.
+
+
WinFX
ESSI2 – Juin 2005
11
2. Développement
A. Visual Studio 2005 bêta 2
Afin de développer notre application, nous avons été obligés d’utiliser le
futur Visual Studio de Microsoft prévu pour la fin de l’année (nom de code
Whidbey). Nous nous le sommes procurés en nous inscrivant sur le site
officiel pour récupérer les DVD officiels.
En effet, la version courante (2003) disponible sur le site de l’E.S.S.I. par
l’intermédiaire de l’alliance MSDN ne peut pas fonctionner avec le .NET
Framework v2 qui est lui aussi en édition Beta 2.
Cette version est assez simple et intuitive d’utilisation notamment pour
générer des applications Windows avec le langage C#. Les principales
nouveautés par rapport à la version précédente sont :
Refactoring du code (changement des références, pas en XAML),
IntelliSense amélioré (auto-complétion, pas en XAML),
Diagramme de classe généré et dynamique,
Génération intelligente et intuitive de code web ASP.NET 2.0.
Fenêtre de Visual Studio 2005 beta 2
ESSI2 – Juin 2005
12
B. C#
Le langage C# créé par Microsoft dans le but de concurrencer Java, est
devenu un standard approuvé par la spécification ECMA-334 de
l'
association européenne ECMA (European Computer Manufacturer'
s
Association) en décembre 2001.
Le langage C# permet de développer des applications Windows et Web en
se basant sur l'
architecture .NET. Ce langage a été conçu dans le but
d'
être indépendant de la plate-forme et de l'
environnement d'
exécution.
Normalement, le compilateur C# devrait pouvoir fonctionner partout où les
types et fonctionnalités spécifiés dans l'
ECMA-334 sont correctement
prises en charge par l'
environnement d'
exécution.
Actuellement, l'
environnement d'
exécution du langage commun (CLR :
Common Language Runtime) de la technologie.NET est évidemment, le
domaine de prédilection du langage C#. Le mécanisme de traitement du
code source écrit en C# par la plateforme Microsoft.NET, produit lors de la
phase de compilation, un code binaire particulier dénommé MSIL
(MicroSoft Intermediate Language), lequel sera interprété ensuite par le
CLR chargé de la transformation en instructions exécutables par la
machine. La technologie .NET met également à la disposition du
programmeur de nombreuses classes du .NET Framework, comprenant de
nombreuses méthodes et propriétés exploitables dans des programmes.
Le langage C# est une savante combinaison des langages C, C++ et Java
en expurgeant la plupart des sources d'
erreurs et en améliorant certaines
fonctionnalités.
Exemple de code c# basique
La gestion de la mémoire par l'
utilisation des pointeurs a été maintenue
tout en veillant à y intégrer un dispositif d'
appel explicite par l'
utilisation de
mots-clés spécifiques.
Le concept d'
héritage multiple dans la programmation orientée objet a été
abandonné au profit de l'
utilisation d'
interfaces.
Le langage C# permet une programmation orientée objet simple et
moderne. Dérivé des langages de programmation C et C++, C# est familier
aux habitués du développement en C, C++ et Java. Effectivement, le
langage C# ne comporte que 77 mots-clés. De plus, la programmation en
C# se révèle intuitive, familière et moins verbeuse produisant du code se
démarquant par sa lisibilité et sa concision. C’est pourquoi nous l’avons
choisi pour le développement de l’interface XP. Pour l’interface Longhorn,
nous l'
avons préféré au VB# trop basique car le code XAML se marie avec
le
C#
pour
le
développement
d’applications
graphiques.
ESSI2 – Juin 2005
13
3. Moyens de communication
A. Forum
Nous avons commencé par communiquer via un forum phpBB2 (Open
Source, version 2.0.15 mise à jour pour l'
occasion afin de corriger
quelques failles de sécurité), installé sur le site web de Gilles, & accessible
via le lien http://longhorn.reant.net. Cela permettait de se partager les
travaux effectués, les liens visités & l'
avancement de l'
installation des
différentes versions des RunTimes & de Longhorn. Cela a été très pratique
avant le début de la période du projet, pour ne pas surcharger nos boîtes
mails de messages longs & pompeux qui n'
auraient probablement pas été
lus. De plus, ce type de forum permet de poster des messages au contenu
riche très facilement, de les éditer après coup, & enfin d'
y avoir accès à
n'
importe quel moment de la journée. Ce type de communication nous a
aussi servi de pense-bête (quand une information nous échappait, une
petite visite sur le forum nous permettait de nous rafraîchir la mémoire).
Enfin, pour Gilles, le coordinateur de l'
équipe, cela a permis de transmettre
des informations à la fois à l'
intégralité de l'
équipe, au tuteur & aux
personnes intéressées par le projet en une seule fois. Il est à noter que ce
forum est ouvert à toute lecture/écriture (sans enregistrement nécessaire),
& qu'
il restera sur le web en vue d'
être une documentation supplémentaire
à notre projet, & éventuellement d'
aider d'
autres personnes cherchant à
coder pour Longhorn.
À la fin du projet, le forum aura contenu plus de 70 messages (répartis
entre les membres de l'
équipe) & affiché les messages plus de 800 fois.
Une partie du forum longhorn.reant.net
ESSI2 – Juin 2005
14
B. SVN ou la gestion de version
TortoiseSVN est un client Open Source (http://tortoisesvn.tigris.org/) pour
serveur Subversion. Subversion est un outil de gestion de version
généraliste. Il permet ainsi de gérer aussi bien des fichiers sources ou des
programmes exécutables. Subversion retient les différentes modifications
qu’on subit ces fichiers et plus généralement la hiérarchie complète de
répertoires. Ainsi on pourra demander quel était l’état du fichier X vendredi
dernier. Subversion permet aussi l’accès d’une même ressource par
plusieurs utilisateurs.
Cette solution nous a été proposée par M. Peter Sanders, qui a stocké
l'
intégralité
des
fichiers
sur
son
ordinateur
à
l'
adresse
svn://svn.essi.fr/cvsroot/2004-05/essi2/proj/longhorn.
Ce serveur nous a principalement servi à gérer l'
avancement asynchrone de
chaque partie de notre projet, mais pourtant basées sur des classes
communes. Nous avons effectué plus de 150 opérations d'
écriture sur ce
serveur.
Un des principaux avantages de TortoiseSVN est de s’intégrer directement &
de façon transparente à l’explorateur de Fichiers Windows.
Principes
Système de gestion de modification concurrente
Un problème courant survient lorsque 2 personnes modifient en même temps
un fichier puis décident d’enregistrer les modifications. Forcément, si aucun
traitement spécifique n’est prévu, une des deux modifications sera plus ou
moins oubliée et le travail associé perdu. Avec Subversion la solution
apportée est la suivante :
Tout le monde peut demander une copie du même fichier ou plus
généralement du projet.
Tout le monde peut modifier sa copie personnelle.
Au moment d’enregistrer ses modifications sur le serveur, si quelqu’un
d’autre a déjà validé des modifications, le serveur prévient l’utilisateur.
L’utilisateur en question regarde les modifications apportées par
l’autre utilisateur et les fusionne avec les siennes. Il publie alors la
version fusionnée sur le serveur.
ESSI2 – Juin 2005
15
C. Direct
Dès le début du projet, nous avons passé l'
intégralité de notre temps de
travail ensemble, ce qui a du coup réduit l'
intérêt du forum (qui a
cependant continué à nous servir pendant le reste du projet).
Nous faisions de petites réunions 2 à 3 fois par jour pour voir où en était le
travail de chacun, & pour prendre des décisions qui nécessitaient l'
avis de
tous. Nous avons également fait assez souvent de longues réunions en
vue de décrire (ou de réécrire) l'
architecture du programme.
Nous rencontrions M. Bond deux fois par semaine pour le tenir au courant
de nos avancées. Nous avons aussi eu différents rendez-vous avec M.
Sanders pour discuter du serveur Subversion. Enfin, nous avons pu
rencontrer M. Pierre Lagarde durant une petite entrevue après son
intervention à l'
IUT qui sera détaillée lors de la recherche de solutions.
La communication directe nous a évidemment permis de transmettre plus
facilement & de façon plus conviviale les informations que nous
souhaitions véhiculer.
D. Rapports quotidiens
Tous les soirs, un rapport journalier était écrit par le coordinateur visant à
résumer les opérations effectuées par chaque membre durant la journée
ainsi que les objectifs à remplir le lendemain. Cependant, il nous a été très
dur de se tenir à ces prévisions, & les différents évènements s’étant
produits durant le projet nous ont obligé de revoir sans cesse notre
planning. Ces rapports restent disponibles soit sur le serveur SVN soit sur
le site web du projet.
E. Mail
Le mail servait principalement à communiquer avec les personnes
extérieures au projet, que ce soit nos contacts chez Microsoft, les
professeurs de l'
E.S.S.I. ou notre tuteur pour prendre rendez-vous. La
partie "relations extérieures" a été gérée par le coordinateur ; les mails
étant néanmoins vérifiés par le reste de l'
équipe avant envois. Nous avons
essayé autant que faire se peut de ne pas utiliser de mail, les autres
moyens de communication nous semblant meilleurs.
Chacun de ces moyens de communication nous a été utile ; ils sont rarement
entrés en concurrence & semblaient plutôt complémentaires. Il est à noter que
nous avons également utilisé à de rares occasions le partage de dossiers en
lecture/écriture Windows, le client de messagerie instantanée MSN
Messenger & le téléphone portable.
ESSI2 – Juin 2005
16
VI. Diagramme de classes
Diagramme de classes simplifié de nos applications
ESSI2 – Juin 2005
17
VII. Description détaillée
1. Contrôleur
Cette classe se situe au centre du programme.
Elle sert de pont entre chaque partie. La
plupart de ses méthodes ne consistent qu'
en
un rappel de la fonction associée dans une
autre classe. Les seules méthodes qui peuvent
être appelées sans le contrôleur sont les rares
méthodes statiques. Le contrôleur contient
aussi quelques méthodes qui lui sont propres :
ouverture d'
une page web à partir d'
une URL.
De plus, il effectue un travail qui lui est spécifique : vérifier qu'
une capture
d'
écran est bien contenue dans un favoris, ou vérifier si elle existe déjà dans le
dossier des captures; auquel cas il appelle ou non la classe ScreenMaker
pour faire la capture, uniquement si nécessaire. Cela permet de gagner un
temps précieux lorsque l'
Interface graphique demande une série d'
images. Il
est aussi chargé de contenir la liste des favoris; liste qui sera lue par l'
Interface
graphique.
2. Interfaces graphiques
Nous avons réalisé trois interfaces graphiques pour notre programme. Trois
interfaces différentes pour montrer les capacités d’un programme utilisant les
technologies Longhorn et pour pouvoir comparer avec les technologies
existantes.
A. XP
Nous
avons
développé
une
interface XP de
notre programme à
la demande de
notre tuteur. En
effet, il pensait bon
de
pouvoir
comparer ce que
l’on peut réaliser de
nos jours avec les
outils existants sur
Windows XP et ce qui va exister sous Longhorn.
L’interface graphique de Windows XP a été entièrement réalisée en
langage C#. La mise en forme des composants dans la fenêtre a été
réalisée grâce à l’éditeur WYSIWYG (What You See Is What You Get) de
Visual Studio 2005.
ESSI2 – Juin 2005
18
Interface WYSIWYG de Visual Studio 2005
L’interface est scindée en trois principaux blocs :
La visualisation des captures d’écran des favoris.
L’affichage sous forme d’arborescence de la liste des favoris
Les informations sur le favori courant
La visualisation des images se fait dans un objet de type PictureBox qui
est un composant qui peut contenir un objet de type Image.
L’arborescence des favoris s’obtient en appelant une méthode du
contrôleur qui renvoie une arborescence des favoris sur le disque dur. Le
détail de cette méthode sera expliqué dans la partie prévue à cet effet (cf.
IOFileSystem).
A chaque clic de la souris sur un élément de l’arbre, on affiche les
informations de l’élément sélectionné dans le Label situé dans la dernière
zone de l’application. De plus, on essaie de récupérer un screenshot du
site courant si l’utilisateur est connecté à Internet et si un screenshot
n’existe pas déjà, sauvegardé dans le dossier prévu à cet effet. Un
message d’erreur apparaît si l’opération a échouée pour essayer d’orienter
l’utilisateur.
Message d’erreur en cas d’échec de
prise d’un screenshot
ESSI2 – Juin 2005
19
B. Longhorn
a. Version 2D
Diagramme de classes pour l’interface 2D
L'
Interface Graphique Avalon 2D est composée de quelques classes.
Le reste du programme a besoin d'
une InterfaceGraphiqueGenerique,
que nous avons implémenté pour créer cette Interface 2D.
Au démarrage du programme, l'
InterfaceGraphique2D est lancée. Cette
dernière crée les premiers objets nécessaires : FenetreAvalon2D &
Controleur, entre lesquels elle servira de pont (pour la méthode
ReceptionImage, dont il a été question précédemment). L'
IHM
proprement dite est contenue dans la classe FenetreAvalon2D, qui est
partial, c'
est-à-dire qu'
elle est codée à la fois dans un fichier XAML &
dans un fichier C#. Dans l'
ensemble, le fichier XAML décrit la fenêtre au
démarrage, & le fichier C# décrit son évolution en fonction de différents
évènements. Néanmoins, il est possible avec Avalon de coder une
interface 100% avec C#. Nous n'
avons cependant pas utilisé cette
méthode qui court-circuitait les avancées d'
Avalon, malgré le fait que
XAML nous ait engendré un très grand nombre de problèmes.
La Fenetre permet d'
afficher la liste des favoris dans le dossier courant
(les Favoris d'
Internet Explorer étant stockés dans une arborescence),
& de naviguer dans ces favoris. L'
explication de cette Interface sera
reprise plus tard.
Resources & Settings servent à contenir les Ressources & les
Paramètres contenus dans le programme (en dur dans le .exe). Nous
avons essayé de les utiliser, mais elles semblent poser problème avec
la langue du système d'
exploitation. Malgré le fait que notre code
semble correct (directement récupéré sur un tutorial officiel), le
programme compile mais plante au démarrage. Nous avons
malheureusement donc du stocker certaines images dans le dossier
courant, & non à l'
intérieur du programme comme nous l'
avions prévu.
Ces 2 classes ne servent donc a priori à rien.
ESSI2 – Juin 2005
20
b. Version 3D
Diagramme de classe de la version Longhorn 3D
L’interface graphique en 3D est composée de deux gros fichiers (Un
fichier XAML et un fichier C# pour le piloter).
Nicolas et Alban ont collaboré pour faire cette interface et ont
développé des fonctionnalités pour permettre facilement de rajouter des
nouvelles animations. En effet, nous possédons des hashtable pour
contenir l’association bouton, animations associées aux évènements du
bouton et des fonctions permettant de naviguer dedans. Il y a des
fonctions pour arrêter ou suspendre l’ensemble des animations et de
les reprendre quand on le souhaite. Toutes les animations sont définies
dans le XAML et permettent de manipuler les mesh (Objet dans
l’espace 3D). Les fonctionnalités permettront d ‘accélérer le
développement future que nous ou d’autre pourront utiliser.
Bien évidemment, l’interface est spécialisée pour un type d’utilisation et
d’affichage des informations. Quelques évènements de la souris sont
attrapés comme le click gauche, droit, la roulette. D’autres évènements
sont codés, comme l’entrée et la sortie d’un objet 3D.
On peut considérer cette classe comme une petite API et bien
évidemment grâce aux nombreuses possibilités de XAML nous
pourrions faire beaucoup plus. Les bugs rencontrés lors du
développement de ces fonctions ont été rectifiés, mais bien sur le
temps est l’utilisation est le meilleur d’indiquer la solidité du code.
ESSI2 – Juin 2005
21
3. « ScreenMaker »
Le ScreenMaker est un objet crée par le Controleur qui devra se charger de
se connecter à Internet pour prendre les aperçus (ScreenShot) des Urls
indiquées. Le constructeur de SreenMaker prend en paramètre un pointeur de
fonction (nommé Delegate en C#) et une fenêtre (Objet de type Form au sens
System.Windows.Forms).
Le pointeur de fonction nous permet de savoir quelle fonction est appelée
lorsque la capture est terminée. Cela est nécessaire car la gestion du
navigateur est asynchrone et donc nous ne pouvons pas avoir un
fonctionnement linéaire.
La fenêtre nous permet de créer notre objet control pour le navigateur. Cela
est une contrainte rencontrée et qui nous a apporté son lot d’inconvénients.
En effet, dans cette version de ScreenMaker, il se peut que l’utilisateur
entende les sons joués par le navigateur lors de l’ouverture du site et de sa
capture. Même si la capture se fait de façon transparente, il reste ce problème
de son dû à la nécessité de créer le control pour le navigateur.
L’objet connaît donc lors de sa création la fonction à appeler lors de la fin de la
capture et le moyen de créer le navigateur grâce à la Form.
Le Contrôleur, lorsqu’il désire faire une capture demandée, appelle la méthode
Capture sur l’objet ScreenMaker. Cette méthode prend un objet
ParamCapture. Il contient comme, son nom l’indique, les paramètres
nécessaires au ScreenMaker pour faire sa capture. Il contient les propriétés
(Attributs possédants les méthodes get et set) permettant d’indiquer les
dimensions de la fenêtre du navigateur (DimCaptureX DimCaptureY).
Il contient aussi les propriétés indiquant la taille du screenshot souhaitée
(DimResizeX DimResizeY). Ces deux dernières ne sont pas exploitées et
ScreenMaker renvoie le screenshot avec les dimensions DimCaptureX,
DimCaptureY.
Pour finir, ParamCapture contient les propriétés Url et TimeOut qui précisent
respectivement l’adresse du site à capturer et le temps maximum autorisé.
La mise en place de la capture fût plus longue que prévue car nous avons
rencontré des difficultés inattendues en ce qui concerne la gestion du
navigateur et des différentes approches possibles pour la capture. En effet,
plusieurs voies se sont offertes à nous, avec bien sur pour chacun leurs
défauts et leurs qualités. Après études de ces différentes possibilités, nous
avons adopté l’approche suivante.
Utiliser un IHTMLDocument2 et par la suite récupérer respectivement un
IHTMLElement puis un IHTMLElementRender pour enfin écrire dans
l’image.
Cette partie a nécéssité la moitié de l’équipe (Alban Campo et Nicolas
Bousquet) pendant environ 9 jours.
ESSI2 – Juin 2005
22
4. Autres
A. IOFileSystem
Classe IOFileSystem et ses méthodes
C’est la classe qui gère, comme son nom
l’indique, la lecture et l’écriture sur le disque dur.
Elle permet donc d’écrire une image prise par le
ScreenMaker (dans la mémoire vive) de façon
persistante dans le répertoire de l’application
selon le format qui est spécifié dans EXTENSION
(par défaut PNG).
Durant la première moitié du projet, cette classe
était séparée en deux autres classes:
IO, qui reprend la plupart des fonctions présentes maintenant
Synchronisation, qui s’occupe de scanner les favoris pour les
stocker dans un objet CompositeFavori que l’on détaillera dans la
partie suivante.
Après avoir donc passé la moitié du projet, nous avons décidé que
Synchronisation consistait en une lecture de fichiers sur le disque dur ;
voila pourquoi nous avons fusionnée ces deux classes en une seule.
La synchronisation des favoris étant une des fonctionnalités primordiales
de notre programme, nous allons la détailler : la méthode appelée se place
dans le dossier correspondant à celui par défaut de l’utilisateur
(PATH_FAVORIS) et parcours récursivement chaque répertoire pour créer
des objets de type ElementFavori qui contiennent des attributs qui seront
détaillés plus tard. L’objet renvoyé contient donc toutes les informations sur
les favoris de l’utilisateur, on l’appellera « root ».
ESSI2 – Juin 2005
23
B. ElementFavori et ses filles
Schéma Composite représentant la gestion des favoris
Afin de gérer les favoris pour les stocker en mémoire vive, nous avons
décidé d’utiliser le schéma de conception « Composite ». Étudié en cours,
ce schéma convient parfaitement pour l’utilisation que nous voulions en
faire. En effet, les fichiers .url représentant les favoris de l’utilisateur sont
stockés dans la classe Favori. De ce fait, un Favori contient donc :
L’état de son image sous forme de type énuméré (capturé,
problème, non capturé),
Le chemin vers l’image stockée sur le disque dur sous forme de
chaîne de caractères,
l’image de son screenshot (objet Image)
le nom de son image (juste le nom du fichier avec son extension)
l’URL du favori (le site Internet vers lequel il est rattaché) sous
forme de string.
L’intérêt de ce schéma vient du fait que, gérant dossiers et fichiers, un tel
schéma permet d’englober les deux types indifféremment. En effet, cela
est géré grâce à la classe ElementFavori qui possède un champ commun
à ces deux types de données qui est leur nom. Pour les fichiers, le nom est
le nom du fichier .url avec l’extension, pour les dossiers le nom est le nom
tel qu’il apparaît sous Windows.
CompositeFavori est donc la classe qui va gérer les dossiers. Comme
Favori, elle hérite (d’après le diagramme) d'
ElementFavori mais en plus
contient des éléments de type ElementFavori. Grâce à cette spécificité de
ESSI2 – Juin 2005
24
ce schéma, cette classe peut donc contenir des objets de type Favori
(fichiers) ou des objets de type CompositeFavori (dossiers), ce que nous
voulons pour élaborer notre arborescence récursive.
Remarques :
Afin de respecter au mieux le schéma « Composite », nous avons
créer une classe DossierFavori qui hérite de CompositeFavori pour
gérer les dossiers, c’est donc elle qui va être utilisée tout au long
des étapes dans le programme.
La classe ElementFavori hérite de TreeNode qui est une classe C#
qui gère les nœuds dans une arborescence. Cet héritage a facilité la
représentation dans un arbre pour l’interface graphique de la
version pour XP. Les autres interfaces ne se servent pas de cette
fonctionnalité.
VIII. Difficultés de compatibilité
Dès le début de notre projet (& même avant), il était prévu de faire tourner le plus
rapidement possible un programme directement sous Longhorn (la dernière
version Bêta publique librement téléchargeable, nommées build 4074, datait
d'
une année). Cette idée nous était venue après une démonstration des diverses
technologies Longhorn faite fin avril au WinHEC 2005. Or, la version des
RunTimes que nous utilisions était bien plus récents que la version Bêta de
Longhorn que nous avions. Nous avons donc naturellement commencé à
chercher une version plus récente (la build 5060 étant censée marcher avec nos
programmes). Après une semaine de recherches infructueuses, nous étions
plutôt découragés. Toutes les bêtas récentes étaient réservées à de très rares
développeurs, & aux ingénieurs Microsoft. M. Partouche n'
était pas parvenu à
obtenir une de ces versions, & le contact de M. Bond n'
a pas pu trouver une
version récente. Nous avons donc contacté Mme Blandine Berg, Relations
Enseignement Supérieur, Chef Programme MSDN Academic Alliance, qui nous a
elle-même redirigé vers M. Pierre Lagarde, Relations techniques Développeurs et
speaker aux DevDays (cf. Rencontre avec un ingénieur Microsoft).
Nous lui avons expliqué notre problème, & il nous as d'
abord affirmé que les
versions de WinFX & de Longhorn n'
étaient pas synchronisées, & donc qu'
il était
impossible de faire tourner un quelconque programme Avalon sous Longhorn.
Nous lui avons transmis la vidéo du WinHEC 2005, & il a commencé à chercher
activement une version de Longhorn compatible avec Avalon, tout en nous
transmettant après sa conférence à l'
IUT la dernière version des RunTimes & du
SDK (version Beta1). Il a pu tester quelques versions de Longhorn, sans succès.
La version Beta1 des RunTimes présentait pour notre programme de très
nombreuses incompatibilités avec la version précédente (de très nombreuses
balises avaient changées de nom, quand elles n'
avaient pas totalement disparu),
mais nous avons néanmoins essayé de le rendre compatible.
ESSI2 – Juin 2005
25
Il va sans dire que nous avons par conséquent installé & désinstallé de très
nombreuses fois les différentes versions des librairies en tous genre, pour
effectuer les différents tests. Vers le début de la dernière semaine, Pierre nous a
conseillé d'
abandonner l'
idée de tenter de rendre notre programme compatible, &
nous as annoncé continuer à chercher une version compatible avec la Beta1 RC,
ce qu'
il a finalement réussi (capture d'
écran à l'
appui) mercredi soir.
Microsoft Windows Codename Longhorn Build 5089.winmain.050615-1910
avec différents programmes Avalon Microsoft
Nous avons donc continué à coder nos Interfaces Avalon 2D & 3D. Durant
l'
après-midi de jeudi, il s'
est avéré que l'
un de nos composants nécessitant une
DLL spéciale (AxWebBrowser) posait un problème avec une version récente de
Longhorn, problème que nous avons essayé de résoudre.
Nous avons tenté d'
utiliser des programmes permettant de coder directement en
What You See Is What You Get (WYSIWYG), notamment en utilisant différents
outils
tels
que
ZAM3D
(gratuit
en
version
Bêta,
28
Mo,
http://www.erain.com/Products/ZAM3D/Default.asp), Aurora (gratuit en version
Bêta,
codé
lui-même
en
Avalon,
8,56
Mo,
http://www.mobiform.com/Eng/aurora.html) ou encore Xamlon (gratuit en version
Bêta,
2,63
Mo,
http://www.xamlon.com/software/xamlonpro/winforms/).
Cependant, ces programmes sont très instables, génèrent du code très
approximatif & peu lisible & intégralement incompatible avec la version des
RunTimes que nous avons utilisé. Il ne nous a même pas été possible de
récupérer une partie de ce code pour l'
adapter à notre programme.
ESSI2 – Juin 2005
26
Il nous a alors été nécessaire de calculer nous-mêmes les coordonnées en 3D de
nos objets durant les animations. Il est à noter que la prochaine version de Visual
Studio réalisée pour XAML (Orcas) ne sortira pas avant fin 2007, & que l'
outil
WYSIWYG XAML de Microsoft (Sparkle) n'
est pas encore disponible en version
Bêta.
Enfin, il est à noter qu'
Avalon n'
étant pas encore optimisé, il nécessite une
configuration gargantuesque pour un affichage pourtant raisonnable.
IX. Recherches de solutions
1. Le Web
Bien entendu, la toile a été le principal vecteur de recherche de solutions pour
les problèmes de code que nous avons rencontré. Elle a notamment été
beaucoup utilisée pour le code du ScreenMaker en essayant de récupérer
quelques bouts de code. Malheureusement, cette partie n’ayant jamais été
codée auparavant par d’autres communautés de programmeurs, il a donc été
très difficile voire même impossible d’obtenir de l’aide sur divers forums ou
blogs. La plupart des questions posées sur les forums sont restées sans
réponse.
Les recherches sur le web ont été faites en intégralité à partir du moteur de
recherche de Google (http://www.google.fr & http://www.google.com).
Nous avons également longuement cherché sur les sites officiels de Microsoft
afin de trouver diverses informations sur les versions des SDK et des
RunTimes pour pouvoir faire correctement tourner nos exécutables.
La plupart des sites Internet intéressants se trouvent dans la partie
« Références » & sur le forum longhorn.reant.net.
2. Contact avec Microsoft France
Nous avons essayé plusieurs possibilités pour trouver une solution au
problème de version de Longhorn ainsi que des SDK associés. Pour cela
Alban Campo a fait intervenir un de ces contacts (Mme Blandine Berg) chez
Microsoft France pour voir ce qu’elle pourrait faire à ce sujet. Après plusieurs
mails, elle nous a mis en contact avec M. Pierre Lagarde. Elle nous a aussi
envoyé une invitation pour rencontrer cet ingénieur.
ESSI2 – Juin 2005
27
3. Rencontre avec un ingénieur Microsoft
Grâce à Mme Blandine Berg, nous avons
pu rencontrer M. Pierre Lagarde lors du
forum des professions de l’IUT à l’IUT de
Nice fabron dans le cadre d’une
conférence sur le thème : « Nouveautés
.NET v2, ASP.NET v2, Mobilité ».
Entré en janvier 2003 chez Microsoft,
dans la division développer .NET en
temps que « Relations techniques
Développeurs », il a permis de nous aider à faire fonctionner nos exécutables
sous Longhorn avec une version du système d’exploitation interne à Microsoft.
Nous avons conversé longuement avec lui avant de le rencontrer à sa
conférence pour tester les derniers SDK.
En parallèle, il a fait ses tests pour essayer de faire marcher des programmes
codés avec la version beta 1 RC des SDK sous différente version de
Longhorn.
Cela nous permettra de faire tourner nos applications sur le portable apporté
lors de notre soutenance.
X. Planning des journées et ordonnancement du travail
Afin d’obtenir les rapports journaliers du projet qui explique le travail effectué par
chaque membre du groupe, vous pouvez aller sur le site web du projet à
l’adresse : http://www-local.essi.fr/ProjetJuin2005/Projet19/index.html rubrique
« log book ».
Les fichiers sont au format .doc
ESSI2 – Juin 2005
28
XI. Résultats obtenus
1. XP
Aperçu de l’interface finale pour la version XP
Aperçu de l’interface finale pour la version XP (mouseover sur l’image)
ESSI2 – Juin 2005
29
L’interface prévue pour XP a respecté les fonctionnalités de base qui étaient
énoncées dans les descriptions des fonctionnalités.
La recherche des favoris de l’utilisateur se fait au démarrage du programme et
une arborescence est affichée dans la partie prévue à cet effet ; l’utilisateur
peut ainsi naviguer. A chaque clic de souris sur un nom de favori, un appel à
un screenshot est lancé automatiquement. Si une image existe déjà, on
affiche l’image courante sinon on lance la capture sur Internet et on l’affiche.
Il est possible d’obtenir les informations du favori dans la partie inférieure de la
fenêtre, un grossissement du favori est disponible lorsque l’on passe la souris
sur l’image chargée. Cela permet un certain confort pour l’utilisateur car il peut
distinguer voire lire les caractères présents sur la page capturée.
L’utilisateur peut également forcer la prise d’un screenshot d’un de ces favoris
pour mettre à jour l’image associée sur le disque dur.
Toutes les fonctionnalités supplémentaires n’ont pas pu être implémentées
dans cette interface. Seul la gestion des favoris sur le disque
(ajout/modification/suppression) a été ajoutée, rendant l’interface un peu plus
complète (ces mêmes fonctionnalités existant déjà dans la gestion des favoris
sous Internet Explorer). D’autres petites fonctionnalités utiles ont été ajoutée
comme le vidage du cache image de l’application ainsi que le réglage de la
transparence de la fenêtre.
Le résultat obtenu est donc très satisfaisant et remplit parfaitement les qualités
d’un bon programme Windows malgré quelques bugs minimes.
2. Longhorn
A. Version 2D
Interface 2D pour Longhorn utilisant Avalon
ESSI2 – Juin 2005
30
L'
utilisation de ce programme est très simple : au démarrage, il va cherche
l'
intégralité de vos Favoris Internet Explorer, & va se positionner dans le
dossier de départ. Il va commencer à effectuer les captures d'
écran, qui
s'
afficheront au fur & à mesure qu'
elles seront effectuées. Lorsque vous
sélectionnez une des miniatures, elle s'
affiche en grand à droite. Vous pouvez
naviguer dans la liste de droite entre vos différents favoris, quelques
informations sur ces derniers étant affichées (nom du site, adresse web, taille
de la capture en Ko, date de la dernière capture). Il est également possible de
supprimer le cache disque & de ré effectuer l'
intégralité des captures. Vous
pouvez évidemment naviguer dans les différents dossiers de vos favoris, les
captures étant effectuées automatiquement durant la navigation.
Le programme Interface Graphique Avalon 2D Edition reste dans l'
ensemble
assez peu puissant. Il n'
utilise de loin pas toutes les possibilités offertes par
Avalon, car il nous a été difficile de les cerner toutes avec le peu de
documentation nécessaire (la documentation MSDN sur XAML version Beta1
RC étant sortie une semaine avant la fin du projet).
Nous avons pu néanmoins utiliser quelques fonctions intéressantes. Ce
programme est adapté à toutes les résolutions d'
écran possible. En effet,
l'
image de droite ainsi que la hauteur de la liste se redimensionnent
dynamiquement en fonction de la taille de la fenêtre. De plus, notre
programme offre la possibilité de zoomer avec la molette, ce qui permet de
vérifier que l'
intégralité du programme est codée en vectoriel (à l'
exception
évidemment des captures d'
écran).
Zoom sur la liste des favoris
ESSI2 – Juin 2005
31
De plus, avec le clic-droit, vous pouvez changer le mode d'
affichage de la
bordure de la fenêtre (sans bordure, bordure ToolBox, bordure standard,
bordure 3D). Enfin, grâce au zoom, il est possible de lire la page web aussi
bien que si elle était ouverte par le navigateur lui-même, & donc de voir si cela
vaut le coup de l'
ouvrir ou non au moment où vous avez lancé le programme.
Les 4 types de fenêtres proposées par cette interface
Au final, ce programme occupe un peu moins de 700 Ko sur le disque dur.
Cependant, il est plutôt gourmand en mémoire vive & en mémoire virtuelle
(SWAP). En effet, toutes les captures d'
écran sont stockées en mémoire vive
en haute résolution (1024x768 pixels²), & sous format Bitmap (aucune
compression) pour pouvoir être affichée directement par Avalon. Par
conséquent, la mémoire utilisée par notre programme est directement
proportionnelle au nombre de favoris affichés dans le dossier courant. Par
exemple, avec une vingtaine de favoris dans un dossier, le programme peut
consommer jusqu'
à 260 Mo de mémoire vive en pointe (en moyenne, une
centaine de Mo). Il est à noter qu'
Avalon nécessite pour l'
instant de stocker en
cache les polices de caractère qui lui sont nécessaires, & lance donc
automatiquement un programme (PresentationFontCache.exe), occupant en
moyenne 15 Mo (30 Mo en pointe).
ESSI2 – Juin 2005
32
L'
occupation du processeur reste normale : 30% en moyenne avec un record
de 70%. Le chargement d'
une vingtaine de favoris prend un peu plus d'
une
dizaine de secondes.
Le programme est beaucoup moins gourmand une fois que les captures
d'
écran ont été effectuées, ou qu'
elles ont été enregistrées sur le disque dur.
ESSI2 – Juin 2005
33
B. Version 3D
Screenshot de la version 3D (image de dossier en rotation)
La version 3D a été élaborée à partir du vendredi 17 juin. Cette version,
une fois lancée, présente les favoris sous forme d’explorateur Windows
avec les images des favoris présents ou des dossiers présents sous forme
plane 2D. Des appels à Internet sont faits dès le lancement de l’application
pour récupérer les screenshots de sites Internet qui n’en possèdent pas.
Le passage de la souris sur un élément fait avancer celui-ci (zoom en
profondeur) pour le faire afficher en grand sur l’écran afin de pouvoir
distinguer les informations contenues sur l’image.
Un clic gauche sur la petite image permet d’ouvrir le site Internet associé
dans le navigateur par défaut de l’utilisateur. Un clic droit fait pivoter par
une rotation 3D la grande image affichée pour montrer les informations
associées à l’élément agrandi.
Lorsque la souris sort de la zone de l’image, l’image se réduit pour
retrouver sa place d’origine par un zoom inverse sur l’axe des Z.
La mollette de la souris sert à afficher les favoris restant qui n’ont pas
encore été affichés (12 par défaut), elle sert de navigateur.
Un clic sur les dossiers permet de rentrer à l’intérieur et l’affichage des
images des favoris se fait comme au lancement de l’application.
On retrouve donc dans cette version toutes les fonctionnalités qui étaient
indispensables au logiciel. Par souci de temps, l’ajout des fonctionnalités
supplémentaires comme la gestion des favoris et des dossiers des favoris
n’a pas été implémentée.
Cette version est très gourmande en espace mémoire tout comme celle en
2D, il est donc conseillé d’avoir un ordinateur assez puissant pour faire
tourner l’application (cf. Annexe / configuration minimale).
ESSI2 – Juin 2005
34
XII. Expériences acquises
1. Les points Les plus gros problèmes rencontrés viennent du fait que nous utilisions des
technologies qui n’ont pas eu le temps d’être éprouvé. En effet, le
développement sur les versions Bêta RC SDK n’est pas sans mal. Il y a
quelques bugs mais c’est surtout le manque de documentation (100%
anglaise) qui est handicapante pour un développement productif. Mais cela
est le tribut pour pouvoir développer sur des technologies futures.
2. Les points +
Bien entendu, l’expérience apportée par ce genre de projet est énorme. Nous
avons choisit un projet où les technologies nécessaires pour le réaliser nous
était inconnu. Mais cela nous a permit d’élargir nos connaissances.
Le deuxième point positif est l’aventure humaine. Nous avons fait un projet
entre amis et cela ne fût pas un problème sur la productivité du projet mais au
contraire. Cela nous a permit de comprendre et de confirmer que la bonne
entente dans une équipe surtout restreinte est primordiale pour le déroulement
d’un projet.
3. Conclusion
Nous avons rempli nos objectifs : réaliser une application utilisant les
technologies de Longhorn. Ces versions, malgré certes qu’elles consomment
assez de la mémoire RAM marchent correctement et donne un bon aperçu de
ce que ressembleront les futures applications sous Longhorn.
Malheureusement, peu de personnes se sont consacrées à ces technologies
et nous avons eu beaucoup de mal à trouver de l’aide à travers le web. Nous
avons néanmoins découvert beaucoup de choses nouvelles, car nous avons
utilisé des logiciels récents (tous en version bêta non stable) que nous ne
connaissions pas, avec un langage que nous avons appris au cours de ces
trois semaines de projet, le C#. Un cruel manque s’est fait sentir au niveau de
XAML car nous n’avions pas d’éditeur graphique ce qui a été très difficile.
Néanmoins, Microsoft a annoncé son futur éditeur XAML : Sparkle.
La version XP est peut-être plus fonctionnelle mais beaucoup moins jolie que
celles utilisant Avalon. Il reste encore beaucoup de chemin à parcourir pour
avoir des applications stables en utilisant Avalon et, couplé avec Indigo et
WinFS, Longhorn promet un bel avenir aux développeurs avec un système
puissant et sûrement facile à maîtriser.
ESSI2 – Juin 2005
35
Références
Sites Internet :
Forum Longhorn de l'
équipe [http://longhorn.reant.net]
Longhorn Blogs [http://www.longhornblogs.com]
Longhorn Developer Center Home [http://msdn.microsoft.com/longhorn/]
Paul Thurrot’s SuperSite for… [http://www.winsupersite.com/longhorn]
Wikipedia Longhorn [http://en.wikipedia.org/wiki/Windows_Longhorn]
XAML [http://xaml.net/]
FAQ Longhorn [http://www.lab-os.com/index.htm]
Microsoft Download Center [http://www.microsoft.com/downloads/]
C#/C#.NET codes sources [http://www.csharpfr.com]
XAML avec C# [http://jab.developpez.com/CSharp/XAML/]
Install Creator (ClickTeam) [http://www.clickteam.com/fr/install_creator.htm]
Plus de références sur le forum longhorn.reant.net…
ESSI2 – Juin 2005
36
Annexes
I. Configuration minimale pour l'utilisation de notre
programme
1. Version XP
Processeur Athlon XP 1800+ ou Pentium 4 2Ghz, 512 Mo de mémoire vive.
Pour une utilisation optimale, il serait mieux d’avoir 1Go de mémoire vive.
2. Version Avalon 2D
Processeur Pentium4 ou Athlon XP, 512 Mo de mémoire vive (P4 3GHz ou
Athlon 64 couplé à 1 Go de mémoire vive conseillés pour une navigation
parfaitement fluide)
3. Version Avalon 3D
Processeur AMD Athlon 64 avec 1Go de mémoire vive. 512 Mo de RAM et un
processeur Pentium 4 2.8 Ghz ou Athlon XP sont justes pour afficher les effets
3D qui sont très gourmands.
II. Installation
La version Xp comprend son propre fichier de setup, les versions Longhorn
devant être dézippées dans un dossier quelconque. Pour que notre
programme fonctionne, il est nécessaire d'
installer les RunTimes Avalon &
Indigo (cf partie Outils Utilisés). Dans le cas contraire, le programme refusera
de démarrer.
winfxsetup.exe
Microsoft® Pre-Release Software Code Named “Avalon” and “Indigo” Beta1
RC
parfois nommé May 2005 CTP
publié le 24 mai 2005
version 2.0.50215.28
téléchargé sur
http://www.microsoft.com/downloads/details.aspx?familyid=b789bc8d-4f254823-b6aa-c5edf432d0c1&displaylang=en
ATTENTION : bien lire cette page web avant l'
installation
%TEMP%\setup.exe demande un accès au web pendant l'
installation, il
télécharge les différentes parties par le net
lors de l'
installation, l'
antivirus peut poser problème pour ce script:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\InstallIndigo.js;
simplement l'
autoriser
ESSI2 – Juin 2005
37
Si vous désirez consulter le code source, vous pouvez nous contacter
directement par mail : [email protected], [email protected], [email protected],
[email protected] .
III. Configuration du pare-feu :
Il est nécessaire de permettre l'
accès de notre programme (Longhorn Project
Avalon 2D Edition.exe) au web via le port local 80 (le port distant est variable),
l'
adresse distante étant l'
URL de chaque favori (permettre toutes les URLs
possibles via le protocole TCP). La configuration des pare-feu logicielle est
simple à effectuer (inutile de donner les droits de serveur à notre programme),
les pare-feux matériel ne nécessitent pas de configuration spéciale pour notre
programme. Notre programme indiquera qu'
il lui est impossible de prendre la
capture si vous le bloquez ou si vous tardez trop à accepter sa requête (il est
conseillé de configurer votre pare-feu une fois pour toutes, & de ne pas
accepter les nombreuses requêtes au cas par cas).
ESSI2 – Juin 2005
38

Projet ESSI2

Transcription

Documents pareils

Microsoft : nous pouvons battre Linux sans Longhorn

Fiche Siw en PDF

print / multimedia / photo communication

Hôpital privé de Bois-Bernard / 62320 - Bois-Bernard

Maison et Services / 97200 - Fort-de

Microsoft Logiciel - Système d`exploitation - Windows 10

Maison et Services / 91540 - Ormoy

Association Loisirs Handicap (A.L.H) / 35600

Pierre-Marty Institut de psychosomatique (IPSO

Clinique Jeanne d`Arc / 75013 - Paris