Discussion :

[ZenZiTone]

Aujourd'hui, une IHM développée en Java est toute aussi performante qu'une IHM développée en C/C++.

Deux langages, deux domaines d'application différents. Donc effectivement, le Java sera plus adapté à la réalisation d'interfaces homme-machine en terme de performance/productivité, mais ce n'est pas/plus le domaine de prédilection de langages plus bas niveau.

au point où les outils de bureautique Desktop peuvent être facilement remplacés par des outils on-line.

Alors pour ma part il s'agit d'un beau contre exemple (pour le moment du moins) ! Les web-app sont beaucoup moins performantes que les application de bureau. Elles offrent l'avantage d'être accessible depuis différents terminaux, certes, mais ne permettent pas une utilisation aussi fluide et complète que les versions desktop.

[Pyramidev]

Donc effectivement, le Java sera plus adapté à la réalisation d'interfaces homme-machine en terme de performance/productivité

Ça, ça se discute.

D'ailleurs, il y a un sujet là-dessus sur stackoverflow :
Java vs C++ Qt : what choice for a gentle deployment?

[MikeRowSoft]

Inclure une librairie implémenté en C dans un environnement C++ est courant.
Les librairies que j'ai utilisé le plus souvent sont souvent codé en C++.

Inclure une librairie implémenté en C++ dans un environnement C est peu commun.
Je crois bien que si l'utilisateur (programmeur) veut du maloc c'est peut-être pour certaines raisons que le C++ ne propose pas... Vue que c'est plus de l'orienté objet.

Je pense qu'il est plus probable d'approcher du "langage Assembleur" en C qu'en C++.
Question .c/.h et .cpp/.h, les algorithmes les fonctions qui ne sont pas des méthodes liés aux modèles objets... Je vois bien la subtilité.

---

Sachant que selon ce lien http://franckh.developpez.com/tutoriels/posix/pthreads/ le langage C est multi thread, je ne vois encore moins qu'elle serait l'obstacle. Si ce n'est la "densité" du code source et taille du binaire par rapport aux d’objets qui traites et l'exécutes employés. Simplement une question de lisibilités...

[kilroyFR]

Maintenant, je reste toujours ouvert à l'évaluation d'autres langages.

La meilleure reponse. Je me suis retrouvé pendant longtemps a faire du C/C++/MFC. Quand les outils sont maitrisés + utilisation de libs deja faites (ex: bcgsoft qui permet de faire des applis ruban etc. tres facilement) le propre de l'informatique n'etant pas de tout reinventer a chaque fois) et je sors de IHM en C++ aussi rapidement qu'un developpeur C#.
Pour le web les langages C#/java (que je considere comme le 'visual basic' de leurs ancetres C/C++) sont plus facile a apprehender sur les domaines web evidemment.
Mais comme toi j'ai essayé presque tous les langages disponibles pour y trouver un interet dans mes projets. Certains ont ete concluants, d'autre moins (CORBA, COM etc. WPF/SL ayant ete mes plus grosses deceptions ... tout ca... pour ça).

[Madmac]

Des langages qui rentre en concurrence, il ne peut en rester qu'un à la fin. PL/I vs Cobol, cobol l'a emporté, Python vs Ruby => python l'a emporté, Java vs C# ???
Et puis que dire de JS qui lui aussi commence à envahir d'autre domaine autre que les pages web

Dans l'ensemble, je pense que C a perdu du terrain quand même, avant il était encore utilisé dans le domaine scientifique, aujourd'hui il a été complètement remplacé par R.
Et google avec sont langage Go pourrais lui faire encore perdre du terrain.

Python n'a pas gagné la guerre. Le seul avantage qui lui restait était la compilation. Et il l'a en quelque sorte perdu.

C et C++ était sur respirateur artificiel, dans le coeur de beaucoup de programmeurs, depuis un bon bout de temps. Produire du code sans fuite de mémoire demande beaucoup de discipline. Plusieurs tentatives pour les substituer avait été fait sans succès (Langage D, C Objective). Mais ce n'est plus le cas, Ruby a donné naissance à un autre langage de programmation qui met la machine au service du programmeur: Crystal.

Un langage très très prêt de Ruby.(pas identique, parce certains avantage d'un langage interprété ne peuvent être reproduit dans un langage compilé). Les performances sont suffisamment prêt de C++ pour la majorité des programmeurs. À moins de faire du web, Java et .NET va également devenir beaucoup moins intéressant. Et pour cette raison, je crois que ce langage va devenir extrêmement populaire.

http://www.blogduwebdesign.com/langa...ment-ruby/1880

Une raison de plus de préféré Ruby à Python ...

[Invité]

Python n'a pas gagné la guerre. Le seul avantage qui lui restait était la compilation. Et il l'a en quelque sorte perdu.

C et C++ était sur respirateur artificiel, dans le coeur de beaucoup de programmeurs, depuis un bon bout de temps. Produire du code sans fuite de mémoire demande beaucoup de discipline. Plusieurs tentatives pour les substituer avait été fait sans succès (Langage D, C Objective). Mais ce n'est plus le cas, Ruby a donné naissance à un autre langage de programmation qui met la machine au service du programmeur: Crystal.

Un langage très très prêt de Ruby.(pas identique, parce certains avantage d'un langage interprété ne peuvent être reproduit dans un langage compilé). Les performances sont suffisamment prêt de C++ pour la majorité des programmeurs. À moins de faire du web, Java et .NET va également devenir beaucoup moins intéressant. Et pour cette raison, je crois que ce langage va devenir extrêmement populaire.

http://www.blogduwebdesign.com/langa...ment-ruby/1880

Une raison de plus de préféré Ruby à Python ...

Conseiller à quelqu'un d'apprendre Ruby au lieu de Python aujourd'hui c'est quand même lui conseiller de se tirer une balle dans le pied, Ruby est utilisé principalement (uniquement ?) pour le développement web et est en perte de vitesse. Python est utilisé pour le web également mais est aussi le langage de script tout terrain utilisé un peu partout, notamment pour le scripting serveur et dans les domaines scientifiques. Bref d'un côté tu as un langage en perte de vitesse avec un marché du travail restreint et utilisé dans un domaine uniquement, et de l'autre un langage en plein essor avec un marché du travail correct et qui ouvre sur de multiples domaines.

Le choix est plutôt simple en fait.

[RyzenOC]

Conseiller à quelqu'un d'apprendre Ruby au lieu de Python aujourd'hui c'est quand même lui conseiller de se tirer une balle dans le pied, Ruby est utilisé principalement (uniquement ?) pour le développement web et est en perte de vitesse. Python est utilisé pour le web également mais est aussi le langage de script tout terrain utilisé un peu partout, notamment pour le scripting serveur et dans les domaines scientifiques. Bref d'un côté tu as un langage en perte de vitesse avec un marché du travail restreint et utilisé dans un domaine uniquement, et de l'autre un langage en plein essor avec un marché du travail correct et qui ouvre sur de multiples domaines.

Le choix est plutôt simple en fait.

+1 j'aurais pas dit mieux...
Ah si j'en rajoute une couche, python est intégré à de nombreux programme comme blender 3D ou C4D et bientôt peut etre carrément dans la suite MS office (pour remplacer VB)

Ruby est belle est bien en train de mourir, c'est un fait.
Et c'est pas utile de se réfugier dans un langage sortie de nul part comme "Crystal". Jamais je prendrais le risque de démarrer un projet d'entreprise avec ce langage dont le développement peut s’arrêter à tous moment.

[Madmac]

Conseiller à quelqu'un d'apprendre Ruby au lieu de Python aujourd'hui c'est quand même lui conseiller de se tirer une balle dans le pied, Ruby est utilisé principalement (uniquement ?) pour le développement web et est en perte de vitesse. Python est utilisé pour le web également mais est aussi le langage de script tout terrain utilisé un peu partout, notamment pour le scripting serveur et dans les domaines scientifiques. Bref d'un côté tu as un langage en perte de vitesse avec un marché du travail restreint et utilisé dans un domaine uniquement, et de l'autre un langage en plein essor avec un marché du travail correct et qui ouvre sur de multiples domaines.

Le choix est plutôt simple en fait.

Dire que "Ruby n'est que pour du web"est un erreur très répandue. À titre d'exemple, la gestion de paquet de Gentoo est faite en Ruby. La gestion de packet d'OpenSuse et la version graphique( Yast) est également en Ruby. Tu peux remplacer Bash par Ruby sur les Linux et Unix. Et c'est avantageux de le faire parce qu'avec le temps, un petit script peu finir par devenir un véritable programme. Et à tout les fois que tu utilise du CSS programmable, tu fais du Ruby! CoffeeScript, c'est du Ruby compilé en Javascript. Donc tous les programmeurs qui font du Full Stack ou du Front-end on intérêt à apprendre Ruby pour pouvoir aller plus loin que SASS et SCSS.

Dire que Ruby n'a d'intérêt que pour les gens qui font du web à assez risible comme argument. Le Web doit bien représenté au moins 50% du secteur de la programmation. La ligne entre du web et du PC devient de plus en mince. Un smarphone est un cellulaire qui fonctionne sous une version réduite de Linux. Prétendre que Ruby est que pour du Web, c'est ignorer qu'il est existe des interfaces graphique pour tous les OS. Il existe des interfaces graphiques pour tous les OS (La majorité des desktops sur Linux ont leur interface spécifique).. Apple en a fabriquer un spécifiquement un pour ces machines et peut-être étendue en C objective. Et c'est une interface très populaire pour faire des applis pour IPhone. Mais bon, j'imagine qu'à tes yeux, que c'est juste du web,

Tout ce qui est faisable en Python, peut-être fait en Ruby, avec un code qui ne pique pas les yeux. Mais l'inverse n'est pas vrai. parce qu'il est un langage interprété qui a des propriétés qui sont unique dans le monde des langages interprétés. Les objets en Python sont une addition par dessus le langage original. Ruby utilise Unicode dans son mode natif, ce n'est pas le cas pour Python. Python a un support partiel de l'unicode. Il peut l'écrire mais il n'a de grep qui support l'unicode. Et comme ce n'est qu'une addition, pour trouver de la documentation pour faire du Francais en Python est plus rare qu'en Ruby. En Ruby, ma base de donnée supporte le français sans j’aie à me soucier de la configuration de la base de donnée! Ĉ'est aussi simple qu'en anglais.

Et les capacités de métaprogrammation de Python sont insignifiante comparativement à Ruby. J'ignore si le concept de module existe dans les nouvelles versions. Mais le concept de Mixin n'existe pas: http://rubylearning.com/satishtalim/modules_mixins.html . Les Mixin sont un alternative à l'héritage et le multiple héritage. Et je ne crois pas qu'ils pourront être implanté du façon aussi élégante, car Ruby est un langage pure objet comme Smalltalk. Et je n'aborderai pas le fait que la majorité de prof sont collé à la version 2 de Python et que les deux versions ne sont pas compatible.

Avec ces facilités, Ruby supporte presque tous des modèles de programmation. À l'exception de langage déclaratif comme Prolog, tu peux "penser" ton programme en n'importe quel type de langage pour produire ton programme. Un programmeur de Pascal/C++/Smalltalk peut passer aussi bien en Ruby qu'un programmeur de LISP peut passer à Ruby. Il est possible de faire LISP avec du C++ ou d'autre langages. Au final, n'importe quel langage peut-être utilisé pour imiter un paradigme de programmation d'un autre langage, la différence sera dans la simplicité à le faire et la lisibilité du code produit. La différence est la ! Et généralement le résultat final va devoir très bien documenté pour que le programmeur en charge de la maintenance ne fasse pas un dépression.Pour faire des prototypes ou des Proof of Concept, il n'y a pas de meilleur langage. Et comme depuis la version 2.3, les changements se concentre principalement sur la vitesse, les prototypes sont souvent suffisamment rapide pour ètre le produit final. Et si ce n'est pas le cas, il y a JRuby(la version Java de Ruby) et Crystal qui produit du code presqu'aussi rapide que C++. Et garde à l'esprit que ce n'est mème pas la version 1.0 . Ruby a été penser pas son inventeur comme un outil pour que le programmeur puisse concentré sur son programme plutôt que la façon de l'écrire pour pouvoir le réaliser.

Ruby a également une librairie très solides pour les calculs scientifiques Narray (https://fr.slideshare.net/igrigorik/...l_Ndimensional). Ruby n'a pas besoin de toute ces librairies dès le démarrage, ce qui fais qu'il est relativement facilité de faire de l'auto-programmation et d'inventer des objets pendant l'exécution du programme. En Ruby, tout est indéfinissable, même la classe Class( très commode pour déboguer). Tout les classes sans exception peuvent être étendue. Ou on peut étendre juste un objet spécifiquement. Même Smalltalk ne permet pas ce genre de chose. Ruby poussé les limites de la programmation-objet comme aucun autre langage. Certaines chose peuvent être faite en Ruby qui ne peuvent pas être fait dans d'autre langage.

Je peux faire du code et le protéger en le compilant et avoir une application qui est 400% fois la vitesse de la version compilé de Python. À l'heure actuel, Il ne manque que quelque interface pour certaine bases de donnée. Mais cela devrait arrivé assez vite, puisqu'il ne faut adapté du code existant.

Bref tu faire de la programmation dans tous les secteur et pas seulement pour du web. Mais "juste le web" est plus payant que faire du jeux pour EA ou des applis pour MS. Mais bon, les idiots annoncent la disparition de Ruby depuis dix ans et la demande augmente à chaque année. Et ils sont démentis à chaque année.

Donc au bout du compte, c'est l'apprentissage de Python qui est du temps perdue. Et c'est se tirer des balles dans les deux pieds.

[Madmac]

+1 j'aurais pas dit mieux...
Ah si j'en rajoute une couche, python est intégré à de nombreux programme comme blender 3D ou C4D et bientôt peut etre carrément dans la suite MS office (pour remplacer VB)

Et Ruby est utilisé dans Sketchup et dans SASS, SCSS, LESS ..

En Python, tu ne peux que faire des programmes qui fonctionne qu'en anglais. En Ruby, tu peux écrire pour presque toute la planète. Et la plupart des jeux de rôle japonais sont fait en Ruby. Et Ruby est très populaire en Asie pour l'apprentissage de la programmation. Les sondages sur les langages ne couvrent ordinairement que le marché anglophone. Alors ils faut les prendre pour ce qu'ils sont: Des sondage que sur le marché anglophone!

[Invité]

Impressionnant. Ruby sait faire trop tout. D'ailleurs, j'ai crevé un pneu sur ma bagnole. Tu peux me le réparer avec Ruby, stp ?

[Madmac]

Impressionnant. Ruby sait faire trop tout. D'ailleurs, j'ai crevé un pneu sur ma bagnole. Tu peux me le réparer avec Ruby, stp ?

Si ton robot comprend le Ruby... Mais c'est drôle, personnes ne semble remarquer que le PHP ne peut faire que du web. Et il n'y a pas beaucoup d'applis en JavaScript, non plus! J'imagine qu'ils sont mourrants, ces 2 là !

Sérieusement dire que Ruby n'est que pour le web est une preuve d'ignorance de la situation véritable du langage. Ce langage est devenu populaire prématurément. Les optimisations du garbage collecteur n'était même pas faite. Et les gens sont resté sur cette impression du langage. Mais dès le début, c’était un langage qui permettait de faire du script ou des applis complexes. J'ai fait du Python et du PHP, et je sais à quelle point, c'est difficile de devoir trouvé des informations quand tu veux faire en sorte que ton application supporte le français et l'espagnol pour le marché mexicain. Ne pas avoir de regex qui supporte du unicode est un vrai casse-tête. On peut écrire en Ruby, ce que tu peut faire en Perl, en PHP, en Python. Mais en moins de temps, parce que Ruby écrit les accesseurs à la place du programmeur. En Ruby, je passe pas mon temps à écrire des "getters et putter" ( ex: putvalue, getvalue)

Tant qu'à travailler sur quelque chose, je préfère la version originale: Laravel et Symphonie, sont de mauvaises copies de Rails. Et la quantité de programmeurs qui travaille sur ces programmes est négligeable en comparaison du support de Rails. Et avoir une locomotive comme Rails fait que les base de données populaires et les librairies pour les base de donnée sont solide comme du roc.

Moi avec Ruby et C++, je peux tout faire.

[Pyramidev]

C et C++ était sur respirateur artificiel, dans le coeur de beaucoup de programmeurs, depuis un bon bout de temps. Produire du code sans fuite de mémoire demande beaucoup de discipline.

En langage C, en général, c'est celui qui alloue la mémoire qui a la charge de la désallouer. Une telle conception réduit fortement les chances d'oublier d'appeler un free.
En C++, écrire du code sans fuite de mémoire est facile si on utilise des types comme std::unique_ptr qui libèrent automatiquement la mémoire quand ils sont détruits au lieu d'utiliser des pointeurs nus sur lesquels il faut penser à appeler delete ou delete[]. Quand des développeurs C++ écrivent plein de fuites de mémoire, cela ne vient pas seulement d'un manque de rigueur, mais aussi d'un problème d'enseignement.
En C et en C++, ce qui demande vraiment de la rigueur par rapport aux langages qui ont un ramasse-miettes, c'est d'éviter d'accéder par mégarde à une donnée qui a été détruite. On peut parfois éviter ce problème en remplaçant la sémantique de référence par une sémantique de valeur, mais cela se fait alors généralement au détriment des performances (même quand on utilise le Copy On Write).

[Invité]

Quand des développeurs C++ écrivent plein de fuites de mémoire, cela ne vient pas seulement d'un manque de rigueur, mais aussi d'un problème d'enseignement.

C'est clair, je me demande bien ce qu'ils foutent ces flemmards d'enseignants. C'est quand même pas compliqué d'enseigner le delete, le delete [], le unique_ptr, le RAII, la move semantic, l'héritage multiple de classe (virtuel ou pas, évidemment), le polymorphisme, les templates, les templates variadiques, les constexpr...

[Invité]

...

Dire que le code Python pique les yeux il faut quand même être sacrément gonflé tellement c'est simple et facile à lire. De même dire que quand tu fais tu SCSS tu fais du Ruby c'est complètement faux, quand tu fais du SCSS tu fais du SCSS et tu en as rien a foutre du Ruby. Il existe d'ailleurs des implémentations de SCSS qui ne sont pas écrites en Ruby. Idem pour CoffeeScript (qui au passage n'est pas exactement en vogue), tu fais du CoffeeScript pas du Ruby, de la même façon que quand tu fais du Python tu ne fais pas du C.

De toutes façons ton post est typique du fanboyisme aveugle et rempli de bêtises du type python ne supporte pas UTF-8 nativement ou le concept de Mixin n'existe pas. Dans l’hypothèse ou tu déciderais de brancher ton cerveau, je t'invite a utiliser ton moteur de recherche favori et te renseigner sur l'état de Python.

Au final je ne dis pas que Ruby c'est inutile ou nul, je dis que c'est en perte de vitesse et que le domaine ou c'était le plus utilisé (le web avec rails) est rattrapé qualitativement par Python + Django/Flask, PHP + Laravel/Symfony, voir même l’écosystème Node.JS, et est moins demandé (pour ne pas dire presque plus). Vas sur n'importe quel portail de recherche d'emploi si tu ne me crois pas et vérifie par toi même.

[_Bérenger_]

Tu peux remplacer Bash par Ruby sur les Linux et Unix.

Je me pose réellement la question par rapport à ça. J'ai déjà entendu plusieurs fois: "on peut remplacer bash par python/perl/ruby", mais je n'ai jamais trouvé une manière de faire qui soit aussi simple qu'en bash. La majeure partie du temps, je me retrouve à faire des appels système du type:

Code :

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

1
2
from subprocess import call
call(["ls", "-l"])

ce qui est objectivement pire que

Code :

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

ls -l

Et je n'ai pas l'impression que ce soit bien différent en Ruby. En gros, il n'y a pas de shell ruby/python/perl au sens de shell bash (il y a eu des essais mais ce n'était pas bien concluant).

C'est clair, je me demande bien ce qu'ils foutent ces flemmards d'enseignants. C'est quand même pas compliqué d'enseigner le delete, le delete [], le unique_ptr, le RAII, la move semantic, l'héritage multiple de classe (virtuel ou pas, évidemment), le polymorphisme, les templates, les templates variadiques, les constexpr...

Le problème, c'est qu'au lieu d'enseigner la seule technique de gestion des ressources essentielle (RAII), ils vont t'enseigner tout le reste: delete, delete[], unique_ptr, shared_ptr. Un enseignant qui connait bien le C++ devrait savoir que parmi la liste que tu donnes, il n'y a en réalité que le RAII et les templates niveau basique (faire un conteneur d'un type générique T) qu'il soit réellement nécessaire d'enseigner aux débutants. Le reste est utile dans certains cas particuliers (uniquement librairie bas niveau dans le cas de delete et delete[], librairie de métaprogrammation dans le cas des templates variadiques, extrêmement rare dans le cas de l'héritage virtuel), mais ne doit certainement pas être enseigné dans l'absolu, sans cas concret d'utilisation derrière.

Dire que le code Python pique les yeux il faut quand même être sacrément gonflé tellement c'est simple et facile à lire.

Oui et non. Le langage de programmation ne peut pas grand-chose à lui tout seul pour la lisibilité du code, c'est avant tout la responsabilité du programmeur. Il y a du code qui pique les yeux en Python, en Ruby, et en n'importe quoi. Parfois, j'ai l'impression qu'il y a une sorte de mauvaise foi chez les programmeurs python avec l'argument: "on comprend facilement ligne à ligne": oui, mais le problème c'est qu'on ne comprend rien dans la globalité .

[wolinn]

...
C et C++ était sur respirateur artificiel, dans le coeur de beaucoup de programmeurs, depuis un bon bout de temps. Produire du code sans fuite de mémoire demande beaucoup de discipline. Plusieurs tentatives pour les substituer avait été fait sans succès (Langage D, C Objective). Mais ce n'est plus le cas, Ruby a donné naissance à un autre langage de programmation qui met la machine au service du programmeur: Crystal.
...

Il est clair que C et C++ ne sont pas des langages de débutants. Et il y a même un certain nombre de programmeurs qui n'atteindront jamais la rigueur requise pour écrire des logiciels robustes dans ces langages. D'où le grand développement des langages qui gèrent tout cela automatiquement, avec des ramasse-miettes par exemple, qui ont du succès dans les domaines où la productivité de codage est plus importante que tirer les performances maximales de la machine.
Mais si on y tient vraiment, on peut aussi implémenter des ramasse-miettes généralistes en C++, et faire du comptage de références, ça peut être utile dans certains domaines. Mais quand ça ne l'est pas et que c'est même potentiellement pénalisant, on est bien content d'être libre de s'en passer.

[zecreator]

En fait, derrière la question posée dans cet article, se pose une autre question :

Le C/C++ permet-il de trouver plus facilement un job de dev que d'autres langages de programmation ? Est-ce une carte de visite qui peut durer dans le temps ?

[Jamatronic]

C'est clair, je me demande bien ce qu'ils foutent ces flemmards d'enseignants. C'est quand même pas compliqué d'enseigner le delete, le delete [], le unique_ptr, le RAII, la move semantic, l'héritage multiple de classe (virtuel ou pas, évidemment), le polymorphisme, les templates, les templates variadiques, les constexpr...

Pensez-vous que les étudiants suivent systématiquement tout ce que nous leur recommandons, tout le temps ?

[zecreator]

C'est clair, je me demande bien ce qu'ils foutent ces flemmards d'enseignants. C'est quand même pas compliqué d'enseigner le delete, le delete [], le unique_ptr, le RAII, la move semantic, l'héritage multiple de classe (virtuel ou pas, évidemment), le polymorphisme, les templates, les templates variadiques, les constexpr...

Ton commentaire peut se transposer sur n'importe quel type d'école. Il y a l'enseignement, et ce qu'en font les élèves une fois dehors. Regarde la politique, l'ENA est sans doute l'école la plus pointue et la plus exigeante en terme de respect des procédures et de l'éthique. Et regarde nos politiques ? Est-ce réellement les profs qui ont fait ce qu'ils sont... Je ne pense pas.

En informatique, y a tout de même un problème majeur, ça évolue trop vite. Du coup les besoins se définissent mal. Certaine formation sont larguées et ne savent plus si leurs cours sont encore utiles. Ce qui est vrai aujourd'hui à l'école, risque de ne plus être vrai une fois dehors. Y a pas d'inertie, le changement est radical. Une techno hyper tendance hier, et aujourd'hui plus personne en veut. Flash par exemple, le nombre de Flashers qui se sont retrouvés sur le carreau, avec pourtant une excellente formation en école.

[marc.collin]

Si ton robot comprend le Ruby... Mais c'est drôle, personnes ne semble remarquer que le PHP ne peut faire que du web

faux, fais une simple recherche sur le web... tu peux faire des applications de bureau avec gtk