Forum du club des développeurs et IT Pro - Blogs - epeios https://www.developpez.net/forums/blogs/22748-epeios/ Developpez.com, le Club des Développeurs et IT Pro fr Fri, 29 May 2026 18:02:45 GMT vBulletin 15 https://forum.developpez.be/images/misc/rss.jpg Forum du club des développeurs et IT Pro - Blogs - epeios https://www.developpez.net/forums/blogs/22748-epeios/ <![CDATA['Epeios organizer' : un exemple d'interface desktop et web en C++.]]> https://www.developpez.net/forums/blogs/22748-epeios/b1562/epeios-organizer-exemple-d-interface-desktop-web-cpp/ Tue, 09 Aug 2016 15:29:02 GMT _* Introduction *_(Ce...
Introduction

(Ce billet est issu d'un autre site, et a été reproduit ici sur la suggestion d'un modérateur)

Cette application a pour buts, d'une part, de tester la mise en œuvre de certains concepts de développement (proof of concepts), et, d'autre part, au fur et à mesure de son évolution, de mettre à disposition des fonctionnalités de prise de notes, d'agenda, de gestion d'adresses…

Ces deux buts vont être détaillés dans les deux sections suivantes.

Auparavant, voici quelques liens relatifs à cette application :


Les sources peuvent aussi être consultés directement à l'adresse :


Le lien sur la technologie XDHTML mise en œuvre dans cette application.

But n° 1 : proof of concepts

Hors gestion de l'interface graphique

Pour l'ensemble des binaires sous forme d'utilitaire avec interface en ligne de commande (CLI), ou déployés en tant que daemon, les objectifs suivants sont visés :
  • développement uniquement en C++,
  • portabilité multi-plateformes et multi-architectures,
  • utilisation uniquement des bibliothèques C/C++ standards et systèmes.

Par rapport à ces objectifs, cette application tourne sur GNU/Linux (et potentiellement toute plateforme POSIX), OS X et Windows, sous architecture IA-32, AMD-64 et ARM 32 bits. Pour la compilation, seul un compilateur C++, ainsi que la commande make, sont nécessaires.

Gestion de l'interface graphique

Pour la gestion de l'interface graphique, en plus des objectifs ci-dessus, sont visés les objectifs suivants (technologie XDHTML) :
  • utilisation des technologies web (HTML5, CSS…),
  • un seul et unique code C++ pour les versions web, desktop et mobile,
  • modification de l'apparence de l'application sans avoir à modifier son code source, juste en modifiant des fichiers XSL.

Par rapport à ces objectifs, seules les versions web et desktop ont été développées. Hors version desktop, et notamment pour la version web, les mêmes observations que ci-dessus concernant les plateformes, les architectures et la compilation sont valables. L'adaptation de l'interface aux particularités des plateformes sur lesquelles elle tourne (desktop, web ou mobile), par rapport aux dimensions de l'affichage notamment, se fera au niveau des fichiers XSL.

Le cœur de l'application prend la forme d'une bibliothèque dynamique, qui répond intégralement aux objectifs ci-dessus (notamment pas de dépendances hors bibliothèques C/C++ standards et systèmes). Sa mise en œuvre en tant que version desktop est prise en charge par un utilitaire nommé xdhcefq, et sa mise en œuvre en tant que version web, par un utilitaire nommé xdhbrwq (qui, de ce fait, est assimilable à une CGI).

xdhcefq s'appuie sur Chromium Embedded Framework (CEF), et est donc soumis aux mêmes contraintes en termes de plateformes, architectures et compilation. Néanmoins, on peut envisager de développer l'équivalent de xdhcefq en s'appuyant sur XULRunner ou QtWebKit, par exemple, ou tout autre composant, présent ou à venir, proposant un moteur de rendu web. Le cœur de l'application n'aura pas à être modifié.

Réutilisabilité

Un maximum de code développé dans le cadre de cette application est intégré dans un framework (publié sous licence AGPL), pour qu'il puisse être réutilisé pour d'autres applications. Les utilitaires xdhcefq et xdhbrwq notamment, qui permettent de déployer une application respectivement dans sa version desktop et sa version web, ne sont pas propres à cette application, mais seront utilisables par n’importe quelle application s'appuyant sur la technologie XDHTML.

But n° 2 : les fonctionnalités

A terme, cette application proposera des fonctionnalités de prise de notes, d'agenda, de carnets d'adresse…, avec de notables différences avec l'existant.

Une de ces différences, suite à la mise en œuvre de la technologie XDHTML, porte sur la facilité avec laquelle l'aspect de son interface pourra être modifié par toute personne familière avec les technologies web et XSLT. Une autre de ces différences portera sur l'adaptabilité de l'application. Ainsi, la gestion de l'authentification, des types de champs, et du stockage des données se fait par un système de plugins, ce qui facilitera la mise en œuvre d'alternatives.

L'apparence de l'application est très rustique, d'une part parce que mes connaissances en HTML et CSS sont très limitées, et, d'autre part, parce qu'il est facile pour toute personne ayant des connaissances en HTML, CSS et XSLT de modifier cette apparence à sa guise, conformément à ce qui est annoncé dans la précédente section.

Du fait que l'on se concentre actuellement sur le but n°1 (les proof of concepts) de l'application, ses fonctionnalités sont encore très limitées. Voici celles qui sont actuellement disponibles :
  • prise en charge de plusieurs utilisateurs,
  • gestion d'onglets,
  • réorganisation des onglets par drag & drop,
  • création d'une fiche,
  • modification d'une fiche en cliquant sur son entrée dans la liste,
  • création, dans une fiche, de champs mono ou multi de type :
    • texte simple,
    • texte enrichi (avec mise en forme),
    • date,
    • heure,

  • réorganisation de l'ordre des champs d'une fiche par drag & drop,
  • modification d'un champ d'une fiche en cliquant sur son libellé,
  • modification d'une entrée d'un champ multi en cliquant sur son contenu,
  • réorganisation des entrées d'un champ multi par drag & drop,
  • et, accessoirement, affichage d'un A propos… avec la séquence de touches Ctrl-Shift-A (cela provoque l'ouverture d'une nouvelle page avec certains navigateurs ; il faudra revenir sur la page de l'application).

Une démonstration en ligne de l'application est accessible à : http://q37.info/xdh/orgnzq.html.

Cette démonstration tourne sur un petit serveur placé derrière une box ADSL. De ce fait, l'application peut manquer de réactivité. Cette démonstration devrait tourner sur la plupart des navigateurs web graphique moderne, à la notable exception de Microsoft Edge (sauf s'il s'agit de la dernière version, celle fournie avec Windows 10 version 1607). En outre, à cause de ceci, certaines données ne s'afficheront pas correctement dans Firefox.

Avec la version desktop de l'application, vous pouvez vous connecter directement au backend de la version web de démonstration en sélectionnant Moteur de traitement sur q37.info sur la première page de l'application. Si vous vous connectez avec le même compte sur la version de démonstration en ligne et sur la version desktop, les modifications opérées dans l'une seront naturellement visibles dans l'autre, et vice-versa.

Déploiement

GNU/Linux

Compilation

En supposant que g++ et make soient installés :
  • Télécharger et décompresser les sources de l'application situés à : http://q37.info/download/computing/apps/orgnzq/,
  • télécharger et décompresser la version de CEF de la branche 2704 correspondant à votre architecture (Linux 32bit ou Linux 64bit) située à http://cefbuilds.com/,
  • créer une variable d'environnement nommée CEF pointant sur la racine du package de CEF (export CEF=<path to>/cef_binary_3.2704...),
  • se placer à la racine du package de l’application et lancer la commande make.

Lancement de l'interface desktop

Pour lancer l'interface desktop, se placer dans le répertoire frontend et lancer xdhcefq/xdhcefq -m=XDHTML/orgnzqxdh. A cause d'une particularité de la version Linux de CEF, il faut faire CTRL-C dans la console pour fermer l'application.

Lancement du backend comme daemon

Pour lancer le backend en mode daemon, se placer dans processing, et lancer dmnzq/tool/dmnzq backend/dmnzq.xprj. Vous pouvez alors, dans l'interface desktop, sélectionner Moteur de traitement local pour se connecter à ce backend.

Lancement de l'interface web

Dans le répertoire frontend/xdhbrwq, il y a un répertoire htdocs dont il faut placer le contenu à un endroit qui soit accessible à votre serveur httpd.

Pour lancer la CGI, se placer dans le répertoire frontend et lancer xdhbrwq/xdhbrwq XDHTML/orgnzqxdh. Puis ouvrir un navigateur web et saisir l'adresse correspondant au fichier orgnzq.html du répertoire htdocs mentionné ci-dessus. Remplir les champs, et sélectionner localhost à la place de q37.info.

Windows

Les binaires fournis sont destinés à Windows XP SP3 et supérieurs.

Prendre à l'adresse http://q37.info/download/computing/apps/orgnzq/ et désarchiver le package correspondant aux binaires Windows. Une fois chargé et désarchivé, suivre les instructions données dans le chapitre GNU/Linux (sauf ceux relatifs à la compilation). Selon la version de Windows, les / (slash) devront peut-être être remplacés par des \ (backslash).

Autres systèmes d'exploitation

Pour les systèmes d'exploitation POSIX pour lesquels il n'y a pas de version de CEF, il n'est possible que de lancer le backend et la CGI. Suivre les instructions concernant GNU/Linux, en ignorant tout ce qui concerne CEF. La compilation de l'utilitaire xdhcefq, qui intervient en dernier, échouera naturellement, mais tout le reste devrait être compilé et pouvoir être lancé en suivant les instructions dans la section consacrée à GNU/Linux.

Pour la version OS X, la procédure est détaillée ici.

Les nouveautés

Dans cette version, il y a deux principales nouveautés, détaillées dans les sections suivantes.

Nouveaux types de champs basés sur jQuery

La première nouveauté concerne la mise en œuvre de widgets basés sur jQuery, qui semblent jouir d'une certaine popularité. Ainsi, en plus du type texte de base, il y a trois nouveaux types, texte enrichi, date et heure, qui font appel à des widgets basés sur jQuery. Des plugins ont été développés pour gérer ces nouveaux types de champs. Un plugin n'est pas associé à un widget précis, mais à l’ensemble des widget manipulant des données de même nature. Ainsi, pour le texte enrichi, c'est le widget CKEditor qui est utilisé, mais on pourrait utiliser jQuery TE à la place, tout en utilisant le même plugin, les deux widgets manipulant des données au format HTML. Par contre, si l'on voulait utiliser un widget qui manipulerait des données au format BBCode, il faudrait développer un nouveau plugin.

Concernant le type texte enrichi basé sur du HTML, les données correspondantes sont malheureusement mal affichées dans Firefox à cause de ceci. Vu la popularité de ce navigateur, ainsi que le fait que la fonctionnalité incriminée soit considérée comme obsolète dans XSLT 2.0, j'ai cherché une alternative, mais n'est malheureusement encore rien trouvé. Depuis que la dernière version de Microsoft Edge, celle fournie avec la dernière mise à jour de Windows 10 (version 1607), est capable d'afficher correctement la version Web de cette application, cela fait de Firefox le seul navigateur Web graphique moderne à poser problème…

Les onglets

La seconde nouveauté concerne les onglets. Cette application devant ultérieurement offrir la possibilité de créer des champs de type fiche, c'est-à-dire d'insérer dans une fiche une référence à une ou plusieurs autres fiches (faire du relationnel en quelque sorte), l'idée est d'avoir, d'une part, la fiche en cours de saisie, celle dans laquelle on voudrait référencer une ou plusieurs fiches, dans un onglet et, d'autre part, une liste de fiches, parmi lesquelles on sélectionnerait les fiches à référencer, dans un autre onglet. Bien sûr, ce n'est qu'un des usages envisageables des onglets.

Accessoirement, on peut réorganiser les onglets par drag & drop. ]]> epeios https://www.developpez.net/forums/blogs/22748-epeios/b1562/epeios-organizer-exemple-d-interface-desktop-web-cpp/ De l’utilisation des technologies web dans une application native. https://www.developpez.net/forums/blogs/22748-epeios/b1561/l-utilisation-technologies-web-application-native/ Tue, 09 Aug 2016 15:22:31 GMT * Introduction* (Ce...
Introduction

(Ce billet est issu d'un autre site ; je le reproduis ici car un billet à venir y fait référence).

Ce billet présente un projet portant sur le développement en C++ d'interfaces graphiques, qui a la particularité d'offrir à l'utilisateur un moyen simple de personnaliser au maximum l'interface d'une application sans avoir à en modifier le code source. Mettre les sources d'une application à disposition de l'utilisateur pour qu'il puisse l'adapter à ses besoins, c'est bien, mais lui offrir la possibilité de la personnaliser sans avoir à modifier ces sources (surtout qu'en l’occurrence, il s'agit de sources C++), c'est mieux.

Ce projet est issu d'un ancien projet qui s'appuyait sur XULRunner ; cela expliquera certains choix qui ont été fait. Cependant, un bug rédhibitoire (pour moi) de XULRunner, et des doutes concernant la pérennité de XULRunner, m'ont poussé à l'abandonner, et à explorer d'autres technologies en vue de le remplacer.

HTML5

A plusieurs reprises, on m'avait vanté les qualités de Qt ; je résolus donc d'essayer ce dernier. Mais je n'ai pas persévéré dans cette voie, leur approche ne me convenant pas. Je précise que je cherchais uniquement une technologie pour gérer les interface graphiques, ce qui était l'unique usage que j'avais de XULRunner, bien qu'il soit capable de beaucoup plus ; pour toute la partie traitement, j'utilisais un autre framework.

Coïncidence, à peu près au même moment fût publiée la version finalisée de HTML5, et j’entrepris donc d'explorer cette piste. Au final, pour l'usage que je comptais en faire, HTML5 s'est révélé être très proche de XUL (langage dont XULRunner est le moteur de rendu) ; je pouvais donc réutiliser pas mal d'outils que j'avais développés dans le cadre de mon utilisation de XULRunner.

Chromium Embedded Framework

Comme mon but était de trouver des technologies pour développer des applications natives, il me fallait trouver un moyen d'exécuter HTML5 dans ce contexte. Comme j'avais déjà Qt d’installé, j'ai essayé QtWebKit, mais certaines limitations de ce composant, ainsi que le fait de recourir à tout l'environnement de développement Qt pour n'utiliser que ce composant m’apparaissait totalement disproportionné, je me suis mis à la recherche d'un équivalent.

Qui dit HTML(5), dit JavaScript. Néanmoins, C++ étant mon langage de prédilection, je choisis de délaisser JavaScript au profit de ce dernier. Restait, comme écrit, à trouver le moyen d’exécuter HTML5 dans un contexte natif. Ce moyen, je l'ai trouvé avec Chromium Embedded Framework (CEF).

xdhcefq

Un problème que j'avais lorsque j'utilisais XULRunner, c'est que ses fichiers d’en-tête polluaient les sources de mes applications. Pour éviter ce désagrément, je résolus de développer un utilitaire qui prenait en charge toutes les interactions avec CEF, le code proprement dit de traitement de l'interface graphique étant déporté dans une bibliothèque, bibliothèque dont le code source n'aura donc pas à inclure de fichier d'en-tête de CEF. Cet utilitaire, c'est xdhcefq.

A noter que les exemples d’utilisation qui sont donnés pour CEF s'appuient sur son API C++. Comme l'utilisation de cet API nécessitait la compilation de bibliothèques supplémentaires, j'ai préféré utiliser l'API C, qui ne nécessitait pas ces bibliothèques supplémentaires. Mais la mise en œuvre de CEF est nettement plus compliquée en passant par la version C de l'API. Cependant, comme je n'ai à me préoccuper de CEF que lors du développement de xdhcefq, et que, pour le développement des applications proprement dites, je n'aurais plus à me préoccuper de l'API (C ou C++) de CEF (ce qui est, je le rappelle, justement l'objet de xdhcefq), j'ai préféré recourir à l'API C, car elle moins contraignante.

xdhdq

L'ensemble des technologies concernant la gestion d'interfaces graphiques dans le framework Epeios est regroupé sous le vocable XDHTML. Ci-après, vous allez trouver les principes de base de cette technologie. Pour rendre cela plus concret, une petite application triviale, s'appelant xdhdq, a été développée. Cette application prend la forme d'une bibliothèque dynamique, qui est chargée par xdhcefq. C'est de cette application que les exemples ci-dessous sont tirés.

Si vous désirez approfondir, xdhdq est librement téléchargeable à partir de sa page dédiée. Elle vient avec xdhcefq, qui est indispensable pour la faire tourner. Elle est disponible pour GNU/Linux, OS X et Windows, avec architecture IA-32 et AMD64.

Génération des composants HTML de l'interface graphique

Le code HTML de l'interface n'est pas directement généré par l'application, mais est le résultat d'une transformation XSL sur des données XML fournies par l'application. Les fichiers XSL utilisés pour la transformation sont spécifiés dans le fichier de configuration de l’application. Des exemples de tels fichiers XSL sont visibles ici (ce sont ceux suffixés par Layout.xsl).

Gestion de l'accessibilité des éléments

Pour gérer l'accessibilité d'un élément (c'est-à-dire le fait qu'un élément ait un attribut comme hidden ou disabled de défini ou non) se fait à l'aide d'un élément et d'un attribut maison (respectivement xdh-cast et data-xdh-cast). L'attribut data-xdh-cast est affecté aux éléments concernés lors de l'opération décrite juste au-dessus, et la définition des éléments xdh-cast se fait, comme précédemment, à partir d'une transformation XSL sur des données XML générées par l’application. Les fichiers XSL utilisés pour cette transformation sont également spécifiés dans le fichier de configuration de l’application, et des exemples de tels fichiers sont également visibles ici (ce sont ceux suffixés par Casting.xsl).

Voici un exemple de déclaration (issu de PrologLayout.xsl) :

Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
<select data-xdh-cast="PredefinedProjectsCast">...</select>

Et la définition correspondante (issue de PrologCasting.xsl):

Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<xsl:template match="ProjectType">
 <xsl:variable name="Type" select="."/>
  <xsl:choose>
   <xsl:when test="$Type='New'">
    <xdh-cast id="PredefinedProjectsCast" kind="Hide"/>
   </xsl:when>
   <xsl:when test="$Type='Predefined'">
    <xdh-cast id="PredefinedProjectsCast" kind="Plain"/>
   </xsl:when>
   <xsl:when test="$Type='Remote'">
    <xdh-cast id="PredefinedProjectsCast" kind="Hide"/>
   </xsl:when>
  </xsl:choose>
</xsl:template>

Gestion d’événements

La gestion d’événement se fait grâce aux attributs data-xdh-onevent, pour définir un seul gestionnaire d’événement, ou data-xdh-onevents (avec un s à la fin), pour en définir plusieurs. Les événements déclenchent une action définie dans un callback écrit en C++ et pourvu d'un identifiant unique. La définition d'un gestionnaire d’événement consiste donc à indiquer un événement (mouseleave, click...) ainsi que l'identifiant de l'action à lui associer. Par exemple (tiré de MainLayout.xsl) :

Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
<fieldset data-xdh-onevents="(mouseenter|HideFacetiousButton)|(mouseleave|ShowFacetiousButton)">

On peut omettre la spécification de l’événement, auquel cas ce sera l’événement par défaut qui sera utilisé (généralement click).

Il existe certains événements prédéfinis, qui peuvent prendre plusieurs paramètres. Par exemple (issu de PrologLayout.xsl) :

Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
<button data-xdh-onevent="(OpenFile|DisplayProjectFilename|(#plgSelectProjectFile#|.xprj))">

Un clic (événement qui n'est pas spécifié, car c'est l’événement par défaut pour cet élément) sur ce bouton provoquera l'affichage d'une sélecteur de fichier (action prédéfinie OpenFile), avec, pour titre, le texte correspondant à l'identifiant plgSelectProjectFile (qui est défini dans la section Locale du fichier de configuration), et .xprj comme filtre d'extension. Une fois le sélecteur fermé, l’action DisplayProjectFilename (qui est une action classique, c'est-à-dire qui correspond à un callback C++) est lancée.

Composants HTML et JQuery

De nombreux composants HTML d'interface graphique s'appuient sur JQuery, et, de ce fait, ont toujours quasiment le même code JavaScript d’instanciation. Pour éviter d'avoir à taper ce code, on peut recourir à l'attribut data-xdh-widget, par exemple de la manière suivante (tiré de FieldsLayout.xsl) :

Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
<textarea data-xdh-widget="ckeditor|enterMode : CKEDITOR.ENTER_BR, linkShowTargetTab: false, language: '#fieldsLanguage#', startupFocus : true,|val\(\)|ckeditor\(\).editor.focus\(\)">

Cela crée un composant ckeditor, avec certains paramètres propres à ce composant (situés entre le premier et le second | ; voir le site du composant pour leurs significations). Comme la récupération du contenu de ce composant, ainsi que la manière de lui donner le focus, ne se fait pas de façon classique, le code JavaScript adéquat est précisé (respectivement val() et ckeditor().editor.focus() ; les \ servent à échapper les caractères (et )).

Et maintenant ?

Il y a principalement deux projets en cours relatifs à la technologie XDHTML. Le premier consiste en une véritable application, à titre de POC évoluée, mais pleinement fonctionnelle et d'une réelle utilité. Le second consiste à développer l'équivalent de xdhcefq, mais pour les applications web. L'idée et d'avoir un seul et même code C++, et pour la version native, et pour la version web d'une application (il restera néanmoins possible, si désiré, d'adapter l'interface pour l'une ou l'autre type d'application). ]]> epeios https://www.developpez.net/forums/blogs/22748-epeios/b1561/l-utilisation-technologies-web-application-native/