19/07/10

Voilà les derniers résultats obtenus après ces quelques semaines de travail et compte tenu des évaluations du travail restant à effectuer dans le dernier post:

-   Gérer les deux mini toolbar au dessus du chat room (l’une est prête, pas l’autre)

Réalisé. Même si pour le moment, les boutons ne déclenche rien à proprement parler (je ne suis pas encore sûr de leur utilisation) à part le changement d’image, les boutons sont prêt à être utilisés. il ne reste donc que les liaisons avec les fonctionnalités à gérer.

-   Gérer le contenu du plugin vidéo conférence

Réalisé à 98%. Le plugin est maintenant découpé en deux parties: d’une part la main vidéo, qui prend désormais place dans le tabfolder, avec sa toolbar (reste encore un petit problème avec la seekbar), tandis que les deux toolbars et la liste des stickers des utilisateurs restant sont dans la partie droite du programme. J’ai néanmoins dû désactiver une petite partie du code de N.Richasse pour cela. Au début, on test si il y a quelque chose dans la partie sidebar et la partie sidebarfooter du xml. S’il n y a un plugin que dans le footer, on le plaçait dans la sidebar et annulé la partie footer. j’ai du enlever cela, ce qui fait que la partie footer ne prend plus toute la place disponible si jamais on n’active rien dans la sidebar droite.

-   Changer le contenu des toolbars selon ce qui est demandé

Réalisé à 90%. Le contenu évolue dynamiquement selon le plug in chargé, la footerToolBar est remplie, et les toolbars présentes les fonctions telles que présentées dans la maquette. Reste une validation concernant les nouvelles fonctionnalités (ruler du whiteboard par exemple).

-   Activer les nouvelles fonctionnalités (fullscreen, hide rightsidebar etc)

Réalisé à 50%. La fonctionnalité hide sideBar et Fullscreen sont effectives. Les fonctionnalité annuaire et resizeToBar, pas encore.

-   rétablir les éventuelles connexions brisées (normalement, elles ne devraient pas être nombreuses, d’après ce que j’ai pu tester)

Réalisé. Il n’y avait pratiquement pas de modification à faire. Reste uniquement la question de gestion des labels d’informations (nombres de fichier en share…), et la question de “l’avenir” de la status bar (qui visiblement disparait).

-   gérer les modifications d’ihm entrainées par le resize.

Le problème est toujours là, même si j’ai un ersatz de solution. Le cas échéant, on peut replacer la toolbar courrante comme on l’a place au chargement du plug in, mais ce n’est pas une solution propre, tant au niveau visuel (impression de scintillement là où la toolbar se déplace) qu’au niveau du code (insatisfaisant)

-   modification de l’ihm selon la charte graphique

Réalisé à 90%. Le changement des icônes est terminés pour celle qui m’ont été fournies (il m’en manque quelques une je pense). La gestion des couleurs est plus difficile à gérer: swt a été créé pour baser son jeu de couleur sur l’os actif. Je ne peux pas modifier ce comportement à moins de réécrire l’ensemble du programme en swing, et je ne pense pas que ce sera fait.

-   ajout des nouveaux plugins

Je ne dispose pas encore de la liste des plugins à créé. En attente donc.

Voilà où j’en suis pour l’instant. L’adaptation à un envirionnement que je ne connais quasiment pas (j’ai plus travaillé avec swing, jamais avec swt), des comportements que je ne maitrise pas encore, et le fait de disposer d’un code de 4 ans de développement rend le sujet parfois tendu à maitriser, mais ça progresse dans le bon sens.

09/07/10

Poursuite du travail concernant la modification de l’ihm du logiciel UBIK. Voici les résultats obtenus après ces quelques jours:

Commençons par des images:

Voici l’actuelle ihm d’UBIK:

Voici à présent ce que présente la charte graphique et ce que l’on souhaiterais obtenir dans le cadre du projet DGA:

Enfin, voilà ce à quoi ressemble actuellement l’ihm:

on peut donc voir pour l’instant:

la modification de la toolbar principale. Ne sachant pas encore si les deux labels devront être modifiés en boutons ou non, ils restent pour l’instant à l’état de label disabled.

En bas, la footer-toolbar évolue, et son sontenu change selon le plugin chargé. Pour le moment le contenu de cette toolbar n’a pas été modifié, c’est à dire que je me content de récupérer (déjà plus facile à dire qu’à faire) puis de replacer la toolbar inclus dans le plugin actif. Les icones de bout de toolbar sont fixe.

Côté side bar, pas beaucoup d’évolution. les boutons sont en train d’être mis en place et je cherche comment diviser le videoconfplugin afin d’en placer une partie dans le mainPane (la main video output) et une dans la sidebar (les stickers). De nouveau, je ne connais pas exactement le comportement des stickers, mais je suppose qu’il faudra inclure une scroll bar dans la liste des utilisateurs “locaux”

Me reste donc à faire:

Gérer les deux mini toolbar au dessus du chat room (l’une est prête, pas l’autre)

Gérer le contenu du plugin vidéo conférence

Changer le contenu des toolbars selon ce qui est demandé

Activer les nouvelles fonctionnalités (fullscreen, hide rightsidebar etc)

rétablir les éventuelles connexions brisées (normalement, elles ne devraient pas être nombreuses, d’après ce que j’ai pu tester)

Et surtout, gérer les modifications d’ihm entrainées par le resize. Pour le moment, le contenu alternatif des toolbars disparait en cas de resize…

06/07/10

Aujourd’hui, première approche de la problèmatique de la toolbar dynamique selon le plugin chargé.

Pour commencer, première approche du système de gestion des composantes de toolbar, notamment comment espacer deux éléments sans pouvoir spécifier, comme en swing, la colonne dans laquelle tel élément doit être placé. Il faut ici créer un nombre de colonne max et fixer un espacement entre deux éléments éloignés. De plus, les toolItem composant une toolBar ne peuvent pas subir ce genre de manipulation. Il faut donc créer une toolbar, même si c’est pour un seul élement… De ce point de vue là, swing est beaucoup plus flexible et rapide à prendre en main que swt.

En effet, selon le nouvel ihm, il doit y avoir en bas de l’appli une toolbar qui varie selon le plugin affiché. Le problème ici vient du fait qu’il n’existe pas encore dans la version existante d’UBIK de moyen de connître le plugin actif. Dès lors, il n’existe que deux solutions:

Détecter le tab actif dans le tabFolder (le “browser” de plugin). En fonction de cela, on devrait pouvoir détecter le plugin actif, et récupérer une toolbar selon le nom du plugin (qui seront alors détectée en static vraisemblablement)

Ou alors créer une toolbar dans chaque plugin, et dupliquer les boutons communs (prendre la main et full screen). Néanmoins, il y a une perte d’optimisation et le résultat n’est pas franchement le meilleur à mettre en place, même si c’est le plus simple.

05/07/10

Aujourd’hui, poursuite du travail sur l’interface d’UBIK. je commence enfin à saisir comment fonctionne l’organisation de l’interface du logiciel. Afin de répondre à la nouvelle forme de l’ihm, voilà ce que je dois prévoir:

déplacer certains bouton (sélection média, file sharing etc)

Modifier les apparences de certains plugins (chatroom, videoconference…)

ajouter une nouvelle toolbar, dont le contenu sera modifié dynamiquement selon le plugin chargé

faire disparaitre la status bar

gérer les plugins (disparitions de certains, apparition de nouveaux)

gérer les couleurs principales

Gérer les réactions des boutons (changement de l’icône active)

En soit, ça à l’air simple comme ça, mais n’ayant jamais touché à swt, j’ai un peu de mal, surtout au niveau du placement des objets dans leur container. l’exemple le plus flagrant du moment: je ne sais pas encore comment incorporer un espace vide entre deux boutons dans les toolbars.

01/07/10

Aujourd’hui, première modification rapide de l’ihm, plus en tant que test qu’en tant que résultat à proprement parler. Le travail sera définitivement beaucoup plus long que ce que je croyais. Il ne s’agit plus seulement de changer une ou deux icônes, mais bien de transformer une bonne partie du code. Les action/réaction du logiciel doivent être pour beaucoup modifier, l’emplacement des icônes entraine une modification des toolbars et de leur comportement, il va falloir ajouter une sorte de nouveau plugin, le plugin “video” qui regroupe plusieurs options de la vidéo main en haut à droite etc…

Bref, je me suis complètement trompé sur l’ampleur du travail, et commence à redouter de ne pas parvenir à en finir “rapidement”

29 et 30/06/10

Depuis hier, je me suis lancé dans le travail sur UBIK. Le premier point a déjà été de réussir à lancer une fenêtre depuis le code source du logiciel. Pour se faire, Nicolas Hennion m’a écrit une sorte de tutoriel à suivre. Une fois corrigé et complété, on peut finalement lancer une fenêtre (mine de rien, ça m’a déjà pris une journée, le temps de tout importé, de tout faire fonctionner dans eclipse, de corriger les erreurs générées par les imports avec l’aide de Nicolas Richasse etc).

Aujourd’hui a donc été consacré à la première approche à proprement parler du code du logiciel en lui même, et plus précisément de la fonction ihm/ui.

Contrairement à ce que j’ai tout d’abord pensé, ce ne sera pas un travail simple et rapide. L’ajout de fonctionnalité à l’aide de l’outil de gestion de plugin est simple et visiblement rapide (passage par le xml, mais en soi rien de bien compliqué), la modification complète de l’ihm nécessite de rentrer complètement dans le code source, à travers différentes classes (une par plugin, une pour l’ihm de base, une pour chaque sous partie de l’ihm etc), ce qui fait que les transformation a apporter sont nombreuses et que chaque petite modification peu entraîner un bug total (par exemple, j’ai voulu supprimer simplement un bouton. Résultat: crash, il faut effacer toutes occurence ou simple allusion à ce dit bouton pour que cela soit faisable.)

En clair, l’outil de recherche sera surchargé de travail et le rendu sera un peu plus long à venir que prévu…

23/05/10

Ces derniers jours (du 19 au 23, minimum) ont été consacré à la correction et l’amélioration du mini soft permettant de diffuser une vidéo dans un environnement 3D utilisant glfilterreflectedscreen. Ainsi, lors du lancement de l’application la première fois après l’upgrade de gstreamer, le mode display fonctionnait correctement, mais plus le mode record. Etant donné que ce devait être le plus utilisé, j’ai passé plusieurs jours à chercher l’erreur, sans la trouver, y compris avec l’aide de la communauté gstreamer présente sur irc.

C’est finalement hier que nous avons compris ce qui coinçait. Sans vraiment pour expliquer les raisons de ce problème, la connexion des pads entre les src et les sinks des différents éléments généraient une erreur au niveau du join entre theoraenc et gldownload. Et malgré tout nos efforts nous étions dans l’incapacité de comprendre pourquoi. Il faut savoir qu’à ce moment là, on diposait de trois bin: le bin principal, le pipeline, le bin vidéo et le bin audio. A cet instant, oggmux et filesink se trouvaient dans le bin principale, puisqu’ils devaient constituer avec filesrc et decodebin la base immuable du pipeline. Le problème venait en fait d’ici. Le bin vidéo ne parvenait pas à connecter les pad de son dernier élement (theoraenc) à ceux du premier du bin principal (oggmux). Finalement, le soucis a été résolu en plaçant oggmux et filesink dans le bin video.

S’en est alors suivi un nouveau problème. En effet, dans le cadre d’un montage vidéo “normal” il est plus que probable qu’au moins un des fichiers d’entré contienne une piste vidéo, mais également une piste audio. Dans ce cas là, pas de problème, les deux bin fonctionnent. Mais dans le cas où les DEUX vidéos ne contiennent aucun son (comme c’est le cas pour nous), le bin audio attends un flux de donnée qui ne vient, et le pipeline se bloque.

Ayant déjà passé beaucoup de temps là dessus sans pouvoir trouver une solution “propre”, je me suis résigner à une solution “de secours”: l’interface java comprend désormais un checkbox de plus, qui permet à l’utilisateur de spécifier si son fichier d’entré comprend ou non du son.

Il s’agit comme je viens de le dire d’une solution de secours temporaire. Lorsque mes compétences dans le maniement de gstreamer seront un peu efficace (même si je crois comprendre comment faire, j’ai toujours une erreur que je ne sais pas comment gérer), il sera possible de détecter si le fichier d’entré comprend du son ou non et de le jouer, quelque soit le résultat. La démarche est la suivante:

montage de base du pipeline: videosrc + decodebin

phase de preroll: permet de connecter les pad et de déterminer le type de données

modification du pipeline en fonction des résultats (ajout video et/ou audio)

phase playing: lancement du pipeline.

Pour le moment, la détection semble être incorrecte au niveau de l’audio, et l’ajout de la vidéo ne fonctionne pas. Bref il s’agit, avec l’utilisation de glmosaic lorsque celui-ci sera disponible, des dernières améliorations possibles concernant ce mini soft.

Il a également été effectuer une petite retouche de l’aspect graphique du filtre, afin d’augmenter la taille des écrans, d’avoir un angle plus important entre les deux, et de perdre moins d’espace en haut et en bas de l’image.

Voici quelques screen permettant de comprendre le fonctionnement du soft:

Fenêtre par défaut (accueil)

choix du fichier d’entré (via browser)

gestion des options

rendu

Ou une petite vidéo pour montrer en temps réel comment cela fonctionne:

17/06/10

Aujourd’hui, préparation des vidéos de préparation. La création se fait selon les étapes suivantes:

-1 capture de deux ordinateurs différents

-2 montage pour l’utilisateur 1

-3 montage pour l’utilisateur 2, au plus proche de la vidéo précédente

-4 supression des éventuelles erreurs (notamment sous linux, kdenlive créé automatiquement des Bandes noires à droite et à gauche qui doivent être supprimé. Pour cela, on passe par avidemux, on utilise un crop, qui supprime ces bandes, puis on resize selon nos choix)

-5 montage côte à côte des deux côtés.

-6 diffusion/enregistrement 3D via le filtre glfilterreflectedscreen

note: on perd pas mal de qualité de vidéo en plaquant les textures. L’effet de perspectives et le low-level programming d’OpenGl en sont probablement les causes, mais on ne peux pas faire grand chose à ce sujet.

16/06/10

Aujourd’hui, montage de la vidéo de démo d’UBIK, côté utilisateur 2. En s’appuyant sur le travail de Xavier, je devais faire correspondre chaque temps de sa vidéo avec la mienne. Même si le rendu est un rendu “utopique”, c’est à dire une réception dans les meilleurs conditions qui soit, sans perte de temps au niveau du transit, le travail à été long et fastidieux. A cela c’est ajouté une recherche sur les codec de kdenlive.

KDenlive est, avec pititi, openshot et quelques autres, l’un des rares logiciels de montages vidéos disponible sous Ubuntu. Celui-ci comprend de nombreux codec audio/video, même si certains ne fonctionnent pas (notamment ogv et h264, les deux que j’aurais voulu utiliser…) Néanmoins, il présente des fonctionnalités que les autres n’ont pas, comme l’utilisation de transition ou le multi-piste vidéo/audio.

Enfin, il peut prendre en entré tout les formats de vidéo, ce qui n’est pas le cas dans certains autre logiciel, et ai relativement simple d’utilisation comparé à Cinelerra par exemple.

Le rendu sera donc fait en avi codec xvid, par défaut (malgré toutes mes tentatives, je n’ai pas réussi à ajouter le codec h264, alors que les libs sont bien en place et marche avec ffmpeg hors du logiciel, et l’export en théora plante au niveau de l’encoder, mais là encore, aucune solution n’est apporté sur le net). On pourra éventuellement le réencoder derrière en ogv, mais de toute façon le format de sortie du visualisateur 3D est un fichier ogv.

14/06/10

Aujourd’hui, deux phases de travail suivies en parallèle:

d’un côté, poursuite sur le travail de vidéo montage. Certaines vidéos sont à reprendre (partage web), mais le sujet commence enfin à avancer. Deux montages seront réalisés: un sous windows, par Xavier, un second par moi, sous linux. Si les résultats sont pseudo-identique, mon montage sera gardé, puisqu’il permet de travailler directement en ogv, sans avoir besoin de passer par des encodages décodages successifs qui font perdre une importante qualité vidéo. Le rendu final devrait être utilisé soit en ogv (Linux) soit en avi h264(window).

En parallèle à cela donc, je poursuis mes tentatives de réparation de mon programme de diffusion 3D de vidéo. Le mode display fonctionne dorénavant avec l’interface développée en java, et le mode record, lui, ne fonctionne plus du tout…Pourtant, lorsque celui-ci est lancé via ligne de commande, tout fonctionne (sauf, comme d’habitude, la disparition du gradient en fond, mais je n’ai jamais réussi à comprendre pourquoi). Je suis en ce moment aidé par plusieurs personnes, tant Julien Isorce que la communauté gstreamer via freenode, mais pour le moment, les raisons en reste franchement obscures. Je vais tenter de récupérer une version ou ce mode fonctionnait et comparerais les codes, dans l’espoir d’être enfin éclairé sur ce qui coince…