• 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

Rappelez vous, il y a un an

Y aura-t-il un portage de l'IDE pour linux ?

MC Nous y avons sérieusement réfléchi, mais ce n'est pas une priorité. Nous aimerions qu'il y ait plus de demande pour ca Oui, mais la seule chose qui fait que certains restent sous windows c'est flash justement MC et oui, je sais

Bien, faisons maintenant nos observations :

1. Macromedia s'associe a la fondation eclipse. On apprend que flex2 sera basé sur le fameux éditeur libre multi plateformes
2. Macromedia lache l'alpha publique. Surprise : le framework est en java, technologie multiplateformes
3. Pas de flash player 8 pour linux. Macromedia laisse tomber la plateforme ? Que neni, ils se concentrent sur le FP8.5 (9 maintenant) et veulent l'optimiser pour les archis 64 bits
4. On apprend que le framework sera gratuit.

Des points 1 et 3, on déduit que l'éditeur tel quel pourrait être indépendant de la plateforme. Il n'y a aucun problème entre java et linux, eclipse en est la preuve. Reste le problème à l'heure actuelle : le player est le facteur bloquant. Ce n'est qu'une question de temps.

Ah, pourquoi je parle du framework gratuit ? C'est une question de distribution. S'il n'est pas tres difficile pour certaines distributions de faire des rpms payants, il en va autrement des debian based.
Rendre le framework gratuit, outre le fait que c'est un argument de pub génial, garanti que au strict minimum on pourra trouver Flex2 sur les depots PLF.

Voila pourquoi je ne doute pas et que j'attends une annonce imminente :)

• 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 :)

First, we will create the .swf containing the remoting classes.
Let's create the remoting.sexie file :

mx.remoting.PendingCall
mx.remoting.Service
mx.rpc.FaultEvent
mx.rpc.RelayResponder
mx.rpc.ResultEvent

the .fla we will compile, containing only :

(new Library()).doNothing();

then, using ANT and Sexier, we will create the Library.as file :

<taskdef name="sexieLibrary" className="org.aggelos.sexie.app.ant.SexieLibrary" classpath="${path.to.sexie}" />
<taskdef name="flashCompile" classname="FlashANT" classpath="${user.home}/.fdt"/>
	
<target name="create remoting lib" >
		<sexieLibrary 
					outputDirectory="remoting" 
					sources="${pathtoyourclassesfolder}" 
					mode="mtasc" 
					classList="remoting.sexie"
		/>
		 <flashCompile file="remoting.fla" exe="${path.to.flash}"/>
</target>

Well, here I made a little shortcut, assuming you used the flashCompile task shipped with FDT. You can do it manually too. Let's suppose that your output swf is remoting.swf

I will now explain the parameters for the sexieLibrary task :

• outputDirectory is the directory where the results (intrinsic package, or exclusion files, and Library.as) will be created
• source represents a list of the folders where Sexier should be looking for classes, ";" separated
• mode - if set to mtasc, generates a exclude.mtasc file, if xml, generates exclude.xml (to be renamed to yourflaname_exclude.xml), else will generate the intrinsic package
• classList corresponds here to "remoting.sexie"
• exclude corresponds to a ";" separated list of files not to include in the exclusion (a little farfetched, I know)

By now you should create another library with all the classes for your application. Let's call it library.sexie

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

Sexie will scan for ClassA, ClassB, and all the classes they depend on, and generate the appropriate exclusion files or intrinsic files. The remoting classes will also be included if ClassA and/or ClassB depend on those.
Let's generate the libray and compile it (using mtasc this time :p)

<taskdef name="mtasc" classname="org.as2lib.ant.Mtasc" classpath="${path.to.antmtasc}" />
 
<target name="create lib" description="creates the library"> 
		<sexieLibrary 
			outputDirectory="main" 
			sources="${src};${dep1};${dep2}" 
			mode="mtasc" 
			classList="library.sexie"
			exclude="mx.utils.Delegate"
		/>
             <mtasc mtasc="${mtasc.path}" 
    	        	src="main/Library.as" 
    	        	classPath="${deps.mtasc}"  
    				excl="remoting/exclude.mtasc"
    				swf="library.swf"
    				header="1:1:25">        	
    	</mtasc>  
</target>

I won't come back on how to compile with mtasc, you will find tutorials elsewhere.

Ok, now we have two libraries. How to include them in your code ? Here come the AggLibTools. You will need to use two classes :

LibrariesLoader
LoadingLibrary

Create a file containing the list of the urls of the libraries you want to load :

/libs/remoting.swf
/libs/library.swf

Let's call it libraries.libs

import org.aggelos.utils.libs.LibrariesLoader;
import org.aggelos.utils.libs.LoadingLibrary;
import org.aggelos.events.Event;
import org.aggelos.app.ClassA;
import org.aggelos.app.ClassB;
 
class Application {
	
	function Application() {
		var ll:LibrariesLoader = new LibrariesLoader(this.createEmptyMovieClip("libs",0));
		
		ll.addEventListener("ALL",this);
		ll.loadFile("libraries.lib");
	}
	
	function onLibraryStart(evt:Event) {
		trace("Starting "+evt.target.name);
	}
	
	function onLibraryLoaded(evt:Event) {
		trace("Loaded "+evt.target.name);
	}
	
	function onLibraryProgress(evt:Event) {
		var lib:LoadingLibrary = LoadingLibrary(evt.target);
		trace("Progress "+lib.bytesLoaded+"/"+lib.bytesTotal);
	}
	
	function onLibrariesComplete(evt:Event) {
		trace("loading complete");
                startApp();
	}
	
	function onLibrariesError(evt:Event) {
		trace("Error "+evt.target.name);
	}
	
	public static function main() {
		new Application();
	}
 
        public function startApp() {
             var ca:ClassA = new ClassA();
             var cb:ClassB = new ClassB();
        }
	
	
	
}

Your code should really start on the onLibrariesComplete event, when all your libraires are loaded. It may look a tad difficult at first sight, but since you automate everything, the only cost is what you do when starting your project. Well, I now gain a lot of time.

Everything you need is on the SVN ^^

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)

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 ^^

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