Aggelos - Developpement

It's the great event of the day for our community. Adobe decided to open source the Flex SDK. Great.

Technically speaking, the SDK is (as is mtasc) a set of tools to create, from a set of assets (for example your source MXML or AS3 code) a group of binary objects in a still closed format (swf).
Yes, it is important to remember that, for now, the SWF format is still (as far as I know) a proprietary format ! We will come back on that later.

Let's have a little flashback on the open sourcing of flash. Until Flash MX 2004, the tools used to create flash applets were all closed source and all proprietary. Then came Nicolas CANASSE and Mtasc. For the first time, we had a free and open source way to compile assets in the latest up to date swf binary format. The stance of Macromedia at that time was to encourage the initiative, and it was already a great progress. And MTasc was open source, which means that not only was it free to use, but you also had with it the ability to audit the source code to check where it could fail, and also play with it to create new powerful functionalities from it (see HamTasc).
Then came Flex and AS3. Since it was born, the Flex framework was free to use. Although it was already a really appreciable move from Adobe it had its side effects. For example, Nicolas CANASSE would not create an AS3 compatible MTasc since he did not see why he would create an alternative for a framework that was free to use. And thus we lost all the power we had with MTasc. We could not play at the source anymore.
Now that power is back, and it may be for the best... And yet not.

Because swf is still a binary proprietary format. It is not by any mean an open standard ! One could object swf is a de facto standard through its extensive usage over the web... But just as much as JPEG or GIF are !
Now, the great move would have been to open the swf specification, but such is not the case.

Let's think outside of any context for now. No I really mean it. Please just put aside the fact that PDF is now an ISO standard and also put aside every former moves by either Adobe or Microsoft. It will be time to think about it again in the next part of this analysis.

• We have free and open source tools to develop flash source assets (FlashDevelop, Scite, ASDT etc)
  
• We now have free and open source tools to convert these source assets in swf binary format
  
• We have a free widespread plugin for internet browsers that can interpret this binary format
  
• And... for now (mark my words) these binary format are free to use, free to deliver...
  

Yet if you think about it, this format we love or hate is now more at risk than ever. Let us admit that using this free and open source framework creates a wonderful momentum around the technology, and that tomorrow more and more web applications (and/or sites) are developped using flash foundation technologies. And that at a given point Adobe decides to have you pay a license to deploy a swf binary. What will you do ? You will pay off course or you will fear the lawsuits.

This first part of the analysis was there to underline the key concepts of what is free and/or open source in the swf chain. The next parts will deal about :

• Part 2 : The Mozilla license and Ecma - Flex SDK and Tamarin
• Part 3 : Adobe and open source - Analysis of the strategy

Oulah y a de la poussière ici.

Bref, a l'occasion de la montée a Paris d'un helvète du nom de Cédric TABIN (thecaptain), je propose

un petit pic nic ce week end,
genre par exemple samedi soir
genre par exemple à partir de 19h
genre par exemple sur les canaux de la Seine
et genre par exemple à tous les flasheux sur Paris à cette date


On leve la main bien haut si on veut venir s'il vous plait !
Et on passe le message, parce que plus on est de fous, plus il y aura de la salade de riz

Attendu que je n'utilise presque plus ce blog, étant donné que je ne fais presque plus de flash pour mon plaisir.

Attendu que l'essentiel des commentaires que je recois sont du spam

Je prends la décision de fermer les commentaires. Attendez vous à une éventuelle fermeture de ce blog.

Bien cordialement, l'auteur

Je discute avec Kiroukou (Thomas PFEIFFER, l'auteur de Sandy) à l'instant, et il semble surpris quand je dis que j'attends l'annonce imminente de la sortie de Flex2 pour linux. Voici mon analyse de la situation.

Lire la suite

Ce matin mon j'avais organisé pour mon équipe une rencontre avec un technico commercial d'Adobe (anciennement Macromedia)
Question pertinente de mon n+2 sur l'évolution des produits Adobe et Macromedia. Voici l'heure des révisions :

• GoLive est sans doute amené a disparaitre. En effet, Dreamweaver occupe 75% du marché, et GoLive une place toute à fait marginale
• De gros problèmes se posent avec Freehand. Tout à fait marginal en France, il n'en reste pas moins majoritaire en Italie et en Allemagne par exemple, et est très utilisé outre atlantique. Le produit ne disparaitra donc sans doute pas. Au pire il pourrait être revendu.
• Ce brave monsieur avait oublié de parler de Paper. Je l'ai rattrapé au vol un peu plus tard. Bah ils ne savent pas apparemment. Ils ne savent pas DU TOUT ce qu'ils vont faire de Paper. En tout cas c'est le message que j'en retiens.

Enfin, ouala :)

Je relaie la nouvelle :
Flex 2 sort demain. C'est une bonne nouvelle en soi... Mais on a avec ça une excellente nouvelle...
LE FRAMEWORK FLEX2 ET LES COMPILOS SERONT GRATUITS
J'ai du mal à exprimer ce que je ressens, j'ai envie de baiser les pieds d'Adobe ^^

I wanted to make your life easier, once again. Sexier does not have a GUI... yet. And using dynamic libraries may be a pain in the neck for many of you. That's why I've created the AggLibTools and ameliorated SexieR to simplify your life.
To illustrate how you could use SexieR and the Library Tools, here's how I use it to fix the issue of MTasc not compiling mx remoting classes

Lire la suite

Dans le cadre de mon gros projet actuel, je m'étais heurté à un sale bout de code.
En effet, je voulais une fonctionnalité qui permette d'activer une action en fin de lecture d'un swf captivate. Je pensais naivement que le bout de code suivant allait fonctionner :

var cible:MoviecClip;
 
unmachin.onEnterFrame = function() {
	if(cible._currentframe == cible._totalframes) triggerEvent("onFini",cible);
}

Et bah quedalle ! Le changement se faisait beaucoup trop tot, et je n'ai jamais bien su pourquoi, alors n'ayant pas le temps j'avais laissé tomber.
Suite à la demande du patron du patron de mon patron, j'ai rejeté un coup d'oeil à tout cela, et j'ai découvert le pot au roses !

Tout d'abord, test pratique : j'ai voulu regarder ce qui n'allait pas. Résultat, flash me découvre 113 frames dans mon SWF... Pour une demo de plusieur minutes. Bon, surtout, ne pas se dégonfler ;p

Par conséquent, j'ai voulu voir le fla associé au projet .cp.
C'est possible, il faut pour cela :

1. exporter le fla
2. dans celui ci (vide) importer le .cp

Hum... Plus de 7000 frames, je me disais bien.

Réaction : il y a une saloperie qui englobe le contenu dont j'ai besoin et qui a le bon nombre de frames. Allez, un petit for in

var cont:MovieClip = this.createEmptyMovieClip("cont",0);
var mcl:MovieClipLoader = new MovieClipLoader();
mcl.addListener(this);
 
function onLoadInit() {
	for(var prop in cont) trace(prop);
	trace(cont instanceof MovieClip);
	//this.onEnterFrame = countCurrentFrame;
}
 
mcl.loadClip("uncaptivate.swf",cont);

Bingo ! Voici la sortie :

isExpired
setExpired
decrementWait
incrementWait
isWaiting
CaptivateVersion
rdcmndNext
rdcmndPrevious
rdcmndPause
rdcmndResume
rdcmndGotoFrame
rdIsPreview
rdIsMainMovie
rdinfoSlideCount
rdinfoCurrentSlideInProject
rdinfoCurrentSlide
rdinfoCurrentFrame
rdinfocurrFrame
rdinfoFPS
rdinfoSlidesInProject
rdinfoFrameCount
loading_mc

C'est y pas mignon ? Alors voila, c'était le piège du jour. Conséquemment, dorénavant, je teste si la propriété CaptivateVersion existe, et si c'est le cas, j'utilise le test

if(rdinfoCurrentFrame==rdinfoFrameCount)

Ca y est, la fonctionnalité permettant de générer tout ce qui faut pour une librairie partagée est prête ^^. L'occasion pour moi de vous démontrer comment avec un simple script ant on peut créer un déploiement automatique d'application avec une librairie partagée.

Imaginons la classe de départ suivante :

import org.aggelos.myapp.ClassA;
import org.aggelos.myapp.ClassB;
 
class Application {
	
	public function Application() {
		var classA:ClassA = new ClassA();
		var classB:ClassB = new ClassB();
	}
	
	public static void main() {
		var app:Application = new Application();
	}
	
}

Ce qu'il y a, c'est que ClassA et ClassB sont utilisées par d'autres SWF de mon application... On veut donc les charger dynamiquement via une librairie partagée.
Qu'à cela ne tienne, il suffit de changer le code de la sorte :

import org.aggelos.myapp.ClassA;
import org.aggelos.myapp.ClassB;
 
class Application {
	
	private var tgt:MovieClip;
	
	public function Application(tgt:MovieClip) {
		this.tgt = tgt;
		
	}
	
	public function init() {
		var container:MovieClip = tgt.createMovieClip("lib",tgt.getNextHighestDepth());
		var mcl:MovieClipLoader = new MovieClipLoader();
		mcl.addListener(this);
		mcl.loadClip("library.swf",container);
	}
	
	public function onLoadInit() {
		var classA:ClassA = new ClassA();
		var classB:ClassB = new ClassB();
	}
	
	public static void main() {
		var app:Application = new Application(_root);
	}
	
}

Bon, le problème, c'est qu'il ne faut pas :

• ni que A et B ne soient inclus dans ce swf
• ni que les classes dont dépendent A et B soient incluses

Qu'à cela ne tienne, il suffit :

• pour MTasc faire un fichier de la sorte

org.aggelos.myapp.ClassA
org.aggelos.myapp.ClassB
org.aggelos.myapp.ClassDependsA1
org.aggelos.myapp.ClassDependsA2
...

• pour MMC un xml d'exclusion de la sorte :

<?xml version="1.0" encoding="UTF-8"?>
<excludeAssets>
  <asset name="org.aggelos.myapp.ClassA" />
  <asset name="org.aggelos.myapp.ClassB" />
  <asset name="org.aggelos.myapp.ClassDependsA1" />
  <asset name="org.aggelos.myapp.ClassDependsA2" />
</excludeAssets>

• dans les deux cas, il est possible d'utiliser les classes intrinsèques.

La gestion des dépendances, c'est un beau bordel. C'est là qu'intervient SexieR.

Je veux une librairie qui incluse ClassA, ClassB et toutes leurs dépendances. Je vais juste créer un fichier "librairy.sexie" et un petit fichier build.xml pour ant

<?xml version="1.0"?>
<!-- ====================================================================== 
     Jan 2, 2006 4:27:28 PM                                                        
 
     Sexie test                                                      
     ====================================================================== -->
<project name="Sexie test" default="default">
	<property file="build.properties"/>
 
	<taskdef name="sexieLibrary" className="org.aggelos.sexie.app.ant.SexieLibrary" classpath="${path.to.sexie}" />
	<taskdef name="mtasc" classname="org.as2lib.ant.Mtasc" classpath="${path.to.antmtasc}" />
		
	<target name="sexie library" >
	    <sexieLibrary outputDirectory="${basedir}/src" source="${src}" mode="mtasc" dependencies="${dep1};${dep2}" classList="${lib.src}"/>
	</target>
	
 
    <target  name="compile library" >
        <mtasc mtasc="${mtasc.path}" 
        	src="${basedir}/src/Library.as" 
        	excl="exclude.mtasc"
        	classPath="${deps.mtasc}" 
        	swf="${basedir}/bin/library.swf"
        	mx="true" 
        	header="1:1:25">        	
        </mtasc>
    </target>
 
        <target  name="compile app" >
        <mtasc mtasc="${mtasc.path}" 
        	src="${basedir}/src/Application.as" 
        	excl="src/exclude.mtasc"
        	classPath="${deps.mtasc}" 
        	swf="${basedir}/bin/main.swf"
        	header="800:600:25">        	
        </mtasc>
    </target>
 
</project>

Bon, un peu d'explications :

<taskdef name="sexieLibrary" className="org.aggelos.sexie.app.ant.SexieLibrary" classpath="${path.to.sexie}" />
<taskdef name="mtasc" classname="org.as2lib.ant.Mtasc" classpath="${path.to.antmtasc}" />

On crée ici deux taches, la tache mtasc, pour la compilation, et la tache sexieLibrary.

• mtasc necessite as2ant.har, une partie de as2lib (ici précisé dans la variable ${path.to.antmtasc} dans le build.properties
• sexieLibrart necessite sexie.jar et dom4j.jar si vous voulez générer du XML

<target name="sexie library" >
	    <sexieLibrary 
             outputDirectory="${basedir}/src" 
             source="${src}" 
             mode="mtasc" 
             dependencies="${dep1};${dep2}" 
             classList="${lib.src}"/>
</target>

Voila un target ant, qui executé lance la création du matériel de librairie par Sexie

• outputDirectory est le répertoire dans lequel sexie créera ses résultats
• source est la racine du package source
• mode - si mtasc, génère un fichier exclude.mtasc pour mtasc, si xml, génère un xml d'exclusion, si intrinsic génère le package de classes intrinsèques
• dependencies est la liste des packages dont dépend votre package principal. En généra le répertoire Classes de flash rentre là dedans
• classList est la fameux fichier "librarie.sexie"

Ce dernier fichier à la forme suivante :

org.aggelos.myapp.ClassA
org.aggelos.myapp.ClassB

tout simplement

Si je lance cette tache, je récupère le fichier d'exclusion ou le package intrinsèque complet (avec toutes les dépendances) et le fichier Library.as suivant :

class Library extends MovieClip {
	public function doNothing() {
		var arr:Array = [
			org.aggelos.myapp.ClassA,
 			org.aggelos.myapp.ClassB
		];
	}
	public static function main() {
		(new Library()).doNothing();
	}
}

Bien, il ne nous reste donc plus qu'a compiler tout ça. J'ai pris le cas ou on génère le fichier mtasc, donc j'utilise l'attribut excl de la tache mtasc pour choisir un fichier d'exclusion.
Voila, si vous voulez, vous pouvez faire un dernier target qui fait tout dans l'ordre, et tout votre build est maintenant automatisé. Vive la technologie ^^

SexieR (Sexie Reloaded) est prêt... Enfin, dans les grandes lignes ^^

Note préliminaire : si vous ne connaissez pas le principe des librairies partagées, fichiers d'exclusion et classes intrinsèques, reportez vous à cet article

Vous vous rappelez de Sexie ? Un truc un peu fastidieux utilisant le workaround des swc pour générer les classes intrinsèques pour une librairie donnée ? Et bien madame, jetez le, vous n'en aurez plus besoin ^^

J'ai relancé le projet Sexie avec une volonté claire : faire en sorte que la création des librairies et fichiers d'exclusion fasse partie de processus automatisés.
Par conséquent, Sexier ne vous demande plus la création d'un fichier SWC, il peut (dès maintenant) générer tous types de fichiers d'exclusion de compilation (intrinsic, mtasc, xml pour mmc) Ã partir d'un simple répertoire de classes, et éventuellement d'une liste de répertoires de classes dépendantes.

Pas d'interface pour l'instant (ça va venir) mais une tâche Ant pour rendre tout ça tout automatique ^^

<taskdef name="sexiePackage" className="org.aggelos.sexie.app.ant.SexiePackage"
classpath="${path.to.sexie}" />
 
<target name="default" >
        <sexiePackage outputDirectory="${basedir}/src" source="${src}"
mode="mtasc" dependencies="${dep1};${dep2}" />
</target>

arguments :

• outputDirectory : le répertoire dans lequel le résultat sera créé
• source : le répertoire de classes
• mode : mtasc - intrinsic - xml. intrinsic par défaut
• dependencies : classpathes à inclure séparés par ";"

Alors c'est encore en création, je prévois au moins un build par semaine. Voici la liste des features encore à implémenter :

• même chose à partir d'un fichier contenant une liste de classes. Le fichier Library.as serait automatiquement généré
• gestion des #include dans la gestion des dépendances (non implémenté encore)
• faire une interface propre
• réimplémentation des anciennes fonctionnalités avec refactoring (en attendant utilisez l'ancien sexie)

Si vous voulez aider, vous pouvez :

• faire du beta testing
• fournir des tests JUnit pour améliorer le tout
• participer au code (qui est toujours GNU GPL :) )

Le projet dispose d'un Trac, d'un SVN etc. cf la partie Sexie sur le site OSFlash

Je vous souhaite à tous une très heureuse année, pleine de réussite, de bonheur, d'amour, plein de bonnes choses quoi.

N'oubliez pas de vous embrasser sous le geek :p

Bon, après moultes réflexions, beaucoup d'insatisfactions et quelques frustrations, j'ai enfin trouvé mon outil.

Enterprise Architect de chez Sparx dispose de toutes les qualités que j'attends :

• Il fait tout, de la MOA (use cases, business process...) à la MOE (classes, séquences...)
• on peut faire plusieur diagrammes de chaque type (contrairement a visual paradigm community)
• Il est rapide et ergonomique
• ET SURTOUT, il génère le stub pour java, C#, C++... Mais aussi PHP et surtout AS2 (love)... Et fait aussi le reverse engineering (c'est à dire qu'il génère les diags de classes à partir des fichiers AS) (relove)

C'est un outil pro, mais franchement, $235 pour une version pro... spa bien cher pour tout ça !

Bon, j'ai l'aval de mon supérieur pour passer du temps sur Sexie afin de l'utiliser de façon intensive dans nos développements futurs. Ceux ci passeront par une méthodo XP, donc Sexie a besoin d'un petit relookage complet.
Les fonctionnalités que je veux ajouter sont :

• Exploration des packages (avec dépendances) pour générer la sortie (plus de swc)
• tâches ant
• refonte du GUI avec des vrais layouts ce coup ci ^^
• optionel : un plugin eclipse

Les fonctionnalités que vous aimez seront conservées, naturellement. Le soft sera développé en XP et disposera de nightly builds, et vous serez les clients, donc je veux un max de retours.
Ah oui, c'est le moment de faire votre wishlist ^^

Aral BALKAN a réussi à me foutre un pincement au coeur. On apprend aujourd'hui que les dernieres paperasses de l'acquisition de Macromedia par Adobe ont été réglées. Adieu Macromedia. Malgré toutes tes anneries, je te dois énormément. J'espère te recroiser un peu chez Adobe.