Ajout de l’affichage tête haute dans les applications GTK+

Plotinus est un projet encore en phase de développement qui offre une palette de commandes aux différentes applications GTK+, ce qui permet de parcourir les différentes fonctions d’un logiciel depuis une boîte de recherche textuelle, plutôt qu’en parcourant les différents menus à la souris.

Si le principe vous parle, c’est qu’il est similaire aux palettes de commandes offertes par un certain nombre d’éditeurs de texte (Atom, Sublime Text, Visual Studio Code…) ou la fonction HUD de l’environnement Unity proposé par Ubuntu.

Comme dit précédemment, le projet est encore jeune et contient par conséquent un certain nombre de limitations, comme l’impossibilité de s’installer facilement ou de pouvoir modifier le raccourci clavier utilisé. Ce dernier point étant problématique, puisque un certain nombre d’applications, telles que Firefox ou LibreOffice Writer, utilisent le même raccourci clavier, rendant l’utilisation du module impossible.

Pour ceux qui souhaiteraient tout de même tester, sous Fedora ou RHEL, il faut tout d’abord installer les paquets git cmake vala gtk3-devel. Sous Ubuntu, Linux Mint ou elementary OS, ça sera git cmake valac libgtk-3-dev.

Vient ensuite la récupération des sources et la compilation :

git clone https://github.com/p-e-w/plotinus.git
cd plotinus
mkdir build
cd build
cmake ..
make

Il ne reste plus qu’à indiquer aux applications GTK+ où trouver le module. Pour cela, il faut éditer le fichier /etc/environment et y ajouter la ligne :

GTK3_MODULES=/chemin/vers/libplotinus.so

Mais si un simple test vous suffit, vous pouvez passer par le terminal et utiliser la même ligne, en y ajoutant le nom de l’application que vous souhaitez tester à la fin. Par exemple, pour l’éditeur de texte, ça donnera :

GTK3_MODULES=/chemin/vers/libplotinus.so gedit

Une fois l’application lancée, vous pouvez tester la fonctionnalité à l’aide du raccourci clavier Ctrl+Maj+P.

GTK+ 4.0 ne sera pas GTK+ 4

GTK+ Hackfest 2016 (© Matthias Clasen)

Le GTK+ Hackfest 2016 se déroule en ce moment même à Toronto. Plus d’une quinzaine de développeurs s’y sont retrouvés pour trois jours de développement et de discussions, décidant ainsi du futur de cette bibliothèque utilisée pour concevoir les interfaces graphiques des applications GNOME et d’un certain nombre d’autres projets majeurs.

L’une des discussions ayant fait le plus de bruit concerne le versionnage des prochaines versions majeures (GTK+ 4, 5, 6…).

Depuis la sortie de GTK+ 3.0 en février 2011, les nouvelles versions mineures se sont succédé ces dernières années, apportant à chaque fois leur lot de nouvelles fonctionnalités, mais également de problèmes, cassant régulièrement l’API ou les thèmes utilisateurs. À tel point que ce manque de compatibilité ascendante est désormais l’une des critiques les plus courantes, et que différents projets ont préféré abandonner GTK+ au profit de Qt, ou de retarder leur migration de GTK+ 2 vers la version 3.

Pour rappel, GTK+ 1 est sorti en 1998, GTK+ 2 en 2002 et GTK+ 3 en 2011. Des écarts toujours plus grands, qui obligent à apporter régulièrement de nouvelles fonctionnalités pour pouvoir coller aux nouvelles technologies ou couvrir de nouveaux besoins.

L’une des solutions envisagées, serait de sortir plus régulièrement de nouvelles versions majeures, considérées comme stables, qui ne recevraient plus que des correctifs améliorant la stabilité ou la sécurité (pour de plus amples informations, je vous conseil la lecture des deux billets de blog d’Allison Lortie, Gtk 4.0 is not Gtk 4 et Gtk 5.0 is not Gtk 5).

Après la sortie de GTK+ 4, qui ne devrait probablement pas avoir lieue avant 2018, une nouvelle version majeure sortirait approximativement tous les deux ans. Et entre chaque nouvelle version majeure, nous continuerions comme aujourd’hui de bénéficier de nouvelles versions mineures tous les six mois, qui apporteraient leur lot de nouveautés.

Mais c’est là que ça se gâte. Pour le moment, on semble se diriger vers un GTK+ 4 qui ne correspondrait pas à GTK+ 4.0. Et il en irait de même pour GTK+ 5 ou 6. En gros, durant les dix-huit premiers mois (ce qui correspond à trois versions mineures), les développeurs seraient libres d’ajouter de nouvelles fonctionnalités et de casser l’API autant qu’ils le souhaitent. Une fois le code stabilisé, il sera alors décidé que GTK+ 4.6 ou 4.8 pourra devenir le nouveau GTK+ 4.

GTK+ Hackfest 2016 (© Matthias Clasen)

À ce moment de l’article, vous ne pouvez vous empêcher de trouver ça idiot et de vous demander pourquoi ils ne travailleraient pas plutôt sur une branche de développement qui, une fois stabilisée, donnerait GTK+ 4.0, première version stable de cette nouvelle branche ?

De l’avis des développeurs, il semble y avoir deux publics, qui ont chacun des besoins différents. D’un côté des projets comme GNOME, qui souhaitent pouvoir bénéficier rapidement des dernières nouveautés sans avoir besoin d’attendre deux ans. Projets qui, de par leur taille, auront toujours la main d’œuvre nécessaire pour adapter les différentes applications aux éventuelles nouveautés ou autres cassures d’API. Et de l’autre, les développeurs d’applications tierces, qui préféreront plutôt se baser sur une version stable qui ne bougera plus, et ne nécessitera donc plus une maintenance incessante et régulière.

Maintenant, il faut savoir que les discussions ont toujours lieues et qu’aucune décision ne sera prise avant le prochain GUADEC, qui se tiendra cette année du 12 au 14 août en Allemagne. Il est donc possible que le versionnage change encore d’ici là. Mais une chose est sûre, de l’avis même des développeurs, des versions stables plus régulières devraient faciliter et accélérer le développement, ce qui devrait nous apporter plein de bonnes choses dans les années à venir.

Une inconnue demeure néanmoins. Combien de branches seront maintenues en parallèle ? Surtout quand on sait que GTK+ 2, qui en est actuellement à la version 2.24.30, est toujours maintenu, près de quinze ans après sa première apparition.

Raccourcis clavier

Du temps de GNOME 2, les applications possédaient des barres de menu qui contenaient les différentes fonctions disponibles et les raccourcis clavier associés. Avec le passage à GNOME 3 et sa nouvelle façon de concevoir les interfaces, les barres de menu ont disparues et la liste des raccourcis clavier avec elles.

Depuis, il n’existe malheureusement plus vraiment de façon simple d’obtenir la liste de tous les raccourcis clavier. Parfois disponibles dans l’aide en ligne, la liste des raccourcis est bien souvent absente, incomplète ou non mise à jour.

Mais ce problème sera bientôt du passé, les développeurs Christian Hergert et Matthias Clasen ayant récemment ajouté le composant GtkShortcutsWindow au toolkit GTK+.

Photos 3.19 et sa fenêtre de raccourcis clavier

Ce dernier pourra proposer, depuis les raccourcis Ctrl+? ou Ctrl+F1, la liste complète et à jour de tous les raccourcis clavier et autres gestes tactiles de l’application.

Plusieurs fonctionnalités intéressantes seront également proposées, comme la possibilité de rechercher facilement un raccourci, de montrer les raccourcis qui appartiennent à différentes vues ou modes (comme l’application Horloges, qui propose des vues Alarme, Chronomètre ou Minuteur), ou de fournir des informations supplémentaires sur les gestes tactiles ou les raccourcis clavier.

Normalement, toutes les applications GNOME devraient pouvoir en bénéficier pour la sortie de la version 3.20. De leur côté, les développeurs d’applications tiers intéressés pourront consulter la documentation qui leur est dédiée.

Prise en charge du renommage et de la suppression dans les boîtes de dialogue de fichiers

Parfois, en découvrant certaines nouveautés à venir, on ne peut s’empêcher de se demander pourquoi elles n’étaient pas présentes depuis le début. C’est le cas des nouvelles boîtes de dialogue Ouvrir et Enregistrer sous de GNOME 3.18, qui permettront enfin de pouvoir supprimer ou renommer directement des fichiers ou dossiers…

Pour la musique, il s’agit du morceau Sad Robot du groupe pornophonique.

Nouveau composant GTK+ pour l’affichage des images

Dans le but d’éviter la duplication de code et ainsi faciliter le développement et la maintenance des différentes applications qui nécessitent de pouvoir afficher une image en taille réelle (le Visionneur d’images, Photos, un client Twitter ou de messagerie…), Timm Bäder s’est attelé à développer un nouveau composant GTK+, GtkImageView.

Bien que toujours en cours de développement, ce dernier devrait, à terme, offrir des possibilités de mise à l’échelle, rotation, chargement asynchrone, prise en charge des gestes tactiles (pour la mise à l’échelle et la rotation), tout en permettant de définir différents niveaux de zoom.