Parce que certaines personnes (dont je ne fais pas partie) ne veulent pas installer Mono pour diverses raisons, parce que Monodevelop s*cks, pour le plaisir, etc ...
Autant demander pourquoi Vala alors qu'il existe déjà C#/Mono.
> la plupart des applis Linux vont être très difficiles à porter vu la forte incompatibilité entre les deux libc.
Je vois de quoi tu parles mais l'incompatibilité entre la GNU libc et bionic est principalement du à une divergences d'intérêt, pas à un problème lié aux standards. D'un côté, GNU libc cherche à être le plus complet possible, de l'autre bionic cherche à être le plus compact possible, rajoute les extensions propres à chacune des implémentations, au final, il y a quelques soucis d'intéropérabilité.
Mais ça, tu retrouves ce problème avec les autres libc dédié à l'embarqué, pas seulement avec bionic. Je te renvoie à un excellent papier des mainteneurs d'uClibc qui explique assez bien le problème. http://www.uclibc.org/downloads/Glibc_vs_uClibc_Differences.(...)
PS: Les allusions à Ubuntu, c'était complétement gratuit, vu que Vendredi, c'est permis /o\
> Marrant parce que justement le dévelopement est complètement ouvert : bug tracker, mailing-list, Developers Summit ouverts à tous.
http://source.android.com/
ça correspond à tes critères ? Mais, on parlait pas de çà, tu te plaignais que les développeurs externes n'avaient pas voix au chapitre mais je ne crois pas que la parole d'un développeur externe ait plus de poids face à Canonical dans Ubuntu que face à Google dans Android. Mais bon, ce n'est pas le coeur du problème.
> certains membres de l'OpenHandset Alliance ne voulaient pas de GStreamer car il est sous LGPL et c'est mal
Certes, je te l'accorde, l'OHA veut limiter la présence de composants (L)GPL dans les bibliothèques systèmes pour des raisons évidentes: Android est destiné au marché de la téléphonie mobile qui est encore très "privateur". Néanmoins, il y a des précédents (WebKit, Bluez, D-Bus, etc ...), ils n'ont pas encore fermé la porte aux composants LGPL.
Quant à dire qu'Android c'est des maichans parce qu'ils sont "privateur"-friendly, c'est du même niveau que de dire que "la licence BSD sapu, ça permet de faire du logiciel privateur".
> mais uniquement dans un Java compatible Dalvik alors. D'ailleurs, nous faisons attention de ne jamais dire "Java" car nous ne sommes pas vraiment compatibles Java.
Au niveau du langage lui-même, il n'y a rien à apprendre, c'est du Java classique, le subset du classpath Java/J2ME supporté est entièrement compatible.
Google avait 2 possibilités: fournir une JVM classique (complétement inadapté à l'embarqué) ou le très limité J2ME ! Se fonder sur le fait qu'ils utilisent leur propre VM (pour des raisons de performances avant tout), et qu'ils n'utilisent pas la marque Java (qui nécessite d'implémenter TOUT Java ce qui n'est pas forcément pertinent), ne signifie pas qu'il faut tout réapprendre. http://www.betaversion.org/~stefano/linotype/news/110/
> Tu ne peux utiliser que Skia, notre nouvelle librairie graphique qui est et restera la seule libraire graphique disponible
Ton logiciel ne tourne plus sur une machine de bureau surpuissante mais sur un téléphone limité en terme de puissance de calculs, d'autonomie etc ...
> Dbus tourne sur la machine mais tu ne peux pas t'y connecter
Euh si, tu peux t'y connecter mais c'est mal foutu faut passer par du code natif ou par les utilitaires en ligne de commande.
> mais je peux porter facilement mon appli Linux quand même ?
Je vais encore le répèter c'est de l'embarqué, tu n'as pas les mêmes contraintes.
Même le portage d'une bête application Gtk+ sur ton fameux N770 n'est pas instantané du fait que Nokia a du forké Gtk+ pour ses besoins. Question subsidiaire, pourquoi Nokia n'a-t-il pas intégré la fonction téléphonie sur ses tablettes internet ? Peut-être parce que c'est une fonction particulièrement énergivore, et qu'il aurait fallu soit inventer des batteries plus puissantes sans que tu ais besoin de faire de la musculation pour porter ton N770, soit optimiser la partie logicielle.
> Et bien non car nous n'utilisons pas la libc standard car elle est sous GPL et c'est un cancer, du coup nous utilisons la librairie Bionic qui est incompatible
1. la GNU libc n'est pas la libc standard mais une implémentation de la libc parmi d'autres.
2. tu n'es pas demandé si l'utilisation de la GNU libc n'était peut-être pas pertinente en environnement embarqué ? Ce n'est pas un reproche, la GNU libc est destiné à des machines de bureau et cherche avant tout à être la plus complète possible.
En embarqué, on lui préfère souvent uClibc, dietlibc, newlib voire une libc maison pour de bonnes raisons: facilité de portage, modularité (je n'active que ce dont j'ai besoin), empreinte mémoire plus faible, etc ....
3. incompatible en quoi ? ça implémente les standards Posix, moins les trucs qui leur sont inutiles comme beaucoup de libc en embarqué, ouh la la, c'est des maichans chez Google.
> Fournit comme un bon gros tar.gz très très difficilement exploitable : on respecte la licence à la lettre, pas à l'esprit. Le truc c'est qu'en rendant un fork très très coûteux à maintenir, on arrive à créer une situation quasi-propriétaire en utilisant des logiciels libres
Les sources fournies par Google sont aisément exploitables, il y a un port pour le Neo Freerunner qui avance bien. En gros, ça consiste à porter Android d'ARMV5 (sa plateforme d'origine) à ARMv4T, rien de bien méchant. Le fork n'est pas coûteux à maintenir, puisque les changements sont incorporé en upstream.
Le kit de développement c'est un scratchbox tout ce qu'il y a de plus normal, tu peux modifier ton image comme tu veux, tu peux la recompiler, l'installer sur ton téléphone. Il y a même eu un article dans le GLMF de Janvier à ce sujet. http://wiki.openmoko.org/wiki/Android
> Iphone = mal et android = bien : la différence entre les deux est très très fine et subtile.
Je suis plutôt d'accord sur ce point. Certes la plateforme logicielle Android est libre et permet techniquement d'avoir un téléphone 100% libre. Néanmoins, c'est oublier que le constructeur du téléphone peut tout à fait fermer la plateforme et là c'est nettement moins drôle.
Ma principale critique vis à vis de l'iPhone en dehors de la nature privatrice de l'environnement logiciel, c'est l'enfermement carcéral auquel est soumis le développeur et l'utilisateur. Si je veux développer une application iPhone, je suis obligé d'utiliser la chaine de compilation d'Apple, je suis obligé d'avoir une licence de développement, je suis obligé de passer par l'AppStore pour partager mon appli etc ... Et ça, c'est tout sauf libre-friendly.
> un projet "pseudo-libre" où les développeurs extérieurs n'ont pas voix au chapitre
Tiens, ça me rappelle bizarrement une certaine distribution avec un fond d'écran marron.
Blague à part, les sources sont libres donc si la gestion d'Android par Google ne te plait, paie ton fork !
> imposition d'un pseudo-Java avec une API très limitée
Android est destiné au marché des téléphones mobiles qui extrêmement fragmenté au niveau des architectures matérielles. Écrire une application native pour un seul mobile, c'est pas rentable, les gammes changent très vite (et le hardware associé également !), supporter plein de mobiles, ça demande pas mal de ressources. Si J2ME a la cote auprès des développeurs d'applications pour téléphones mobiles c'est pas pour des prunes.
Le choix de Java/Dalvik est un "smart move" de la part de Google, les développeurs peuvent écrire des applications portables sur toutes les plateformes supportés par Android, ils ont des APIs de haut niveau avec des outils de développement plus que potables, avec une VM performante.
Certes, l'API est encore trop limité à mon goût, mais ça l'est nettement moins que J2ME.
Certes, mais c'est pas un peu contre-productif pour une société d'affecter des ressources à un projet puis de le laisser végéter une fois fini ?
Qt Software en tant que société avait deux possibilités, soit le mettre en avant, soit arrêter les frais. Ils ont choisi la 2ème option parce que Jambi ne faisait plus partie de leur stratégie, c'est un choix raisonné et logique que je comprends parfaitement. Je ne suis pas complétement débile, non plus.
> comme pour mon commentaires sur les bindings mono peut être que l'équipe Qt a d'autre priorités?
Je ne critique pas Qt Software sur sa décision d'abandonner Jambi, je dis juste que l'échec de Jambi leur est en partie imputable par manque de visibilité.
Il était très peu mis en avant sur le site, très peu de moyens ont été mis en oeuvre pour le faire connaitre au plus grand nombre. C'est juste un peu trop facile de dire simplement "Jambi n'intéresse personne parce que y a Swing/SWT etc ..." pour justifier cet abandon.
Comme tu l'a souligné, la véritable de raison, c'est un recentrage des priorités de Qt Software pour faire de Qt un framework encore plus complet, encore plus multiplateforme, encore plus versatile (notamment dans le domaine de l'embarqué), avec des outils encore plus performants. Et je ne m'en plains pas, loin de là !
> C'est aussi ça l'opensource.
Ai-je dis le contraire ?
Si tu avais lu mes commentaires dans le journal sur l'abandon de Qt Jambi, tu aurais vu que c'est exactement ce que j'ai dis modulo la forme.
Personne n'a dit que l'écriture d'un binding était simple, loin de là.
Mais la simplicité du langage C facilite pas mal les choses pour la génération des bindings au niveau technique. De fait, le C est la lingua franca de l'informatique.
Le C++ étant un langage nettement plus complexe, c'est un peu plus délicat, le débogage est plus difficile (essaie de déboguer un module Python développé en C ou avec Boost.Python, tu m'en diras des nouvelles). Effectivement, si tu fais ton binding à la main, mieux vaut que le langage source soit en C qu'en C++.
Mais le point que tout le monde semble oublier dans cette enfilade, c'est que des frameworks tels que Qt et Gtk+ possèdent un modèle objet bien établie, imposent des conventions de code qui permettent de générer automatiquement des bindings sans trop de gruikage.
La totalité des bindings de Qt et Gtk+ sont automatiquement générés à partir du sources que ce soit PyQt avec SIP, QtJambi avec son générateur, PyGtk avec codegen, Gtkmm avec gmmproc etc ...
Une fois, l'obstacle technique du langage source dépassé, la très grande partie du boulot c'est surtout du peaufinage, rendre les APIs plus agréables et mieux intégrés au langage cible.
Bref, cette discussion c'est de la sodomisation de mouches.
> Laquelle des 4 libertés prétendues fondamentales n'est pas réspectée ?
Toutes potentiellement. La licence commerciale de PyQt est modelé sur celle de Qt [1]
* Liberté d'exécuter le programme.
==> Cf plus bas, royalties
* Liberté d'étudier le fonctionnement du programme
==> certains bouts de la version commerciale de Qt/PyQt ne sont pas libres notamment ActiveQt. Si tu veux vérifier, lance la démo webbrower.py dans le répertoire ActiveQt et lis le message qui s'affiche.
* Liberté de redistribuer des copies
==> Ce n'est pas systèmatique mais dans certains cas, Qt Software peut demander des royalties pour l'installation de runtime. C'est surtout destiné à l'embarqué mais ça peut également s'appliquer à la version standard de Qt dans certains cas.
* Liberté d'améliorer le programme et de publier ces améliorations.
==> la licence commerciale de Qt t'interdit de publier le source de ton application. No source code must be disclosed
> Combien de temps il faudra encore pour avoir un compilateur C++ correcte ?
Attention à ne pas confondre LLVM (#backend de GCC) avec Clang (#frontend de GCC).
Si tu utilises le frontend par défaut basé sur GCC, t'as à peu de choses près un support du C++ équivalent à celui de GCC 4.2 [1], tu peux déjà compiler avec llvm (lui-même écrit en C++), Mozilla, Qt, etc ...
Quant à Clang, il reste énormément de boulot à faire au niveau du support du C++ [2], mais il apporte pas mal de fonctionnalités intéressantes en plus de celle apportés par LLVM lui-même, il s'intégre plus facilement aux environnements de développement (refactoring, IDE, outils d'analyse de sources [3], warnings plus explicites et détaillés etc ...).
Du reste, c'est un excellentissime compilateur C, Objective-C.
> Tout n'est pas aussi rose que ça même avec une architecture propre (pour le moment).
Tu fais très bien de le rappeller, même si LLVM est un projet prometteur, GCC a encore de beaux jours devant lui.
Oui, tant que l'ensemble est licencié sous une licence compatible avec la GPL, ce qui est le cas de la licence BSD? c'est OK.
Là, où ça se corse, c'est si tu incorpore ton code BSD dans un ensemble sous une licence privatrice ou incompatible avec la GPL (ce que te permet la licence BSD), là, tu es obligé d'acheter une licence commerciale de PyQt.
Tu n'as pas le droit de faire tourner une application GPL avec la version privatrice de PyQt à moins de rajouter une clause d'exception de liens avec des bibliothèques non-libres.
Donc en résumé:
* les sources peuvent rester sous licence BSD.
* si je lie mon application avec la version GPL de PyQt, l'ensemble passe sous GPL.
* si je lie mon application avec la version privatrice, je fais comme je veux sauf à utiliser la licence GPL nue.
> Je ne sais pas si Apple utilise LLVM pour OpenCL.
On en avait déjà parlé dans la news sur la sortie d'OpenCL 1.0 [1].
La réponse courte est oui. Pour les détails techniques, Apple dans sa culture du secret (à la con), n'a pas révélé grand chose. Tout ce que l'on sait, c'est qu'une implémentation d'OpenCL dans GCC, c'est pas pour demain [2], mais que l'implémentation d'Apple est très similaire à celle de la pile OpenGL dans OS X [3].
> On pourrait aussi imaginer d'utiliser LLVM pour améliorer les perfos des langages comme Python, Perl, ou php.
Il y a le projet VMKit [4]qui cherche à implémenter la JVM et la CLR au-dessus de LLVM, et PyPy s'intéresse également à LLVM [5].
>J'ajouterai que le socle technique de .NET/Mono normalisé ISO propose une méthode pour écrire des bindings bien plus portable qu'en Java par exemple.
Faut le reconnaitre, Timaniac marque un point.
Invoquer du code natif en Mono avec P/Invoke c'est nettement plus simple que de passer par la JNI. D'ailleurs, la communauté Java a fini par pondre JNA (Java Native Access) qui s'inspire ouvertement des P/Invoke mais également ctypes (Python).
Hein, si tu devais développer une application Windows avec les MFC, ce n'est pas 350€ et des poussières qu'il te faudrait débourser.
Avant la LGPL-isation de Qt 4.5, pour développer un logiciel privateur en PyQt, il fallait débourser le prix de la licence Qt (entre 2000€ et 3000€/développeur) et de la licence PyQt. C'était réellement un frein à la progression de PyQt en entreprise, là, ça l'est beaucoup moins.
Pour le moment, rien n'est décidé l'unique mainteneur évalue les options qui s'offrent à lui
Hein, n'oublions que RiverBank n'a pas la solidité financière de Nokia et qu'il faut bien payer les factures à la fin du mois. Ce serait un poil ingrat d'exiger de Phil Thompson de relicencier PyQt sans certitude que son énorme travail soit rétribué à sa juste valeur.
L'idéal serait que Qt Software décide de sponsoriser PyQt mais on n'aura très probablement la réponse qu'à la sortie de PyQt 4.5
Qt ne gère effectivement pas le port série (encore moins le parrallèle) mais il existe une classe (C++) relativement mature et bien testée qui le fait: http://qextserialport.sourceforge.net/
Tu parles probablement du dernier HS électronique de GLMF
Si tu écris ton application en Python, ce sera plus simple d'utiliser PySerial. Je ne connais pas l'équivalent Ruby, mais j'ai déjà utiliser PySerial avec succès sur GNU/Linux, MacOS X, Windows
Quant au binding Qt Ruby, tout ce que je sais c'est qu'il est généré à l'aide de smoke et dépends donc des kdelibs.
Ton lien date un peu (relatif à Qt 3.3), voilà le bon lien http://doc.trolltech.com/4.5/activeqt-dotnet.html
En gros, si tu veux utiliser Qt en .Net, soit tu utilises les outils associés à C++/CLI (pas standard, pas supporté par Mono), soit tu utilises ActiveQt (en gros, tu passes par COM) qui sapusaipalibre.
Quel est le rapport ? TurboGears 2 aka TG2 est fondé sur Pylons ! [1]
Comme l'a bien souligné l'auteur de la dépêche, Pylons insiste sur 2 points: la réutilisation des composants déjà existants et la conformité aux "standards" pythonniques tel que WSGI.
Il avait été envisagé de fusionner les deux frameworks mais cela ne s'est pas fait à cause de "priorités différentes mais compatibles".
Contrairement à Pylons qui se veut un framework minimaliste et agnostique au niveau des composants (ORM, moteur de templates, etc ...), TG cherche à offrir un environnement de développement web complète avec une base commune à tous.
TG2 se veut complétement compatible avec Pylons, pas de code dupliqué, l'outil en ligne de commande tg-admin a été remplacé par Paster, respect des conventions de Pylons etc ... L'avantage pour le développeur TG, c'est que l'on bénéficie automatiquement des avantages de Pylons (débogueur interactif, Shell intégré, support de WSGI, le composant Routes pour avoir de jolies url etc ...), sans pour autant réapprendre tout un framework.
Pour le développeur qui ne connaissait pas TG, TG2 lui offre un environnement Pylons un peu moins brut de décoffrage.
[1] Pour ceux qui ne connaissent pas, Turbogears aka TG est un framework web RoR-like en Python et qui a pour particularité de ne pas réinventer la roue et la possibilité de remplacer les "briques" par défaut. ORM: SQLObject, SQLAlchemy templates: Kid,Genshi , controleur: CherryPy, javascript: MochiKit.
... de cliché éculés et voilà le résultat.
La trame est usée jusqu'à la corde, un mec un peu (beaucoup) paumé devient du jour au lendemain un bogosse (enfin, un ersatz ala Michael Vendetta) puis la princesse charmante qui lui résistait lui tombe dans les bras. Parce que c'est sensé être un film comique, on multiplie les allusions graveleuses, les clichés, on reprends les recettes qui ont marchés ailleurs.
Le cinéma c'est un peu comme la cuisine, il faut savoir doser les ingrédients, marier les saveurs mais là, on verse des sacs dans une bétonneuse en aveugle, espérant que les convives apprécient.
C'est de l'Élie Sémoun, on grossit tellement le trait que ça dépasse le concept d'humour ou même de surréalisme. Le public même averti, ne comprends plus la blague, il est perturbé, il se demande ce qu'il a fait pour mériter ça. Ce qui était bien dans les petites annonces, c'est qu'elles était très courtes, là on a droit à une annonce de plus d'1h30.
Ce qui manque à Élie Sémoun, c'est cette petite touche de poésie qui différence l'humouriste du tonton potache qui sort des vannes lors des dinés familiaux.
Élie sans Dieudonné, c'est un humoriste pas drôle, Dieudonné sans Élie, ça aurait pu être un grand humoriste mais ses dérives fascistes ont tout gâchés.
> GTK ne propose qu'un toolkit GUI... pas de truc pour gérer le réseau, les threads, le xml, le render html etc comme le propose QT...
Gtk+ repose sur la GLib, donc t'as une gestion du réseau, un parseur xml (certes sommaire), des threads et pleins d'autres trucs intégrés. Pour le reste, t'as une multitude d'APIs complémentaire basés sur la GLib qui forme un ensemble cohérent (GStreamer, Webkit-Gtk, libsoup, Clutter, GNet etc ...), l'exception étant libxml.
Tu n'as pas totalement tort en disant que Gtk+ n'est pas l'équivalent de Qt, mais la toolbox du développeur Gtk+ est aussi riche que celle du développeur Qt qui dépuis Qt4 est découpé en modules.
Pour simplifier QtCore # GLib, QtGui #Gtk+, QNetwork # GNet, etc ...
> je suis pas d'accord non plus avec le commentaire d'au-dessus qui préconiserait d'utiliser ces classes QT au lieu de la lib standard.
La JCL traine pas mal de boulets, et je trouve personnellement l'API Qt (ou Gtk+) nettement plus agréable à utiliser. QtJambi a fait des choix plutôt intelligents, par exemple, ils utilisent le type Java.String plutôt que QString, on peut mélanger les classes d'I/O, bref, ça s'intégre plutôt bien dans une application Java standard. C'est loin d'être un binding bête et méchant qui t'impose ses choix fascistes.
Je n'incite pas plus à utiliser QtJambi que la JCL, Java-Gnome, SWT ou autre chose, chacun fait ce qu'il veut, ce n'est pas mon problème.
On a la chance d'avoir le choix entre plusieurs APIs de qualité (et libres), avec chacune des avantages et des inconvénients, donc autant choisir celle qui nous convient le mieux selon nos besoins et nos expériences.
Si je devais préconiser quelque chose, ce serait carrément d'abandonner Java mais on serait hors sujet. ;o)
Ça dépends, tu as deux générations du binding Java-Gnome, la branche 2.x et la branche 4.x.
Si tu me parles de la première génération que fournissent toutes les distributions, elle est non seulement obsolète mais je ne m'avancerais pas à dire que l'API est de qualité.
Andrw Cowie d'Operational Dynamics [1] avait fait une présentation (au Guadec notamment) pour expliquer pourquoi Java-Gnome 2.x était une impasse.
Quant à la seconde génération, c'est clairement mieux foutue (c'est même avec Gtkmm, un des bindings les plus réussis de l'API Gtk+ &cie) mais ça n'avance pas niveau intégration dans les distributions. Si ça t'intéresse, au niveau de Fedora, c'est le ticket 438452.
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).
Si tu ajoutes ça au manque de polish, pas de distributions clés-en-main pour Windows, MacOS X (en dehors de GNU/Linux, Solaris[2], c'est un peu l'inconnu), une doc spartiate comparé à celle fournis par Qt Software (avec des exemples non triviaux), l'absence de bindings des APIs complémentaires (Clutter, Gstreamer [3], etc ...) Java-Gnome va encore avoir du mal à se diffuser malgré toutes ses qualités.
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.
[1] Son blog est une mine d'information sur Java-Gnome http://research.operationaldynamics.com/blogs/andrew/softwar(...)
[2] en même temps, j'en ai rien à battre de Windows.
[3] il y a un binding Gstreamer-Java non officiel mais il ne s'intégre pas vraiment à Java-Gnome.
Ne pas utiliser la Java Class Library ? (Pour moi, ça constitue un avantage énorme)
À la différence de la JCL, Qt4 n'a pas à se soucier d'un historique plutôt encombrant au nom de la compatibilité ascendante. Sans oublier les outils associés (le generator pour générer le code glue, Qt linguist, Qt designer etc ...). Le seul truc qui m'ennuie un peu, c'est l'absence de qmake.
Quant aux développeurs Qt auquels les décideurs pressés ont imposés Java, de retrouver leurs marques rapidement. :o)
L'abandon de Qt Jambi était prévisible dans une certaine mesure: pas de béta de Qt Jambi 4.5, les blogs des employés de Qt Software était relativement silencieux à ce sujet, pas de support de QtJambi dans Qt Creator.
QtJambi c'est une bonne idée mais il y a tellement de chantiers dans Qt entre le développements de nouveaux outils, de nouvelles classes ou modules, les portages qu'il a fallu couper dans certains projets. C'est dommage, car QtJambi venait de commencer à percer auprès des développeurs, mais ce n'est pas critique car le C++ à la sauce Qt c'est quand même bien prémâché et ça n'a pas les inconvénients de Java.
Qt, c'est un peu le meilleur des 2 mondes.
Qyoto/Kimono ce ne sont pas des projets KDE utilisant smoke ?
D'ailleurs, le gros reproche que je puisse faire des bindings utilisant smoke, c'est d'être dépendant des kdelibs (du moins le binding ruby). Peut-être que je me trompe (et vous êtes cordialement invité à le faire si vous avez plus de renseignements), mais la dépendance aux kdelibs, pour un gnomers c'est "no pasaran".
[^] # Re: similitudes
Posté par GeneralZod . En réponse à la dépêche Sortie de Val(a)IDE 0.4. Évalué à 10.
Autant demander pourquoi Vala alors qu'il existe déjà C#/Mono.
[^] # Re: "Tout feedback/idée etc est le bienvenue"
Posté par GeneralZod . En réponse au journal LinuxFr sur iPhone. Évalué à 3.
Je vois de quoi tu parles mais l'incompatibilité entre la GNU libc et bionic est principalement du à une divergences d'intérêt, pas à un problème lié aux standards. D'un côté, GNU libc cherche à être le plus complet possible, de l'autre bionic cherche à être le plus compact possible, rajoute les extensions propres à chacune des implémentations, au final, il y a quelques soucis d'intéropérabilité.
Mais ça, tu retrouves ce problème avec les autres libc dédié à l'embarqué, pas seulement avec bionic. Je te renvoie à un excellent papier des mainteneurs d'uClibc qui explique assez bien le problème.
http://www.uclibc.org/downloads/Glibc_vs_uClibc_Differences.(...)
PS: Les allusions à Ubuntu, c'était complétement gratuit, vu que Vendredi, c'est permis /o\
[^] # Re: "Tout feedback/idée etc est le bienvenue"
Posté par GeneralZod . En réponse au journal LinuxFr sur iPhone. Évalué à 7.
http://source.android.com/
ça correspond à tes critères ? Mais, on parlait pas de çà, tu te plaignais que les développeurs externes n'avaient pas voix au chapitre mais je ne crois pas que la parole d'un développeur externe ait plus de poids face à Canonical dans Ubuntu que face à Google dans Android. Mais bon, ce n'est pas le coeur du problème.
> certains membres de l'OpenHandset Alliance ne voulaient pas de GStreamer car il est sous LGPL et c'est mal
Certes, je te l'accorde, l'OHA veut limiter la présence de composants (L)GPL dans les bibliothèques systèmes pour des raisons évidentes: Android est destiné au marché de la téléphonie mobile qui est encore très "privateur". Néanmoins, il y a des précédents (WebKit, Bluez, D-Bus, etc ...), ils n'ont pas encore fermé la porte aux composants LGPL.
Quant à dire qu'Android c'est des maichans parce qu'ils sont "privateur"-friendly, c'est du même niveau que de dire que "la licence BSD sapu, ça permet de faire du logiciel privateur".
> mais uniquement dans un Java compatible Dalvik alors. D'ailleurs, nous faisons attention de ne jamais dire "Java" car nous ne sommes pas vraiment compatibles Java.
Au niveau du langage lui-même, il n'y a rien à apprendre, c'est du Java classique, le subset du classpath Java/J2ME supporté est entièrement compatible.
Google avait 2 possibilités: fournir une JVM classique (complétement inadapté à l'embarqué) ou le très limité J2ME ! Se fonder sur le fait qu'ils utilisent leur propre VM (pour des raisons de performances avant tout), et qu'ils n'utilisent pas la marque Java (qui nécessite d'implémenter TOUT Java ce qui n'est pas forcément pertinent), ne signifie pas qu'il faut tout réapprendre.
http://www.betaversion.org/~stefano/linotype/news/110/
> Tu ne peux utiliser que Skia, notre nouvelle librairie graphique qui est et restera la seule libraire graphique disponible
Ton logiciel ne tourne plus sur une machine de bureau surpuissante mais sur un téléphone limité en terme de puissance de calculs, d'autonomie etc ...
> Dbus tourne sur la machine mais tu ne peux pas t'y connecter
Euh si, tu peux t'y connecter mais c'est mal foutu faut passer par du code natif ou par les utilitaires en ligne de commande.
> mais je peux porter facilement mon appli Linux quand même ?
Je vais encore le répèter c'est de l'embarqué, tu n'as pas les mêmes contraintes.
Même le portage d'une bête application Gtk+ sur ton fameux N770 n'est pas instantané du fait que Nokia a du forké Gtk+ pour ses besoins. Question subsidiaire, pourquoi Nokia n'a-t-il pas intégré la fonction téléphonie sur ses tablettes internet ? Peut-être parce que c'est une fonction particulièrement énergivore, et qu'il aurait fallu soit inventer des batteries plus puissantes sans que tu ais besoin de faire de la musculation pour porter ton N770, soit optimiser la partie logicielle.
> Et bien non car nous n'utilisons pas la libc standard car elle est sous GPL et c'est un cancer, du coup nous utilisons la librairie Bionic qui est incompatible
1. la GNU libc n'est pas la libc standard mais une implémentation de la libc parmi d'autres.
2. tu n'es pas demandé si l'utilisation de la GNU libc n'était peut-être pas pertinente en environnement embarqué ? Ce n'est pas un reproche, la GNU libc est destiné à des machines de bureau et cherche avant tout à être la plus complète possible.
En embarqué, on lui préfère souvent uClibc, dietlibc, newlib voire une libc maison pour de bonnes raisons: facilité de portage, modularité (je n'active que ce dont j'ai besoin), empreinte mémoire plus faible, etc ....
3. incompatible en quoi ? ça implémente les standards Posix, moins les trucs qui leur sont inutiles comme beaucoup de libc en embarqué, ouh la la, c'est des maichans chez Google.
> Fournit comme un bon gros tar.gz très très difficilement exploitable : on respecte la licence à la lettre, pas à l'esprit. Le truc c'est qu'en rendant un fork très très coûteux à maintenir, on arrive à créer une situation quasi-propriétaire en utilisant des logiciels libres
Les sources fournies par Google sont aisément exploitables, il y a un port pour le Neo Freerunner qui avance bien. En gros, ça consiste à porter Android d'ARMV5 (sa plateforme d'origine) à ARMv4T, rien de bien méchant. Le fork n'est pas coûteux à maintenir, puisque les changements sont incorporé en upstream.
Le kit de développement c'est un scratchbox tout ce qu'il y a de plus normal, tu peux modifier ton image comme tu veux, tu peux la recompiler, l'installer sur ton téléphone. Il y a même eu un article dans le GLMF de Janvier à ce sujet.
http://wiki.openmoko.org/wiki/Android
> Iphone = mal et android = bien : la différence entre les deux est très très fine et subtile.
Je suis plutôt d'accord sur ce point. Certes la plateforme logicielle Android est libre et permet techniquement d'avoir un téléphone 100% libre. Néanmoins, c'est oublier que le constructeur du téléphone peut tout à fait fermer la plateforme et là c'est nettement moins drôle.
Ma principale critique vis à vis de l'iPhone en dehors de la nature privatrice de l'environnement logiciel, c'est l'enfermement carcéral auquel est soumis le développeur et l'utilisateur. Si je veux développer une application iPhone, je suis obligé d'utiliser la chaine de compilation d'Apple, je suis obligé d'avoir une licence de développement, je suis obligé de passer par l'AppStore pour partager mon appli etc ... Et ça, c'est tout sauf libre-friendly.
[^] # Re: "Tout feedback/idée etc est le bienvenue"
Posté par GeneralZod . En réponse au journal LinuxFr sur iPhone. Évalué à 5.
Tiens, ça me rappelle bizarrement une certaine distribution avec un fond d'écran marron.
Blague à part, les sources sont libres donc si la gestion d'Android par Google ne te plait, paie ton fork !
> imposition d'un pseudo-Java avec une API très limitée
Android est destiné au marché des téléphones mobiles qui extrêmement fragmenté au niveau des architectures matérielles. Écrire une application native pour un seul mobile, c'est pas rentable, les gammes changent très vite (et le hardware associé également !), supporter plein de mobiles, ça demande pas mal de ressources. Si J2ME a la cote auprès des développeurs d'applications pour téléphones mobiles c'est pas pour des prunes.
Le choix de Java/Dalvik est un "smart move" de la part de Google, les développeurs peuvent écrire des applications portables sur toutes les plateformes supportés par Android, ils ont des APIs de haut niveau avec des outils de développement plus que potables, avec une VM performante.
Certes, l'API est encore trop limité à mon goût, mais ça l'est nettement moins que J2ME.
[^] # Re: hécatombe ?
Posté par GeneralZod . En réponse au journal Après Jambi, Qtopia ?. Évalué à 2.
Qt Software en tant que société avait deux possibilités, soit le mettre en avant, soit arrêter les frais. Ils ont choisi la 2ème option parce que Jambi ne faisait plus partie de leur stratégie, c'est un choix raisonné et logique que je comprends parfaitement. Je ne suis pas complétement débile, non plus.
[^] # Re: hécatombe ?
Posté par GeneralZod . En réponse au journal Après Jambi, Qtopia ?. Évalué à 2.
Je ne critique pas Qt Software sur sa décision d'abandonner Jambi, je dis juste que l'échec de Jambi leur est en partie imputable par manque de visibilité.
Il était très peu mis en avant sur le site, très peu de moyens ont été mis en oeuvre pour le faire connaitre au plus grand nombre. C'est juste un peu trop facile de dire simplement "Jambi n'intéresse personne parce que y a Swing/SWT etc ..." pour justifier cet abandon.
Comme tu l'a souligné, la véritable de raison, c'est un recentrage des priorités de Qt Software pour faire de Qt un framework encore plus complet, encore plus multiplateforme, encore plus versatile (notamment dans le domaine de l'embarqué), avec des outils encore plus performants. Et je ne m'en plains pas, loin de là !
> C'est aussi ça l'opensource.
Ai-je dis le contraire ?
Si tu avais lu mes commentaires dans le journal sur l'abandon de Qt Jambi, tu aurais vu que c'est exactement ce que j'ai dis modulo la forme.
[^] # Re: hécatombe ?
Posté par GeneralZod . En réponse au journal Après Jambi, Qtopia ?. Évalué à 1.
En même temps, Qt Software n'a pas fait grand chose pour promouvoir QtJambi, hein.
[^] # Re: Qyoto/Kimono
Posté par GeneralZod . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 5.
Mais la simplicité du langage C facilite pas mal les choses pour la génération des bindings au niveau technique. De fait, le C est la lingua franca de l'informatique.
Le C++ étant un langage nettement plus complexe, c'est un peu plus délicat, le débogage est plus difficile (essaie de déboguer un module Python développé en C ou avec Boost.Python, tu m'en diras des nouvelles). Effectivement, si tu fais ton binding à la main, mieux vaut que le langage source soit en C qu'en C++.
Mais le point que tout le monde semble oublier dans cette enfilade, c'est que des frameworks tels que Qt et Gtk+ possèdent un modèle objet bien établie, imposent des conventions de code qui permettent de générer automatiquement des bindings sans trop de gruikage.
La totalité des bindings de Qt et Gtk+ sont automatiquement générés à partir du sources que ce soit PyQt avec SIP, QtJambi avec son générateur, PyGtk avec codegen, Gtkmm avec gmmproc etc ...
Une fois, l'obstacle technique du langage source dépassé, la très grande partie du boulot c'est surtout du peaufinage, rendre les APIs plus agréables et mieux intégrés au langage cible.
Bref, cette discussion c'est de la sodomisation de mouches.
[^] # Re: Qyoto/Kimono
Posté par GeneralZod . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Parce que c'est un projet communautaire ? parce que personne n'est payé pour bosser à temps plein dessus ? C'est pas les bonnes raisons qui manquent.
[^] # Re: PyQt
Posté par GeneralZod . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
[^] # Re: PyQt
Posté par GeneralZod . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Toutes potentiellement. La licence commerciale de PyQt est modelé sur celle de Qt [1]
* Liberté d'exécuter le programme.
==> Cf plus bas, royalties
* Liberté d'étudier le fonctionnement du programme
==> certains bouts de la version commerciale de Qt/PyQt ne sont pas libres notamment ActiveQt. Si tu veux vérifier, lance la démo webbrower.py dans le répertoire ActiveQt et lis le message qui s'affiche.
* Liberté de redistribuer des copies
==> Ce n'est pas systèmatique mais dans certains cas, Qt Software peut demander des royalties pour l'installation de runtime. C'est surtout destiné à l'embarqué mais ça peut également s'appliquer à la version standard de Qt dans certains cas.
* Liberté d'améliorer le programme et de publier ces améliorations.
==> la licence commerciale de Qt t'interdit de publier le source de ton application.
No source code must be disclosed
[1] http://www.qtsoftware.com/products/licensing/licensing#qt-co(...)
[^] # Re: Oui mais...
Posté par GeneralZod . En réponse à la dépêche La version 2.5 du compilateur LLVM est disponible. Évalué à 3.
Attention à ne pas confondre LLVM (#backend de GCC) avec Clang (#frontend de GCC).
Si tu utilises le frontend par défaut basé sur GCC, t'as à peu de choses près un support du C++ équivalent à celui de GCC 4.2 [1], tu peux déjà compiler avec llvm (lui-même écrit en C++), Mozilla, Qt, etc ...
Quant à Clang, il reste énormément de boulot à faire au niveau du support du C++ [2], mais il apporte pas mal de fonctionnalités intéressantes en plus de celle apportés par LLVM lui-même, il s'intégre plus facilement aux environnements de développement (refactoring, IDE, outils d'analyse de sources [3], warnings plus explicites et détaillés etc ...).
Du reste, c'est un excellentissime compilateur C, Objective-C.
> Tout n'est pas aussi rose que ça même avec une architecture propre (pour le moment).
Tu fais très bien de le rappeller, même si LLVM est un projet prometteur, GCC a encore de beaux jours devant lui.
[1] modulo les exceptions qui sont pleinement supportés sur x86 et PowerPC (32/64 bits) seulement depuis llvm2.4 pour Linux et Darwin.
[2] http://clang.llvm.org/cxx_status.html
[3] http://clang.llvm.org/StaticAnalysis.html
C'est certes très jeune, c'est limité à C et Objective-C mais associé à DTrace, le développeur Mac est plutôt gâté.
http://iphonedevelopment.blogspot.com/2009/02/clang-static-a(...)
[^] # Re: PyQt
Posté par GeneralZod . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Là, où ça se corse, c'est si tu incorpore ton code BSD dans un ensemble sous une licence privatrice ou incompatible avec la GPL (ce que te permet la licence BSD), là, tu es obligé d'acheter une licence commerciale de PyQt.
Tu n'as pas le droit de faire tourner une application GPL avec la version privatrice de PyQt à moins de rajouter une clause d'exception de liens avec des bibliothèques non-libres.
Donc en résumé:
* les sources peuvent rester sous licence BSD.
* si je lie mon application avec la version GPL de PyQt, l'ensemble passe sous GPL.
* si je lie mon application avec la version privatrice, je fais comme je veux sauf à utiliser la licence GPL nue.
[^] # Re: Virtual Machine && Gallium3D
Posté par GeneralZod . En réponse à la dépêche La version 2.5 du compilateur LLVM est disponible. Évalué à 8.
On en avait déjà parlé dans la news sur la sortie d'OpenCL 1.0 [1].
La réponse courte est oui. Pour les détails techniques, Apple dans sa culture du secret (à la con), n'a pas révélé grand chose. Tout ce que l'on sait, c'est qu'une implémentation d'OpenCL dans GCC, c'est pas pour demain [2], mais que l'implémentation d'Apple est très similaire à celle de la pile OpenGL dans OS X [3].
> On pourrait aussi imaginer d'utiliser LLVM pour améliorer les perfos des langages comme Python, Perl, ou php.
Il y a le projet VMKit [4]qui cherche à implémenter la JVM et la CLR au-dessus de LLVM, et PyPy s'intéresse également à LLVM [5].
[1] http://linuxfr.org/2008/12/10/24777.html
[2] http://zrusin.blogspot.com/2009/02/opencl.html
[3] http://linuxfr.org/comments/990345,1.html
[4] http://vmkit.llvm.org/
[5] http://codespeak.net/pypy/dist/pypy/doc/jit/backend.html
[^] # Re: Qyoto/Kimono
Posté par GeneralZod . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 4.
Faut le reconnaitre, Timaniac marque un point.
Invoquer du code natif en Mono avec P/Invoke c'est nettement plus simple que de passer par la JNI. D'ailleurs, la communauté Java a fini par pondre JNA (Java Native Access) qui s'inspire ouvertement des P/Invoke mais également ctypes (Python).
Un billet que j'ai lu il y a un moment et qui résume bien pourquoi JNI sapugrave.
http://www.koushikdutta.com/2009/01/jni-in-android-and-forew(...)
[^] # Re: PyQt
Posté par GeneralZod . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Avant la LGPL-isation de Qt 4.5, pour développer un logiciel privateur en PyQt, il fallait débourser le prix de la licence Qt (entre 2000€ et 3000€/développeur) et de la licence PyQt. C'était réellement un frein à la progression de PyQt en entreprise, là, ça l'est beaucoup moins.
Pour le moment, rien n'est décidé l'unique mainteneur évalue les options qui s'offrent à lui
Hein, n'oublions que RiverBank n'a pas la solidité financière de Nokia et qu'il faut bien payer les factures à la fin du mois. Ce serait un poil ingrat d'exiger de Phil Thompson de relicencier PyQt sans certitude que son énorme travail soit rétribué à sa juste valeur.
L'idéal serait que Qt Software décide de sponsoriser PyQt mais on n'aura très probablement la réponse qu'à la sortie de PyQt 4.5
[^] # Re: Python ou Ruby ?
Posté par GeneralZod . En réponse au message Ruby et Qt. Évalué à 2.
Tu parles probablement du dernier HS électronique de GLMF
Si tu écris ton application en Python, ce sera plus simple d'utiliser PySerial. Je ne connais pas l'équivalent Ruby, mais j'ai déjà utiliser PySerial avec succès sur GNU/Linux, MacOS X, Windows
Quant au binding Qt Ruby, tout ce que je sais c'est qu'il est généré à l'aide de smoke et dépends donc des kdelibs.
[^] # Re: Qyoto/Kimono
Posté par GeneralZod . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 3.
http://doc.trolltech.com/4.5/activeqt-dotnet.html
En gros, si tu veux utiliser Qt en .Net, soit tu utilises les outils associés à C++/CLI (pas standard, pas supporté par Mono), soit tu utilises ActiveQt (en gros, tu passes par COM) qui sapusaipalibre.
# Turbogears 2.0 beta6 sorti le 25 février
Posté par GeneralZod . En réponse à la dépêche Python et le web : deux sorties majeures et trois articles Linux Mag. Évalué à 2.
Comme l'a bien souligné l'auteur de la dépêche, Pylons insiste sur 2 points: la réutilisation des composants déjà existants et la conformité aux "standards" pythonniques tel que WSGI.
Il avait été envisagé de fusionner les deux frameworks mais cela ne s'est pas fait à cause de "priorités différentes mais compatibles".
Contrairement à Pylons qui se veut un framework minimaliste et agnostique au niveau des composants (ORM, moteur de templates, etc ...), TG cherche à offrir un environnement de développement web complète avec une base commune à tous.
TG2 se veut complétement compatible avec Pylons, pas de code dupliqué, l'outil en ligne de commande tg-admin a été remplacé par Paster, respect des conventions de Pylons etc ... L'avantage pour le développeur TG, c'est que l'on bénéficie automatiquement des avantages de Pylons (débogueur interactif, Shell intégré, support de WSGI, le composant Routes pour avoir de jolies url etc ...), sans pour autant réapprendre tout un framework.
Pour le développeur qui ne connaissait pas TG, TG2 lui offre un environnement Pylons un peu moins brut de décoffrage.
http://turbogears.org/
http://turbogears.org/2.0/docs/main/WhatsNew.html
[1] Pour ceux qui ne connaissent pas, Turbogears aka TG est un framework web RoR-like en Python et qui a pour particularité de ne pas réinventer la roue et la possibilité de remplacer les "briques" par défaut. ORM: SQLObject, SQLAlchemy templates: Kid,Genshi , controleur: CherryPy, javascript: MochiKit.
[^] # Re: nom de domaine
Posté par GeneralZod . En réponse au journal Vous aimez élie sémoun ?. Évalué à 4.
# Un scénario pour pub Axe recalé, un humoriste pas drôle, saupoudrez .
Posté par GeneralZod . En réponse au journal Vous aimez élie sémoun ?. Évalué à 9.
La trame est usée jusqu'à la corde, un mec un peu (beaucoup) paumé devient du jour au lendemain un bogosse (enfin, un ersatz ala Michael Vendetta) puis la princesse charmante qui lui résistait lui tombe dans les bras. Parce que c'est sensé être un film comique, on multiplie les allusions graveleuses, les clichés, on reprends les recettes qui ont marchés ailleurs.
Le cinéma c'est un peu comme la cuisine, il faut savoir doser les ingrédients, marier les saveurs mais là, on verse des sacs dans une bétonneuse en aveugle, espérant que les convives apprécient.
C'est de l'Élie Sémoun, on grossit tellement le trait que ça dépasse le concept d'humour ou même de surréalisme. Le public même averti, ne comprends plus la blague, il est perturbé, il se demande ce qu'il a fait pour mériter ça. Ce qui était bien dans les petites annonces, c'est qu'elles était très courtes, là on a droit à une annonce de plus d'1h30.
Ce qui manque à Élie Sémoun, c'est cette petite touche de poésie qui différence l'humouriste du tonton potache qui sort des vannes lors des dinés familiaux.
Élie sans Dieudonné, c'est un humoriste pas drôle, Dieudonné sans Élie, ça aurait pu être un grand humoriste mais ses dérives fascistes ont tout gâchés.
[^] # Re: Utilité de QtJambi
Posté par GeneralZod . En réponse au journal Qt Jambi abandonné pat Qt Software. Évalué à 3.
Gtk+ repose sur la GLib, donc t'as une gestion du réseau, un parseur xml (certes sommaire), des threads et pleins d'autres trucs intégrés. Pour le reste, t'as une multitude d'APIs complémentaire basés sur la GLib qui forme un ensemble cohérent (GStreamer, Webkit-Gtk, libsoup, Clutter, GNet etc ...), l'exception étant libxml.
Tu n'as pas totalement tort en disant que Gtk+ n'est pas l'équivalent de Qt, mais la toolbox du développeur Gtk+ est aussi riche que celle du développeur Qt qui dépuis Qt4 est découpé en modules.
Pour simplifier QtCore # GLib, QtGui #Gtk+, QNetwork # GNet, etc ...
> je suis pas d'accord non plus avec le commentaire d'au-dessus qui préconiserait d'utiliser ces classes QT au lieu de la lib standard.
La JCL traine pas mal de boulets, et je trouve personnellement l'API Qt (ou Gtk+) nettement plus agréable à utiliser. QtJambi a fait des choix plutôt intelligents, par exemple, ils utilisent le type Java.String plutôt que QString, on peut mélanger les classes d'I/O, bref, ça s'intégre plutôt bien dans une application Java standard. C'est loin d'être un binding bête et méchant qui t'impose ses choix fascistes.
Je n'incite pas plus à utiliser QtJambi que la JCL, Java-Gnome, SWT ou autre chose, chacun fait ce qu'il veut, ce n'est pas mon problème.
On a la chance d'avoir le choix entre plusieurs APIs de qualité (et libres), avec chacune des avantages et des inconvénients, donc autant choisir celle qui nous convient le mieux selon nos besoins et nos expériences.
Si je devais préconiser quelque chose, ce serait carrément d'abandonner Java mais on serait hors sujet. ;o)
[^] # Re: Utilité de QtJambi
Posté par GeneralZod . En réponse au journal Qt Jambi abandonné pat Qt Software. Évalué à 2.
Si tu me parles de la première génération que fournissent toutes les distributions, elle est non seulement obsolète mais je ne m'avancerais pas à dire que l'API est de qualité.
Andrw Cowie d'Operational Dynamics [1] avait fait une présentation (au Guadec notamment) pour expliquer pourquoi Java-Gnome 2.x était une impasse.
Quant à la seconde génération, c'est clairement mieux foutue (c'est même avec Gtkmm, un des bindings les plus réussis de l'API Gtk+ &cie) mais ça n'avance pas niveau intégration dans les distributions. Si ça t'intéresse, au niveau de Fedora, c'est le ticket 438452.
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).
Si tu ajoutes ça au manque de polish, pas de distributions clés-en-main pour Windows, MacOS X (en dehors de GNU/Linux, Solaris[2], c'est un peu l'inconnu), une doc spartiate comparé à celle fournis par Qt Software (avec des exemples non triviaux), l'absence de bindings des APIs complémentaires (Clutter, Gstreamer [3], etc ...) Java-Gnome va encore avoir du mal à se diffuser malgré toutes ses qualités.
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.
[1] Son blog est une mine d'information sur Java-Gnome
http://research.operationaldynamics.com/blogs/andrew/softwar(...)
[2] en même temps, j'en ai rien à battre de Windows.
[3] il y a un binding Gstreamer-Java non officiel mais il ne s'intégre pas vraiment à Java-Gnome.
[^] # Re: Utilité de QtJambi
Posté par GeneralZod . En réponse au journal Qt Jambi abandonné pat Qt Software. Évalué à 4.
À la différence de la JCL, Qt4 n'a pas à se soucier d'un historique plutôt encombrant au nom de la compatibilité ascendante. Sans oublier les outils associés (le generator pour générer le code glue, Qt linguist, Qt designer etc ...). Le seul truc qui m'ennuie un peu, c'est l'absence de qmake.
Quant aux développeurs Qt auquels les décideurs pressés ont imposés Java, de retrouver leurs marques rapidement. :o)
L'abandon de Qt Jambi était prévisible dans une certaine mesure: pas de béta de Qt Jambi 4.5, les blogs des employés de Qt Software était relativement silencieux à ce sujet, pas de support de QtJambi dans Qt Creator.
QtJambi c'est une bonne idée mais il y a tellement de chantiers dans Qt entre le développements de nouveaux outils, de nouvelles classes ou modules, les portages qu'il a fallu couper dans certains projets. C'est dommage, car QtJambi venait de commencer à percer auprès des développeurs, mais ce n'est pas critique car le C++ à la sauce Qt c'est quand même bien prémâché et ça n'a pas les inconvénients de Java.
Qt, c'est un peu le meilleur des 2 mondes.
[^] # Re: Qyoto
Posté par GeneralZod . En réponse au journal Qt Jambi abandonné pat Qt Software. Évalué à 2.
D'ailleurs, le gros reproche que je puisse faire des bindings utilisant smoke, c'est d'être dépendant des kdelibs (du moins le binding ruby). Peut-être que je me trompe (et vous êtes cordialement invité à le faire si vous avez plus de renseignements), mais la dépendance aux kdelibs, pour un gnomers c'est "no pasaran".