La Fabrick » UI Design

Flex 4 et les layouts – Faire une ViewStack « pure » Spark

Hervé — Wed, 14 Jul 2010 16:06:03 +0000

Pour ceux d’entre vous qui ont eu la chance de passer à Flex 4, vous avez peut-être la même tendance que moi à chercher à éviter le préfixe dans vos skins… Spark, quand tu nous tiens… Quoi qu’il en soit, certains types de composants n’ont pas été réécris pour Spark. Pourquoi ? Parce l’architecture Spark propose quelque chose de top : les layouts. Et les layouts, c’est vaaaachement bien.

Explication…

Layouts

Sans faire un article complet sur les layout (ce qui serait tout à fait possible et intéressant), on peut tout de même rappeler que le Flex 4 se distingue de Flex 3 via Spark par une volonté de mieux séparer le fond de la forme, il amène donc une notion de layout pour, comme son nom le suggère, organiser les composants d’un conteneur (par exemple un ).
Exit donc la VBox ou la HBox (même si le VGroup ou le HGroup permettent de faire une transition en douceur), et bienvenue au Group avec layout :

devient donc

Au premier abord on dit : c’est plus verbeux ! Oui mais… le layout a cette particularité, en tant que propriété du composant, d’être modifiable à la volée, contrairement à un composant imposant sa mise en forme. Concrètement, là où la VBox présentera toujours ses enfants verticalement (c’est son nom !), le Group pourra changer à volonté de layout, donc très facilement passer de HorizontalLayout à VerticalLayout par exemple… On comprend encore mieux l’intérêt quand on se met à écrire son propre layout pour faire des choses un peu plus poussées visuellement !

Créer son layout

Pour créer un layout, il faut étendre la classe LayoutBase et surcharger a minima la méthode updateDisplayList() et certainement la méthode measure(). Ces méthodes gardent le même rôle qu’en Flex 3, mais avec l’adaptation contextuelle au Layout :

updateDisplayList : dispose les enfants du conteneur et définit leur taille
measure : donne la taille globale du conteneur

Vous pouvez accéder à la propriété « target » du layout qui correspond au conteneur auquel est appliqué le layout et travailler sur les enfant via les méthodes getElementAt() ou getVirtualElementAt(). La seconde méthode sert dans le cas où le layout est dit « virtualisé ».

Apparté : virtualisation de layout

Flex 4 permet, pour des raison de performance, d’utiliser un layout en mode « virtualisé », c’est-à-dire ne calculant la disposition des seuls enfants à afficher et non l’ensemble des enfants. Ce mode de fonctionnement s’applique particulièrement bien aux composants comprenant une liste de beaucoup d’enfants, mais ne calculant l’affichage d’une poignée à la fois, le reste attendant un scroll ou une action similaire pour être éventuellement affiché.

Application : création d’un ViewStackLayout

Avec les layouts en tête, il est inutile de demander pourquoi le composant ViewStack n’existe pas dans Spark : il devrait en pratique être un layout applicable à n’importe quel conteneur ! Même si le très bon article sur la virtualisation mentionne un prometteur je cite « (Planned) StackLayout », rien ne nous empêche d’en faire un simple, adapté à l’architecture Spark, plutôt que d’attendre (oui on est impatients à la fabrick).

Voici un exemple simple :

	import mx.core.IVisualElement;
	import spark.layouts.supportClasses.LayoutBase;

	public class ViewStackLayout extends LayoutBase {
		public function ViewStackLayout() {
			super();
		}

		protected var _index:uint;

		public function get index():Number {
			return _index;
		}

		public function set index(value:Number):void {
			if (_index != value && target != null && value >= 0 && value < target.numElements) {
				_index = value;
				target.invalidateSize();
				target.invalidateDisplayList();
			}
		}

		override public function updateDisplayList(width:Number, height:Number):void {
			var element:IVisualElement = useVirtualLayout ? target.getVirtualElementAt(index) : target.getElementAt(index);

			if (element) {
				element.setLayoutBoundsSize(element.getPreferredBoundsWidth(), element.getPreferredBoundsHeight());
				target.setActualSize(element.getPreferredBoundsWidth(), element.getPreferredBoundsHeight());
				target.setContentSize(element.getPreferredBoundsWidth(), element.getPreferredBoundsHeight());
			}
		}

		override public function measure():void {
			var count:int = target.numElements;

			for (var i:uint = 0; i < count; i++) {
				var element:IVisualElement = useVirtualLayout ? target.getVirtualElementAt(i) : target.getElementAt(i);

				if (i == index) {
					element.visible = true;
					element.includeInLayout = true;
					target.measuredWidth = element.getPreferredBoundsWidth();
					target.measuredHeight = element.getPreferredBoundsHeight();
				} else {
					element.visible = false;
					element.includeInLayout = false;
				}
			}
		}
	}

Vous noterez ici l’usage du getVirtualElementAt, en prévision de la gestion de la virtualisation.
Vous pouvez donc utiliser ce layout dans un DataGroup « piloté » par une tabbar par exemple comme ceci :

De cette façon, le jour où vous voudrez présenter ces éléments sous forme de CoverFlow, en mode TimeMachine… vous n’aurez pas à modifier le code de votre composant, mais uniquement votre skin.

Alors, on n’est pas mieux habillé en Spark ?Autres articles sur le même sujet

Flex4 : skin et primitives

Fabien — Fri, 04 Dec 2009 16:52:36 +0000

Dans le dernier article, nous avons fait un petit tour d’horizon du nouveau système de skin de Flex4. J’ai brièvement présenté EazeElement que j’utilise dans l’article. Nous allons maintenant rentrer un peu plus profondément dans les primitives, qui vous permettent de créer vos propres formes et autres éléments graphiques personnalisés.

Retour sur les primitives

Dans Flex4, une Skin est une agglomération d’éléments graphiques, définis avec un type de ligne, de fond, et des filtres. L’objet graphique final est une superposition de rectangles, de lignes, d’ellipses, d’images, de formes complexes.

Intéressons nous à celles qui utilisent directement l’API de dessin : Rect, Ellipse, Line, Path

Comment ça marche?

L’architecture des primitives utilisant l’API de dessin est la suivante :

Les classes de bases :

GraphicElement : la base des primitives. Cette classe définit les tailles et positionnement de l’objet dans l’espace, avec ses contraintes de position. Les getters protégés drawX et drawY, utilisés par toutes les primitives, renvoient la position réelle en x et y de l’objet.
StrokedElement : définit le Stroke (interface mx.graphics.IStroke), l’apparence de la ligne, de la primitive. La base des méthodes de dessin est présente : beginDraw, draw, endDraw. La méthode beginDraw applique le style du Stroke dans l’élément graphique Graphics de la primitive.
FilledElement : définit le Fill (interface mx.graphics.IFill), l’apparence du fond, de la primitives. La méthode beginDraw prépare l’objet graphique en appliquant la ligne Stroke et le fond Fill. A ce niveau, la méthode draw n’effectue aucun tracé.

Les primitives :

Line : (extension de StrokedElement) dessine une ligne, passant par 2 points (xFrom/yFrom et xTo/yTo). Si votre ligne est encadrée dans des contraintes top, bottom, left, right; la ligne dessinée sera une diagonale, respectant les contraintes top/left et bottom/right;
Ellipse : (extension de FilledElement) dessine une ellipse définie par ses contraintes de positionnement;
Rect : (extension de FilledElement) dessine un rectangle défini par ses contraintes de positionnement. Sa particularité est de pouvoir définir des rayons de courbure globaux (radiusX/radiusY), ou localisés aux angles du rectangle (topLeftRadiusX/topLeftRadiusY, bottomLeftRadiusX/bottomLeftRadiusY, …).
Path : (extension de FilledElement) dessine une forme complexe, définie dans une propriété data. Cette source utilise la syntaxe SVG.

Digression : Définition et obtention d’un “data Path”

Le “data source” d’une primitive Path est définit par un code, identique à celui utilisé dans le format vectoriel SVG. Ce code ressemble a celui-ci :
 M 8 4 C 8 4 15 4 15 4 L 15 0 L 27 8 L 15 15 L 15 11 L 8 11 L 8 11 L 8 11 L 0 11 C 0 11 0 11 0 11 C 0 7 3 4 8 4 Z

Il représente une flèche avec un bord arrondi, d’une largeur de 27 pixels, et une hauteur de 15 pixels.

Fonctionnement du code

c’est une succession de commandes (définies par des lettres), et de positions de points (les chiffres) en pixels utilisées par la commande.

Les différentes commandes sont :

M : Move, déplacement de la ligne vers le point définit par le couple de chiffres suivant. Exemple : “M 8 4” déplace le point courant de la ligne à la position x=8 et y=4. C’est toujours la première commande du code.
L : Line, création d’une ligne, avec comme point de destination le couple de chiffres suivant. Exemple “ L 15 11” crée la ligne depuis le point précédent, vers le point x=15 et y 11.
H : Horizontal Line, identique à la commande L, à la différence que seul le point de destination x est nécessaire. Exemple : “H 15” construit une ligne horizontale depuis le point précédent, vers le point x=15.
V : Vertical Line, identique à la commande H, en vertical.
Q : Quadratic Bezier, création d’une ligne courbe, a partir du précédent point, à destination du point définit par le dernier couple x/y, et passant par le point de contrôle définit par le premier couple x/y. exemple : “Q 15 11 20 22” la ligne est créée entre le point précédent et le point x=20, y=22, en passant par le point de contrôle x=15, y=11;
C : Cubic Bezier, identique à la commande Q, à la différence que la ligne passe par un point de contrôle supplémentaire. Exemple : “ C 0 7 3 4 8 4” la ligne est créée entre le point précédent et le point x=8 / y=4, en passant par un premier point de contrôle x=0, y=7, et un second x=3, y=4;
Z : Close, définit la fermeture de la forme. C’est aussi le dernier code du data.

Obtenir un code à partir d’une forme

La meilleur méthode pour obtenir le code de votre forme vectorielle est de passer par Fireworks. Je vous recommande fortement d’utiliser ce logiciel pour vos créations d’interface, car très complet, performant, et beaucoup plus adapté à la création graphique web que Photoshop ou Illustrator.

Fireworks, depuis la CS4, dispose d’une commande d’exportation FXG. Vous pouvez la trouver sous “Commandes” > “Exporter au format FXG”.

Il vous suffit de sélectionner votre forme, (si rien n’est sélectionné, c’est la totalité du document, y compris les calques masqué, qui sera exporté), et de lancer la commande d’exportation.

Vous obtenez un document de ce type :

Copiez le data du noeud , et utilisez le dans votre skin comme dans cette exemple :

Et maintenant?

L’idée serait de pouvoir créer des primitives, spécialisées ou non, utilisables dans un contexte de composants très précis, comme la primitive EazeElement du dernier article; ou dans une perspective plus globale, type librairie… Allons-y

Un trou dans mon Rectangle

Il peut être intéressant dans certains cas d’avoir un “trou” dans un rectangle. Pour créer par exemple une bordure qui pourrait avoir un Stroke ET un Fill. C’est ce que j’ai fais ici.

Pour obtenir un rectangle “troué” avec l’api de dessin, c’est extrêmement simple : il suffit de dessiner 2 rectangles l’un dans l’autre, à la suite : les points de vecteurs faisant partie du même chemin, cela génère l’exclusion du rectangle 2 dans le rectangle 1.

Bon c’est une méthode rapide, mais qui est suffisante pour nos besoin… Nous ne sommes pas en train de coder un outil de Pathfinding !

Dessin de rectangle

Au lieu d’utiliser les méthodes de dessin de rectangle fournies par Flex, j’utilise celle proposée par Philippe Elsass. Performante, elle m’évite de recourir au méthode de base, qui lance des contrôles de positions évitable.
Pour plus d’information sur son fonctionnement, je vous invite à vous rendre sur cette explication.

La méthode utlisée dans la librairie, que j’expose ci-après, derrière ce lien.

La primitive ExclusionRect

Donc nous avons besoin de 2 rectangles. Le premier est celui qui correspond aux contraintes de positionnement de base de la primitive. J’utilise une petite méthode getOutterVectorPoint qui me renvoie le vecteur définissant les points de ce rectangle. Le second rectangle, celui définissant la zone à exclure, à lui besoin de contraintes spécifiques, que j’ai ajouté dans la classe (innerTop, innerRight, innerLeft, innerBottom). la méthode getInnerVectorPoint remplit la même fonction que getOutterVectorPoint. Dans l’override de la méthode draw, celle qui “dessine”, les 2 rectangles sont créés l’un après l‘autre. Cela donne :

/**
 * Return the Vector of Point for the rectangle
 */
protected function getOutterVectorPoint() : Vector.
{
    var vector : Vector. = new Vector.();
    vector.push( new Point( drawX, drawY ) );
    vector.push( new Point( drawX+width, drawY ) );
    vector.push( new Point( drawX+width, drawY+height ) );
    vector.push( new Point( drawX, drawY+height ) );
    return vector;
}
/**
 * Return the Vector of Point for the inner rectangle
 */
protected function getInnerVectorPoint() : Vector.
{
    var vector : Vector. = new Vector.();
    vector.push( new Point( drawX+innerLeft, drawY+innerTop ) );
    vector.push( new Point( drawX+width-innerRight, drawY+innerTop ) );
    vector.push( new Point( drawX+width-innerRight, drawY+height-innerBottom) );
    vector.push( new Point( drawX+innerLeft, drawY+height-innerBottom ) );
    return vector;
}

/**
 * Draw the rectangle
 * @see com.lafabrick.uigfx.utils.UigfxUtils
 */
override protected function draw(g:Graphics) : void
{
    UigfxUtils.drawRoundPath( g, getOutterVectorPoint(), radius, true );

    if( enableExclusion ) {
        UigfxUtils.drawRoundPath( g, getInnerVectorPoint(), innerRadius, true );
    }
}

Utilisation

L’utilisation est très proche de celle de Rect, avec les contraintes et radius intérieur :

La classe complète de la primitive

Dessine moi une forme !

Une primitive qui me manque est celle permettant de dessiner une forme, à la manière de Path, mais en définissant un tableau de points. Quelque chose qui ressemble à ça :

Bien, mais pas suffisant.
Dans ce premier essai, les points sont définis “statiquement”. Une utilisation parfaite pour moi d’une telle primitive serait de pouvoir définir des contraintes de placement sur les points (top, verticalCenter, bottom et left, horizontalCenter, right), par rapport à la primitive.

J’ai donc fait une classe ConstraintPoint.

ConstraintPoint : un point “contraint”

Cette classe toute simple, extension de Point, dispose de propriétés de placement, en getter/setter : top, left, bottom, right, horizontalCenter, verticalCenter. Une méthode getConstraintPoint() renvoie un point x/y, calculer par rapport à une cible GraphicElement, en tenant compte des contraintes de placement. J’ai préféré avoir ce type de fonctionnement, plutôt que d’avoir le couple x/y directement modifié lors du set des différentes propriétés de contraintes.

Une primitive se dessine par rapport à son positionnement global. GraphicElement fournit les propriétés protégés drawX et drawY, qui donne les positions x/y de la primitive de manière global, par rapport à l’application.

La méthode getConstraintPoint() doit donc renvoyer le point par rapport à l’application. GraphicElement fournit tout la mécanique de calcul nécessaire, notamment l’objet postLayoutTransformOffsets, qui contient la position globale de la primitive.

La méthode en question :

public function getConstraintPoint( graphicElement : GraphicElement ) : Point
{
    var px : Number = 0;
    var py : Number = 0;

    var xOffset : Number;
    var yOffset : Number;

    if (graphicElement.displayObjectSharingMode ==
                        DisplayObjectSharingMode.OWNS_UNSHARED_OBJECT) {
        xOffset = 0;
        yOffset = 0;
    }
    else {
        xOffset = graphicElement.postLayoutTransformOffsets ?
                        graphicElement.x + graphicElement.postLayoutTransformOffsets.x : graphicElement.x;
        yOffset = graphicElement.postLayoutTransformOffsets ?
                        graphicElement.y + graphicElement.postLayoutTransformOffsets.y : graphicElement.y;
    }

    // Calcutates y position
    if( !isNaN( top ) ) {
        py = yOffset + top;
    }
    else if( !isNaN( bottom ) ) {
        py = yOffset + graphicElement.height - bottom;
    }
    else if( !isNaN( verticalCenter ) ) {
        py = ( yOffset + graphicElement.height ) / 2 + verticalCenter;
    }
    else {
        py = yOffset + y;
    }

    // Calcutates x position
    if( !isNaN( left ) ) {
        px = xOffset + left;
    }
    else if( !isNaN( right ) ) {
        px = xOffset + graphicElement.width - right;
    }
    else if( !isNaN( horizontalCenter ) ) {
        px = ( xOffset + graphicElement.width ) / 2 + horizontalCenter;
    }
    else {
        px = xOffset + x;
    }

    return new Point( px, py );
}

La classe complète ce trouve derrière ce lien.

Intéressons nous maintenant à la primitive.

Primitive PointsPath

J’utilise toujours la méthode de dessin drawRoundPath, contenu dans ma classe static UigfxUtils.

Ici, la classe étend FilledElement. Une propriété points, définit les différents points de type ConstraintPoint de la primitive. J’utilise ici un vecteur comme conteneur des points : Vector.. Le “set” de cette propriété appelle invalidateDisplayList(), afin de lancer le processus de dessin de la forme.

La méthode draw parcour le vecteur de points ConstraintPoint, appelle pour chacun sa méthode getConstraintPoint, et pousse le point dans un vecteur. C’est ce vecteur qui est utilisé par drawRoundPath.

Le code de cette mécanique :

public function get points():Vector.
{
    return _points;
}

/**
 * @private
 */
public function set points(value:Vector.):void
{
    _points = value;
    invalidateDisplayList();
}

/**
 * Draw the path
 * Drawing method is static, in UiGfxUtils
 * @see com.lafabrick.uigfx.utils.UiGfxUtils
 */
override protected function draw(g:Graphics) : void
{
    // replace points from local to global position
    var vectorPoint : Vector. = new Vector.();
    for each( var point : ConstraintPoint in points ) {
        vectorPoint.push( point.getConstraintPoint( this ) );
    }
    // launch drawing method
    UigfxUtils.drawRoundPath( g, vectorPoint, radius, true );
}

La classe PointsPath en entier

Utilisation

Reprenons l’exemple, avec cette primitive et les contraintes de placement :

La forme respecte les contraintes de placement, en fonction de l’évolution de la taille de la primitive. Amazing !
L’exemple complet (les sources au clic droit), ce cache sous ce lien.

Librairie Uigfx

Tout ce que je viens d’exposer fait partie d’une librairie nommée par Erick « uigfx ».
Cette petite librairie, sera bientôt disponible publiquement sur le svn lafabrick. Vous pouvez d’ores et déjà télécharger le projet (format .fxpl), dans la version proposée dans cette article. La documentation ( en anglais… pas parfait ! ) est disponible là.

[UPDATE]
Le projet uigfx a maintenant sa page sur google code. Pour plus d’information, la présentation de ce projet.
[/UPDATE]

Je vous laisse la place sur le fil de commentaire !

Autres articles sur le même sujet

Flex4 : composant personnalisé et skinning

Fabien — Fri, 27 Nov 2009 16:49:45 +0000

Je vous propose un petit tour d’horizon de la création de compo personnalisés avec Flex4 et le skinning. Vous allez voir ! Comme moi, vous ne voudrez plus jamais faire de Flex3. Moi ça fait 5 mois… et j’en suis bien content !

Alors voila. Nous allons voir comment faire un composant personnalisé avec le SDK4, de la conception actionScript, au skinning.
Il me fallait une idée de départ… Ceux qui me suivent sur Twitter aurons vu/lu qu’en ce moment je m’éclate avec Eaze, la librairie d’animation de Philippe Elsass. Super légère, facile d’utilisation et performante (Nicoptère a réalisé quelques “petites” démos sur le sujet). Je ne saurais que trop vous la conseiller.
Et bien on va se faire un petit compo de visualisation de ces fonctions d’animations

Première étapes : la primitive étendue

Avant de partir sur le composant, nous allons d’abord faire une extension de StrokedElement, qui va se charger de dessiner les courbes d’animations.

La classe StrokedElement est, dans Flex4, la classe de base pour tous les éléments graphiques ayant à dessiner une ligne. FilledElement, extensions de StrokedElement, s’occupe du remplissage. Les classes Line, Rect, Ellipse, Path… sont elles mêmes des extensions de FilledElement.

Nous allons donc créer une classe EazeElement, qui étend StrokedElement.
L’idée ici n’est pas d’afficher la “vraie” courbe d’accélération, mais plutôt d’avoir une “information visuelle” qui nous donne une idée sur l’évolution de l’animation, avec un point de départ et d’arrivé identique… Le voir en vrai c’est plus simple qu’à expliquer…

Nous allons associer à cette primitive 2 propriétés : eazeFunction : la fonction d’animation a tracer, et step la “précision” de la ligne.

Ensuite, il suffit d’overrider la méthode draw, et de faire ce que l’on veut dedans.
En gros nous allons boucler sur la largeur de l’élément, en se décalant à chaque passe de la valeur step, et calculer la position x, y de notre ligne en fonction de eazeFunction…. Vous pouvez voir en vrai la classe sous ce lien.

Aller hop on test tout ça ! Pour l’apparence, nous ajoutons à notre élément un “IStroke”. Cela peut être, , , … Y’en à d’autres : à vous de tester !

Rhooo ! C’est jouli !

C’est parti pour le composant

Notre composant va étendre SkinnableContainer, base pour la création de composant.

package com.lafabrick.components
{
    public class SimpleEazeViewer extends SkinnableContainer
    ...

Nous voulons utiliser notre primitive EazeElement dans ce compo. Il pourra aussi être redimensionnable, via une “ancre”. Nous devons donc définir ces différents objets de contrôles, dans la définition de notre composant. Nous utilisons ici les SkinPart.

SkinPart

Une skinPart définit un objet, visuel ou non, devant être présent (de manière obligatoire ou non) dans la skin. Ajoutons nos parties :

public class SimpleEazeViewer extends SkinnableContainer
{
    [SkinPart(required="false")]
    public var anchor : Group;

    [SkinPart(required="true")]
    public var eazeElement : EazeElement;

ici, eazeElement est requis et obligatoire. anchor, l’ancre pour redimensionner le composant, par contre est optionnel.

Nous verrons plus bas comment les utiliser dans le composant. Occupons nous des états de ce composant.

SkinState

SkinnableContainer définit 2 états de base : “normal” et “disabled”. Ces états devront être présents dans la skin. Nous allons ajouter un état “selected” : lorsque l’utilisateur déplacera l’ancre, le composant passera en état “selected”. Pour ajouter un état personnalisé, dans l’en-tête de classe, ajoutons le tag suivant :

[SkinState(name="selected")]

Nous allons également créer une propriété selected, qui définira si le composant est sélectionné…

dans le setter, nous allons appeler la fonction invalidateSkinState(), qui va déclencher le processus de changement d’état. Pour relier la propriété selected à l’état sélectionner, nous devons overrider la fonction protégée getCurrentSkinState().

private var _selected : Boolean = false;

public function get selected():Boolean
{
    return _selected;
}

public function set selected(value:Boolean):void
{
    _selected = value;
    invalidateSkinState();
}

override protected function getCurrentSkinState() : String
{
    return selected ? "selected" : "normal";
}

Ajoutons enfin la dernière propriété eazeFonction : Function qui va nous permettre de définir la fonction à tracer par la primitive.

Overridons un brin

Il est temps de passer à la gestion de tout ça. Ce que l’on a besoin, c’est de savoir quand les différents éléments définit dans les SkinPart sont ajoutés, pour leur pousser les propriétés et autres écouteurs qui vont bien. Pour cela, nous devons overrider la méthode partAdded de la manière suivante.

override protected function partAdded(partName:String, instance:Object) : void
{
    super.partAdded( partName, instance );

    if( instance == eazeElement ) {
        eazeElement.eazeFunction = eazeFunction;
    }

    if( instance == anchor ) {
        anchor.addEventListener(MouseEvent.MOUSE_DOWN, onAnchorMouseDown );
        systemManager.getSandboxRoot().addEventListener(MouseEvent.MOUSE_UP, onMouseUp );
        systemManager.getSandboxRoot().addEventListener(MouseEvent.MOUSE_MOVE, onMouseMove );
    }
}

Dans le sens inverse, il faut overrider partRemoved pour, entre autre chose, enlever les écouteurs sur les éléments.

override protected function partRemoved(partName:String, instance:Object) : void
{
    super.partRemoved( partName, instance );

    if( instance == anchor ) {
        anchor.removeEventListener(MouseEvent.MOUSE_DOWN, onAnchorMouseDown );
        systemManager.getSandboxRoot().removeEventListener(MouseEvent.MOUSE_UP, onMouseUp );
        systemManager.getSandboxRoot().removeEventListener(MouseEvent.MOUSE_MOVE, onMouseMove );
    }
}

Plus qu’à mettre la mécanique dans les fonctions qui vont bien.

La classe complète ici

plutôt super simple ce fonctionnement !

Côté skin

Skin ou SparkSkin ?

Vous avez 2 possibilités : partir de Skin ou SparkSkin, la dernière étant une extension de la première. La différence est que SparkSkin ajoute une mécanique spéciale pour exclure des éléments de la mécanique de skinning. Dans Flex4 vous pouvez injecter des couleurs de base à vos skin, avec la propriété baseColor. L’exclusion permet d’éviter de coloriser les éléments sélectionnés. Je vous invite a faire un saut dans les classes Skin des boutons (ex: spark.skins.spark.ToggleButtonSkin ) pour voir à quoi cela ressemble.

Nous allons choisir Skin.

Pointer sur le composant cible

En premier lieu, nous devons spécifier quel est le composant cible de cette skin. Cela se passe dans le tag metadata :


    [HostComponent("com.lafabrick.components.SimpleEazeViewer")]

Les états

Nous devons aussi retrouver les états définit dans le composants : normal, disabled et selected :

Plus qu’a ajouter vos éléments définit dans les skinPart (un Group avec l’id “anchor” et un EazeElement avec l’id “eazeElement” ). Et puis vous amusez a faire de la déco à grand coup de Rect, Ellipse, Line, Path, …. La grande classe !
Tout ces éléments se calibrent avec les contraintes top, left, bottom, right. Les possibilités sont infinies.

Pimp my State! inclusion, exclusion, groupage….

Voyons comment gérer notre skin en fonction de ses états.
Le nouveau système de gestion d’états est bien loin de celui proposé dans Flex3. Plus simple et bien plus logique, il vous permet un contrôle total de votre skin.
Admettons que vous ayez un composant avec les états suivants :

Un rectangle est définit dans la skin, et doit être inclus dans les états « up », « down », « over ». La déclaration de l’inclusion, et des différentes couleurs en fonction des états devra se faire suivant cette exemple :

Vous pouvez voir ici que l’attribution de valeur en fonction des états fonctionne aussi bien sur des couleurs que sur n’importe quelle autre propriété, comme sur le filtre.

Les états proposent une mécanique de groupage par nom, qui vous permet de pousser encore plus loin la gestion de la skin. Un état peut faire partie de plusieurs groupes :

Les états down et over, en vue « normal » et « sélectionné » font partie d’un même groupe « mouseOn ». De même, les états sélectionnés sont regroupés dans un groupe « selected ».

Nous pouvons alors modifier la skin de notre rectangle. Au lieu de définir dans quel état le rectangle est présent, nous allons plutôt lui définir dans quels groupes d’états il est exclu :

De même, la définition des couleurs et des propriétés du filtre peut être affectée globalement en fonction du groupe d’état :

Le rectangle est exclu des états sélectionnés, et les couleurs sont attribuées en fonction du groupe définissant une interaction de l’utilisateur « mouseOn ».

Sympa non?

Je veux mon composant !

Vous pouvez bien sur accéder a votre composant via hostComponent : si par exemple vous définissez un texte dans votre composant, vous avez possibilité de l’affecter directement dans votre skin comme ceci :

Bon a savoir : le contentGroup

SkinnableContainer définit un Group optionnel, contentGroup, qui, comme son nom l’indique est le groupe du contenu Ce groupe est le réceptacle des différents éléments que vous pouvez ajouter a votre compo. Par exemple un Panel dispose de ce contentGroup. Sinon on met rien dedans et ce ne serait plus un Panel…. Bon nous n’en avons pas besoin ici, mais si jamais vous avez besoin d’un composant qui peut être aussi un réceptacle de composants, n’oublier pas le contentGroup !

Retournons à notre compo…

… et regardons la skin complète.

Un peu plus loin…

Imaginons maintenant que vous ne vouliez plus afficher une courbe mais plusieurs à la suite, définit dans un tableau. Vous n’aurez donc plus un eazeElement, mais un Group qui contiendra vos primitives.
Le problème alors est de pouvoir skinner le trait de vos primitives. Vous devrez donc définir un IStroke. Ce qui est intéressant dans ce nouveau système de skin, c’est qu’il est aussi possible de définir ce Stroke, pourtant élément non visuel, dans une SkinPart.

[SkinPart(required="false")]
public var anchor : Group;

[SkinPart(required="true")]
public var eazeGroup : Group;

[SkinPart(required="true")]
public var eazeStroke : IStroke;

La déclaration côté Skin ce fera a l’intérieur des balises déclaration :


    [HostComponent("com.lafabrick.components.MultipleEazeViewer")]

La nouvelle classe, se cache derrière ce lien, et la skin associée derrière celui-ci.

La démo finale ( les sources )
J’espère que comme moi vous tomberez sous le charme. C’est fou comme une évolution peut vous montrer à quel point c’était tout nul avant !Autres articles sur le même sujet

Data visualization : BeeDocs 3D TimeLine Concept

Erick — Thu, 08 Jan 2009 01:00:16 +0000

Si les interfaces 3D permettent de très jolis effets graphiques ( whitevoid par exemple ) , j’ai vu peu d’exemples dans lesquels la 3D apportait une réelle amélioration en terme « d’ergonomie ». Dans la présentation qui suit, BeeDocs propose un intéressant concept de visualisation 3D de chronologies.

On dirait que les rotations 3D de FP10 arrivent à point… ;-p

Et vous ? vous z’en connaissez des exemples d’interfaces « utilement » en 3D ???

Plus d’info sur BeeDocs

Autres articles sur le même sujet

Design d’applications riches : les objectifs de Thermo ?

Erick — Wed, 30 Apr 2008 18:01:55 +0000

Durant les conférences MAX 2007 Adobe a présenté Thermo : l’outil qui va « révolutionner » le workflow « designer / developper » durant la création d’appli Flex. Les démos nous montraient la possibilité de créer des fichiers mxml en quelques clics à partir de fichiers graphiques ( photoshop, fireworks… ).

Dans cette nouvelle vidéo, un des concepteurs de l’application revient sur les avancées de Flex builder 3 en terme de personnalisation graphique, et nous explique pourquoi et comment Thermo viendra épauler Flex 4 pour la création de nos futures applications riches.

Thermo@adobe Labs

Voir la présentation vidéo officielle de Thermo

via http://www.rictus.com/muchadoAutres articles sur le même sujet

Le design déclaratif à un nom : Degrafa

Fabien — Sat, 05 Jan 2008 21:18:53 +0000

Ce 2 janvier est sortie un framework qui fera certainement parler de lui dans les mois à venir : j’ai nommé Degrafa. Cela fait un moment que je l’attendais celui-là… et en teasing ils en connaissent un rayon les p’tit gars de Degrafa !

Baptisé Origin dans sa version Beta, Degrafa est un framework de design déclaratif pour Flex. En gros : 2/3 balises mxml et vous voilà avec un joli polygone ou autres géométries vectorielles. De quoi se réinventer un tableau blanc.
Mais c’est aussi bien plus que ça : en plus de formes simples classiques, de formes libres, et autres outils de barbouillages; Degrafa nous fournis un certain nombre de classe nous permettant de skinner nos composants simplement. Une gestion étendue des fichiers SVG est prévu par la team… miam ! Et certainement d’autre chose à découvrir.

Le Framework est disponible sur le Google Code Degrafa. Plus d’information sur degrafa.com

A noter quelques bugs, notamment dans la gestion des skins CSS (class CSSSkin), que j’ai pu faire remonter sur le Google group du projet. Une version prochaine devrait résoudre tout ça.

En attendant, et parce que c’est bien d’agir, vous pouvez voir mon petit essai (les sources au clic droit. Le composant lafabrick dispo ici ).

UPDATE | Un autre exemple de création de forme en AS3 (sources incluses)

Autres articles sur le même sujet

Librairie lafabrick : parce que je le vaut bien

Fabien — Thu, 06 Dec 2007 14:37:45 +0000

Le développement du simulateur Climatus demande une bonne dose d’architecture pour ne pas ce noyer dans les classes. Et quoi de mieux qu’un petit framework pour structurer tout ça ?!

J’ai donc démarré le développement d’une librairie de composants, avec un ensemble de classes pour la gestion de mes vues, que j’utilise directement dans le simulateur. 3 composants principaux pour l’instant, dérivés de TitleWindow :

DraggableWindow et ResizableWindow : un TitleWindow draggable et resizable (on s’en serait douté !), inspiré de plusieurs travaux sur des composants Flex glané sur le web. La notion de Skin à une place importante, et, je l’espère, moins limitative que certain exemple que l’on peux trouver… et d’autres petites « features » que je vous laisse découvrir !
ExpandedWindow est le concentré des 2 autres, avec une gestion d’évenements « minimize » et « maximize », à la manière de l’évenement « close » du TitleWindow.

Je vous propose de découvrir cette petite librairie, via le googleCode « lafabrick » (pour changer !)

UPDATE
Un petit exemple, avec les sources.

N’hésitez pas à me faire part de vos réactions, remarques et idées qui me permettront d’améliorer et d’étoffer cette librairie.Autres articles sur le même sujet

TileUI : un bureau « réaliste » en AS3

Erick — Tue, 07 Aug 2007 07:06:20 +0000

Inspiré du projet BumpTop, et dans le même genre que les travaux de Thomas Brault ( et surtout de ) , voici une présentation du projet TileUI.

Prenez un bol de Flex , ajoutez une goutte de physique , une pointe de 3D. Secouez pendant une douzaine de jours…

Plus d’infos ici
Démo : www.tileui.comAutres articles sur le même sujet

Pimp my Flex

Erick — Fri, 06 Apr 2007 13:20:23 +0000

Flex Style Explorer est une appli Flex pratique et pédagogique, qui vous permet de visualiser et de générer des styles CSS pour vos composants Flex. Ca permet de découvrir rapidement une partie des (nombreuses) propriétés disponibles. C’est pas exhaustif, au bout d’un moment vous serez obligé de vous plonger dans la doc, mais pour commencer c’est pratique.

C’est l’occasion de signaler que vous pouvez trouver de nouveaux composants sur FlexLib et FlexBox.

Autres articles sur le même sujet