Shadoware.Org - Mot-clé - planet

KMDAlert - Logiciel de surveillance de périphérique RAID - Version pour KDE 4.0

Ulrich Van Den Hekke — Sun, 14 Aug 2011 20:43:00 +0200

Présentation

Possédant chez moi des disques durs en RAID logiciels sous Gnu/Linux, en 2007 (cela fait déjà 4 ans), j'avais écrit un petit logiciel dont le but était de faire du monitoring RAID.

En cas de reconstruction du RAID ou de disque défectueux, le logiciel affiche une notification à l'utilisateur, et change le statut affiché dans la barre de notification (systray). L'icône change bien sur en fonction de l'état du RAID :

dégradé (avec un point d'exclamation)
en cours de synchronisation (avec une barre de progression)
disque RAID dans un état normal

Ce logiciel ne tournait que sous KDE 3.X.

Voici donc une nouvelle version (qui a mis le temps de sortir) qui est un portage de l'application sous KDE 4.X. Elle utilise donc le nouveau système de notification de KDE (pour l'instant en passant uniquement par les notifications standard). Quelques améliorations y seront apportées plus tard.

Requis

Pour fonctionner KMDAlert nécessite que le dossier /sys soit monté et que /sys/block/ soit renseigné pour chaque volume RAID (exemple /sys/block/md0, /sys/block/md1, ...). KMDAlert observe ensuite les modifications faites sur les fichiers pour informer l'utilisateur des modifications faites sur le volume RAID ou sur les disques le composant.

De nos jours le dossier /sys et /sys/block devraient être toujours présents.

L'application a été développée sur Gnu/Debian Squeeze, sur un KDE 4.4.5 avec un noyau 2.6.32.

KMDAlert ne nécessite pas de Inotify. KMDAlert lit le contenu de plusieurs fichiers dans le dossier /sys toutes les 6 secondes pour être informé de la modification de l'état du périphérique. Sur l'application d'origine, développé sous un noyau 2.6.18, Inotify n'est pas averti des modifications faites sur le système de fichier /sys. Les dates de ces fichiers ne sont pas non plus modifiées. Si quelqu'un a une autre méthode à me proposer, je reste ouvert à toutes propositions.

KMDAlert est une application écrite en utilisant les librairies de KDE, mais devrait tout de même fonctionner sous Gnome. Les messages de notification utilisent donc le système de notification de KDE (bien que je n'utilise pas toutes ses possibilités).

Compilation / Installation

La compilation et l'installation de KMDAlert se fait à l'aide du trio habituel :

# Décompression de KMDAlert
tar xjfv kmdalert-0.2-77c0d6b4d49f.tar.gz
cd kmdalert-77c0d6b4d49f
 
# Préparation de la compilation
mkdir build
cd build
 
# Comilation
cmake ../
make
 
# Installation
make install

La compilation nécessite les librairies de développement KDE et Qt3, ainsi que le compilateur GCC.

Licence

La licence choisie est la GNU GENERAL PUBLIC LICENSE

Téléchargement

Vous pouvez télécharger une archive déjà construite de l'application sur KDE-Apps.org.
Le dépôt officiel pour télécharger les sources et participer : http://hg.shadoware.org/kmdalert.
Vous pouvez également télécharger la version attachée au billet.

Système de suivi

Il n'y a actuellement plus de système de suivi pour ce logiciel. En cas de problème, vous pouvez laisser un message dans les commentaires ou m'envoyer un mail.

[C++/Qt] CMake et Qt

Ulrich Van Den Hekke — Sun, 26 Jun 2011 14:41:00 +0200

Suite à un billet datant de 2008, je reviens vers vous pour ajouter quelques précisions sur la compilation de programme Qt avec CMake. En effet, pour mon programme XINX, j'ai modifié la chaîne de compilation actuelle utilisant QMake par une chaîne de compilation CMake.

CMake est un puissant générateur de Makefile, il permet de remplacer les anciens (mais pas complètement révolus) autotools. CMake ne remplace donc pas le programme make mais vient se placer en amont.

CMake permet de compiler un programme à différents endroits du dossier des sources, ce qui permet de garder le répertoire des sources propre.

Nous allons considérer dans la suite le dossier projet suivant :

projet
- source
- build

Compilation

Nous passerons sous silence la compilation d'un programme non Qt qui peut être retrouvé dans la documentation et nous nous limiterons aux explications liées aux programmes écrits en ''Qt' (qui peuvent également être retrouvés dans d'autres tutoriels sur Internet).

Package à utiliser

Pour utiliser Qt4 avec CMake, il faut inclure le package Qt4 :

project(lenomdemonprojet) 
cmake_minimum_required(VERSION 2.8.0)
find_package(Qt4 REQUIRED)

Définir les modules Qt à utiliser :

Il est ensuite possible d'activer ou de désactiver les différents modules de Qt à utiliser suivant le programme que vous écrivez :

set(QT_DONT_USE_QTCORE TRUE)
set(QT_DONT_USE_QTGUI TRUE)
set(QT_USE_QT3SUPPORT TRUE)
set(QT_USE_QTASSISTANT TRUE)
set(QT_USE_QAXCONTAINER TRUE)
set(QT_USE_QAXSERVER TRUE)
set(QT_USE_QTDESIGNER TRUE)
set(QT_USE_QTMOTIF TRUE)
set(QT_USE_QTMAIN TRUE)
set(QT_USE_QTNETWORK TRUE)
set(QT_USE_QTNSPLUGIN TRUE)
set(QT_USE_QTOPENGL TRUE)
set(QT_USE_QTSQL TRUE)
set(QT_USE_QTXML TRUE)
set(QT_USE_QTXMLPATTERNS TRUE)
set(QT_USE_QTWEBKIT TRUE)
set(QT_USE_QTSVG TRUE)
set(QT_USE_QTTEST TRUE)
set(QT_USE_QTUITOOLS TRUE)
set(QT_USE_QTDBUS TRUE)
set(QT_USE_QTSCRIPT TRUE)
set(QT_USE_QTASSISTANTCLIENT TRUE)
set(QT_USE_QTHELP TRUE)
set(QT_USE_PHONON TRUE)

Par exemple pour faire un programme utilisant le module Xml, XmlPatterns, et Webkit il faut ajouter :

set(QT_USE_QTXML TRUE)
set(QT_USE_QTXMLPATTERNS TRUE)
set(QT_USE_QTWEBKIT TRUE)

Quelques déclarations supplémentaires

Après avoir compilé les différentes parties du programme avec le générateur de Makefile de Qt (QMake), j'ai relevé les différentes définitions à ajouter lors de la compilation. De plus une fois les modules définis, il faut inclure également le module UseQt4.

add_definitions(-DUNICODE)
# Les Q_ASSERT, Q_ASSERT_X, ... sont désactivés en mode Release
if(CMAKE_BUILD_TYPE STREQUAL "Release")
	add_definitions(-DQT_NO_DEBUG)
endif()
 
# Include utilisé par Qt (du style include (UseQt4))
include(${QT_USE_FILE})
# Ajoute les définitions propres à Qt (suivant les modules ajoutés)
add_definitions(${QT_DEFINITIONS})

Macros pour générer les fichiers `moc`.

Macro par défaut

La facilité de programmation en Qt est due à l'ajout par le framework de la notion de méta-objet. Cette notion se fait à l'aide d'un générateur propre à ce framework : moc^[1].

Pour générer les méta-objets, il faut définir sur les objets descendants de QObject, une macro Q_OBJECT. Cette macro ajoute, côté interface, la déclaration de méthodes supplémentaires pour la gestion des méta-informations, et coté implémentation, ajoute l'implémentation de ces méta-informations ainsi que la déclaration des signaux et de slots de l'objet^[2].

Pour générer les fichiers d'implémentation générés par le compilateur moc, il est possible d'utiliser la macro suivante pour une liste de fichier sources (extension .cpp, ou .cxx, ...) :

qt4_wrap_cpp(outfiles inputfile ... OPTIONS ...)

Cette macro générera un fichier de type moc_nomfichier.cxx qu'il faudra inclure dans le ficher CPP (car il n'est pas inclus automatiquement dans la liste des fichiers à compiler.

#include "moc_nomfichier.cxx"

Une autre macro

Autre possibilité, faire comme avec les fichiers .pro de QMake et générer un fichier moc pour chaque fichier .h possédant une macro Q_OBJECT. Pour cela j'ai écrit la petite macro suivante :

macro(xinx_automoc outfiles)
  qt4_get_moc_flags(moc_flags)
  qt4_extract_options(moc_files moc_options ${ARGN})
 
  foreach (it ${moc_files})
    get_filename_component(it ${it} ABSOLUTE)
 
    if ( EXISTS ${it} )
		file(READ ${it} _contents)
 
		string(REGEX MATCHALL "Q_OBJECT" _match "${_contents}")
		if(_match)
			qt4_make_output_file(${it} moc_ cxx outfile)
			qt4_create_moc_command(${it} ${outfile} "${moc_flags}" "${moc_options}")
			macro_add_file_dependencies(${it} ${outfile})
			set(${outfiles} ${${outfiles}} ${outfile})
		endif(_match)
    endif ( EXISTS ${it} )
  endforeach(it)
endmacro(xinx_automoc)

Elle s'utilise ainsi :

xinx_automoc(moc_headers ${headers})

Macro pour générer les fichiers en tête d'interface graphique.

Les interfaces graphiques sont développées à l'aide de Qt-Designer. Ces fichiers sont au format XML.

La macro CMake suivante permet de transformer ces fichiers XML en fichier d'entête C.

qt4_wrap_ui(outfiles inputfile ...)

Macro pour compiler les fichiers de resources

La macro CMake suivante permet de compiler le fichier de ressource (extension *.qrc) en fichier cpp qui sera ensuite compilé avec le reste du programme :

qt4_add_resources(outfiles inputfile ... OPTIONS ...)

Macro pour compiler les fichiers de traduction

La macro CMake suivante est utilisée pour compiler un fichier de traduction ts en fichier de traduction compilé qm. Ce dernier est ensuite à inclure dans le programme (soit par un fichier de ressource, soit dans un dossier à coté).

qt4_add_translation(qm_files ts_files ...)

Compilation d'un plugin

En plus des options décrites ci-dessus, pour compiler un plugin, il faut ajouter quelques définitions supplémentaires.

Il faut bien faire attention à ce que le plugin soit compilé en mode Release si le programme l'est aussi (Ce qui n'est pas forcément pratique pour faire du debug).

Plugin dynamique

add_definitions(-DQT_PLUGIN)
add_definitions(-DQT_SHARED)
add_library(webplugin SHARED ${webplugin_SRCS} ${webplugin_MOC_SRCS})

Plugin Static

add_definitions(-DQT_PLUGIN)
add_definitions(-DQT_STATICPLUGIN)
if(CMAKE_SIZEOF_VOID_P MATCHES 8)
	add_definitions(-fPIC)
endif()
add_library(webplugin STATIC ${webplugin_SRCS} ${webplugin_MOC_SRCS})

Ajout d'un fichier RC pour windows

Les fichiers RC Windows contiennent des informations, comme par exemple, la version et le nom du programme.

Ces informations peuvent être utilisées par les programmes d'installation sous Windows ou aussi par Windows lui-même.

Afin de pouvoir ajouter un fichier RC file au programme, on peut ajouter ceci :

if(MINGW)
	set(CMAKE_RC_COMPILER_INIT windres)
	enable_language(RC)
	set(CMAKE_RC_COMPILE_OBJECT "<CMAKE_RC_COMPILER> <FLAGS> <DEFINES> -O coff -o <OBJECT> <SOURCE>")
endif(MINGW)

Ensuite le fichier RC se compile comme tout autre fichier (C++, ...)

Compilation d'une librairie static

add_definitions(-DQT_SHARED)
add_library(xinxplugins STATIC ${xinxplugins_SRCS} ${xinxplugins_MOC_SRCS})

Utiliser le programme CMake

Une fois le programme configuré, il est possible de compiler ce dernier à l'aide des commandes suivantes :

mkdir build
cd build
 
cmake ../sources
 
make
make install

Sous Windows, il est possible de compiler en utilisant MinGW pour compiler ou d'utiliser le compilateur de Visual Studio.

Il est également possible de définir un emplacement pour l'installation différent du dossier par défaut :

cmake -DCMAKE_INSTALL_PREFIX=/home/login/usr/

Notes

[1] C'est ce qui fait tout l'avantage de Qt mais est aussi son inconvénient car il ajoute une couche supplémentaire. C'est ensuite une question de goût.

[2] facilitant la gestion des évènements dans Qt

[C++/Qt] Performance de l'utilisation de QSharedPointer

Ulrich Van Den Hekke — Tue, 25 Jan 2011 12:00:00 +0100

Présentation

Qt est un framework orienté objet écrit en C++ et permettant de faire des interfaces graphiques. Ce framework est utilisé par le projet KDE depuis ses débuts pour en faire un environnement de bureau très complet.

Qt fournit un ensemble de pointeur intelligent^[1] permettant de gérer plus facilement la mémoire. Le but est alors de ne plus avoir à supprimer des objets. La suppression se fera soit par un pointeur intelligent soit par le système de hiérarchie d'objet existant en Qt (l'objet père qui supprime l'ensemble des objets fils qui lui sont rattachés).

Qt propose l'ensemble des pointeurs intelligents suivants:

QSharedDataPointer / QSharedData : ces deux classes utilisées ensemble permettent d'écrire un objet avec partage implicite. Cela signifie que l'objet fonctionnera comme la classe QString. Tant que l'objet est copié, passé en paramètre, .... l'objet n'est pas dupliqué (tous les objets pointes vers le même espace mémoire). Au moment où l'objet est modifié, l'objet est dupliqué. C'est ce qu'on appelle le COW^[2].
QExplictlySharedDataPointer / QSharedData : QExplicitlySharedDataPointer est une variante de QSharedDataPointer. Ce pointeur intelligent, comme son nom l'indique, est détaché uniquement lorsque la méthode detach() est appelée explicitement. Cette classe permet de faire des objets qui fonctionnent comme des pointeurs mais qui sont utilisés sans la notion de pointeur (le *). La suppression des données partagées se fait donc quand tous les objets ne sont plus utilisés.
QScopedPointer : Ce pointeur est le plus simple. Il permet de déclarer un pointeur sur le tas et s'occupe de la destruction de l'objet, lorsque le programme sort de la portée du bloc. Cela permet de ne plus se soucier de la libération du pointeur dans les cas d'erreur (exception, retour avant la fin de la fonction car le fichier n'a pu être ouvert, ...).
QSharedPointer : Le pointeur dont on parlera dans la suite de ce billet. Il permet de partager non plus des données (comme le fait QSharedData) mais de partager un pointeur^[3]. Nous allons voir dans la suite du billet, comment simplement utiliser ce pointeur, et les performances de ce pointeur par rapport à un pointeur standard.

Sommaire

Notes

[1] en anglais : smart-pointer

[2] COW = Copy On Write

[3] Ce pointeur est l'équivalent du pointeur intelligent boost::shared_ptr du projet Boost. Boost est une librairie qui ajoute beaucoup de facilité pour les programmes en C++, comme par exemple les smart-pointer dont certains seront inclus dans C++0x, ou de la boucle std::for_each.

Utilisation de QSharedPointer

A quoi sert-il ?

L'objet QSharedPointer fait partie des pointeurs intelligents. Ces pointeurs permettent de gérer automatiquement la libération de la mémoire (plus besoin de faire delete ptr; quand le pointeur n'est plus utilisé) tout en restant utilisable comme un pointeur normal.

QSharedPointer fonctionne par comptage de référence. Après la déclaration, à chaque affectation, on augmente le compteur de référence, lorsqu'on quitte la portée du bloc, on décrémente le compteur de référence. QSharedPointer détruit donc automatiquement le pointeur quand il n'existe plus aucune référence vers ce pointeur. QSharedPointer vient donc comme une encapsulation de notre pointeur.

Comment l'utiliser ?

La déclaration d'un pointeur en C, se fait en écrivant MyObject*. La syntaxe en utilisant un QSharedPointer se fait en écrivant QSharedPointer<MyObject>. Par la suite dans le programme, l'utilisation du pointeur QSharedObject se fera de la même manière qu'un pointeur C. (Avec l'opérateur -> pour appeler un membre, une méthode, ...) . Appelons dans la suite pointeur C, les pointeurs standards et QSharedPointer, le pointeur intelligent.

Afin d'éviter d'avoir un pointeur normal pouvant être supprimé à tout moment dans l'application, lors de l'utilisation de QSharedPointer, il ne faut utiliser le pointeur C résultant du new que pour la création du QSharedPointer. On peut donc directement créer le QSharedPointer en utilisant le constructeur QSharedPointer ( T * ptr ) qui prend en paramètre le pointeur C. C'est entre ces parenthèses que nous allons créer le pointeur C^[1].

{
  // Création du pointeur intelligent à partir d'un pointeur normal.
  QSharedPointer<MyObject> ptr(new MyObject());
 
  // Utilisation du pointeur intelligent comme un pointeur normal.
  if (ptr)
  {
    ptr->setMembre(maValeur);
  }
 
  // Appel d'une méthode utilisant ce pointeur
  maMethode(ptr);
}

Lorsque l'on quitte le bloc, si le comptage de référence tombe à 0, on supprime le pointeur. A l'intérieur de maMethode() le nombre de référence sera passé à 2. Si la méthode utilise le pointeur mais ne l'assigne nul part, le nombre de référence devrait être retombé à 1 et donc ici sera décrémenté à 0.

Si par contre, maMethode() fait des opérations d'assignation de ptr et conserve une copie, le comptage ne tombera pas à 0 tant que l'objet restera utilisé (assigné) ailleurs.

Regardons un exemple de maMethode() :

void maMethode(QSharedPointer<MyObject> ptr)
{
  ptr->setMembre2(maValeur);

Au début du bloc, ici le comptage de référence est à 2 et sera décrémenté à la sortie de la méthode. On peut modifier les membres de ptr, et dans ce cas pas de changement du comptage de référence.

this->monPtr = ptr;
}

Au contraire, on peut également l'assigner à un autre objet. Dans ce cas le comptage de référence de cet objet passera à 3. A la sortie de la méthode il sera décrémenté et passera alors à 2. L'objet ne sera pas supprimé tant qu'on ne fera pas un this->monPtr.clear() ou que this ne sera pas détruit.

Si on veut garder une référence d'un pointeur mais qu'on ne souhaite pas que celle-ci incrémente le nombre de référence du QSharedPointer, il est possible de créer un pointeur faible. Ce pointeur passe par l'objet QWeakPointer. Pour obtenir ce type de pointeur, il suffit de faire :

QWeakPointer<MyObject> ptrW = ptr->toWeakRef ();

ptrW n'incrémente donc pas le comptage de référence, cela signifie donc que le pointeur peut être détruit même si un objet QWeakPointer existe. Il sera alors possible de faire un ptrW.isNull() pour savoir si le pointeur est toujours valide. Si l'utilisateur a également besoin d'avoir accès à un membre de l'objet, il pourra le transformer en QSharedPointer avant de l'utiliser sauf si le pointeur est null.

QSharedPointer<MyObject> ptr2 = ptrW->toStrongRef ();
if (ptr) 
{
   ptr->maMethodePtr();
}

Il faut tester que ptr2 est encore valide, car tant que la transformation du pointeur faible vers le QSharedPointer n'a pas encore été fait, il est possible que le nombre de référence vers l'objet soit tombé à 0 et qu'il ait été supprimé.

Comment utiliser `this`

Un des points peu pratique de l'utilisation de QSharedPointer est que le comptage de référence ne fonctionne pas si plusieurs QSharedPointer pointent vers le même objet mais ont tous été créés à partir du pointeur C. Prenons par exemple, le cas suivant :

MyObject * ptr = new MyObject();
 
QSharedPointer<MyObject> ptr1 = QSharedPointer(ptr);
QSharedPointer<MyObject> ptr2 = QSharedPointer(ptr);

Le problème d'écrire ces lignes ainsi, et que pour ptr1 comme pour ptr2, l'objet n'est référencé qu'une fois. Ainsi le premier qui tombera à 0 détruira l'objet, alors que l'autre pourrait encore l'utiliser. Il faut donc écrire les choses comme suite :

QSharedPointer<MyObject> ptr1 = QSharedPointer(new MyObject());
QSharedPointer<MyObject> ptr2 = ptr1;

Ainsi ptr1 et ptr2 ont bien chacun connaissance de l'existence de l'autre. Cela contraint donc à remplacer toutes les déclarations du type MyObject* par QSharedPointer<MyObject>. Ceci est donc à faire dans les paramètres des méthodes, dans les membres, dans la déclaration des variables locales, ... . On ne peut donc plus utiliser le pointeur C MyObject* directement, mais seulement au travers de QSharedPointer ou de QWeakPointer.

Cela commence à poser problème lors de l'utilisation de this dans un objet. Imaginons une méthode d'un objet mettant à jour des membres fils avec en paramètre le père. Nous aurions alors tendance à écrire ceci :

void Object2::setParent(QSharedPointer<MyObject> parent)
{
...
}
 
....
 
void MyObject::setMember(Object2 * obj)
{
  _membre = obj;
  if (obj)
  {
    obj->setParent(QSharedPointer<MyObject>(this));
  }
}

Ceci ne marchera pas car on créerait un nouvel objet QSharedPointer commençant son comptage de référence à 1, alors que nous en avons déjà au moins un autre pointant vers notre instance^[2]. MyObject pourrait alors être détruit alors qu'il est encore utilisé par Object2.

Pour éviter cela, il faut alors passer par un pointeur intelligent this. Pour cela nous allons utiliser deux choses :

Un membre nommé _this de type pointeur intelligent QWeakPointer, contenant une référence à l'objet lui même. (Nous n'utilisons pas un QSharedPointer, pour éviter une référence circulaire, voir le paragraphe suivant).
Une méthode statique utilisée pour la création (nous n'allons plus utiliser le constructeur, car à ce moment, il n'existe pas encore de QSharedPointer pointant vers notre objet).

Voici un exemple de comment écrire le constructeur maison :

class MyObject
{
public:
  static QSharedPointer<MyObject> create(QString parametre)
  {
    QSharedPointer<MyObject> ptr(new MyObject(parametre);
    ptr->_this = ptr.toWeakRef();
    return ptr;
  }
private:
  MyObject(QString parametre)
  {
    ...
  }
 
  QWeakPointer<MyObject> _this;
};

Le constructeur devient alors privé (ou protégé si on a besoin de la notion d'héritage) afin d'obliger l'utilisateur de la classe à utiliser notre méthode de création. Dans notre nouvelle méthode de création create, qui est une méthode statique, nous allons créer le pointeur et initialiser le QWeakPointer de notre objet avec le pointeur intelligent que nous venons de créer. Nous retournons un QSharedPointer. La méthode create devient alors notre nouveau constructeur, mais créant des instances d'objets de type QSharedPointer<MyObject> et non plus des instances d'objet MyObject*.

Notre méthode setMember() peut alors être ré-écrite :

void MyObject::setMember(Object2 * obj)
{
  _membre = obj;
  if (obj)
  {
    obj->setParent(_this.toStrongRef());
  }
}

Comment éviter les références circulaires

Le principe d'une référence circulaire est qu'un objet A référence l'objet B et l'objet B référence l'objet A.

Voici par exemple, un cas de référence circulaire :

class A
{
public:
  static create()
  {
    QSharedPointer<A> ptr(new A());
    return ptr;
  }
  ~A()
  {
  }
private:
  A()
  {
    b = B::create();
    b->setA(_this);
  }
  QSharedPointer<B> b;
  QWeakPointer<A> _this;
};
 
class B
{
public:
  static QSharedPointer<B> create() 
  {
    QSharedPointer<B> ptr(new B());
    return ptr;
  }
  void setA(QSharedPointer<A> b);
  QSharedPointer<A> getA();
private:
  QSharedPointer<A>  a;
};

Cela peut-être aussi le cas, si par exemple une instance d'objet C référence des instances d'objets fils C, qui possèdent eux-même un pointeur vers l'objet C père.

class C
{
public:
  static QSharedPointer<C> create()
  {
    QSharedPointer<C> ptr(new C());
    _this = ptr.toWeakPtr();
    return ptr;
  }
 
  ~C()
  {
  }
 
  void addChild(QSharedPointer<C> c)
  {
    _childs.append(c);
    c->setParent(_this);
  }
 
  void setParent(QSharedPointer<C> c);
  QSharedPointer<C> getParent();
private:
  C()
  {
  }
 
  QWeakPointer<C> _this;
  QSharedPointer<C> _parent;
  QList< QSharedPointer<C> > _childs;
};

Dans ces cas là, on a : - L'objet A possède la référence vers l'objet B - L'objet B possède une référence vers l'objet A. - Même principe avec l'objet C

Dans ce cas, il restera alors toujours une référence vers A, et une vers B, même si plus aucune variable ne référence ces objets. Cette référence circulaire fait que l'objet ne sera jamais détruit même si on n'a plus besoin de l'objet.

Si on décide que l'objet A sera l'objet maitre (donc que sa destruction engendrera la destruction de l'objet B), on peut alors écrire les choses ainsi pour l'objet B :

class B
{
public:
  static QSharedPointer<B> create() 
  {
    QSharedPointer<B> ptr(new B());
    return ptr;
  }
  void setA(QWeakPointer<A> b);
  QWeakPointer<A> getA();
private:
  QWeakPointer<A>  a;
};

Dans ce cas, avec l'utilisation d'un QWeakPointer, lorsque qu'il n'existera plus de référence vers l'objet A, le pointeur faible a sera mis à jour comme ne contenant plus de référence^[3]. L'instance de l'objet A sera réellement détruite. Il n'y aura alors plus aucune référence vers l'objet B qui sera alors également détruit^[4].

Utilisation dans les applications multi-thread.

L'utilisation de QSharedPointer simplifie l'écriture des applications multi-thread (les objets QSharedPointer et QWeakPointer sont thread-safe).

Dans ces applications il n'y a alors plus besoin de se soucier si l'objet est en cours d'utilisation ailleurs dans l'application avant de le supprimer^[5]. Lorsqu'un pointeur ne devient plus utilisé dans un thread donné, il ne sera détruit que s'il n'y a pas d'autres références dans d'autres threads de l'application^[6].

Avec l'utilisation de QWeakPointer, un thread pourra tester l'existence du pointeur avant d'effectuer une opération et pourra aviser le cas échéant sans faire planter toute l'application^[7].

Utilisation d'un pool

Si la création et la destruction d'un objet est coûteux, il est envisageable de diminuer le coût de destruction et de création d'un thread en utilisant un Pool d'objet. Dans ce cas l'objet QQueue pourra être utilisé pour représenter notre Pool.

Lors de la demande de création, en utilisant notre méthode create ci-dessus, on prend alors une valeur du pool (si disponible) et on la retourne sous forme d'un QSharedPointer.

QSharedPointer<MyObject> MyObject::create()
{
  MyObject * c_ptr;
  if (_queue.size())
  {
	c_ptr = _queue.dequeue();
  }
  else
  { 
	c_ptr = new MyObject();
  }
  QSharedPointer<MyObject> ptr(c_ptr, ReturnToPool);
  ptr->_this = ptr.toWeakRef();
  return ptr;
}

Dans l'exemple ci-dessus^[8], on demande à la queue, qui doit être une variable globale ou statique, un élément, et si ce n'est pas possible, on crée un nouvel objet de type MyObject (dont on suppose la création coûteuse).

Lors de la création du QSharedPointer on utilise alors le constructeur QSharedPointer ( T * ptr, Deleter deleter ) sur lequel on définit une méthode Deleter nommée ReturnToPool dont le but est de remettre les objets en pool.

static void ReturnToPool(MyObject *obj)
{
  if (_queue.size() < MAX_SIZE_QUEUE)
  {
	_queue.enqueue(obj);
  }
  else
  {
	delete obj;
  }
}

Dans ce cas de retour au pool, si le pool est rempli, on détruit l'objet (pour éviter de consommer trop de mémoire), sinon on l'ajoute au pool. Dans ce cas, le pool est agrandi au fur et à mesure des besoins, jusqu'à une taille limite.

Bien sûr il faut que la performance de l'utilisation d'un pool soit plus intéressante que celle de la création de l'objet et de son initialisation.

Attention : Ce point ne fonctionne, par contre, pas si l'objet (MyObject) est un descendant de QObject. En effet QObject garde une référence du QSharedPointer en mémoire et lors de la réutilisation du QObject une erreur indique que l'objet n'a pas été détruit et est déjà utilisé par un QSharedPointer. On n'a pas le problème avec std::tr1::shared_ptr

Benchmark

Le but du benchmark est de se faire une idée sur les performances d'une application utilisant des QSharedPointer à la place des pointeurs normaux. Attention, ce bench ne prend pas en compte le besoin potentiel de Mutex, de comptage de référence manuel, ... dans les applications multi-thread qui pourrait être nécessaire pour ne pas supprimer le pointeur si besoin.

Dans ce test nous allons tester également (en comparaison), le pointeur intelligent du C++0x^[9].

Nous allons donc tester les opérations courantes de création, destruction, modification, affectation.

Code source

Le code source est disponible, attaché au billet. Dans la suite du billet, seuls les morceaux intéressants du benchmark seront décris. Le benchmark utilise QTest. Nous avons créé un objet bidon ObjetTest qui dans le constructeur allouera un pointeur et remplira une liste, et le destructeur supprime ce pointeur (et forcément la liste).

Pour que chaque test soit indépendant, le jeu de test sera initialisé avant le début de chaque QBENCHMARK et détruit à la fin du bloc. Nous aurons quatre méthodes :

Allocation
Modification
Affectation
Nettoyage

Pour chaque test nous allons faire le test avec

un pointeur C standard
le pointeur QSharedPointer de Qt
le pointeur std::tr1::shared_ptr de C++0x

Pour le test d'allocation et le test de nettoyage, nous allons également utiliser l'optimisation possible, vu ci-dessus, d'un Pool d'objet. Nous allons faire le test avec :

le pointeur QSharedPointer de Qt
le pointeur std::tr1::shared_ptr de C++0x

Le jeu de test

Test de l'allocation

La création du pointeur en utilisant QSharedPointer instancie le pointeur ainsi que le QSharedPointer. Le temps d'exécution est donc potentiellement deux fois plus long (voir le benchmark à la fin de ce billet).

Pour la création du pool, nous allons utiliser une méthode qui créera le pointeur s'il n'est pas dans le pool, et sinon prendra le pointeur du pool. Dans notre cas de test, il y aura toujours une valeur dans le pool, que l'on aura rempli au préalable.

La méthode createFromPool() et createFromBoostPool() est sensiblement identique :

QSharedPointer<ObjetTest> createFromPool()
{
        ObjetTest * c_ptr;
        if (_queue.size())
        {
          c_ptr = _queue.dequeue();
        }
        else
        {
          c_ptr = new ObjetTest();
        }
 
        QSharedPointer<ObjetTest> ptr(c_ptr, returnToPool);
        return ptr;
}

C Pointer
ObjetTest* ptr = new ObjetTest();
Qt Smart Pointer
QSharedPointer<ObjetTest> ptr(new ObjetTest());
Qt Smart Pointer as Pool
QSharedPointer<ObjetTest> ptr = createFromPool ();
C++0x Smart Pointer
std::tr1::shared_ptr<ObjetTest> ptr(new ObjetTest());
C++0x Smart Pointer as Pool
std::tr1::shared_ptr<ObjetTest> ptr = createFromBoostPool ();

Test de Modification d'une donnée

Pour la modification d'une donnée, on génère un nombre aléatoire que l'on va stocker (toujours le même pour chaque test, cela n'a pas d'importance). La génération du nombre aléatoire se fait en dehors du bloc, pour éviter de polluer le test avec le calcul d'un nombre aléatoire. Ici il n'y a pas création d'affectation du pointeur, juste une affectation d'une valeur dans le contenu du pointeur. La syntaxe pour le C, et pour le pointeur intelligent est identique.

C Pointer / Qt Smart Pointer / C++0x Smart Pointer
obj->value = random_number;

Test d'affectation

Pour l'affectation nous allons créer une nouvelle variable qui pointera sur le même pointeur, et sur lequel on fera une modification. La création d'un pointeur peut arriver par exemple lors du passage du pointeur à une fonction, ou lors de la déclaration d'une variable devant contenir la même valeur. Cette déclaration supplémentaire a peu d'impact pour un pointeur C mais pour un pointeur intelligent oblige la création d'un objet, et l'incrément d'un nombre d'instance (qu'on décrémente ici dans la même boucle).

C Pointer
ObjetTest * obj2 = obj; obj2->value = random_number;
Qt Smart Pointer
QSharedPointer<ObjetTest> obj2 = obj; obj2->value = random_number;
C++0x Smart Pointer
std::tr1::shared_ptr<ObjetTest> obj2 = obj; obj2->value = random_number;

Test de destruction

Pour ce test, nous allons initialiser une liste de pointeur, et pour le benchmark, nous allons supprimer un à un chaque élément de la liste. La destruction du pointeur en C se fait par un delete. Pour le pointeur ''intelligent', il n'y a pas de destruction explicite. Nous allons juste supprimer le pointeur de la liste, le pointeur sera alors automatiquement détruit car il n'y aura plus de référence vers ce pointeur.

Pour le cas de test utilisant la notion du Pool, on aura créé le pointeur avec le delete returnToPool() :

void returnToPool(ObjetTest *obj)
{
        _queue.enqueue(obj);
}

Cette méthode ne fait pas de réelle destruction, mais juste un ajout de l'objet au pool.

C Pointer
delete c_ptr_list.at(0); c_ptr_list.removeFirst ();
Qt Smart Pointer / Qt Smart Pointer as Pool / C++0x Smart Pointer / C++0x Smart Pointer as Pool
smart_ptr_list.removeFirst ();

Résultat du test

Le test a été fait en utilisant la version 4.6.3 de Qt. Test effectué pour 5 000 000 itérations.

	Pointeur C	Pointeur Qt	Pointeur C++0x	Pool en utilisant QSharedPointer	Pool en utilisant std::tr1::shared_ptr
Allocation	0.0004275 msec	0.0007692 msec	0.0006604 msec	0.0002590 msec	0.0002286 msec
Modification	0.000010 msec	0.000012 msec	0.000012 msec
Affectation	0.000010 msec	0.0000386 msec	0.0000230 msec
Destruction	0.000190 msec	0.0003161 msec	0.0003359 msec	0.0004003 msec	0.0003601 msec

Conclusion que l'on peut en tirer, le pointeur C est ce qu'il y a de plus rapide à partir du moment où on fait de l'allocation de l'affectation ou de la destruction. Par contre il n'apporte pas la souplesse qu'apporte les pointeurs intelligents entre autre pour les applications multi-threadé.

On remarque que le pointeur C++0x est plus rapide pour la création, mais apparemment plus lent en destruction. Il est également possible avec le pool de gagner en performance (surtout en création). Par contre le coût de destruction de l'objet n'est pas encore assez fort pour y gagner en utilisant le pool.

Ensuite il est important de se faire son propre jugement selon ses besoins. Si besoin le source est attaché, vous pouvez faire vos propres tests.

Notes

[1] Si à un moment donné il faut utiliser le pointeur C pour une raison quelconque, on peut utiliser ptr.data() mais il faut s'assurer que le pointeur ne sera pas détruit en déclarant un QSharedPointer dans le même bloc utilisant le pointeur C. Le QSharedPointer ne devra être détruit qu'après utilisation du pointeur C. Ceci peut être fait dans certain cas pour des raisons de performance.

[2] Sinon nous ne serions plus là pour lancer la méthode

[3] Le QWeakPointeur ne gardant pas d'instance d'objet, car il n'incrémente pas le compteur de référence

[4] s'il n'existe pas de référence vers l'objet B ailleurs dans l'application

[5] Attention quand même, QSharedPointer protège le pointeur mais pas le contenu

[6] d'autres threads pouvant inclure le thread principal

[7] Si l'objet est supprimé, QWeakPointer, sera alors remis à null

[8] Dans le code en question, il faudrait ajouter la notion de mutex autour de la gestion de la queue, en cas de création parallèle.

[9] Le pointeur intelligent shared_ptr de C++0x à pour origine le pointeur Boost

[C++/Qt] Concaténation de chaînes de caractères

Ulrich Van Den Hekke — Wed, 22 Dec 2010 13:03:00 +0100

Présentation

Qt est un framework orienté objet écrit en C++ et permettant de faire des interfaces graphiques à l’aide de ces widgets. Ce framework est utilisé par le projet KDE depuis ses débuts pour en faire un environnement très complet.

Qt permet donc de faire des interfaces graphiques mais aussi d’accéder à des bases de données SQL, de faire de la communication réseau, une gestion simplifiée des threads, la lecture de fichier XML. Qt intègre aussi le moteur HTML Webkit.

Qt ajoute une couche supplémentaire au C++ permettant de faire de l’introspection de classe un peu plus poussée (comme l’appel d’une méthode dont on ne connaît le nom qu’à l’exécution). Qt permet également la gestion d’évènement par l’intermédiaire d’un système puissant de SIGNALS et de SLOTS.

Dans la suite de cet article nous allons nous concentrer sur une très petite partie de Qt mais qui est utilisée dans beaucoup d’applications écrites en Qt : les chaînes de caractères, et plus précisément, la concaténation de chaînes de caractères.

Concaténation de chaînes de caractères.

Comme dans d’autres langages, la concaténation de chaînes de caractères se fait à l'aide de l'opérateur +. Prenons un exemple simple :

#include <QString>
 
QString abc = "abc", def = "def";
QString result;
 
result = abc + def;

L'utilisation de l'opérateur + facilite l'écriture de la concaténation des chaînes de caractères (tout comme l'opérateur == permet de facilement comparer des chaînes de caractères de type QString).

Malheureusement cette écriture rend le code peu performant pour diverses raisons (que l’on peut retrouver dans la documentation de l’objet QString).

Concaténation rapide de chaînes de caractères

A partir de Qt 4.6, Nokia, a ajouté un template nommé QStringBuilder (cet objet fait beaucoup penser à l'objet StringBuilder de JAVA permettant d'accélérer les concaténations de chaînes de caractères).

Ce template ne s’utilise pas directement mais au travers de l'opérateur %. En remplaçant donc l'opérateur + par % on gagne en performance (dixit la doc de Qt).

Pour pouvoir utiliser l'opérateur, il suffit d'inclure le fichier QStringBuilder :

#include <QStringBuilder>
 
QString abc = "abc", def = "def", ghi = "ghi";
QString result;
 
result = abc % def % ghi;

Une autre possibilité est de définir (par exemple dans votre fichier .pro ou dans un include général de votre application) les définitions QT_USE_FAST_CONCATENATION, et QT_USE_FAST_OPERATOR_PLUS.

Ces définitions permettent de remplacer l'opérateur + par l'opérateur % dans toute l'application. Par contre cette opération peut demander quelques modifications de votre code.

#define QT_USE_FAST_CONCATENATION
#define QT_USE_FAST_OPERATOR_PLUS
 
#include <QString>
 
QString abc = "abc", def = "def";
QString result;
 
result = abc + def;

Benchmark

Nous allons donc dans la suite du document vérifier que l'opérateur % est plus rapide que l'opérateur +. Pour cela nous allons utiliser le module de benchmark de Qt.

Code source

Voici le petit programme permettant de tester la performance de la concaténation. Notre exemple simple va constituer à la concaténation de 26 chaînes de caractères créées au début. L'appel se fera une première fois en utilisant l'opérateur + et une seconde fois en utilisant l'opérateur %.

#include <QtCore/QString>
#include <QtTest/QtTest>
#include <QStringBuilder>
 
class TestPerf : public QObject
{
    Q_OBJECT
 
public:
    TestPerf();
 
private Q_SLOTS:
    void concat();
    void concat_data();
};
 
TestPerf::TestPerf()
{
}
 
void TestPerf::concat()
{
	QFETCH(bool, useStringBuilder);
	QString result;
 
	QString a("a"), b("b"), c("c"), d("d"), e("e"), f("f"), g("g"), h("h"), i("i"), j("j"), k("k"), l("l"), m("m"), n("n"), o("o"), p("p"), q("q"), r("r"), s("s"), t("t"), u("u"), v("v"), w("w"), x("x"), y("y"), z("z");
 
	if (useStringBuilder)
	{
		QBENCHMARK
		{
			// Concaténation en utilisant QStringBuilder
			// Dans ce cas la concaténation devrait être plus rapide
			result = a % b % c % d % e % f % g % h % i % j % k % l % m % n % o % p % q % r % s % t % u % v % w % x % y % z;
		}
	}
	else
	{
		QBENCHMARK
		{
			// Concaténation en n'utilisant pas QStringBuilder. On utilise alors la concaténation normal de chaînes de caractères en utilisant
			// QString
			result = a + b + c + d + e + f + g + h + i + j + k + l + m + n + o + p + q + r + s + t + u + v + w + x + y + z;
		}
	}
}
 
void TestPerf::concat_data()
{
	QTest::addColumn<bool>("useStringBuilder");
	QTest::newRow("Don't use QStringBuilder") << false;
	QTest::newRow("Use QStringBuilder") << true;
}
 
QTEST_APPLESS_MAIN(TestPerf);
 
#include "tst_testperf.moc"

Résultat du test

Le test a été fait en utilisant la version 4.6.3 de Qt. Le résultat est sensiblement le même avec la version 4.7.0

Sans QStringBuilder	0.00367 msec
Avec QStringBuilder	0.00046 msec

On voit dans ce test que la version en utilisant QStringBuilder est 8 fois plus rapide que sans. Bien sûr vu le temps que prend la concaténation de chaînes de caractères, ce test commence à avoir de l'intérêt uniquement à partir du moment où on fait beaucoup de concaténation dans la seconde, ou si les temps de réponses sont critiques.

Sur ce, je vous souhaite à tous un Joyeux noël et une bonne année.

Calcul de la distance entre deux fichiers

Ulrich Van Den Hekke — Sun, 06 Jun 2010 11:40:00 +0200

Présentation

Suite à un billet sur LinuxFR, où je demandais comment calculer la distance (ou le pourcentage de similitude entre deux logiciels), j'ai obtenu la formule suivante :

distance = 1 - ( C(A) + C(B) - C(AB) ) / Max(C(A), C(B))

où C(X) est la taille du fichier X compressé^[1].

Après avoir testé les formats gzip, bzip2 et lzma, j'ai conclu que le format de compression le plus performant pour le calcul, est le format lzma, car le dictionnaire avec la mise en commun était le plus gros, et donc le calcul de distance est plus efficace.

Notes

[1] On peut retrouver l'explication de cette formule ici

Le programme

J'ai donc décidé d'écrire un programme parcourant un dossier (avec plusieurs milliers de fichiers) et de calculer pour toutes les combinaisons des fichiers la distance entre chaque fichier. Ce programme consommant énormément de mémoire, il se peut que pour un grand nombre de fichier, le programme se plante avec une erreur d'allocation de mémoire.

Ce programme permet de pouvoir faire une cartographie de ces fichiers et ainsi de pouvoir les classer. Testé sur des fichiers textes (sources de logiciels), le programme est assez efficace.

Testé sur des images, ou des vidéos, les fichiers sont considérés comme tous éloignés les uns des autres, même s'ils sont identiques à compression différente près, ou s'ils sont identiques à un mouvement près sur la photo (du genre une photo où une même personne se tient dans une position différente).

Si vous avez une idée sur comment calculer la distance entre deux fichiers déjà compressés (avec perte qui plus est), ca m'intéresse.

Comme l'exécution est très lente (compression lzma niveau 9), le programme peut être arrêté et redémarré.

Pour démarrer le programme, il faut exécuter la commande :

./calcul_distance /mon/dossier

Le programme va alors créer un fichier {5ac1fd3c-504f-4110-9f7e-d6fc89e57bdb}.db où {5ac1fd3c-504f-4110-9f7e-d6fc89e57bdb} est différent à chaque nouveau lancement.

Pour reprendre le traitement où il était, il suffit alors de lancer :

./calcul_distance --uuid {5ac1fd3c-504f-4110-9f7e-d6fc89e57bdb}

Si on veut ajouter un dossier au traitement après coup :

./calcul_distance /nouveau/dossier --uuid {5ac1fd3c-504f-4110-9f7e-d6fc89e57bdb}

Exemple

Par exemple soit les différentes versions d'un logiciel, mis dans des archives tar. Pour ne prendre que le code source des versions, on va supprimer tous les fichiers suivants de l'archive tar : *.jpg, *.png, *.ico, *.qm, *.db, ... les sources externes à l'application. On ne garde donc que les fichiers textes dont nous avons la possession.

Après le nettoyage des dossiers :

$ for i in `ls` ; do
> tar -c $i/* > $i.tar
> done
$ ls -l
-rw-r--r-- 1 phoenix phoenix 2,5M  6 juin  13:24 v0.6.10.tar
-rw-r--r-- 1 phoenix phoenix 440K  6 juin  13:24 v0.6.4.tar
-rw-r--r-- 1 phoenix phoenix 530K  6 juin  13:24 v0.6.5.tar
-rw-r--r-- 1 phoenix phoenix 610K  6 juin  13:24 v0.6.6.tar
-rw-r--r-- 1 phoenix phoenix 690K  6 juin  13:24 v0.6.7.tar
-rw-r--r-- 1 phoenix phoenix 1,2M  6 juin  13:24 v0.6.8.tar
-rw-r--r-- 1 phoenix phoenix 1,3M  6 juin  13:24 v0.6.9.tar
-rw-r--r-- 1 phoenix phoenix 2,9M  6 juin  13:24 v0.7.0.tar
-rw-r--r-- 1 phoenix phoenix 2,2M  6 juin  13:24 v0.7.1.tar
-rw-r--r-- 1 phoenix phoenix 3,3M  6 juin  13:24 v0.7.2.tar
-rw-r--r-- 1 phoenix phoenix 3,3M  6 juin  13:24 v0.8.0.tar
-rw-r--r-- 1 phoenix phoenix 3,1M  6 juin  13:24 v0.8.1_services.tar
-rw-r--r-- 1 phoenix phoenix 3,1M  6 juin  13:24 v0.8.1.tar
-rw-r--r-- 1 phoenix phoenix 3,8M  6 juin  13:24 v0.9.0.tar
$ cd ..
$ calcul_distance ./xinx/
Step 0 : Create database
Step 1 : Create file list
Step 2 : Compress single file                                     
Step 3 : Compress pair file                                       
$ ls 
{051b93a0-d9a9-4778-ac73-81ee01a3905d}.db
xinx
$ sqlite3 {051b93a0-d9a9-4778-ac73-81ee01a3905d}.db

Nous allons maintenant faire une requête dans la base de données sqlite :

$ .TABLES
distances  files 
$ SELECT files1.path, files2.path, distances.distance FROM distances, files files1, files files2 WHERE distances.id1=files1.id AND distances.id2=files2.id ORDER BY distance ASC;

Version 1	Version 2	Distance
v0.8.1	v0.8.1_services	0.0350740694634633
v0.6.8	v0.6.9	0.132275346477201
v0.8.0	v0.8.1	0.142321125298336
v0.8.0	v0.8.1_services	0.161719318637048
v0.6.5	v0.6.6	0.196933113059686
v0.6.4	v0.6.5	0.231812199675573
v0.6.6	v0.6.7	0.266593999923953
v0.6.10	v0.7.0	0.27412838729727
v0.7.2	v0.8.0	0.312111739912996
v0.6.5	v0.6.7	0.351347925829225
v0.6.4	v0.6.6	0.364115163581424
v0.7.2	v0.8.1	0.386971922637303
v0.7.2	v0.8.1_services	0.401055941017259
v0.7.1	v0.7.2	0.436705836223058
v0.7.0	v0.7.1	0.465121645779551
v0.6.4	v0.6.7	0.468472350726879
v0.8.1_services	v0.9.0	0.516795574578859
v0.8.1	v0.9.0	0.51733623689019
v0.8.0	v0.9.0	0.544376861655528
v0.6.7	v0.6.8	0.558824765667689
v0.7.1	v0.8.0	0.560609480175814
v0.6.10	v0.6.9	0.594036969567445
v0.7.1	v0.8.1	0.604226316444666
v0.7.1	v0.8.1_services	0.613613062086946
v0.6.7	v0.6.9	0.622950487834501
v0.7.0	v0.7.2	0.631060763867616
v0.6.10	v0.7.1	0.632444883185258
v0.6.10	v0.6.8	0.637234847328374
v0.6.6	v0.6.8	0.6494052372746
v0.6.9	v0.7.1	0.666200571812458
v0.7.2	v0.9.0	0.678423568871868
v0.6.5	v0.6.8	0.692250570944195
v0.6.8	v0.7.1	0.701063946130892
v0.6.6	v0.6.9	0.701698986545754
v0.6.9	v0.7.0	0.717262408423359
v0.7.0	v0.8.0	0.720311680104721
v0.6.5	v0.6.9	0.738013305804084
v0.6.4	v0.6.8	0.747495551539097
v0.6.10	v0.7.2	0.747929200720491
v0.6.8	v0.7.0	0.748031544518325
v0.7.0	v0.8.1	0.758510349354368
v0.7.0	v0.8.1_services	0.767204482779187
v0.6.4	v0.6.9	0.772451857549627
v0.6.10	v0.8.0	0.796649043913944
v0.7.1	v0.9.0	0.801221496333008
v0.6.9	v0.7.2	0.804765901655414
v0.6.8	v0.7.2	0.819917045496318
v0.6.10	v0.8.1	0.823540395867048
v0.6.10	v0.8.1_services	0.831055117394626
v0.6.10	v0.6.7	0.838850951377793
v0.6.9	v0.8.0	0.849001032539087
v0.6.7	v0.7.1	0.853848016623182
v0.7.0	v0.9.0	0.860291356912217
v0.6.8	v0.8.0	0.86075956509228
v0.6.10	v0.6.6	0.863340151908353
v0.6.9	v0.8.1	0.872265541006983
v0.6.6	v0.7.1	0.873275579233521
v0.6.10	v0.6.5	0.875332023895544
v0.6.9	v0.8.1_services	0.87987037883801
v0.6.7	v0.7.0	0.879941907871053
v0.6.8	v0.8.1	0.881174812987336
v0.6.5	v0.7.1	0.886172606121206
v0.6.8	v0.8.1_services	0.889515283880001
v0.6.10	v0.6.4	0.892364892140999
v0.6.6	v0.7.0	0.894375709613201
v0.6.10	v0.9.0	0.895694726039398
v0.6.7	v0.7.2	0.898582911617307
v0.6.4	v0.7.1	0.902038058337369
v0.6.5	v0.7.0	0.904821831317442
v0.6.6	v0.7.2	0.910637046476578
v0.6.4	v0.7.0	0.918347943544789
v0.6.5	v0.7.2	0.919716704855963
v0.6.9	v0.9.0	0.921714099772221
v0.6.7	v0.8.0	0.924717744438112
v0.6.8	v0.9.0	0.925849165227404
v0.6.4	v0.7.2	0.928888262611658
v0.6.7	v0.8.1	0.933685479216414
v0.6.6	v0.8.0	0.933940067594635
v0.6.7	v0.8.1_services	0.939898268404416
v0.6.5	v0.8.0	0.940789807767177
v0.6.6	v0.8.1	0.94210246370087
v0.6.6	v0.8.1_services	0.946464528845253
v0.6.4	v0.8.0	0.948830071149278
v0.6.5	v0.8.1	0.94922082772201
v0.6.5	v0.8.1_services	0.951278461132112
v0.6.4	v0.8.1	0.955572468114482
v0.6.4	v0.8.1_services	0.95567206186826
v0.6.7	v0.9.0	0.96084453455483
v0.6.6	v0.9.0	0.964619158469125
v0.6.5	v0.9.0	0.965955795849916
v0.6.4	v0.9.0	0.968866861905835

On peut ainsi voir d'après ce tableau, les versions ayant peu de différences et celles qui ont fait des plus gros bonds en avant.

On voit ainsi qu'il y a plus de différences entre la version 0.8.0 et la 0.9.0, qu'il y en a eu entre la version 0.6.8 et la 0.6.9. On peut également voir que les versions 0.6.4 et 0.9.0 n'ont plus rien à voir entre elles.

Vous pouvez télécharger le logiciel attaché à ce billet.

Présentation de XINX

Ulrich Van Den Hekke — Sun, 02 May 2010 21:55:00 +0200

Ce billet fait suite à la sortie de la version 0.9.0 de XINX et va vous décrire ce logiciel. XINX est éditeur de feuille de style XSL (il fait également éditeur JavaScript et CSS mais actuellement moins bien que ce que peuvent faire d'autres).

Il permet l'édition des feuilles de styles en proposant de compléter sur le nom des balises (normal), sur les attributs (normal), sur les valeurs d'attributs : les variables, les paramètres, ... Il propose également automatiquement les différents paramètres lors de l'utilisation d'un call:template.

L'éditeur est fortement tourné vers l'édition de feuille de style XSL pour génération d'HTML mais peut être utilisé pour générer du XML.

Historique

Depuis un certain temps déjà (5 ans), je travaille pour la société Generix Group éditant et intégrant un ERP^[1] du nom de GCE.

Sur la partie Web de cet ERP, il est possible d'intervenir à plusieurs endroits pour modifier son fonctionnement :

Le paramétrage (BDD) : Modification d'un paramètre pour agir sur le comportement du logiciel
La couche métier (JAVA) : Lit le paramétrage (BDD) et réalise les traitements. Il est possible de développer de nouveaux objets, mais aussi de dériver ceux existants.
La couche de présentation (XSL) : A l'aide d'un flux de présentation généré par la couche métier et d'un fichier de configuration, présente les données à l'écran.

La dernière couche est donc l'interprétation d'un flux de donnée, générée à partir de la couche métier (JAVA), à l'aide de feuille de style XSL.

XINX sert à modifier la couche de présentation (XSL). Sur cette dernière couche, on crée et modifie des feuilles de styles pour modifier la présentation des données à l'écran (Déplacer des champs, supprimer des champs, ajouter des champs, règle de gestion simple ...).

En mode projet, chez les clients, les modifications ne sont pas faites directement sur les feuilles de styles standard livrées, mais sur des feuilles de styles dérivées, afin de faciliter les migrations, et la correction des anomalies.

Lors de la modification de feuille de style standard, il faut alors renommer et placer ce fichier dans un dossier séparé. C'est de cette tâche récurrente qu'est venue la création de l'éditeur de feuille de style XINX.

Le but était alors, lors de la sauvegarde d'un fichier standard, de proposer automatiquement la sauvegarde dans le bon dossier.

L'autre point à l'origine de la création de XINX est la non-existence d'un logiciel de développement de feuille de style XSL gratuit et/ou libre (Il y a bien XML Spy qui correspondait à peu prés mais qui était payant, et dont nous n'avions pas la licence).

Sont alors venu s'ajouter d'autres fonctionnalités : la complétion sur les balises, les attributs, les variables, ....

Qu'est que XINX aujourd'hui ?

XINX prévu initialement comme aide au développement des consultants qui font des développements de feuille de style, est maintenant un éditeur de feuille de style XSL avec gestion des plugins. L'un des plugins contient des petites fonctionnalités utiles au quotidien par les consultants travaillants sur l'ERP, fonctionnalité auparavant implémenté directement dans le logiciel.

Dit autrement, cette nouvelle version marque donc une étape : La partie de XINX propre à Generix Group à été séparée dans un plugin. XINX en lui même n'est alors plus qu'un éditeur de feuille de style, extensible via des plugins, mais il retrouve les mêmes fonctionnalités grâce à ce plugin.

Licence

XINX est un logiciel libre dont la licence choisie est la GPLv3. Ce qui signifie que vous pouvez :

télécharger le logiciel
utiliser le logiciel pour faire ce que vous voulez
télécharger les sources du logiciels
modifier les sources du logiciels
utiliser le logiciel modifié par vos soins
distribuer le logiciel ou la version modifiée (attention à différencier les parties originales du logiciel avec le bon copyright, et les parties modifiées).

En tant que logiciel libre XINX possède une plateforme de contribution (ticket, wiki, source, ...) qui se trouve à l'adresse http://xinx.shadoware.org. Vous pouvez donc y aller pour contribuer.

Vous pouvez contribuer de plusieurs façons :

Développement d'un Plugin
Développement d'un script ECMAScript
Développement d'un petit patch
Développement d'un gros patch

Technologie

XINX est un logiciel développé en Qt. Il compile et tourne sous Gnu/Debian (normalement n'importe quelle distribution devrait faire l'affaire, mais Gnu/Debian est la seule distribution testée), et sous MS/Windows. Il devrait normalement également tourner sous MacOS (si les dépendances comme les librairies libxml2 et libxslt sont compilables sous cet OS).

A chaque version un paquet Gnu/Debian est mis à disposition sur le dépôt (apt.shadoware.org) et un binaire MS/Windows est proposé en téléchargement. XINX est toujours compilable à partir des sources pour les autres distributions ou juste parce que vous préférez ainsi. :D

Intégration continue & Tests

A chaque validation sur le référenciel SubVersion, l'application est compilée et testée (vous pouvez voir le résultat des tests à l'adresse suivante. A la sortie de la version 0.9.0, les tests couvrent 27% de la librairie principale. Je dois donc encore écrire d'autres jeux de tests.

Code réutilisable pour d'autres projets

XINX peut également être intéressant pour d'autres développeurs Qt.

En effet, vous pouvez trouver dans la dernière version, ainsi que dans les versions précédentes plusieurs classes utilitaires. Par exemple (liste presque non exhaustive) :

TreeProxyItemModel : convertit un modèle format table en modèle format arbre. Utile lorsque l'arbre est représenté dans une base de donnée relationnelle par exemple.
RecursiveSortFilterProxyModel : Utilisé pour rechercher facilement des données dans un arbre et permet d'afficher les enfants.
XinxLineEdit : Inspiré de KDE, affiche un bouton pour effacer le texte dans la ligne d'édition
XinxListWidgetImpl : Permet de modifier une liste de valeur (ajout, suppression, valeur par défaut, classement, ...)
PluginSelector : Inspiré de KDE, permet d'afficher une liste des plugins, avec un bouton A propos de ... et un bouton Configurer ....
QMenuView : Inspiré d'un exemple de Qt et permet d'afficher un menu à partir d'un modèle.

Fonctionnalités

Recherche parmi les fichiers d'un dossier

Un dock sur le coté permet en mode projet de rechercher et d'ouvrir un fichier parmi une multitude de fichier d'un projet (utile pour les fichiers avec beaucoup de feuille de style).

La recherche peut se faire avec des Jockers (*)

La complétion XSL

XINX permet de compléter sur les feuilles de styles à plusieurs niveaux^[2] :

la balise (fonctionnalité standard vous allez me dire) : XINX permet de compléter sur les balises xsl:, les balises html ...
les attributs (encore standard). Pour chaque balise, XINX est capable de compléter sur les attributs de la balise saisie.
les valeurs d'attribut (là c'est intéressant). Permet de compléter sur les variables déclarées dans le fichier XSL, ainsi que dans les fichiers importés (pour retrouver les fichiers importés, XINX, utilise le mode projet et les paramètres qui y sont définits). De plus sur les attributs non XSL, XINX ajoute automatiquement les accolades { } et les $ pour les variables et les paramètres.

De plus lors de l'utilisation de la balise call:template, XINX va chercher automatiquement les paramètres (xsl:param) du template donné, et les ajoute automatiquement en xsl:with-param. Pour les balises xsl:apply-templates XINX propose la liste des modes des templates existants.

Le parsing de la feuille de style

Fonctionnalité du moment, si vous indiquez un flux de données et une feuille de style, XINX est capable d'afficher le résultat (la source HTML et le résultat dans un navigateur Webkit)

Si l'emplacement où doivent s'exécuter les pages est définit alors, les feuilles de styles, les images, ... pourront être affichées.

A venir

Bien que l'avenir du logiciel dépend de ces utilisateurs, voici les nouvelles fonctionnalités que devrait apporter la prochaine version :

Déverminage de feuille de style XSL
Amélioration du parseur JavaScript et CSS
Quelques réécritures (Vue projet, ...)

Le plugin GCE

Comme indiqué ci-dessous, il existe un plugin GCE utilisé par les consultants travaillants sur l'ERP GCE.

Ce plugin permet de dupliquer une feuille de style d'un dossier à un autre (sans modification des fichiers standards), de lire les dictionnaires de libellé de l'ERP GCE, la lecture du fichier de configuration du lecteur GCE.

Téléchargement

Vous pouvez télécharger XINX à l'adresse http://xinx.shadoware.org/downloads (source et version Windows).

Si vous voulez installer XINX sur une Gnu/Debian (32 ou 64 bits) vous pouvez inclure le dépôt suivant :

# Shadoware.Org
deb http://apt.shadoware.org/ squeeze main

Et installé de la façon suivante :

aptitude install xinx

Vous pouvez vous tenir au courant des sorties de version grâce à la mailing list

Notes

[1] Un ERP et un logiciel de gestion d'entreprise. Un ERP permet de gérer, par exemple, les produits, les clients, les fournisseurs, les stocks, les ventes, les achats, la logistique, la comptabilité, .... Je ne vais pas vous faire une présentation des ERPs, car même si cela pourrait faire un billet intéressant, ce n'est pas le but ici.

[2] Merci à QCodeEdit qui me fournit quelques fonctionnalités utiles.

[Qt] Transformation d'une vue tableau en une vue hiérarchique

Ulrich Van Den Hekke — Mon, 21 Sep 2009 13:50:00 +0200

Pour visualiser des données internes à l'écran, Nokia/Qt nous propose l'architecture MVC à l'aide des classes QAbstractItemModel et de ses sous classes (QAbstractListModel, QAbstractTableModel, ...). Le but de l'architecture MVC est de séparer la représentation mémoire des données, de l'affichage qu'elles auront.

Si les données sont par exemple issue d'une requête SQL, le modèle QSqlQueryModel permet de représenter la sélection SQL, à l'écran dans un composant QTableView. Ces données sont alors représentées sous forme d'un tableau deux dimensions.

Si l'on veut représenter les dossiers de l'ordinateur, le modèle QDirView permet d'afficher les données de façon hiérarchique.

Il est également possible d'écrire nos propres modèles pour représenter nos propres données.

Le but de cet article est de présenter l'écriture d'un modèle, transformant une vue plane (tableau deux dimensions) en vue hiérarchique. Pour cela nous allons prendre l'exemple de l'affichage d'une liste de catégorie^[1].

Notes

[1] La construction de notre objet s'est basé sur l'analyse de l'objet QSortFilterProxyModel de Nokia.

Présentation de l'exemple

Nous allons voir ci-dessous comment transformer une vue plane en une vue hiérarchique. Pour cela nous allons prendre l'exemple d'une liste de catégorie. Ces catégories seront stockées dans une base de données Sqlite. Ceci n'a pas d'importance mais permet d'expliquer pourquoi les données en mémoire ne sont pas déjà sous forme hiérarchique.

La description d'une catégorie passe donc par :

un identifiant unique appelé id
un nom de catégorie
un lien vers la catégorie parente appelé parent_id

C'est le champ parent_id qui permettra de déterminer dans quelle catégorie notre sous-catégorie se trouve. Dans notre cas, test3 a comme parent_id l'identifiant 11 qui est la catégorie test.

Dans notre exemple, nous allons nous conditionner à un modèle en lecture seul. Il est également possible de faire un modèle en lecture/écriture mais nous n'en parlerons pas dans cet article. Nous nous cantonnerons donc à un modèle lecture seul sur un modèle source de type QSqlTableView. (Un modèle en lecture/écriture peut nécessiter de mettre à jour notre structure, ce qui peut être assez compliqué, par exemple en cas de changement de la catégorie parente).

Déclaration d'un modèle

Qu'est qu'un proxy ?

Notre interface se basera sur la classe QAbstractProxyModel. Le but de cette classe est de permettre de faire une transposition entre un premier modèle et une vue. Elle peut par exemple (à l'aide de QSortFilterProxyModel) permettre de filtrer ou trier les données d'une vue.

Cette vue nous permettra de faire la transposition entre un modèle tableau et une vue arborescente.

Interface du proxy

Les méthodes à ré-implémenter pour faire fonctionner une proxy, sont les suivantes :

virtual QModelIndex index( int row, int column, const QModelIndex & parent ) const;
virtual QModelIndex parent( const QModelIndex & index ) const;
 
virtual int rowCount( const QModelIndex & parent = QModelIndex() ) const;
virtual int columnCount( const QModelIndex & parent = QModelIndex() ) const;
 
virtual QModelIndex mapFromSource ( const QModelIndex & sourceIndex ) const;
virtual QModelIndex mapToSource ( const QModelIndex & proxyIndex ) const;

Les quatre premières méthodes appartiennent à l'objet QAbstractItemModel et seront questionnées par la vue (liste, arbre, …) pour connaître la représentation à l'écran.

Les méthodes mapFromSource(), et mapToSource() sont à implémenter pour l'objet QAbstractProxyModel. Elles permettent de faire la liaison entre les indexes (QModelIndex) du modèle d'origine et les indexes du nouveau modèle.

Les méthodes data(), headerData(), flags() sont réimplémentées par l'objet QAbstractProxyModel et utilisent les méthodes mapFromSource() et mapToSource() pour, lors de l'appel d'une de ces méthodes, récupérer les informations stockées sur le modèle d'origine.

Des méthodes sourceModel() et setSourceModel() permettent de spécifier le modèle d'origine.

Implémentation de notre modèle

Structure interne

Nous allons, dans cette partie, parler de la structure interne utilisée par notre objet.

struct Mapping {
	int id, parrentId;
	int index, parentIndex;
	QVector<int> source_rows;
};
typedef QMap<int,Mapping*> IndexMap;
 
IndexMap m_sourcesIndexMapping;
QHash<int,int> m_categoryIdMapping;

Nous allons créer une structure Mapping qui associera pour une ligne dans le modèle source, les informations concernant :

l'identifiant de la ligne.
l'identifiant de la ligne parente.
l'index dans le modèle source.
l'index du parent dans le modèle source.
la liste des indexes dans le modèle source des enfants dans notre modèle.

Une table de hashage permettra de retrouver à partir d'un identifiant (id), la ligne dans le modèle source correspondante. On ne gardera que la seconde colonne (le nom de la catégorie), on ne fera donc l'association qu'entre le nom de la colonne de notre modèle et le modèle source en dure dans le programme.

createMapping()

Le but de cette méthode est de générer l'arborescence qui sera ensuite utilisée dans la suite des méthodes. Cette arborescence étant générée une fois pour toute (ou à chaque fois que le modèle source sera réinitialisé), il faudra parcourir l'ensemble des lignes du modèle source pour construire notre arbre. Parcourir l'ensemble des lignes du modèle source peut prendre du temps si ce dernier contient beaucoup de ligne.

Nous allons considérer dans la suite, que l'identifiant de ligne 1 (id) correspond à la catégorie de plus haut niveau (ci-dessus du nom de Categories). Nous allons créer une catégorie fictive 0 qui correspondra à la racine de notre modèle. Cette catégorie sera donc la catégorie parente de celle à l'identifiant 1. Dans notre modèle source, la catégorie 0 n'a pas d'équivalence parmi les lignes du modèle source. Nous allons donc lui associer la ligne -1 dans le modèle source.

Maintenant voyons la génération de la structure interne.

qDeleteAll( m_sourcesIndexMapping );
m_sourcesIndexMapping.clear();
m_categoryIdMapping.clear();

Nous commençons ci-dessous par nettoyer les différentes structures afin de les régénérer. Il faudra à la suite de la création du mapping appeler la méthode reset() afin de prévenir la vue que l'ensemble des indexes du modèle sont obsolètes.

int source_rows = m_sourceModel->rowCount();
for( int i = -1; i < source_rows; ++i ) {
	Mapping * m = new Mapping;
	IndexMap::const_iterator it = IndexMap::const_iterator( m_sourcesIndexMapping.insert( i, m ) );
	m->index = i;
	m->parrentId = 0;
	m->parentIndex = 0;
 
	if( i >= 0 ) {
		QSqlRecord record = m_sourceModel->record( i );
		m_categoryIdMapping[ record.value( list_id ).toInt() ] = i;
		m->id = record.value( list_id ).toInt();
	} else { // Create the root Item
		m->id = 0;
		m_categoryIdMapping[ 0 ] = -1;
	}
}

Nous récupérons le nombre de ligne dans le modèle source et commençons à initialiser notre structure. Le but de cette boucle est surtout d'initialiser dans notre correspondance identifiant/index (m_categoryIdMapping), l'emplacement des identifiants dans notre tableau. Ainsi dans la suite lorsque l'on essaiera d'associer une ligne à son parent, nous pourrons savoir à quel emplacement retrouver notre id dans la structure m_sourcesIndexMapping.

Nous profitons également de cette boucle pour initialiser les différents champs de notre structure comme l'index (qui correspond à la ligne dans le modèle source), et l'id qui correspond à un identifiant unique dans notre liste.

Nous n'oublions pas notre cas particulier que représente notre racine (ligne source -1 inexistante).

for( int i = 0; i < source_rows; ++i ) {
	QSqlRecord record = m_sourceModel->record( i );
 
	int parentCategoryId = record.value( list_parentid ).toInt();
	int parentCategoryIndex = m_categoryIdMapping.value( parentCategoryId, -2 );
	Q_ASSERT( parentCategoryIndex > -2 );
	Mapping * mapping = m_sourcesIndexMapping.value( i );
	mapping->parentIndex = parentCategoryIndex;
	mapping->parrentId   = parentCategoryId;
 
	Mapping * categoryMapping = m_sourcesIndexMapping.value( parentCategoryIndex );
	categoryMapping->source_rows.append( i );
}

Enfin pour chaque enregistrement de notre modèle source, nous récupérons l'identifiant du parent et recherchons dans la structure que nous venons de créer l'index dans le modèle source de la catégorie parente.

Ces valeurs sont alors renseignées dans le modèle. Nos ajoutons également dans la structure de mapping de la catégorie parent, notre ligne dans la liste des enfants.

Notre structure est ainsi complètement initialisé. Un identifiant connaît donc son parent, et la liste de ses enfants. C'est sur cette structure que se basera le reste des méthodes de notre modèle.

mapFromSource()

Le but de cette méthode est de convertir notre index venant du modèle source vers un index de notre modèle à nous.

L'index du modèle source nous donne l'emplacement de la donnée dans le modèle source sous forme (ligne, colonne) alors que l'index de notre modèle doit donner l'emplacement dans notre modèle sous la forme (ligne, colonne, pointeur indiquant le parent).

if( ! sourceIndex.isValid() ) return QModelIndex();
if( sourceIndex.model() != m_sourceModel ) {
	qWarning( "CategoryItemModel: index from wrong model passed to mapFromSource" );
	return QModelIndex();
}

Il faut donc d'abord vérifier que l'index du modèle source est valide. S'il n'est pas valide, alors il ne sera pas valide non plus dans notre modèle à nous.

int row = sourceIndex.row();
IndexMap::const_iterator it = m_sourcesIndexMapping.constFind( row );
Q_ASSERT( it != m_sourcesIndexMapping.constEnd() );

Nous récupérons l'index dans le modèle source, et à l'aide de notre tableau d'index source, nous allons retrouver l'objet Mapping correspondant. Cette objet Mapping correspondra à celui de notre index source. Ce dont nous avons besoin pour notre modèle est l'objet Mapping de l'objet parent (En effet, notre index est construit sous la forme : ligne, colonne, pointeur sur la structure Mapping du parent de notre index). Nous récupérons donc l'index de la ligne source dans l'objet parent.

int parentRow = it.value()->parentIndex;
IndexMap::const_iterator parentIt = m_sourcesIndexMapping.constFind( parentRow );
Q_ASSERT( parentIt != m_sourcesIndexMapping.constEnd() );
 
Mapping * m = parentIt.value();

Cela nous permet de récupérer l'objet Mapping de l'index parent.

int proxyRow    = m->source_rows.indexOf( row );
int proxyColumn = sourceColumnToProxy( sourceIndex.column() );
if( proxyColumn == -1 ) return QModelIndex();

La méthode sourceColumnToProxy() permet de transformer une colonne de l'objet source en une colonne de l'objet courant. Cela signifie que la colonne 2 sera convertie en colonne 1, et que les colonnes 1 et 3 ne seront pas converties (et cachées). Dans ce dernier cas, nous retournons QModelIndex().

L'index de la ligne dans notre modèle sera donné par la position dans la liste source_rows dans notre structure de conversion.

return createIndex( proxyRow, proxyColumn, *parentIt );

Nous pouvons alors créer notre index.

mapToSource()

De la manière inverse à la méthode mapFromSource(), cette méthode permet de convertir un index de notre objet en un index du modèle source.

if( ! proxyIndex.isValid() ) return QModelIndex();
if( proxyIndex.model() != this ) {
	qWarning( "CategoryItemModel: index from wrong model passed to mapToSource" );
	return QModelIndex();
}

Si le modèle est invalide dans notre modèle, il l'est aussi dans le modèle source. Il n'y a pas d'équivalent dans le modèle source de l'index racine.

Mapping * m = static_cast<Mapping*>( proxyIndex.internalPointer() );

Nous récupérons la structure dans le pointeur interne de notre index.

int sourceColumn = proxyColumnToSource( proxyIndex.column() );
if( sourceColumn == -1 ) return QModelIndex();

Nous récupérons également les informations sur notre colonne (Soit, conversion de la colonne 0 dans notre modèle, en la colonne 1 dans le modèle source).

int sourceRow = m->source_rows.at( proxyIndex.row() );

Nous recherchons dans notre liste source_rows la ligne dans le modèle source qui correspond à la ligne (relative au père) indiqué par notre index et nous construisons un index de type (ligne, colonne) correspondant au modèle source.

return m_sourceModel->index( sourceRow, sourceColumn );

L'implémentation des méthodes mapFromSource() et mapToSource() permettent de faire fonctionner les implémentations des méthodes data(), headerData(), et flags(). Il n'y aura donc aucun intérêt à ré-implémenter ces méthodes à moins de vouloir traiter les données de ces fonctions. Nous ne les décrirons donc pas ici, mais vous pourrez voir dans le fichier attaché, un exemple d'utilisation.

index()

Le principe de cette méthode est de générer un index pour notre modèle. L'index doit être valide et réutilisable dans les méthodes rowCount(), flags(), columnCount(), data(), mapToSource().

if( ( row < 0 ) || ( column < 0 ) ) return QModelIndex();

Si la ligne ou la colonne est inférieure à 0, l'index n'est pas valide.

IndexMap::const_iterator it = m_sourcesIndexMapping.constFind( -1 );
 
QModelIndex sourceParent = mapToSource( parent );
if( sourceParent.isValid() ) {
	it = m_sourcesIndexMapping.constFind( sourceParent.row() );
}

A partir de l'index parent nous retrouvons l'index qui correspond dans le modèle source (sourceParent'). Si l'on ne trouve pas d'index dans le modèle source, nous considérons être sur l'élément racine de notre arbre. Sinon nous recherchons dans la table de Mapping'' la structure qui correspond.

Q_ASSERT( it != m_sourcesIndexMapping.constEnd() );
if( it.value()->source_rows.count() <= row )
	return QModelIndex();

Nous vérifions le nombre d'élément dans la structure et nous retournons un index non valide si l'index demandé va au delà de la taille du tableau.

return createIndex( row, column, *it );

Finalement nous retournons l'index créé avec le pointeur vers la structure Mapping du père en internalData.

parent()

Cette méthode permet de retourner pour l'index donné du proxy, l'index du parent. Un index invalide n'a pas de parent.

if( ! index.isValid() ) return QModelIndex();
 
Mapping * m = static_cast<Mapping*>( index.internalPointer() );

On récupère la structure de correspondance stockée dans le pointeur interne de l'objet. Cette structure nous donne les informations du parent (en effet dans internalPointer(), on stock la structure Mapping du parent), et donc l'index dans le modèle source.

int sourceRow = m->index;
if( sourceRow == -1 ) return QModelIndex();
 
QModelIndex sourceParent = m_sourceModel->index( sourceRow, proxyColumnToSource( 0 ) );
QModelIndex proxyParent = mapFromSource( sourceParent );

On utilise alors notre méthode mapFromSource() pour retrouver l'index du parent dans le référentiel du proxy.

return proxyParent;

rowCount()

Le but de cette méthode est de retourner le nombre de ligne enfant pour un index. Dans le modèle source les indexes n'ont pas d'enfant. Lorsque l'index vaut QModelIndex(), cela signifie qu'il faut retourner le nombre de ligne pour notre racine.

if( index.column() > 0 ) return 0;

Seul la première colonne a des enfants.

if( ! index.isValid() ) {
	Mapping * rootMapping = m_sourcesIndexMapping.value( -1 );
	return rootMapping->source_rows.count();

Pour l'index racine, on récupère le nombre de ligne à la ligne -1 du modèle source.

} else {
	Mapping * parrentMapping = static_cast<Mapping*>( index.internalPointer() );
	int sourceRowIndex = parrentMapping->source_rows.at( index.row() );
	Mapping * rowMapping = m_sourcesIndexMapping.value( sourceRowIndex );
 
	return rowMapping->source_rows.count();

Sinon on récupère la structure stockée dans le pointeur interne. Cette structure est celle du parent de notre objet. On récupère à l'aide de la méthode row() de l'index l'emplacement de la ligne source. Cette ligne source nous permet de récupérer la structure de correspondance de notre index, et ainsi le nombre de ligne de notre index.

columnCount()

Notre modèle ne possède qu'une seule colonne.

return 1;

proxyColumnToSource()

Si la colonne du proxy vaut 0, alors on retourne la colonne 1, sinon on retourne la colonne -1 : la colonne n'est pas convertible, elle n'existe pas dans notre proxy.

if( proxyColumn == 0 )
	return list_name;
return -1;

sourceColumToProxy()

Si la colonne source est 1, alors nous convertissons celle-ci en la colonne 0. Sinon la colonne n'existe pas dans notre proxy.

if( sourceColumn == list_name )
	return 0;
return -1;

Parseur XML

Ulrich Van Den Hekke — Sun, 31 May 2009 23:13:00 +0200

Bonjours à tous,

L'utilisation des fichiers XML est, à ce jour, un fait dans la plupart des logiciels et est fortement à la mode. Une entreprise qui ne fait pas un peu de XML est souvent has-been. On utilise alors le XML à bon ou mauvais escient.

Avantages / Inconvénients

Pourquoi utiliser les fichiers XML ? Les fichiers XML sont, pour commencer, des fichiers textes, il seront donc toujours lisibles, ce qui garantit une meilleur pérennité de l'information. Les fichiers XML sont structurés hiérarchiquement et suivent une syntaxe stricte. Ainsi le XML est lisible informatiquement par les différents langages de programmation existant, pour organiser vos données, en utilisant différents niveaux. Les fichiers XML peuvent être commenté ce qui peut améliorer la lisibilité pour un humain.

Le gros inconvénient du XML est sa verbosité. Pour chaque noeud dans la hiérarchie, il y a une balise de début, et une balise de fin contenant le nom de la balise. Le fichier est moins compact que s'il avait été écrit en binaire. Cela peut poser des problèmes comme alourdir les communications réseaux (ex: pour les webservices). Le fichier est aussi plus long à lire qu'un fichier binaire et peut contenir des erreurs.

Si le fichier n'a pas besoin d'être hiérarchique, il est possible d'utiliser une structure de fichier INI pour ses données.

Nous nous arrêterons là pour les avantages/inconvénients. L'utilisation ou non d'un fichier XML est ensuite une question (besoin, éthique, ...) à se poser pour ses données et la nécessité de pouvoir les lire autrement que par le programme lui-même.

Performance des parseurs.

Je me suis amusé à effectuer le test de lecture de différents fichiers de donnée au format XML de taille différentes par une variété de parseur XML en construisant si possible un arbre DOM. Le but est donc de créer un objet par noeud/attribut du fichier XML et de reconstituer la hiérarchie.

Les parseurs choisis pour ce test sont :

QtXml : Le module XML de la librairie Qt (de la société Nokia)
LibXml2 : Une librairie C permettant de faire du parsing XML en utilisant DOM ou SAX
LibExpat : Un parseur orienté flux (plus proche de la méthode SAX que du DOM)
SCEW : Un parseur basé sur Expat générant un arbre DOM (donc un peu plus comparable aux autre parseur).
TinyXML : Encore un autre parseur XML
Xerces-C++ : Le parseur XML d’Apache
Oracle XML Parser : Le parseur d’Oracle propriétaire utiliser dans le serveur d’application.

Pour faire cette suite de benchmark^[1], j’ai utilisé la librairie QTestLib de Nokia/Qt. Je vous offre donc en avant première le résultat de ce test :

Temps de lecture d'un fichier XML en ms
	250k	9300k	11300k
Qt DOM	41,42 ms	2184,34 ms	2648,71 ms
LibXML2	16,55 ms	710,09 ms	874,42 ms
Expat (SAX)	5,95 ms	312,02 ms	393,58 ms
Oracle	23,24 ms	928,93 ms	1135,86 ms
Scew	12,05 ms	944,37 ms	1184,46 ms
Tiny XML	28,91 ms	1101,8 ms	1369,8 ms
Xerces (Apache)	25,03 ms	742,22 ms	904,62 ms

La conclusion de ce résultat signifie que le parseur inclu dans Qt (pour la construction d'un arbre DOM) est très lent ;). Mais pour une utilisation dans une interface graphique, sur de petits fichiers, ne devrait pas poser de problème.

Enfin le parseur le plus rapide (pour les gros fichiers) est Libxml2. Le parseur C d'oracle, bien que propriétaire n'a rien d'exceptionnel (si on compte avec les problèmes présenté également ci-dessous). Peut-être que la version Java est elle plus performante.

Vous pouvez retrouver quelques graphiques ci-dessous :

Le source du benchmark

Vous pouvez trouver attaché au billet, le source de l'application ayant servi au bench. Pour la partie utilisation du Parseur Oracle, il a fallut contourner plusieurs petits problèmes. Ceci est la joie des librairies propriétaires bien documentées.

Compilation avec le XDK 9

Lors de la compilation avec le XDK 9, l'application ne dépasse pas le stade du linkage. Les méthodes sont pourtant bien dans les includes. De plus les librairies sont bien précisées pour le linkage.

La définition faite dans le projet est :

XDKPATH = xdk9
XDK_LIB = -lxmlg9 -lxml9 -lxsd9
ORA_LIB = -lcore9 -lnls9 -lunls9 -lcore9 -lnls9 -lcore9
NET_LIB = -lnsl
LIBS += -L$$XDKPATH/lib $$XDK_LIB $$ORA_LIB $$NET_LIB -lpthread
INCLUDEPATH += $$XDKPATH/xdk/include

A la suite de ça, lors de la phase de compilation, on se retrouve avec les messages d'erreurs suivants :

g++ -Wl,-O1 -o xmlparserbenchmark libxml2parser.o expatparser.o xercescppparser.o oracleparser.o qtparser.o scewparser.o tinyparser.o tinyxml.o tinystr.o tinyxmlerror.o tinyxmlparser.o xmlparserbenchmark.o moc_xmlparserbenchmark.o -L/usr/lib -lxml2 -lexpat -lxerces-c -Lxdk9/lib -lxmlg9 -lxml9 -lxsd9 -lcore9 -lnls9 -lunls9 -lcore9 -lnls9 -lcore9 -lnsl -lpthread -Lscew/scew -lscew -lQtTest -lQtXml -lQtGui -lQtCore -lpthread
oracleparser.o: In function `parseWithOracleParser(QString const&)':
oracleparser.cpp:(.text+0x82): undefined reference to `XMLParser::xmlinit(unsigned char*, void (*)(void*, unsigned char const*, unsigned int), void*, xmlsaxcb*, void*, unsigned char*)'
oracleparser.cpp:(.text+0xa8): undefined reference to `XMLParser::xmlparse(unsigned char*, unsigned char*, unsigned int)'
oracleparser.cpp:(.text+0x2b4): undefined reference to `XMLParser::getDocumentElement()'
oracleparser.cpp:(.text+0x2ca): undefined reference to `XMLParser::xmlterm()'

J'ai alors essayé de recompiler les exemples de démonstrations mais là, même problème ...

Compilation avec le XDK 10

Avec cette version du XDK, nous avons le droit à deux problèmes. Le premier est une grosse fuite mémoire (si on écrit le programme tel que décrit dans la démo), et à un problème d'initialisation du parseur.

Le code permettant de parser le fichier XML et de générer l'arbre DOM ressemble à ceci :

CXmlCtx * ctxp = 0;
try {
	ctxp = new CXmlCtx();
} catch( XmlException & e ) {
	unsigned ecode = e.getCode();
	QFAIL( qPrintable( QString("Failed to initialize XML context, error %1").arg( ecode ) ) );
}
 
Factory<CXmlCtx,xmlnode> * fp = 0;
try {
	fp = new Factory<CXmlCtx,xmlnode>( ctxp );
} catch( FactoryException & fe ) {
	unsigned ecode = fe.getCode();
	QFAIL( qPrintable( QString("Failed to create create parser, error %1").arg( ecode ) ) );
}
 
DOMParser<CXmlCtx,xmlnode> * parserp = 0;
try {
	parserp = fp->createDOMParser( DOMParCXml, NULL );
} catch( FactoryException & fe ) {
	delete fp;
	unsigned ecode = fe.getCode();
	QFAIL( qPrintable( QString("Failed to create parser, error %1").arg( ecode ) ) );
}
 
const char * fname = filename;
FileSource * isrcp = new FileSource( (oratext*) fname );
try {
	DocumentRef<xmlnode> * docrefp = parserp->parse( isrcp, FALSE );
	if( docrefp == NULL ) {
		QFAIL( qPrintable( QString("NULL document") ) );
		return;
	}
	xmlnode * np = docrefp->getDocumentElement();
	if( np == NULL ) {
		QFAIL( qPrintable( QString("Empty document") ) );
		return;
	}
	docrefp->markToDelete();
	delete docrefp;
} catch( ParserException & pe ) {
	delete parserp;
	delete isrcp;
	delete fp;
 
	unsigned ecode = pe.getCode();
	QFAIL( qPrintable( QString( "Failed to parse the document, error %1").arg( ecode ) ) );
}
//	delete parserp;
//	delete isrcp;
//	delete fp;
//	delete ctxp;

Le premier problème se situe lors de la suppression du contexte (dernière ligne, en commentaire). Si cette ligne est exécutée, alors nous avons une grosse erreur de segmentation. J'ai le problème, quels que soient les delete que je fais avant. Même en faisant le maximum de delete (soit parserp, isrcp, fp), le fait de ne pas supprimer le context (ctxp), fait qu'au bout de plusieurs itérations, nous avons une bonne fuite mémoire^[2].

Vient ensuite le second problème, celui des erreurs d'intialisation. Si le parseur est lancé plusieurs fois de suite, alors l'application affiche les erreurs suivantes à l'écran :

LPX-00202: Message 202 not found; No message file for product=XDK, facility=LPX
FAIL!  : XmlParserBenchmark::oracleParser(file250k.xml) Failed to parse the document, error 202
   Loc: [oracleparser.cpp(73)]

Aucune explication sur le pourquoi. Parfois ça marche, parfois non... Pour contourner le problème, j'ai forké le parseur pour l'exécuter isolé du reste.

pid_t pid = fork();
if( pid > 0 ) {
	waitpid( pid, (int*)0, 0 );
} else if( pid == 0 ) {
	if( ! filename.isEmpty() )
		parse( qPrintable( filename ) );
	exit( 0 );
} else {
	QFAIL( "Cannot fork" );
}

Notes

[1] Ces tests ont été réalisé dans un chroot 32-bits allant à 2,4GHz. Les temps sont une moyenne sur 100 itérations

[2] Si quelqu'un a déjà utilisé ce parseur, et qu'il sait comment il fonctionne, il peut m'écrire

KMyMoney - Logiciel de compte

Ulrich Van Den Hekke — Sat, 23 May 2009 12:31:00 +0200

Voilà un bon logiciel sur lequel on peut compter (mouarf ! mouarf ! mouarf !), KMyMoney est un éditeur de compte. Je l'utilise quotidiennement, et je décide donc d'en parler un peu, pour que d'autres personnes puissent s'intéresser aussi à ce logiciel.

KMyMoney est un logiciel de gestion de compte pour particulier. Il vous permet de gérer plusieurs de vos comptes en banque, en vous permettant de saisir les dépenses et les recettes sur chacun de vos comptes.

Vous pouvez également lui indiquer vos échéances (par exemple : forfait téléphone, prêt immobilier^[1], mais aussi salaire, vos virements internes ou externes, ...) qu'il s'occupera de mettre à jour dans le registre automatiquement ou à votre demande.

Après une année d'utilisation, il vous permet également de sortir un rapport détaillé sur vos dépenses et vos recettes suivant les catégories saisies pour vos opérations. Cette information peut vous être très utile pour voir où se trouve le "trou" de votre porte monnaie et ainsi faire une rustine. Il vous permet aussi de vous projeter vers l'avenir et de faire votre budget pour l'année prochaine. KMyMoney vous offre pour cela, la saisie de votre budget, ainsi que plusieurs rapports d'écart, vous permettant ainsi de retrouver facilement où vous avez finalement dépensé plus que le budget prévu, et où vous avez dépensé moins.

En plus de vos comptes en banque normaux, KMyMoney vous permet également de gérer vos comptes titre, et les actions que vous y avez mises. Vous pouvez alors facilement suivre la chute vertigineuse de la bourse et votre portefeuille fondre littéralement, mais aussi la remontée (on espère), des actions d'ici quelques ... siècles.

Enfin pour les paranos, vos comptes peuvent être cryptés à l'aide de votre clé GnuPG automatiquement par KMyMoney

Après cette courte présentation, je vous souhaite bon compte

Pour une vie équilibrée, n'oubliez pas de profiter du soleil, au lieu de passer votre temps sur votre ordinateur

Notes

[1] Il s'occupera d'ailleurs de calculer la durée des échéances, ... en fonction des différents chiffres que vous allez lui entrer.

KDE4 devient instable ...

Ulrich Van Den Hekke — Sat, 11 Apr 2009 11:29:00 +0200

Titre trolleur, cela ne veux pas dire que KDE 4 est moins stable qu'avant mais qu'il a passé une étape supplémentaire chez Debian.

Voilà quelques jours déjà que la distribution Gnu/Debian intègre KDE 4 dans sa version instable. C'est une grande nouvelle car cela va permettre à toute les personnes se trouvant en instable et n'ayant pas touchées à la branche expérimental de Debian de pouvoir tester KDE 4.

Malheureusement pour les traumatisé de KDE 4, l'intégration de ce dernier remplace KDE 3.5 et ne viens pas se positionner en parallèle. Il me semble pourtant que lors du passage de KDE 2 à KDE 3, il était possible d'avoir les deux bureaux en même temps sur sa machine et de switcher de l'un à l'autre sans difficulté. Cela signifie donc peut-être aussi la perte d'utilisateur pour KDE sous Gnu/Debian au profit d'un autre environnement de bureau.

Afin d'effectuer la migration en douceur, Gnu/Debian propose un assistant de migration de KDE du nom de Kaboom. Cet assistant, démarrer lors de la première connexion de l'utilisateur et vous propose alors de sauvegarder votre ancien dossier de configuration KDE 3 et de migrer le dossier .kde vers la version 4.

Je viens donc de passer à KDE 4 et m'émerveille des nouvelles fonctionnalités de KWin (cube, placement des fenêtres) que je n'avais pas avant, car n'avait jamais installé Compiz ...

Bonne installation,

Qt 4.5 est sortie

Ulrich Van Den Hekke — Tue, 03 Mar 2009 16:42:00 +0100

Voilà quelques heures que la dernière version de Qt est sortie. Cette version, numéroté 4.5, est essentiellement orienté performance.

Elle contient entre autre ^[1]

Une mise à jour de QtWebKit vers un version de WebKit plus récente (avec un nouveau moteur JavaScript plus rapide, la possibilité d'ajouter des greffons comme Flash...). Il est également possible d'utiliser les balises d'HTML 5.
Amélioration des performances sur le moteur de rendu ainsi que sur le rendu du texte. Une librairie permettant de faire des tests de performance a été incluse : QtBenchLib.
Le support de Mac OS X Cocoa
La possibilité de faire des transformations XSLT
Un débuggeur QtScript^[2]

Le support du format OpenDocument (ODF version 1.0, ne supportant que le texte et les images)
Amélioration du support des proxys
Amélioration de QtDesigner, QtLinguist
Une meilleur intégration au thème Gtk

Cette nouvelle version apporte également une grande nouveauté puisqu'elle est LGPL. Il est donc désormais possible de faire une application propriétaire à l'aide de cette librairie sans prendre une licence chez Qt Software. Par contre si une entreprise souhaite un support pour la librairie, il faudra tout de même acheter une licence.

La sortie de Qt 4.5 est accompagné de Qt Creator 1.0. Qt Creator est l'outil dernier né de chez Qt Software (branche de Nokia) et est un IDE de développement de programme Qt. Un paquet est proposé contenant Qt, Qt Creator, ainsi que MinGW et permettant d'avoir une installation tout en un d'un poste de développement.

Vous pouvez donc aller télécharger la dernière version de Qt, ainsi que de Qt Creator (attention les serveurs sont surchargés) à cette adresse.

Je remercie toute l'équipe de nouvellement Qt Software de cette nouvelle version.

Notes

[1] pour plus de détail voir http://doc.trolltech.com/4.5/qt4-5-intro.html

[2] L'image du debugger viens du site Qt Software

Outil de sécurisation non intéropérable

Ulrich Van Den Hekke — Fri, 20 Feb 2009 10:00:00 +0100

Alors que l'UMP est accusé de contrefaçon du groupe MGMT^[1], et est donc accusé du terme de piratage selon le mot utilisé à mauvais escient, nous avons des nouvelles sur le logiciel espion du gouvernement^[2].

Ce dernier sera non seulement payant mais également non interopérable. Pour le rapporteur Riester, l'interopérabilité est un frein au choix et n'est pas nécessaire :

Je n’y suis pas favorable, a-t-il expliqué avant de poursuivre il faut laisser au consommateur sa totale liberté de choix en fonction de son système d’exploitation. L’interopérabilité n’est pas nécessaire pour les consommateurs et elle est trop contraignante pour les éditeurs de logiciels

les moyens de sécurisation mis en place ne sauraient être gratuits, à l’image des logiciels de contrôle parental, mis à la disposition des consommateurs à titre payant, même si leur prix est modique

En plus de l'abonnement internet et du modem ADSL de l'opérateur, il faudra également donc s'acheter ce logiciel espion, ainsi que le système d'exploitation Redmondien qui va avec. En effet, aucun éditeur de logiciel ne trouvera un intérêt (monétaire) à développer un tel logiciel espion (qui sera, de surcroit, à source fermé) pour un système d'exploitation libre. Comment donc pourrions-nous nous défendre, nous utilisateurs du logiciel libre, si vis-à-vis de la loi, nous ne pourrons nous justifier d'un téléchargement illégal même s'il n'en est pas le cas.

Alors que l'on parle de vente lié, M. Henrard répond On crée une incitation et chacun se détermine en fonction de ses obligations. Il y a des aléas dont on veut se protéger et si on est un tout petit peu rationnel, il est évident qu’on va demander à son FAI l’utilisation d’un tel dispositif. et donc payer ...

Le président de l'APRIL^[3] s'insurge qu'il reste encore à l'Assemblée nationale des députés qui sont opposés à l'interopérabilité, opposés à la libre concurrence, opposés au libre-choix des utilisateurs, et opposés au logiciel libre

Quand au logiciel en lui-même, personne ne connait son fonctionnement : - Qu'enverra-t-il comme donnée ? - A qui enverra-t-il les données (au FAI ? au gens plein de fric (major) ? au marketing ? au gouvernement ? à tout ces gens ?) - Devras-t-il être sur chaque ordinateur (avec une licence par ordinateur à payer) ? Sur le modem ADSL ? Sur un seul des ordinateurs (et il nous sera alors interdis d'avoir plus d'un ordinateur par foyer) ?

La France apparaitra alors surement bientôt (pour 2009) dans les pays ennemis d'Internet^[4]. Vive la république et vive la France.

Notes

[1] http://www.lexpress.fr/culture/musique/l-ump-a-t-il-pirate-mgmt_742192.html

[2] http://www.pcinpact.com/actu/news/49218-hadopi-interoperabilite-logiciel-libre-payant.htm?vc=1

[3] Benoît Sibaud, président de l'APRIL

[4] http://fr.wikipedia.org/wiki/Internet_et_la_censure#Les_ennemis_d.E2.80.99Internet

Debian Lenny est sortie

Ulrich Van Den Hekke — Sun, 15 Feb 2009 11:41:00 +0000

Bonjours à tous,

Voici la grande nouvelle de ce Week-End : Hier, le jour de la St Valentin, la distribution stable Gnu/Debian est passé de Etch à Lenny^[1].

Cela annonce donc non seulement une nouvelle version stable de Gnu/Debian (ce qui est loin d'arriver tous les jours) mais aussi le déblocage de sid.

Attention lors des prochaines mises à jour, KDE 4 (ainsi que les dernières versions de tous les logiciels) arrivera doucement sur votre bureau^[2] si vous êtes en sid ou en testing. Cela va de même pour les dernières versions du noyau qui devrait arriver également.

La prochaine, future distribution stable (qui apparaîtra sûrement d'ici 5 ans) sera squeeze.

Notes

[1] http://blog.ganneff.de/blog/2009/02/14/lenny-release.html

[2] http://pusling.com/blog/?p=94

Email2Trac

Ulrich Van Den Hekke — Wed, 22 Oct 2008 09:00:00 +0200

Email2Trac est un logiciel permettant de créer un ticket sous Trac en envoyant un mail au système de suivi de ticket.

L'intérêt d'envoyer un mail au système de suivi plutôt que de se connecter sur le site Internet pour faire ses rapports d'anomalie, est de faciliter l'accès à de nouvelles personnes. En effet, il est parfois plus facile d'envoyer un mail avec son client mail préféré (en considérant que le logiciel est quasiment toujours ouvert, ce qui doit être le cas en entreprise) que d'ouvrir le navigateur pour envoyer une anomalie de temps en temps (ouvrir le site, se logger, remplir tous les champs, ...).

Ceci peut également être utilisé par un outil de rapport de bug, envoyant un mail automatique (avec confirmation de l'utilisateur) au crash dudit logiciel.

Comme dit précédemment, EMail2Trac^[1] permet

d'ajouter un ticket en envoyant un mail, avec des fichiers attachés
mettre à jour un ticket (en répondant au mail du ticket par exemple)

Installation

Pour installer Email2Trac, il faut télécharger le source et le décompresser dans un dossier temporaire (ou utilisateur).

Sans gestionnaire de paquet

Ensuite la compilation se fait à l'aide des habituelles autotools

configure --prefix=/usr/local --with-mta_user=nobody --with-trac_user=www-data
make 
make install

Sous Debian

Après avoir installé les paquets cdbs et autotools-dev, vous pouvez exécuter les commandes suivante en root (ou la première à l'aide de fakeroot) :

debian/rules binary
dpkg -i ../email2trac_<version>.deb

Pour le gestionnaire de paquets RPM vous pouvez visiter la page https://subtrac.sara.nl/oss/email2trac/wiki/Email2tracInstallation

Configuration de l'application

La deuxième étape est l'édition du fichier /etc/email2trac.conf. Dans ce fichier les informations à renseigner concerne la gestion du projet Trac^[2] par Email2Trac.

[DEFAULT]
project: /www/site/trac/projet1
spam_level: 5
drop_spam: 1
ticket_update: 1
strip_signature: 1
 
[projet2]
project: /www/site/trac/projet2
spam_level: 5
drop_spam: 1
ticket_update: 1
strip_signature: 1

Les différentes options dépendent de ce que vous souhaitez avoir. Les différentes possibilités sont à l'adresse suivante.

Spam

La gestion du SPAM se fait à l'aide des 3 lignes :

spam_level: 5
drop_spam: 1
spam_header: X-Spam-Level

La ligne spam_header étant à configurer suivant votre politique de gestion des spams (utilisation de SpamAssassin ou d'un autre utilitaire).

Configuration de Postfix

Il faut maintenant configurer notre système de messagerie pour intégrer Email2Trac. Nous allons détailler ici la mise en place de Email2Trac sous Postfix. Pour les autres serveurs mails vous pouvez visiter la page : http://subtrac.sara.nl/oss/email2trac/wiki/Email2tracMta

Aliases

La première méthode concerne la modification du fichier des alias pour une configuration standard de postfix. Nous allons commencer par modifier le fichier /etc/aliases en ajoutant la ligne suivante (pour le projet 1) :

projet1: |"/usr/bin/run_email2trac"

Il est également possible de préciser le projet sur lequel il faut travailler (projet définit dans /etc/email2trac.conf) :

projet2: |"/usr/bin/run_email2trac --project=projet2 --ticket_prefix=devel"

Dans le fichier /etc/postfix/main.cf, il faut avoir défini l'emplacement des alias de la manière suivante :

alias_maps = hash:/etc/aliases

Les commandes suivantes permettent de mettre à jour le fichier des alias et demander à Postfix de recharger la configuration :

postaliases /etc/aliases
postfix reload

Une fois ceci terminé, les mails envoyé à projet1@domain.org et projet2@domaine.org seront automatiquement redirigés vers email2trac qui s'occupera de créer le ticket dans votre système de suivi.

Transport

Cette configuration concerne les personnes qui ont une configuration plus complexe de postfix par exemple en gérant des domaines virtuels. Il est alors possible de définir une redirection des tickets pour un sous domaine.

Nous avons donc créé le sous-domaine tickets.domaine.org et voulons que les mails envoyés à projet1@tickets.domaine.org est projet2@tickets.domaine.org soient redirigés vers email2trac.

Pour cela nous allons créer un fichier /etc/postfix/transport avec les lignes ci-dessous :

projet1@tickets.domaine.org      projet1:
projet2@tickets.domaine.org      projet2:

Puis dans le fichier /etc/postfix/main.cf nous allons définir que pour le sous domaine tickets.domaine.org, il faut lire et utiliser le fichier des transports. (Attention il ne faut pas ajouter ce sous-domaine dans mydestination.

relay_domains = tickets.domaine.org
transport_maps = hash:/etc/postfix/transport

Ensuite, il nous faut définir dans le fichier /etc/postfix/master.cf notre nouveau mode de transport. Il n'est pas obligé d'utiliser run_email2trac qui fait un changement d'utilisateur, car dans le fichier master.cf on peut directement définir l'utilisateur de destination.

projet1      unix  -       n       n       -       -       pipe
  flags=FR user=www-data argv=/usr/bin/email2trac
  ${nexthop} ${user}
projet2      unix  -       n       n       -       -       pipe
  flags=FR user=www-data argv=/usr/bin/email2trac
  ${nexthop} ${user}

Enfin il faut redémarrer postfix :

postmap /etc/postfix/transport
postfix reload

Et voilà vous pouvez envoyer vos mails à projet1@tickets.shadoware.org.

Tester

Pour tester il est possible d'envoyer un mail, comme ceci :

mail projet1@tickets.shadoware.org < ticket.txt

En cas de problème, vous pouvez vérifier que email2trac est bien configuré avec la commande :

email2trac --project=projet1 < ticket.txt

Notes

[1] http://subtrac.sara.nl/oss/email2tr...

[2] http://trac.edgewall.org/

Nouvelles fonctionnalités de Qt Designer 4.5

Ulrich Van Den Hekke — Sun, 19 Oct 2008 19:24:00 +0200

Sur ~~Trolltech~~Nokia Labs Blogs, Friedelann Kleint nous présente aujourd'hui les nouvelles fonctionnalités de Qt Designer 4.5^[1].

Au menu, on peut trouver l'ajout de filtre sur l'éditeur de propriétés ainsi que sur l'inspecteur d'objet (Ce qui peut permettre de sélectionner un composant et d'en modifier les propriétés plus rapidement).

L'arrangement de la boite à outil est également différent :

De plus il est maintenant possible de :

Sélectionner l'objet ancêtre d'un widget en sélectionnant Select ancestors du menu contextuel.
Changer le Layout sans casser et reconstruire le Layout de la feuille
Ajouter facilement une nouvelle ligne au layout (L'action Add form layout row ouvrant la boite de dialogue ci-dessous)
Créer des Assistants (Wizard) linéaires
Désactiver la traduction de certaine chaîne.
...

Enfin, pour terminer, comme le dit Friedemann : The general focus of the 4.5 release is on stability and performance. Soit : Le but principal de la version 4.5 est la stabilité et les performances.

Pour plus de précision, je vous conseille d'aller voir la page d'origine et/ou de télécharger la snapshot.

Notes

[1] Référence : http://labs.trolltech.com/blogs/200...

QT 4.4.2 puis QT 4.4.3 sont sorties

Ulrich Van Den Hekke — Mon, 06 Oct 2008 17:02:00 +0200

En une semaine sont sortie les versions 4.4.2 et 4.4.3 de Qt.

La version 4.4.2 corrige de nombreux bugs (dont des fuites mémoires sur la partie XmlPatterns). Vous pouvez trouver la listes des changements attachée au billet, ou dans l'archive Qt se trouvant sur le site Trolltech.

La version 4.4.3^[1] modifie chaque entête de fichiers, les icônes, ... pour refléter l'achat de Trolltech par Nokia. Par la même occasion le site de Trolltech a été complètement refait (http://trolltech.com).

Donc si vous avez la version 4.4.2, il n'est pas nécessaire de récupérer la 4.4.3 (sauf si vous souhaiter absolument la dernière version au nom de Nokia), par contre si vous êtes encore à la version 4.4.0 ou 4.4.1, il peut être intéressant d'installer la dernière version (suivant les fonctionnalités que vous utilisez).

Enfin, la question, sans réponse, est, est-ce que le site de Trolltech et de Nokia vont fusionner ou vont-il rester séparer^[2] ?

Notes

[1] http://trolltech.com/about/news/qt-4.4.3-released

[2] ce dernier est tout de même plus pratique, je trouve

Paquet Debian et Qt

Ulrich Van Den Hekke — Mon, 08 Sep 2008 20:45:00 +0000

A titre personnel je fabrique quelques programmes en Qt. Comme j'utilise un système Gnu/Debian, j'ai cherché à fabriquer des paquets pour mon système (plus pour le plaisir qu'autre chose, car la plus grande partie de mes utilisateurs sont sous MS/Windows).

Ce billet explique la création de paquet Gnu/Debian pour des applications Qt 4 utilisant QMake

Installation des paquets

Pour la création des paquets pour des programmes utilisant qmake, il faut cdbs, dh_make, dpkg-buildpackage.

aptitude install cdbs dh-make fakeroot devscripts

Création du paquet

Préparation

Vous pouvez donc choisir un de vos programmes que vous voulez empaqueter. Pour cela vous allez commencer par nettoyer l'arborescence de votre projet pour retirer les fichiers de sauvegarde ainsi que les fichiers de construction (*~ *.o, ...). Ce petit nettoyage va permettre d'avoir un paquet source propre.

Il faut que vous placiez les sources dans un dossier du nom de <programme>-<version>.

Voici un exemple de fichier projet :

TARGET = qgenconfig
TEMPLATE = app

CONFIG += exceptions warn_on qt
QT += xml

HEADERS += src/loadconfigimpl.h \
   src/setupfile.h \
   src/configfile.h \
   src/p_configfile.h
SOURCES += src/loadconfigimpl.cpp \
   src/setupfile.cpp \
   src/main.cpp \
   src/configfile.cpp
FORMS = ui/loadconfig.ui

DESTDIR = bin
MOC_DIR = build
OBJECTS_DIR = build
UI_DIR = build

Pour générer le Makefile, vous pouvez faire comme d'habitude :

qmake-qt4 qgenconfig.pro

Création des scripts

Pour créer les paquets, il faut un ensemble de script dans le dossier debian. Pour se faciliter la vie, il est possible de créer les scripts avec dh_make.

DEBFULLNAME="Ulrich Van Den Hekke" dh_make -e ulrich.vdh@shadoware.org -n -s -c gpl

Voici la description de la liste des paramètres :

DEBFULLNAME indique le nom du mainteneur.
-e Permet de préciser l'email (suivis de l'email).
-n Produit un paquet natif pour Gnu/Debian (quand l'auteur fait ses paquets lui-même).
-s Indique que le paquet ne va contenir qu'un simple exécutable (si vous voulez faire plusieurs paquets, il suffit de ne pas mettre cette option).
-c Indique la licence d'utilisation (ici gpl).

Vous pouvez ensuite supprimer les fichiers exemples (mais pas nécessairement si vous voulez les étudier).

rm debian/*.ex  debian/*.EX  debian/docs  debian/dirs

Paquet simple

Nous allons commencer par créer un paquet simple. Cela signifie qu'il n'y aura qu'un seul exécutable dans le paquet (pas de librairie, ...).

Dans le fichier control, il faut que vous renseignez les informations du paquet que vous allez créer.

Source: qgenconfig
Section: devel
Priority: extra
Maintainer: Ulrich Van Den Hekke <ulrich.vdh@shadoware.org>
Build-Depends: debhelper (>= 7)
Standards-Version: 3.7.3
Homepage: http://projects.shadoware.org/qgenconfig

Package: qgenconfig
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Create a config class in Qt after loading a XML file.
 Load an XML description file of a settings object and create a class
 that can be used to load and save information in a QSettings class. To
 load information structure are used.

Dans le paquet ci-dessus, on créait un paquet binaire et un paquet source. Les variables de dépendance (dans Depends) sont remplacées automatiquement à la génération du paquet. La description est celle écrite dans aptitude. La première ligne est la description courte, les suivantes (précédées d'un espace) sont la description longue.

Ensuite on va remplacer le fichier debian/rules en utilisant cdbs :

#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/qmake.mk
QMAKE=qmake-qt4
 
install/qgenconfig::
	mkdir $(DEB_DESTDIR)/usr/
	mkdir $(DEB_DESTDIR)/usr/bin/
	cp $(CURDIR)/bin/qgenconfig $(DEB_DESTDIR)/usr/bin/

En premier lieu on définit les variables pour la compilation, puis ensuite on définit les opérations d'installations dans la cible install/qgenconfig^[1]. Dans les opérations, vous allez copier votre exécutable dans le dossier de génération de debian (dossier debian/<cible>).

Paquet multiple

Créer plusieurs paquets à partir d'une même source avec cdbs est assez simple. Il suffit de rajouter des cibles, correspondantes au fichier control, dans le fichier rules .

Dans le fichier de control on va avoir plusieurs paquets binaires pour un seul paquet source.

Source: xinx
Section: devel
Priority: extra
Maintainer: Ulrich Van Den Hekke <xinx@shadoware.org>
Build-Depends: debhelper (>= 7)
Standards-Version: 3.7.3
Homepage: http://xinx.shadoware.org/

Package: xinx
Section: devel
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, xinx-scripts (>= 0.7.2.0)
Recommends: xinx-plugins-services, xinx-plugins-cvs, xinx-plugins-svn
Suggests: xinx-doc
Description: XSL/JS/HTML editor for Generix
 XINX is an editor of XSL stylesheet, JavaScript, Cascading Style Sheet.
 This editor is used with egx.

Package: xinx-doc
Section: doc
Architecture: all
Depends: xinx (>= 0.7.2.0)
Description: Documentation for xinx
 Technical Documentation of XINX

Nous allons définir dans le fichier rules les différentes cibles que nous avons dans le fichier control^[2].

#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/qmake.mk
QMAKE=qmake-qt4 project.pro
 
install/xinx::
	mkdir $(CURDIR)/debian/xinx/usr/
	mkdir $(CURDIR)/debian/xinx/usr/bin/
	cp $(CURDIR)/xinx/xinx $(CURDIR)/debian/xinx/usr/bin/
	cp $(CURDIR)/xinxprojectwizard/xinxprojectwizard $(CURDIR)/debian/xinx/usr/bin/
 
	mkdir $(CURDIR)/debian/xinx/usr/lib/
	cp -a $(CURDIR)/libxinx/libsharedxinx* $(CURDIR)/debian/xinx/usr/lib/
	cp -a $(CURDIR)/components/libxinxcmp* $(CURDIR)/debian/xinx/usr/lib/
 
install/xinx-doc::
	mkdir $(CURDIR)/debian/xinx-doc/usr/
	mkdir $(CURDIR)/debian/xinx-doc/usr/share/
	mkdir $(CURDIR)/debian/xinx-doc/usr/share/doc/
	mkdir $(CURDIR)/debian/xinx-doc/usr/share/doc/xinx-doc/
	cp -a $(CURDIR)/doc/* $(CURDIR)/debian/xinx-doc/usr/share/doc/xinx-doc/
	rm -rf $(CURDIR)/debian/xinx-doc/usr/share/doc/xinx-doc/html/.svn

Ici on génère deux paquets, le paquet binaire et la documentation.

Génération du paquet

Mise à jour des informations du paquets

Pour modifier le changelog sur la version courante

dch -a

Pour créer une nouvelle version

dch -i

Création du paquet

dpkg-buildpackage -rfakeroot

L'application va signer le paquet s'il trouve la clé assignée à l'utilisateur.

Création d'un dépôt

Après avoir créé des paquets, il peut-être intéressant de créer un dépôt pour installer ces paquets. voici la marche à suivre pour créer le dépôt.

Sur votre serveur internet (nous ne parlerons pas ici de la mise à disposition sur Internet), vous allez devoir créer un dossier contenant votre référentiel (exemple : /www/sites/apt).

Création de l'arborescence

Vous allez devoir créer une arborescence comme suite :

dists
   +- main 
       |- binary-i386
       |- binary-amd64
       +- source

Parmi les fichiers générés vous allez devoir mettre le fichier .deb dans le dossier binaire, et les fichiers .changes, .dsc, et .tar.gz dans le dossier source.

Création d'un fichier apt-ftparchive.conf

Nous allons commencer par créer un fichier apt-ftparchive.conf dans lequel nous allons définir les fichiers à créer.

Dir {
	ArchiveDir ".";
	CacheDir ".";
};

Tree "dists/unstable" {
	Sections "main";
	Architectures "amd64 source";
};

BinDirectory "dists/unstable/main/binary-amd64" {
	Packages "dists/unstable/main/binary-amd64/Packages";
	Contents "dists/unstable/Contents-amd64";
	SrcPackages "dists/unstable/main/source/Sources";
};

Création du fichier apt-unstable-release.conf

APT::FTPArchive::Release::Origin	"shadoware.org";
APT::FTPArchive::Release::Label		"shadoware.org";
APT::FTPArchive::Release::Suite		"unstable";
APT::FTPArchive::Release::Codename	"unstable";
APT::FTPArchive::Release::Architectures	"amd64 source";
APT::FTPArchive::Release::Components	"main";
APT::FTPArchive::Release::Description	"Paquets du site Shadoware.Org";

Création du fichier update-archive.sh

Ce fichier est celui que l'on doit exécuter pour la génération du contenu de l'arborescence :

apt-ftparchive generate apt-ftparchive.conf
apt-ftparchive -c apt-unstable-release.conf release dists/unstable > dists/unstable/Release

Notes

[1] D'autres cibles sont disponibles (cf la doc de cdbs).

[2] A cause d'un bogue, ou d'une mauvaise utilisation, la variable $(DEB_DESTDIR) ne me ramenait pas la bonne valeur, je l'ai donc remplacée par $(CURDIR)/debian.

Mises à jour Gnu/Debian récentes

Ulrich Van Den Hekke — Mon, 18 Feb 2008 18:28:00 +0000

Bonjour,

La distribution GNU/Debian propose une nouvelle mise à jour pour sa version etch. Les points importants que je remarque, sont

la correction de la faille sur le noyau Linux pour toutes les machines serveurs : Veillez à bien mettre à jour votre noyau car même si vous ne proposez pas de compte aux utilisateurs, l'escalade de privilèges peut intervenir dans une faille de sécurité de votre site Internet (cf de l'injection de code).
la mise à jour de KDE, qui désormais permet à Konqueror de charger le plugin flash non libre.

Bien sûr, cette mise à jour propose également d'autres corrections de Bug et mise à jour de sécurité, ainsi que la suppression de certains paquets (soit trop miné/buggé, soit propriétaire). On peut par ailleurs retrouver le plugin flash dans les backports

Mémo Qt

Ulrich Van Den Hekke — Mon, 21 Jan 2008 20:06:00 +0000

Ceci est un petit mémo pour me permettre de ne pas oublier quelques astuces lors de la programmation avec Qt. En parlant de cela, je me suis commandé le livre suivant : C++ GUI Programming with Qt4.

QAbstractItemModel

Lors de l'insertion (avec beginInsertRows()), les éléments insérés ne doivent pas contenir de sous éléments (rowCount() == 0) sous peine de causer des plantages.
Un model de donnée interne, pouvant être utilisé avec QAbstractItemModel pour afficher une arborescence et étant capable de se rafraîchir à la lecture d'un fichier, se trouve dans les fichiers filecontentstructure.cpp et filecontentstructure.h

CMake et Qt

Compilation d'une librairie static

add_definitions(-DQT_SHARED)
add_library(xinxplugins STATIC ${xinxplugins_SRCS} ${xinxplugins_MOC_SRCS})

Compilation d'un plugin

dynamique

add_definitions(${QT_DEFINITIONS})
add_definitions(-DQT_PLUGIN)
add_definitions(-DQT_NO_DEBUG)
add_definitions(-DQT_SHARED)
add_library(webplugin SHARED ${webplugin_SRCS} ${webplugin_MOC_SRCS})

static

Compilation de fichier RC pour Windows

if(WIN32)
       add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/xinx_ico.obj
               COMMAND windres.exe -I${CMAKE_CURRENT_SOURCE_DIR} -o ${CMAKE_CURRENT_BINARY_DIR}/xinx_ico.obj -i${CMAKE_CURRENT_SOURCE_DIR}/${xinx_RCS}
       )
       set(xinx_RESS ${CMAKE_CURRENT_BINARY_DIR}/xinx_ico.obj)
endif(WIN32)

KMDAlert - Logiciel de surveillance de périphériques RAID

Ulrich Van Den Hekke — Fri, 17 Aug 2007 16:12:00 +0000

Présentation

Possédant chez moi des disques durs en RAID logiciel Gnu/Linux, j'ai toujours ressenti le besoin d'avoir une application graphique minimale pour m'avertir des changements d'états du RAID. (Par exemple un disque dur est défectueux, le RAID est dégradé, le RAID est en reconstruction). Et, par exemple, dans le cas de la reconstruction être averti à la fin de la reconstruction.

KMDAlert est un petit logiciel Gnu/Linux que j'ai écrit, et permettant d'afficher des informations sur les volumes RAID (gérés à l'aide du module noyau md-mod) dans la boîte à miniature (SystemTray).

L'icône change suivant l'état du RAID (ATTENTION : Les icônes choisies sont moches, si un graphiste veut me proposer d'autres icônes, je reste ouvert aux propositions) :

dégradé
en cours de synchronisation
ou tout simplement Ok.

Des messages de notifications informent aussi l'utilisateur du changement d'état d'un disque sur le RAID (par exemple le disque est en échec, supprimé, ajouté, la synchronisation démarre ou est terminée).

Le logiciel est actuellement uniquement disponible en pour KDE 3. Je n'ai pas encore pris le temps de le ré-écrire. Bien que cette application a été écrite dans mon cas particulier (un RAID 1) je me suis dit qu'elle devrait fonctionner pour les autres RAIDs et intéresser d'autres personnes.

Requis

Pour fonctionner KMDAlert nécessite que le dossier /sys soit monté et que /sys/block/ soit renseigné pour chaque volume RAID (exemple /sys/block/md0, /sys/block/md1, ...). KMDAlert observe ensuite les modifications faites sur les fichiers pour informer l'utilisateur des modifications faites sur le volume RAID ou sur les disques le composant.

L'application a été développée sur Gnu/Debian Etch donc sur un KDE 3.5 avec un noyau 2.6.18.

KMDAlert ne nécessite pas de Inotify. KMDAlert lit le contenu de plusieurs fichiers dans le dossier /sys toutes les 6 secondes pour être informé de la modification de l'état du périphérique. En effet sur le noyau 2.6.18 que je possède, Inotify n'est pas averti des modifications faites sur le système de fichier /sys. Les dates de ces fichiers ne sont pas non plus modifiées. Si quelqu'un a une autre méthode à me proposer, je reste ouvert à toutes propositions.

KMDAlert est une application écrite en utilisant les librairies de KDE, mais devrait tout de même fonctionner sous Gnome. Les messages de notification utilisent donc le système de notification de KDE (bien que je n'utilise pas toutes ses possibilités).

Compilation / Installation

La compilation et l'installation de KMDAlert se fait à l'aide du trio habituel :

./configure --prefix=/usr/local/
make 
make install

La compilation nécessite les librairies de développement KDE et Qt3, ainsi que le compilateur GCC.

Licence

La licence choisie est la GNU GENERAL PUBLIC LICENSE

Téléchargement

Vous pouvez télécharger une archive déjà construite de l'application sur KDE-Apps.org.
Le dépot officiel pour télécharger les sources et participer : http://hg.shadoware.org/kmdalert.

Système de suivi

Il n'y a actuellement plus de système de suivi pour ce logiciel. En cas de problème, vous pouvez laisser un message dans les commentaires ou m'envoyer un mail.

Shadoware.Org - Mot-clé - planet

KMDAlert - Logiciel de surveillance de périphérique RAID - Version pour KDE 4.0

Présentation

Requis

Compilation / Installation

Licence

Téléchargement

Système de suivi

[C++/Qt] CMake et Qt

Compilation

Package à utiliser

Définir les modules Qt à utiliser :

Quelques déclarations supplémentaires

Macros pour générer les fichiers moc.

Macro par défaut

Une autre macro

Macro pour générer les fichiers en tête d'interface graphique.

Macro pour compiler les fichiers de resources

Macro pour compiler les fichiers de traduction

Compilation d'un plugin

Plugin dynamique

Plugin Static

Ajout d'un fichier RC pour windows

Compilation d'une librairie static

Utiliser le programme CMake

Notes

[C++/Qt] Performance de l'utilisation de QSharedPointer

Présentation

Sommaire

Notes

Utilisation de QSharedPointer

A quoi sert-il ?

Comment l'utiliser ?

Comment utiliser this

Comment éviter les références circulaires

Utilisation dans les applications multi-thread.

Utilisation d'un pool

Benchmark

Code source

Le jeu de test

Test de l'allocation

Test de Modification d'une donnée

Test d'affectation

Test de destruction

Résultat du test

Notes

[C++/Qt] Concaténation de chaînes de caractères

Présentation

Concaténation de chaînes de caractères.

Concaténation rapide de chaînes de caractères

Benchmark

Code source

Résultat du test

Calcul de la distance entre deux fichiers

Présentation

Notes

Le programme

Exemple

Présentation de XINX

Historique

Qu'est que XINX aujourd'hui ?

Licence

Technologie

Intégration continue & Tests

Code réutilisable pour d'autres projets

Fonctionnalités

Recherche parmi les fichiers d'un dossier

La complétion XSL

Le parsing de la feuille de style

A venir

Le plugin GCE

Téléchargement

Notes

[Qt] Transformation d'une vue tableau en une vue hiérarchique

Notes

Présentation de l'exemple

Déclaration d'un modèle

Qu'est qu'un proxy ?

Interface du proxy

Implémentation de notre modèle

Macros pour générer les fichiers `moc`.

Comment utiliser `this`