J'ai regardé rapidement. C'est pas mal mais il faut tout de même passer un peu de temps pour s'y mettre: tout ne se fait pas à la souris. Par contre quasiment toutes les fonctions peuvent être utilisées par des raccourcis clavier. Au final avec un peu d'habitude l'écriture doit être plutôt rapide.
J'ai eu le même problème.
Pour pouvoir booter de nouveau sous Windows, va dans ton bios et pour le mode d'accès de ton disque dur choisit LBA (et pas auto ou autre).
Une fois sous Windows un outil genre Partiton Magic devrait résoudre définitivement le problème.
Il faudrait un filtre de SSA non seulement pour avidemux mais également pour la lecture de soustitres à la volée comme le permet le filtre directshow de VobSub sous Windows (le rendu est tellement bon qu'on croirait que les soustitres sont incrustés). Peut-être un filtre gstreamer?
Certes mplayer sait lire le SSA mais très mal: seul le texte brute est affiché, pas de couleur ni positionnement précis des soustitres possibles. Et la situation est encore pire pour Xine et tous les autres players que j'ai vu sous Linux, qui ne connaissent pas du tout ce format.
Le SSA permet de faire du soustitrage vraiment très pro, bien mieux que ce qu'on peut voir avec un DVD. C'est dommage qu'il ne soit pas bien supporté sous Linux. (Et non, j'ai ni le temps et surtout ni les compétences pour y remédier).
Sur ma Mandrake 9.2, y a un menu sous KDE (Gnome aussi sans doute) intitulé "Que faire?"
Dedans on trouve des actions comme "Administrez votre système", "Utilisez Internet", ... "Utilisez des outils de bureautique"
Dans ce dernier menu on peut choisir plusieurs actions comme "utilisez un traitement de texte", "utilisez un tableur", "gérez vos finances", ...
Et ça lance l'application par défaut.
Pour graver essaye le logiciel k3b: la première fois il configure tout ce qu'il faut pour la gravure (modification des droits des programmes de gravure, fstab,...). En tout cas j'ai jamais eu à recompiler pour graver des CD. Enfin j'utilise une Mandrake. Je sais pas pour les autres distribs.
Pour la gravure avec linux 2.6 j'ai pas essayé. Par contre j'ai lu qq part que les dernière versions de k3b fonctionnait déjà avec ce noyaux sans émulation scsi.
> Pour le standard :"Il est préférable de faire comme ça car c'est comme ça que
> fait la majorité".
Euh, là tu décrit un "standard de fait" non? En gros un standard qui s'impose de lui-même, sans concertation préalable et avec une implémentation qui précède le document papier.
Sinon, entre norme et standard (qui sont bien français) j'ai du mal à saisir la subtilité.
Moi j'utilise KDE. Voici quelques avantages de KDE par rapport à Gnome:
- standardisation entre les différentes applis: les menus communs entre applications se situent au même endroit. Disons qu'il y a une certaine cohérence. C'est pas indispensable mais je trouve ça plus agréable.
- fenêtre KDE d'ouverture de fichier bien plus conviviale et pratique: affichage aux choix (icone, liste...), possibilité de définir des icônes raccourcis, ... Ca ressemble un peu à ce qui se fait sous Windows XP mais en mieux :)
Alors que sous Gnome on a toujours la même fenêtre horrible. Pas d'avancée par rapport à du motif. Il parait que ça va changer (quand?)
- gestionnaire de fichier (konqueror) bien plus puissant IMHO que Nautilus. Onglet, possibilité de scinder la fenêtre..., et puis un truc que je trouve génial: on peut filtrer les fichiers depuis la barre d'url. Si je met *.avi par exemple, konqueror m'affichera seulement les fichiers avi. J'avais essayé sous Nautilus et ça marchais pas.
Sinon à mon avis les deux environnements se valent.
On est d'accord! C'est clair que je préfère développer en Java qu'en C++.
Côté performances, sans égaler le C++, on s'en rapproche tout de même fortement. Reste les problèmes suivants: c'est lent à démarrer, à chaque programme une nouvelle instance de la JVM se charge en mémoire, il faut beaucoup plus de mémoire vive, et pour avoir de bonnes perf il faut attendre que la JVM est eu le temps de recompiler le code à la volée, processus qui se répète à chaque lancement...
Vivement que gcj soit bien optimisé et supporte les Swings.
Les perf Java entre Linux et Windows sont à mon avis comparables... sauf pour l'aspect GUI. Swing sous Linux repose, à ce que j'ai lu sur Motif (pas très moderne tout ça), mais ça devrait bientôt changer. Quand à SWT j'ai essayé la version GTK. Mais à mon avis y a encore pas mal de boulot pour améliorer les performances. Dire que SWT est aussi réactif qu'une interface native est à mon avis faux sous Linux. Sous Windows ça me semble vrai. Mais sous cet OS Swing me semble également suffisamment rapide, et avec la dernière JVM de SUN le look&feel recopie parfaitement celui de Windows XP.
Les perf Java sont également très dépendantes de la JVM utilisée. J'avais fais quelques essais et il m'a semblé que celle d'IBM était (beaucoup) plus performante que celle de SUN (au prix d'un lancement légèrement plus long).
Y a aussi: http://home.elp.rr.com/tur/download.html(...)
C'est basé sur le client officiel (donc toujours en Python) avec quelques améliorations comme la possibilité de modifier depuis la GUI le taux d'upload utilisé. Assez pratique pour pas saturer la bande passante en upload.
Evidemment on peut toujours lancer le programme en ligne de commande (génial pour lancer un download avec ssh...).
Chez moi Azureus marchait pas terrible. L'interface freeze assez régulièrement et m'oblige à redémarrer le programme. Dommage car c'est plutôt pas mal pensé comme programme. Faudra que j'essaye avec la toute dernière version. Je sais pas si c'est la faute à SWT... Mais bon, on peut pas l'utiliser en mode console donc pour moi ça limite l'utilité (ssh roxor).
Au passage SWT c'est pas trop mal... sous Windows, parceque sous Linux les Swing me semblent presque plus réactifs. Eclipse est d'une lenteur incroyable sous Linux (avec un PIII 500MHz). De plus sous Windows la différence de réactivité entre Swing et SWT n'est pas transcendante. JBuilder par exemple est tout aussi utilisable que Eclipse.
J'ai essayé la fameuse démo de quake en Java.
Chez moi ça tourne très bien.
Sur un PC AMD 700 Duron, 640 Mo de RAM, carte nVidia GeForce 2, Windows XP, j'ai 40 de fps.
Le programme met environ 25 s à se lancer.
Sur un Pentium 2,6 GHz, 256 Mo de RAM, carte ATI Radeon 9500 Pro, Windows XP: 60 fps. Le programme met environ 10-15 s à se lancer.
Dans les 2 cas la démo est lancée en: 1024x768x32 en pleine écran et avec le son.
J'ai pas regardé l'occupation mémoire et je n'ai pu faire ces essais que sous Windows, désolé.
J'ai pas réussi à lancer le Quake original depuis Windows XP (même en mode compatibilité) donc je peux pas comparer les perf. Les perf sont peut-être bien meilleures avec la version originale (en fait j'en sais rien); ceci dit cela montre que l'on peut tout de même faire des choses intéressantes question jeux en Java.
Cette démo nécessite apparemment un JRE 1.4.x. J'ai pas pu comparer avec la version d'IBM car sous windows ils en sont encore à 1.3.1: il faudrait tester sous Linux.
Personnellement je ne constate pas de réelles dégradations des perfs entre un programme Java sous Windows et sous Linux... à part pour les applications graphiques. Que ce soit du swing ou du SWT, c'est pas super réactif sous Linux. La différence entre Eclipe sous Windows et sous Linux est flagrante.
Les performances peuvent dépendre également énormément de la JVM utilisée. En générale celle d'IBM (1.4.0) est plutôt plus performante que celle de SUN (C'est pas systématique mais j'ai déjà observé un facteur supérieur à 2 dans certains cas).
[^] # Re: GNU LilyPond 2.2.0 : esthétisme de la gravure de musique
Posté par ndesmoul . En réponse à la dépêche GNU LilyPond 2.2.0 : esthétisme de la gravure de musique. Évalué à 1.
http://rnvs.informatik.tu-chemnitz.de/~jan/noteedit/noteedit.html(...)
C'est une application KDE capable d'exporter vers LilyPond, MusixTeX et autres formats bizarres. J'ai pas essayé mais ça a pas l'air mal.
[^] # Re: GNU LilyPond 2.2.0 : esthétisme de la gravure de musique
Posté par ndesmoul . En réponse à la dépêche GNU LilyPond 2.2.0 : esthétisme de la gravure de musique. Évalué à 7.
http://denemo.sourceforge.net/(...)
J'ai regardé rapidement. C'est pas mal mais il faut tout de même passer un peu de temps pour s'y mettre: tout ne se fait pas à la souris. Par contre quasiment toutes les fonctions peuvent être utilisées par des raccourcis clavier. Au final avec un peu d'habitude l'écriture doit être plutôt rapide.
[^] # Re: Mandrake 10 Community et Windows XP
Posté par ndesmoul . En réponse au journal Mandrake 10 Community et Windows XP. Évalué à 1.
Pour pouvoir booter de nouveau sous Windows, va dans ton bios et pour le mode d'accès de ton disque dur choisit LBA (et pas auto ou autre).
Une fois sous Windows un outil genre Partiton Magic devrait résoudre définitivement le problème.
[^] # Re: Les outils vidéo pour Linux
Posté par ndesmoul . En réponse à la dépêche Les outils vidéo pour Linux. Évalué à 2.
Certes mplayer sait lire le SSA mais très mal: seul le texte brute est affiché, pas de couleur ni positionnement précis des soustitres possibles. Et la situation est encore pire pour Xine et tous les autres players que j'ai vu sous Linux, qui ne connaissent pas du tout ce format.
Le SSA permet de faire du soustitrage vraiment très pro, bien mieux que ce qu'on peut voir avec un DVD. C'est dommage qu'il ne soit pas bien supporté sous Linux. (Et non, j'ai ni le temps et surtout ni les compétences pour y remédier).
[^] # Re: Une nouvelle approche dans le monde des GUI
Posté par ndesmoul . En réponse à la dépêche Une nouvelle approche dans le monde des GUI. Évalué à 2.
Dedans on trouve des actions comme "Administrez votre système", "Utilisez Internet", ... "Utilisez des outils de bureautique"
Dans ce dernier menu on peut choisir plusieurs actions comme "utilisez un traitement de texte", "utilisez un tableur", "gérez vos finances", ...
Et ça lance l'application par défaut.
Il me semble que c'est déjà un début.
[^] # Re: Kernel 2.6.0 annoncé stable
Posté par ndesmoul . En réponse à la dépêche Le noyau Linux 2.6.0 annoncé stable. Évalué à 5.
Pour la gravure avec linux 2.6 j'ai pas essayé. Par contre j'ai lu qq part que les dernière versions de k3b fonctionnait déjà avec ce noyaux sans émulation scsi.
[^] # Re: Ca bouge bien pour OpenGL
Posté par ndesmoul . En réponse à la dépêche Ça bouge bien pour OpenGL. Évalué à 2.
> fait la majorité".
Euh, là tu décrit un "standard de fait" non? En gros un standard qui s'impose de lui-même, sans concertation préalable et avec une implémentation qui précède le document papier.
Sinon, entre norme et standard (qui sont bien français) j'ai du mal à saisir la subtilité.
[^] # Re: KDE : On ferme ! (les bugs)
Posté par ndesmoul . En réponse à la dépêche KDE : On ferme ! (les bugs). Évalué à 5.
- standardisation entre les différentes applis: les menus communs entre applications se situent au même endroit. Disons qu'il y a une certaine cohérence. C'est pas indispensable mais je trouve ça plus agréable.
- fenêtre KDE d'ouverture de fichier bien plus conviviale et pratique: affichage aux choix (icone, liste...), possibilité de définir des icônes raccourcis, ... Ca ressemble un peu à ce qui se fait sous Windows XP mais en mieux :)
Alors que sous Gnome on a toujours la même fenêtre horrible. Pas d'avancée par rapport à du motif. Il parait que ça va changer (quand?)
- gestionnaire de fichier (konqueror) bien plus puissant IMHO que Nautilus. Onglet, possibilité de scinder la fenêtre..., et puis un truc que je trouve génial: on peut filtrer les fichiers depuis la barre d'url. Si je met *.avi par exemple, konqueror m'affichera seulement les fichiers avi. J'avais essayé sous Nautilus et ça marchais pas.
Sinon à mon avis les deux environnements se valent.
[^] # Re: Mandrake 9.2 (FiveStar) enfin disponible !
Posté par ndesmoul . En réponse à la dépêche Mandrake 9.2 (FiveStar) enfin disponible !. Évalué à 2.
Côté performances, sans égaler le C++, on s'en rapproche tout de même fortement. Reste les problèmes suivants: c'est lent à démarrer, à chaque programme une nouvelle instance de la JVM se charge en mémoire, il faut beaucoup plus de mémoire vive, et pour avoir de bonnes perf il faut attendre que la JVM est eu le temps de recompiler le code à la volée, processus qui se répète à chaque lancement...
Vivement que gcj soit bien optimisé et supporte les Swings.
Les perf Java entre Linux et Windows sont à mon avis comparables... sauf pour l'aspect GUI. Swing sous Linux repose, à ce que j'ai lu sur Motif (pas très moderne tout ça), mais ça devrait bientôt changer. Quand à SWT j'ai essayé la version GTK. Mais à mon avis y a encore pas mal de boulot pour améliorer les performances. Dire que SWT est aussi réactif qu'une interface native est à mon avis faux sous Linux. Sous Windows ça me semble vrai. Mais sous cet OS Swing me semble également suffisamment rapide, et avec la dernière JVM de SUN le look&feel recopie parfaitement celui de Windows XP.
Les perf Java sont également très dépendantes de la JVM utilisée. J'avais fais quelques essais et il m'a semblé que celle d'IBM était (beaucoup) plus performante que celle de SUN (au prix d'un lancement légèrement plus long).
[^] # Re: Mandrake 9.2 (FiveStar) enfin disponible !
Posté par ndesmoul . En réponse à la dépêche Mandrake 9.2 (FiveStar) enfin disponible !. Évalué à 1.
http://home.elp.rr.com/tur/download.html(...)
C'est basé sur le client officiel (donc toujours en Python) avec quelques améliorations comme la possibilité de modifier depuis la GUI le taux d'upload utilisé. Assez pratique pour pas saturer la bande passante en upload.
Evidemment on peut toujours lancer le programme en ligne de commande (génial pour lancer un download avec ssh...).
Chez moi Azureus marchait pas terrible. L'interface freeze assez régulièrement et m'oblige à redémarrer le programme. Dommage car c'est plutôt pas mal pensé comme programme. Faudra que j'essaye avec la toute dernière version. Je sais pas si c'est la faute à SWT... Mais bon, on peut pas l'utiliser en mode console donc pour moi ça limite l'utilité (ssh roxor).
Au passage SWT c'est pas trop mal... sous Windows, parceque sous Linux les Swing me semblent presque plus réactifs. Eclipse est d'une lenteur incroyable sous Linux (avec un PIII 500MHz). De plus sous Windows la différence de réactivité entre Swing et SWT n'est pas transcendante. JBuilder par exemple est tout aussi utilisable que Eclipse.
[^] # Re: Pour un boot plus rapide de Linux
Posté par ndesmoul . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 2.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par ndesmoul . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à 1.
Chez moi ça tourne très bien.
Sur un PC AMD 700 Duron, 640 Mo de RAM, carte nVidia GeForce 2, Windows XP, j'ai 40 de fps.
Le programme met environ 25 s à se lancer.
Sur un Pentium 2,6 GHz, 256 Mo de RAM, carte ATI Radeon 9500 Pro, Windows XP: 60 fps. Le programme met environ 10-15 s à se lancer.
Dans les 2 cas la démo est lancée en: 1024x768x32 en pleine écran et avec le son.
J'ai pas regardé l'occupation mémoire et je n'ai pu faire ces essais que sous Windows, désolé.
J'ai pas réussi à lancer le Quake original depuis Windows XP (même en mode compatibilité) donc je peux pas comparer les perf. Les perf sont peut-être bien meilleures avec la version originale (en fait j'en sais rien); ceci dit cela montre que l'on peut tout de même faire des choses intéressantes question jeux en Java.
Cette démo nécessite apparemment un JRE 1.4.x. J'ai pas pu comparer avec la version d'IBM car sous windows ils en sont encore à 1.3.1: il faudrait tester sous Linux.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par ndesmoul . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à 1.
Les performances peuvent dépendre également énormément de la JVM utilisée. En générale celle d'IBM (1.4.0) est plutôt plus performante que celle de SUN (C'est pas systématique mais j'ai déjà observé un facteur supérieur à 2 dans certains cas).