> Ça dépends, tu as deux générations du binding Java-Gnome, la branche 2.x et la branche 4.x.
Je ne connais pas Java-gnome...
Quand je parlais d'une bonne API, je pensais surtout à Gtk2 (avec glib, cairo, etc).
> c'est même avec Gtkmm, un des bindings les plus réussis de l'API Gtk+ &cie
En passant, j'ai passé du temps sur Gtkmm, j'ai adoré. Et pourtant j'étais un adèpte de Qt pour coder en C++. Mais Gtkmm c'est du bon et très élégant (d'un point de vu codeur C++).
> Contrairement à QtJambi, Java-Gnome peine à sortir de l'anonymat, pas de buzz, pas ou peu d'applications (à l'exception de Frysk qui utilise les vieux bindings, je n'en connais pas).
On peut dire plus largement que Java ne fait pas un carton dans la communauté. Très utilisé par les entreprises, très peu par la communauté.
C'est vraiment dommage.
> Ce qui a popularisé Gtkmm et PyGtk auprès des développeurs, c'est la documentation associée, les distributions binaires pour les plateformes non libres, les bindings des APIs complémentaires etc ... Après avoir gouté à une API de qualité sur un OS propriétaire, ils sont plus enclins à utiliser un OS libre (ou presque libre) ou du moins à supporter les systèmes libres.
Je ne crois pas. Sûr on peut dire qu'il manque le binding pour bidule, qu'il n'y a pas de port pour machin, etc.
Le coeur de problème, à mon avis, est que Java n'est pas perçu comme un language pour les applis graphiques/desktop.
Voir par exemple http://java-gnome.sourceforge.net/4.0/ qui ne peut s'empêcher de faire un référence au web :
We believe that while the web is ideal for offering services, only carefully tailored desktop applications can provide a truly rich user experience that is both responsive and usable.
Aujourd'hui Java est un language quasi idéal pour le libre. Mais l'historique de Java dans le libre est assez mauvais (la java trap, gcj pas très satisfaisant, etc). Java a créé de nombreuses frustrations.
Tous les projets complexes ont besoin d'être supportés par une entreprise. Red Hat, Sun, IBM pour Java restent concentré sur les serveurs.
On peut aussi s'amuser à comparer avec Mono. Hors l'aspect brevet/FUD/MS, Mono n'a pas créé de frustration et Novell a (aussi) cblé de suite le desktop. Il y avait une dynamique dans Mono que Java n'a jamais eu dans le libre (Sun y avait la main mise, c'était proprio, etc).
Le problème est surtout là. A mon avis les raisons que tu avances ne sont que des conséquences. Avis subjectif.
[^] # Re: Utilité de QtJambi
Posté par IsNotGood . En réponse au journal Qt Jambi abandonné pat Qt Software. Évalué à 5.
Je ne connais pas Java-gnome...
Quand je parlais d'une bonne API, je pensais surtout à Gtk2 (avec glib, cairo, etc).
> c'est même avec Gtkmm, un des bindings les plus réussis de l'API Gtk+ &cie
En passant, j'ai passé du temps sur Gtkmm, j'ai adoré. Et pourtant j'étais un adèpte de Qt pour coder en C++. Mais Gtkmm c'est du bon et très élégant (d'un point de vu codeur C++).
> Contrairement à QtJambi, Java-Gnome peine à sortir de l'anonymat, pas de buzz, pas ou peu d'applications (à l'exception de Frysk qui utilise les vieux bindings, je n'en connais pas).
On peut dire plus largement que Java ne fait pas un carton dans la communauté. Très utilisé par les entreprises, très peu par la communauté.
C'est vraiment dommage.
> Ce qui a popularisé Gtkmm et PyGtk auprès des développeurs, c'est la documentation associée, les distributions binaires pour les plateformes non libres, les bindings des APIs complémentaires etc ... Après avoir gouté à une API de qualité sur un OS propriétaire, ils sont plus enclins à utiliser un OS libre (ou presque libre) ou du moins à supporter les systèmes libres.
Je ne crois pas. Sûr on peut dire qu'il manque le binding pour bidule, qu'il n'y a pas de port pour machin, etc.
Le coeur de problème, à mon avis, est que Java n'est pas perçu comme un language pour les applis graphiques/desktop.
Voir par exemple http://java-gnome.sourceforge.net/4.0/ qui ne peut s'empêcher de faire un référence au web :
We believe that while the web is ideal for offering services, only carefully tailored desktop applications can provide a truly rich user experience that is both responsive and usable.
Aujourd'hui Java est un language quasi idéal pour le libre. Mais l'historique de Java dans le libre est assez mauvais (la java trap, gcj pas très satisfaisant, etc). Java a créé de nombreuses frustrations.
Tous les projets complexes ont besoin d'être supportés par une entreprise. Red Hat, Sun, IBM pour Java restent concentré sur les serveurs.
On peut aussi s'amuser à comparer avec Mono. Hors l'aspect brevet/FUD/MS, Mono n'a pas créé de frustration et Novell a (aussi) cblé de suite le desktop. Il y avait une dynamique dans Mono que Java n'a jamais eu dans le libre (Sun y avait la main mise, c'était proprio, etc).
Le problème est surtout là. A mon avis les raisons que tu avances ne sont que des conséquences. Avis subjectif.