Shadoware.Org - Tag - trolltech

[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;

XINX 0.8.0.0

Ulrich Van Den Hekke — Fri, 06 Mar 2009 20:39:00 +0100

J'ai le plaisir de vous annoncer la sortie de la nouvelle version de XINX.

XINX est un éditeur de projet web basé sur les technologies XSL, HTML, CSS, JavaScript. Il possède un mode projet permettant de dériver les projets à la manière des consultants GCE de l'entreprise Generix Group.

Cette dernière version a mis beaucoup de temps pour sortir et est moins complète que celle que je souhaitais faire à l'origine. Cela viens de plusieurs raison :

de gros changement interne
moins de temps le soir et le week-end.

La prochaine version 0.8.1 contiendra les développements que je n'ai pu mettre dans cette version. N'hésitez pas à faire un retour sur les problèmes que vous rencontrez pour que ces derniers soit également corriger pour la prochaine version.

Nous allons détailler ci-dessous les différentes amélioration incluse dans cette version.

QCodeEdit - Le nouvel éditeur

L'éditeur de texte de cette version a complètement été remplacé. On est passé de QTextEdit (éditeur de texte de Qt Software) à QCodeEdit (Développé par Luc Bruant aka fullmetalcoder). Heureusement que les APIs de ces deux éditeurs sont très similaire ce qui a permis d'effectuer les changements assez rapidement (quelques mois au lieu de quelques années ).

Je tiens également à remercier fullmetalcoder de sa réactivité sur le développement de QCodeEdit.

Les nouveautés qu'apportent ce nouvel éditeur par rapport à QTextEdit sont :

le folding

les couleurs de fond sur les marque pages et les erreurs (pour une plus grande clarté).
un chargement plus rapide des fichiers (exemple : configuration.xml)
pourvoir faire des sélections verticales (à l'aide de Ctrl+Shift) comme le font certain éditeurs
afficher les correspondances de parenthèses

Test du XPATH

Cette boite de dialogue permet d'exécuter un X-PATH (ou une requête XQuery) sur un fichier de présentation. Cela permet de tester rapidement les X-PATH compliqué avant de lancer la page sous le navigateur.

Il est possible de saisir des X-PATH relativement à un X-PATH sélectionné dans le flux de présentation ou de manière absolu.

Script automatique

XINX permet également d'appeler un script lors de la sauvegarde d'un fichier. Pour cela un nouvel objet permettant de modifier le contenue de l'éditeur plus facilement a été créé. Comme exemple à la sauvegarde de script ont été mis à jours :

La mise à jours des key('url-param','') par des X-PATH
La mise à jours du nom du fichier dans les feuilles de styles.

obj.beforeSave = function() {
	this.run();
}
 
obj.run = function()
{
	var search = new DocumentSearch( textEdit );
 
	search.options.regExp = true;
	search.searchText = "key\\('url-param', '(.*)'\\)";
	search.replaceText = "/layout_data/application_data/temporaire/param[@name='\\1']";
 
	while( search.next() ) {}
};

La nouveauté se trouve dans l'ajout de quatre nouvelle méthodes. La méthode utilisé ici est beforeSave et permet de faire des modifications au texte avant sauvegarde. Tout comme afterSave permet d'effectuer des modifications au texte après sauvegarde. Nous avons également deux méthodes beforeLoad et afterLoad pour les opérations à faire lors de la lecture.

Autres nouveautés

Bien sur cet version apporte aussi d'autres nouveautés comme :

la fermeture automatique de balise
des nouvelles options, ...

Installation

Sous Ms/Windows

Pour installer la dernière version de XINX vous pouvez télécharger le programme d'installation et le lancer. Il remplacera automatiquement l'ancienne version.

Si vous avez des fichiers de données modifiés (template, script, ...) pensez à les sauvegarder.

Sous Gnu/Linux

Sous Debian, vous pouvez ajouter le dépôt dans le fichier /etc/apt/sources.list. Ainsi vous serez automatiquement prévenu des mises à jours éventuelle.

deb http://apt.shadoware.org/ sid main

puis dans une console :

sudo apt-cache search xinx
sudo aptitude install xinx

Pour les autres distributions ou pour les machines MacOS vous pouvez compiler XINX à partir des sources.

XINX - Editeur de feuille de style

Ulrich Van Den Hekke — Wed, 18 Feb 2009 19:00:00 +0100

Bonjours à tous,

Ce billet, parle de XINX, un logiciel libre que j'ai développé et que je continue à développer sur mon temps libre. Le but de se billet est de présenter XINX et d'être le début d'une longue série de billet parlant de son développement.

En effet, même si le programme est propre à une utilisation particulière pour un cercle de personne restreint, les méthodes, classes, et idées utilisées dans ce programme peuvent intéresser d'autres personnes.

Présentation

XINX est un éditeur de feuille de style sur lequel je travail depuis début 2006. En faite j'avais commencé un autre éditeur à l'aide de Borland/Delphi 7 mais il a été rapidement arrêté pour prendre une nouvelle direction dans un nouveau langage avec un nouveau départ^[1].

Cet éditeur de feuille de style à la particularité de pouvoir être utilisé dans le cadre de mon travail : sur l'application eGx (de la société Générix^[2]). XINX permet non seulement l'édition de feuille de style (XSL), en proposant une complétion intuitive, mais propose également un mode projet, dans lequel il est possible de dérivé une feuille de style plutôt que de la remplacer (de façon spécifique à notre méthode de travail en projet chez le client).

XINX est un acronyme récursive^[3] qui signifie XINX Is Not XDME. Ce nom a été choisis car XINX est le complément idéal à XDME (l'éditeur de fichier de configuration d'eGx).

Au niveau du choix du langage, a contrario des autres applications Generix écritent en JAVA, XINX a été programmé en C++. Le framework Qt de la société ~~Trolltech~~Nokia a été choisis pour simplifier la programmation. Pourquoi ce choix de langage :

XINX est une application écrite sur mon temps libre, j'ai donc choisis un langage que je souhaité apprendre. En faite la raison de l'existence de XINX, et la volonté d'apprendre à utiliser ce framework.
Le framework Qt est utilisé par l'environnement de bureau KDE. Cet environnement de bureau est celui que j'utilise tous les jours, pendant mon temps libre (chez moi), sous Gnu/Linux.
La version 4 de ce framework est utilisable sous MS/Windows, sans payer de licence, dans le cadre de l'écriture d'un logiciel libre (au bureau tout nos poste sont sous MS/Windows)^[4].

Architecture

XINX est décomposé en plusieurs parties :

la librairie de composant (contenant un gestionnaire de plugin en Qt, un combobox pour choisir une couleur, une liste de valeur avec les boutons pour ajouter ou supprimer des éléments, une barre d'édition pour faciliter l'édition de dossier)
la librairie principale (externalisant ce qui peut être nécessaire aux plugins).
une série de plugin permettant, dans XINX de
- gérer CVS
- gérer SubVersion
- gérer les extentions XSL, JS, XML, HTML
- gérer les WebServices
l'application elle-même
une application de migration de projet (pour migrer les fichiers projets XINX quand ces derniers changent)
une librairie gérant l'éditeur de code (l'éditeur utilisé pour la prochaine version est QCodeEdit^[5])
les librairies du framework Qt

Vous pouvez une documentation sur l'écriture de plugins sur le site de XINX ainsi qu'une documentation au format Doxygen des librairies.

Notes

[1] Borland/Delphi 7 étant limité à la plateforme de Microsoft, et l'application ayant pris dés le début une mauvaise direction (orienté fichier de configuration plutôt que feuille de style)

[2] Generix est un éditeur de logiciel de gestion d'entreprise, dit ERP

[3] Un acronyme qui contient l'acronyme même, comme Gnu pour Gnu Is not Unix

[4] XINX est un logiciel libre non parce que je n'avais pas le choix dû à la double licence de la librairie Qt mais bien par choix personnelle de développer du logiciel libre sur mon temps personnel.

[5] QCodeEdit est un éditeur de code écrit pour Qt. Il est très performant, et possède beaucoup de fonctionnalité utile.

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.