Il ne faut pas oublier l'API pour les animations qui semble être de la partie pour Qt 4.5. D'après les réponses de Thiago Macieira aux commentaires d'un de ses posts sur son blog [1], on subodore que cette mystérieuse API serait basée sur Qedje [2,3,4]. On en saura sans doute bien plus le 14 octobre prochain lors de la conf "Qt Technology Roadmap" des qt developer days 2008 [5].
Certes strigi, ne fait pas partie au sens strict de KDE, mais le projet a tout de même pour origine des développeurs de KDE est est hébergé dans la section kdesupport du dépôt subversion de KDE :
"Ils auraient pu commencer par ne faire que porter les API de KDE à QT4. Puis implémenter plasma et toute la clique de façon incrémentale."
C'est un peu ce qui se passe, les API et ABI de Plasma se sont pas encore figées, c'est seulement à partir de KDE 4.1 de les API/ABI de Plasma auront une compatibilité ascendante.
Il me semble aussi que le portage KDE-PIM/Akonadi vers KDE 4 ne sera pas prêt pour KDE 4.0.
Non, car GStreamer ne permet pas d'implémenter toutes les fonctionnalités de Phonon. Par exemple GStreamer ne comprend pas de couche réseau comme NMM (http://www.networkmultimedia.org/).
Tien, toi qui a l'aire de suivre le sujet. Concernant JWS, sera-t-il dispo sur x86_64 avec Java7?
J'ai oublié de préciser plus haut que Red Hat a lancé le projet icedTea[1] destiné à remplacer toutes les parties du JDK qui ne sont pas sous GPL et a utiliser des outils libres pour compiler la bête. JWS fera peut être partie du lot, en tout cas cela devrait facilité le portage du JDK vers des architectures et des systèmes d'exploitation plus exotiques.
Moi qui pensait que cette machine virtuelle modulaire, c'était pour Java 7, et que Java 7 était prévu pour décembre. Grosse déception.
L'évolution envisagée de Java 6 ne concerne que la réduction du temps de démarrage et de l'empreinte mémoire de la JVM. Java 7 introduira par contre une vraie modularité apportant des dépendances et des dépots.
Java 7 risque encore de prendre pas mal de temps vu que les principales JSR (294, 277, 292, 308, 310, 294...)[2] ne sont pas encore finalisées et qu'il ne sortira qu'une fois qu'il sera disponible entièrement sous GPL.
Tien, toi qui a l'aire de suivre le sujet. Concernant JWS, sera-t-il dispo sur x86_64 avec Java7?
Tu m'apprends que JWS n'est malheuresement pas disponible pour x86_64. Moi qui pensais switcher vers un linux x86_64 pour mon prochain poste de travail, je pense que je vais donc reconsidérer cette option. :-(
Les seules informations que j'ai c'est que :
- Java 7 ne devrait pas sortir avant au moins 1 an voir 2.
- Les sources de JWS n'ont pas encore été libérée en GPL à la différence de la très grande majorité des bibliothèques de classes Java standards.
Par contre Sun travaille actuellement encore beaucoup sur Java 6 : un "Consumer JRE" est apparament en préparation (une sorte de JRE minimal qui téléchargerait selon les besoins des bouts de l'actuel JRE) [1].
Il semble donc que Sun veuille que Java fasse son grand retour sur le poste de travail (dont JWS est un élément important pour le déploiement), il n'apparaîtrait pas illogique que JWS soit libéré et porté sur linux x86_64, et ce d'autant plus que le nombre d'utilisateurs de cette plate-forme est amener à croître fortement.
Est-il possible de transformer une application utilisant JWS en un paquet pour l'installer sur une machine sans connection internet ?
Oui mais pas "paquet" au sens linuxien. En fait tu peux te faire une archive zip/tar contenant tous les jars et le fichier jnlp. Ensuite dans le fichier jnlp, tu modifies, l'attribut "codebase" du noeud "jnlp" par une url locale du style "file:///tmp" correspondant au répertoire ou tu as decompressé les jars.
Il ne reste plus qu'a lancer l'appli jnlp en ligne de commande ou en double cliquant sur le fichier jnlp.
Lors du premier lancement, tous les jars sont copiés dans le cache de l'utilisateur jnlp, les entrées dans le menu démarrer et sur le bureau sont créées si cela est précisé dans le fichier jnlp. La version en ligne de commande de JWS (jawaws) possède également une option -system pour utiliser le cache système mais je ne l'ai jamais essayée.
Pour des vrais paquets .deb ou .rpm, je pense qu'il faudra attendre Java 7 avec l'apparition des modules java.
> Pour peu que vous embarquiez dans votre jar à la fois les dlls windows et les lib linux, vous vous retrouvez avec une application véritablement portable entre windows et linux (à condition que Qt soit installé bien sûr).
Pourquoi se compliquer la vie avec l'installation des jars, en utilisant Java Web Start (JWS) l'installation et l'utilisation d'appli Java est vraiment beaucoup BEAUCOUP plus simple (tous les paramètres sont dans le fichier jnlp : mémoire à allouer, jars à utiliser, classe principale, paramètres... et surtout plus de cette M$#@ de classpath). Avec JWS, une appli peut être installée en local et des liens peuvent être automatiquement créés dans le menu démarrer (Windows) et sur le bureau.
Bref le trio Java + Java Web Start + QtJambi, c'est que du bonheur : on peut enfin faire facilement et rapidement des applications pour le Desktop en Java. :-)
J'utilise QtJambi depuis plusieurs mois maintenant et franchement, je ne regrète absolument pas mon chois (et Swing).
Un employé de Sun, développe actuellement une alternative à Flash en Java nommé F3 permettant selon lui de créer des interface graphique plus simplement.
Il est actuellement à la recherche d'un moyen pour diffuser de la vidéo, il essaye actuellement dans un premier temps QT for Java. Un commentaire sur son blog, lui conseille d'utiliser cortado [1] qui est une implementation sous GPL de Theora mais voici ce qu'il répond [2]:
"Sun should buy Fluendo, or at least their Theora player (currently GPL - no linking exception?) - then include it in Java SE." :-(
[^] # Re: BOSC 2010
Posté par lamiducampeur . En réponse à la dépêche MBF : une boîte à outils pour la bioinformatique, par Microsoft. Évalué à 2.
http://www.slideshare.net/bosc2010/mercer-bosc2010-microsoft(...)
# Amazon lance le Quantum Compute Cloud
Posté par lamiducampeur . En réponse au journal Happy premier avril !. Évalué à 1.
http://aws.typepad.com/aws/2010/04/introducing-qc2-the-quant(...)
[^] # Re: Bonne nouvelle ?
Posté par lamiducampeur . En réponse au journal Oracle rachète Sun. Évalué à 4.
De mémoire :
- Btrfs
- BerkeleyDB
Pour le reste
http://oss.oracle.com/
# Animation API (Qedje ?)
Posté par lamiducampeur . En réponse au journal Sortie de Qt-4.4.2 + des infos sur Qt-4.5. Évalué à 2.
[1] http://labs.trolltech.com/blogs/2008/09/18/repeat-after-me-t(...)
[2] http://dev.openbossa.org/trac/qedje
[3] http://labs.morpheuz.eng.br/blog/01/08/2008/qedje-init/
[4] http://labs.morpheuz.eng.br/blog/21/08/2008/plasmoid-with-qe(...)
[5] http://trolltech.com/qtdevdays2008/technical
[^] # Re: L'essentiel est oublié
Posté par lamiducampeur . En réponse au journal KDE 4.1.0 est sorti, "Don't look back !". Évalué à 3.
http://websvn.kde.org/trunk/kdesupport/strigi/
[^] # Re: Cycle de release
Posté par lamiducampeur . En réponse à la dépêche GNOME fête ses dix ans de logiciel libre. Évalué à 3.
C'est un peu ce qui se passe, les API et ABI de Plasma se sont pas encore figées, c'est seulement à partir de KDE 4.1 de les API/ABI de Plasma auront une compatibilité ascendante.
Il me semble aussi que le portage KDE-PIM/Akonadi vers KDE 4 ne sera pas prêt pour KDE 4.0.
[^] # Re: Cycle de release
Posté par lamiducampeur . En réponse à la dépêche GNOME fête ses dix ans de logiciel libre. Évalué à 3.
[^] # Re: Java Web Start
Posté par lamiducampeur . En réponse au journal QT Jambi final version released. Évalué à 1.
J'ai oublié de préciser plus haut que Red Hat a lancé le projet icedTea[1] destiné à remplacer toutes les parties du JDK qui ne sont pas sous GPL et a utiliser des outils libres pour compiler la bête. JWS fera peut être partie du lot, en tout cas cela devrait facilité le portage du JDK vers des architectures et des systèmes d'exploitation plus exotiques.
L'évolution envisagée de Java 6 ne concerne que la réduction du temps de démarrage et de l'empreinte mémoire de la JVM. Java 7 introduira par contre une vraie modularité apportant des dépendances et des dépots.
Java 7 risque encore de prendre pas mal de temps vu que les principales JSR (294, 277, 292, 308, 310, 294...)[2] ne sont pas encore finalisées et qu'il ne sortira qu'une fois qu'il sera disponible entièrement sous GPL.
[1] http://icedtea.classpath.org/wiki//Main_Page
[2] http://jcp.org/en/jsr/all
[^] # Re: Java Web Start
Posté par lamiducampeur . En réponse au journal QT Jambi final version released. Évalué à 1.
Tu m'apprends que JWS n'est malheuresement pas disponible pour x86_64. Moi qui pensais switcher vers un linux x86_64 pour mon prochain poste de travail, je pense que je vais donc reconsidérer cette option. :-(
Les seules informations que j'ai c'est que :
- Java 7 ne devrait pas sortir avant au moins 1 an voir 2.
- Les sources de JWS n'ont pas encore été libérée en GPL à la différence de la très grande majorité des bibliothèques de classes Java standards.
Par contre Sun travaille actuellement encore beaucoup sur Java 6 : un "Consumer JRE" est apparament en préparation (une sorte de JRE minimal qui téléchargerait selon les besoins des bouts de l'actuel JRE) [1].
Il semble donc que Sun veuille que Java fasse son grand retour sur le poste de travail (dont JWS est un élément important pour le déploiement), il n'apparaîtrait pas illogique que JWS soit libéré et porté sur linux x86_64, et ce d'autant plus que le nombre d'utilisateurs de cette plate-forme est amener à croître fortement.
[1] http://weblogs.java.net/blog/chet/archive/2007/05/consumer_j(...)
[^] # Re: Java Web Start
Posté par lamiducampeur . En réponse au journal QT Jambi final version released. Évalué à 3.
Oui mais pas "paquet" au sens linuxien. En fait tu peux te faire une archive zip/tar contenant tous les jars et le fichier jnlp. Ensuite dans le fichier jnlp, tu modifies, l'attribut "codebase" du noeud "jnlp" par une url locale du style "file:///tmp" correspondant au répertoire ou tu as decompressé les jars.
Il ne reste plus qu'a lancer l'appli jnlp en ligne de commande ou en double cliquant sur le fichier jnlp.
Lors du premier lancement, tous les jars sont copiés dans le cache de l'utilisateur jnlp, les entrées dans le menu démarrer et sur le bureau sont créées si cela est précisé dans le fichier jnlp. La version en ligne de commande de JWS (jawaws) possède également une option -system pour utiliser le cache système mais je ne l'ai jamais essayée.
Pour des vrais paquets .deb ou .rpm, je pense qu'il faudra attendre Java 7 avec l'apparition des modules java.
# Java Web Start
Posté par lamiducampeur . En réponse au journal QT Jambi final version released. Évalué à 5.
Pourquoi se compliquer la vie avec l'installation des jars, en utilisant Java Web Start (JWS) l'installation et l'utilisation d'appli Java est vraiment beaucoup BEAUCOUP plus simple (tous les paramètres sont dans le fichier jnlp : mémoire à allouer, jars à utiliser, classe principale, paramètres... et surtout plus de cette M$#@ de classpath). Avec JWS, une appli peut être installée en local et des liens peuvent être automatiquement créés dans le menu démarrer (Windows) et sur le bureau.
Par ailleurs, Trolltech a réussi a contourner le bogue empêchant les toolkits autre que Swing de fonctionner avec JWS sous Mac OS X, comme le montre la démo en ligne de QtJambi :
http://dist.trolltech.com/developer/download/webstart/index.(...)
A ce propos, ce bogue qui touche également SWT vient d'être résolu par Apple :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=63306
Bref le trio Java + Java Web Start + QtJambi, c'est que du bonheur : on peut enfin faire facilement et rapidement des applications pour le Desktop en Java. :-)
J'utilise QtJambi depuis plusieurs mois maintenant et franchement, je ne regrète absolument pas mon chois (et Swing).
# F3
Posté par lamiducampeur . En réponse à la dépêche Itheora, un habillage pour Cortado. Évalué à 3.
http://blogs.sun.com/chrisoliver/
Quelques exemples :
http://blogs.sun.com/chrisoliver/resource/demo2.jnlp
http://blogs.sun.com/chrisoliver/resource/ffour-reflect.jnlp
http://blogs.sun.com/chrisoliver/resource/heroes.jnlp
http://blogs.sun.com/chrisoliver/resource/xhtmldemo.jnlp
Il est actuellement à la recherche d'un moyen pour diffuser de la vidéo, il essaye actuellement dans un premier temps QT for Java. Un commentaire sur son blog, lui conseille d'utiliser cortado [1] qui est une implementation sous GPL de Theora mais voici ce qu'il répond [2]:
"Sun should buy Fluendo, or at least their Theora player (currently GPL - no linking exception?) - then include it in Java SE." :-(
[1] http://www.flumotion.net/cortado
[2] http://blogs.sun.com/chrisoliver/entry/f3_and_video#comment-(...)
# Problèmes d'accent dans les noms de fichiers avec NFS
Posté par lamiducampeur . En réponse au journal Linux veut parler à OS X. Évalué à 1.
J'ai monté une partition NFS provenant d'une Debian testing sur un mac à l'aide du Gestionnaire netInfo avec la configuration suivante:
type: nfs
dir: /import/home2
opts: -P
name: rex:/export/home2
Lorsque je liste le contenu des répertoires du montage, les noms de fichiers accentués apparaissent sous la forme suivante:
qualit?
dans un terminal (et dans le finder ? est remplacé par un caractère quelconque et qui change lors que le dossier est sélectionné) au lieu de
qualité
Comment faire pour que Mac OS affiche correctement les caractères accentués dans les noms de fichier ?