Discussion :

[Stéphane le calme]

GTK 4.0 est disponible. La boîte à outils pour réaliser des interfaces graphiques apporte des améliorations dans le transfert des données,
une prise en charge intégrée de la lecture multimédia et bien d'autres

GTK est un ensemble de bibliothèques logicielles permettant de réaliser des interfaces graphiques. À l'origine, GTK a été développé pour les besoins du logiciel de traitement d'images GIMP (GNU Image Manipulation Program). Actuellement, son domaine d'application ne se limite plus seulement à GIMP, mais est utilisé dans d'autres projets. Par exemple, GTK est au cœur de l'environnement GNOME (GNU Network Object Model Environment), mais il peut également être utilisé pour écrire des applications pour d'autres environnements Linux, ainsi que des applications ciblant Microsoft Windows et Apple macOS.

L'utilisation de GTK pour la création de GUI est très intéressante sur plusieurs points :

• GTK est sous licence GNU LGPL. Cela fait de GTK une bibliothèque libre, permettant ainsi de l'utiliser ou de la modifier sans aucune contrainte financière. Pour avoir plus de renseignements, le plus simple est de visiter le site du projet GNU ;
• GTK existe sur plusieurs plateformes. En effet, GTK fonctionne sur les plateformes UNIX-like, Windows, BeOs ;
• GTK est utilisable avec plusieurs langages de programmation. Même si les créateurs de GTK ont écrit cette bibliothèque en C, sa structure orientée objet et sa licence ont permis à d'autres développeurs d'adapter GTK à leur langage préféré. Ainsi, il est possible de programmer des GUI GTK en C, C++, Ada, Perl, Python, PHP et bien d'autres.

Dans un billet de blog, les responsables de son développement ont annoncé la disponibilité de GTK 4.0 :

« 2020 a été une très longue année. Quelle meilleure façon d'y mettre fin qu'avec une version majeure! Aujourd'hui, nous avons publié GTK 4.0.

« GTK 4.0 est le résultat d'un travail acharné d'une petite équipe de développeurs dévoués. Nous aurons un article séparé pour passer en revue les statistiques, mais le bref résumé est que depuis la version 3.89.1 de novembre 2016, nous avons ajouté plus de 18 000 commits et réalisé plus de 20 versions de développement.

« Félicitations et un grand merci à tous ceux qui ont participé à cet effort, et en particulier à Benjamin, Emmanuele, Timm, Carlos, Jonas et Christian! »

GTK 4.0 propose de nouveaux widgets et des modifications apportées aux éléments existants, une prise en charge intégrée de la lecture multimédia, des améliorations de l'accélération GPU comme le travail sur son nouveau moteur de rendu Vulkan et une meilleure prise en charge de macOS. Nous pouvons également noter des améliorations du transfert de données, la refonte des shaders, le défilement accéléré par GPU, les améliorations du rendu OpenGL au-delà du travail de Vulkan, la restauration du travail sur HTMl5 Broadway, une meilleure prise en charge de Windows, etc.

Voyons quelques points un peu plus en profondeur.

Gestion des médias dans GT4

GTK 4 permettra aux applications GTK d'afficher plus facilement des animations; que ce soit une animation programmatique, un fichier webm ou un flux en direct.

GTK 4 apporte une nouvelle API appelée GdkPaintable qui a été inspirée par l'effort CSS Houdini. Elle est très flexible (tout ce que vous pouvez dessiner peut être un GdkPaintable). Le contenu peut être redimensionnable (comme svg) ou changer au fil du temps (comme webm).

Si vous avez des besoins plus spécialisés, tout ce qui peut être capturé dans un GtkSnapshot peut être transformé en un dessin avec gtk_snapshot_to_paintable(). Si vous créez un widget personnalisé qui souhaite dessiner un objet à peindre, c'est très simple. Appelez simplement gdk_paintable_snapshot().

Vous pouvez disposer du contrôle multimédia en vous servant du widget GtkVideo.

Transfert de données sur GTK4

Les méthodes traditionnelles de transfert de données initiées par l'utilisateur entre les applications de bureau sont le presse-papiers ou le glisser-déposer. GTK+ prend en charge ces méthodes mais, jusqu'à GTK3, les API dont la boîte à outils disposait pour ce type de transfert de données étaient des copies finement déguisées des API X11 correspondants. Ce n'est pas trop surprenant, puisque toute l'API GDK a été calquée sur X11. Malheureusement, l'implémentation inclut des résultats comme des transferts incrémentiels et des conversions de format de chaîne.

Pour GTK4, l'équipe a décidé d'abandonner cette façon de procéder, optant pour une modernisation. Voici le concept de la nouvelle approche :

« Si les données que votre application souhaite envoyer ne sont pas une chaîne, il s'agit probablement d'un objet, tel que GFile, un GdkTexture ou un GdkRGBA. L'application côté réception n'utilise peut-être pas GTK ou GLib et ne connaîtra donc pas ces types. Et même si c'est le cas, il n'y a aucun moyen de faire passer les objets d'un processus à l'autre en un seul morceau.

« En son sein, le transfert de données fonctionne en envoyant un descripteur de fichier à partir de l'application source et l'application cible en lisant un flux d'octets. Les protocoles pour le presse-papiers et le DND utilisent des types mime tels que text/uri-list, image/png ou application/x-color pour identifier le format du flux d'octets.

« L'envoi d'un objet implique la négociation d'un format de données pris en charge par les deux côtés, la sérialisation de l'objet du côté source dans un flux d'octets de ce format, le transfert des données et la désérialisation de l'objet du côté cible. »

Aussi, GTK4 s'accompagne de nouvelles API. « La première API que nous avons introduite pour gérer ces types est l'objet GdkContentFormats. Il peut contenir une liste de formats, qui peuvent être des GTypes ou des types mime. Nous utilisons des objets GdkContentFormats pour décrire les formats dans lesquels une application peut offrir des données, ainsi que les formats dans lesquels une application peut recevoir des données ».

Le presse-papiers

GTK3 a un objet GtkClipboard, qui fournit l'implémentation pour les opérations de copier / coller. Avoir cet objet dans GTK n'est pas idéal, car il nécessite différentes implémentations sur les plateformes prises en charge par GTK. Par conséquent, GTK4 déplace l'objet vers GDK et le renomme GdkClipboard. Il a également été porté sur les nouvelles API de transfert de données. Pour mettre des données dans le presse-papiers dans GTK4, vous devrez utiliser l’une des API « set »:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
gdk_clipboard_set_content()
gdk_clipboard_set_value()
gdk_clipboard_set_text()

En fin de compte, toutes ces fonctions finissent par associer un GdkContentProvider au presse-papiers.

Pour lire les données du presse-papiers dans GTK4, vous devrez utiliser l’une des API asynchrones de «read»:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
gdk_clipboard_read_async()
gdk_clipboard_read_value_async()
gdk_clipboard_read_text_async()

Glisser déposer

L'API Drag-and-Drop GTK3 consiste à écouter un certain nombre de signaux sur GtkWidget et à appeler quelques fonctions de configuration spéciales pour les sources et les destinations du glisser-déposer. Il est flexible, mais généralement considéré comme déroutant.

Dans GTK4, l'API Drag-and-Drop a été réorganisée autour des concepts de fournisseurs de contenu et de contrôleurs d'événements. Pour lancer une opération de glisser-déposer, vous créez un contrôleur d'événement GtkDragSource qui réagit aux mouvements de glissement (vous pouvez également démarrer des opérations de glisser-déposer "uniques" en appelant simplement gdk_drag_begin vous-même), et vous lui donnez un GdkContentProvider pour les données que vous souhaitez transférer. Pour recevoir des opérations de glisser-déposer, vous créez un contrôleur d'événements GtkDropTarget et appelez une méthode de lecture asynchrone lorsqu'elle émet le signal ::drop-done

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
gdk_drop_read_value_async()
gdk_drop_read_text_async()

Contrôleurs d'évènements

L'équipe indique que GTK4 s'est séparé des signaux dans la zone de saisie comme ::button-press-event, ::key-press-event, ::touch-event. À la place, vous devez ajouter des contrôleurs d'événements à votre widget et écouter leurs signaux. Par exemple, il existe GtkGestureClick, GtkEventControllerKey, GtkGestureLongPress et bien d'autres.

Les contrôleurs d'événements peuvent être créés dans des fichiers d'interface utilisateur, mais il est plus courant de le faire dans la fonction init ():

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
static void click_cb (GtkGestureClick *gesture,
                      int              n_press,
                      double           x,
                      double           y)
{
  GtkEventController *controller = GTK_EVENT_CONTROLLER (gesture);
  GtkWidget *widget = gtk_event_controller_get_widget (controller);
 
  if (x < gtk_widget_get_width (widget) / 2.0 &&
      y < gtk_widget_get_height (widget) / 2.0)
     g_print ("Red!\n");
}
 
...
 
  controller = gtk_gesture_click_new ();
  g_signal_handler_connect (controller, "pressed",
                            G_CALLBACK (click_cb), NULL);
  gtk_widget_add_controller (widget, controller);

gtk_widget_add_controller() prend possession du contrôleur et GTK nettoie automatiquement les contrôleurs lorsque le widget est finalisé, il n'y a donc plus rien à faire.

Source : annonce GTK4

[emilie77]

GTK et PHP?? wow

[hyakosm]

On ne peut pas mettre en avant le côté multiplateforme comme un avantage de GTK, ce toolkit n'est pas vraiment multiplateforme. D'accord on peut compiler des applications Windows et Mac avec, mais l'intégration est vraiment catastrophique, pire que du temps de GTK+2. C'est pratique si on veut porter un logiciel déjà développé destiné à Linux/GNOME, mais ce n'est pas une option envisageable si on veut choisir un toolkit pour développer un logiciel multiplateforme dès le début.

[Invité]

C'est pratique si on veut porter un logiciel déjà développé destiné à Linux/GNOME, mais ce n'est pas une option envisageable si on veut choisir un toolkit pour développer un logiciel multiplateforme dès le début.

J'ai rien compris : c'est pratique si on a déjà du code mais c'est pas envisageable pour un nouveau projet ?

[hyakosm]

J'ai rien compris : c'est pratique si on a déjà du code mais c'est pas envisageable pour un nouveau projet ?

Oui, c'est pratique pour pouvoir faire un portage d'un logiciel avant tout destiné à Linux, vers d'autres plateforme (c'est le cas de GIMP par exemple). Mais si on veut dès le début faire un projet vraiment multiplateforme avec une intégration correcte dans Windows ou Mac OS alors non GTK+ n'est pas une bonne idée. GTK est techniquement multiplateforme mais son intégration dans les environnements autres que GNOME est terrible.

[JPLAROCHE]

Ça déjà quelque temps et très sérieusement que j'utilise GTK3.

en c/ c++/nim bref les applications son très simple à réaliser et reste très portable d'un system à l'autre tant soi peu que l'on respecte la norme , bien-sur si vous allez trifouiller dans l'os faut pas vous attendre à avoir le même rendu.

la façon de faire de l'objet est très intéressant (je parle de GTK) c'est vraiment le tools qui est basé sur l'objet. d'ailleur je vous conseille de lire tout ce domaine très bien documenté leurs conception de l'objet.

Quand à GTK4 j'attend d'avoir plus de communication et voir comment migrer ou tout simplement faire d'une autre façon.

bon j'attend aussi la mise à dispo dans ma distribution autrement que par wget

et de la doc encore de la doc car il faudra la lire et relire c'est souvent un coté que l'on oublie dans comment batir un bon projet ...

d'après certains apperçus et des retours de ceux qui sont déjà dans la course il y a encore beaucoup plus de cohérence dans GTK4

si gnome l'utilse je vois cela comme une vitrine et en regardant le rendu c'est pas mal du tout

et utilisé galde le designer ce n'est pas comme développer soit même quoique builder est bien foutue après il faut mettre la main à la pelle et y aller, c'est comme tout il faut de l'huile de coude .

@bientôt

[liberforce]

On ne peut pas mettre en avant le côté multiplateforme comme un avantage de GTK, ce toolkit n'est pas vraiment multiplateforme. D'accord on peut compiler des applications Windows et Mac avec, mais l'intégration est vraiment catastrophique, pire que du temps de GTK+2. C'est pratique si on veut porter un logiciel déjà développé destiné à Linux/GNOME, mais ce n'est pas une option envisageable si on veut choisir un toolkit pour développer un logiciel multiplateforme dès le début.

Tourner sur une plateforme et être intégré à cette platefome sont deux choses différentes. À ce compte là GTK ne serait même pas mono-plateforme, parce que selon si elles ont été conçues pour tourner sous GNOME ou KDE, les applications n'ont pas la même tête déjà sur un Linux, alors pour Windows ou Mac... Mais l'intégration se fait au niveau applicatif, le toolkit ne peut pas tout faire magiquement. Au passage une application comme Mozilla Firefox a son interface en GTK au moins sur les versions Windows et Linux, ça me paraît donc violent de dire que qu'avec GTK l'intégration est "catastrophique".

GTK et PHP?? wow

Les bindings sont assez anciens, je n'en ai trouvé que pour GTK 2, ils n'ont jamais été portés vers GTK 4.

GTK est un ensemble de bibliothèques logicielles permettant de réaliser des interfaces graphiques. À l'origine, GTK a été développé pour les besoins du logiciel de traitement d'images GIMP (GNU Image Manipulation Program). Actuellement, son domaine d'application ne se limite plus seulement à GIMP, mais est utilisé dans d'autres projets. Par exemple, GTK est au cœur de l'environnement GNOME (GNU Network Object Model Environment), mais il peut également être utilisé pour écrire des applications pour d'autres environnements Linux, ainsi que des applications ciblant Microsoft Windows et Apple macOS.

L'utilisation de GTK pour la création de GUI est très intéressante sur plusieurs points :

• GTK est sous licence GNU LGPL. Cela fait de GTK une bibliothèque libre, permettant ainsi de l'utiliser ou de la modifier sans aucune contrainte financière. Pour avoir plus de renseignements, le plus simple est de visiter le site du projet GNU ;
• GTK existe sur plusieurs plateformes. En effet, GTK fonctionne sur les plateformes UNIX-like, Windows, BeOs ;
• GTK est utilisable avec plusieurs langages de programmation. Même si les créateurs de GTK ont écrit cette bibliothèque en C, sa structure orientée objet et sa licence ont permis à d'autres développeurs d'adapter GTK à leur langage préféré. Ainsi, il est possible de programmer des GUI GTK en C, C++, Ada, Perl, Python, PHP et bien d'autres.

Merci pour cette dépêche !

Quelques remarques :

• GTK a été extrait de GIMP: c'est initialement du code de GIMP qui a été extrait pour devenir une bibliothèque indépendante.
• l'acronyme associé à GNOME a été abandonné il y a plus de 10 ans
• GTK est en LGPL 2.1 ou ultérieur (SPDX: LGPL-2.1-or-later). Dans une licence, la version est importante, il y a souvent des changement significatifs d'une version à l'autre.
• Comme je l'ai dit plus haut, les bindings GTK pour PHP ont l'air assez mort vu qu'ils n'ont jamais été portés pour GTK 3

Mais je pinaille .

C'est du bon boulot;, merci pour le temps passé

[hyakosm]

Tourner sur une plateforme et être intégré à cette platefome sont deux choses différentes. À ce compte là GTK ne serait même pas mono-plateforme, parce que selon si elles ont été conçues pour tourner sous GNOME ou KDE, les applications n'ont pas la même tête déjà sur un Linux, alors pour Windows ou Mac... Mais l'intégration se fait au niveau applicatif, le toolkit ne peut pas tout faire magiquement. Au passage une application comme Mozilla Firefox a son interface en GTK au moins sur les versions Windows et Linux, ça me paraît donc violent de dire que qu'avec GTK l'intégration est "catastrophique".

J'ai peut-être été un peu expéditif dans mon précédent message, alors je vais détailler un petit peu.

Oui ça tourne sur différentes plate-formes, mais le problème se situe au niveau de l'intégration, c'est ça. Et effectivement c'est mono-plateforme dans le sens "pour GNOME", parce qu'aujourd'hui le projet GTK est fortement intriqué à GNOME, et si le rendu est acceptable sur KDE ou XFCE c'est parce que les développeurs de ces environnements ont bien voulu faire des efforts de support des apps GTK (ex : support des CSD dans KDE). Un toolkit est réellement multiplateforme pas juste quand ça compile, mais quand le look-and-feel s'adapte à la plateforme un minimum correctement. Sur GTK, le filepicker (sélecteur de fichiers) n'est toujours pas bon sur certaines applications (exemple avec Gimp pour Windows ou Inkscape sur Mac - avec bug graphique en prime), sur Mac il n'y a même pas de thème natif (exemple Gimp ; Inkscape qui se met en Adwaita). Là où Qt en comparaison fait un bon travail : ce ne sera jamais aussi bien intégré qu'une app avec un toolkit natif mais c'est très propre (exemple : VLC pour Linux et Windows), il faut vraiment avoir l'œil pour distinguer une app Qt d'une app Cocoa ou Win32. Il y a eu une discussion intéressante sur le forum du logiciel Audacious à ce propos, qui est passé de GTK à Qt.

Pour Mozilla c'est un cas à part, l'interface est toujours faite avec des composants XUL si je me souviens bien, et emploie par défaut le style graphique de GTK quand ça tourne sur Linux, mais sur Windows ou Mac il reprend le style natif, les raccourcis clavier s'adaptent et les menus aussi.

Qu'on ne s'y trompe pas, GTK c'est un outil avec de nombreuses qualités, qui a sa place dans l'écosystème et qui permet d'offrir un environnement GNOME cohérent, ce qui est très agréable. Leurs équipes prennent des décisions fortes mais controversées, ce qui permet d'aller plus loin dans leur vision de ce que doit être l'expérience utilisateur. Très bien, je respecte ça et je pense même que c'est une bonne idée, mais ça va dans le sens inverse que de proposer une expérience multiplateforme bien intégrée. J'ai moi-même développé avec GTK3 il y a longtemps parce que je visais spécifiquement Linux/GNOME. Mais à mon sens c'est pas le choix le plus judicieux si on veut viser différentes plate-formes.

[Invité]

Là où Qt en comparaison fait un bon travail : ce ne sera jamais aussi bien intégré qu'une app avec un toolkit natif mais c'est très propre (exemple : VLC pour Linux et Windows), il faut vraiment avoir l'œil pour distinguer une app Qt d'une app Cocoa ou Win32.

C'est marrant que tu cites VLC comme exemple de bonne intégration car justement j'utilise xfce avec un thème sombre et VLC est l'un des rares logiciels qui garde son thème clair et c'est extrèmement désagréable.

Perso, d'un point de utilisateur comme développeur, je préfère gtk à qt; je trouve son api plus propre, sa license plus simple, moins lourd...

[JPLAROCHE]

je suis sur manjaro xfce https://ibb.co/r57yTWf
la couleur est sombre ,mais je suis d'accord je préfère GTK même pour le rendu

[liberforce]

Pour rappel, Qt fait beaucoup plus de choses que GTK.

GTK, c'est moins d'un million de lignes de code: https://www.openhub.net/p/gtk
Qt c'est quasiment 5 millions de lignes. https://www.openhub.net/p/qt

Pour la partie intégration aux autres OS, l'équipe GTK a toujours été claire: toute contribution est la bienvenue. Cependant ce sont principalement des développeurs GNOME qui bossent dessus, et forcément, s'il y a très peu de développeurs Windows qui contribuent, forcément il passe au second plan. Il y a aussi plein de sociétés qui contribuent à Qt, beaucoup moins à GTK. Tout ça pour dire que certes l'intégration n'est pas parfaite, mais c'est du logiciel libre: si on veut l'améliorer, on peut contribuer.

[dourouc05]

Pour rappel, Qt fait beaucoup plus de choses que GTK.

Dans ta petite comparaison, il manque quand même un élément essentiel : la licence. GTK, c'est clair, c'est du libre (LGPL partout). Qt, c'est clair que tout est prévu pour que les gens se trompent (certains modules uniquement en LGPL, d'autres uniquement en GPL, même si la majorité est en GPL et LGPL ; sans oublier que les versions de maintenance sont payantes après quelques mois, dès Qt 5.15.3…).

Sinon, les cinq millions de lignes, ça semble être juste Qt 4. Le même site indique huit millions pour Qt 5 (https://www.openhub.net/p/qt5).

[davs34]

Bonjour

On est bien d'accord que GTK pour python sous Windows c'est mort depuis la fin de GTk2 ?

Je ne trouverais plus jamais un ptit fichier executable qui installe GTK que je n'ai plus qu'a " include " avec python ?