Mais justement !!! Y'a aucun besoin de coder un C-pot puisqu'on à déjà Eye of Gnome (pour les besoins basiques de visionnages) et Gthumb (pour la gestion d'image et la retouche basique).
A quoi bon faire entrer F-Spot dans Gnome ?? (c'est pas fait mais ça pointe à l'horizon).
>> si Gnome était limité au C, ca veut dire que dans 20 ans on serait encore à faire des appli desktop en C ?
Mais Gnome n'est justement pas fermé actuellement. Je lui reproche même d'être ouvert au quatre vents. Un compromis me semble souhaitable sur le choix d'un seul langage de haut niveau (et si possible sans qu'il soit lardé de brevets détenus par Microsoft).
>> Un bon conseil : pense à l'expérience des utilisateurs, c'est tout ce qui importe
Quand j'évoque la conso mémoire je pense à quoi à ton avis ?
>> Justement non, le contrat de Gnome, au cas où tu l'aurais pas compris, c'est de proposer un framework en C et un ensemble de bindings pour avoir des applis dans des langages sans discriminiation et sans choix à priori.
Bon on va donc procéder par un exemple par l'absurde.
Tu prônes la non discrimination des langages. Très bien. Moi aussi je suis favorable aux bindings pour laisser le choix aux développeurs. Mais est-ce que Gnome doit avoir, par défaut, des applications dans tous ces langages ?
Une appli en C + Une appli en Ruby + Une appli en Python + Une appli en Mono + Une appli en Java + Une appli en OCAml + Une appli en Haskell...etc etc
C'est absurde !!
Que des bindings existent soit. Que les devs fassent ce qu'ils veulent avec leurs applis soit. Mais le projet Gnome doit CHOISIR un et un seul langage de haut niveau afin d'éviter la situation absurde décrite ci-dessus.
La non discrimination des langages c'est bien beau mais ce qu'on attends du board de la fondation Gnome c'est qu'elle fasse des choix techniques corrects et pertinents pour le futur. Là ce qu'elle nous propose c'est l'intégration d'applications dans tous les langages possibles et imaginables ?
Encore une fois le problème ce n'est pas Tomboy vs Sticky Notes. Le problème c'est qu'on ajoute des dépendances et que ces dépendances vont entrainer l'arrivée de nouveaux logiciels par défaut (F-Spot à coup sur) sans qu'il y ait eu un choix clair pour le langage de haut niveau.
La solution élégante c'est quoi ? Proposer des applications par défaut en C (comme actuellement) ou dans UN langage de haut niveau. Comme ça les besoins des développeurs sont satisfaits (ils peuvent choisir entre la vitesse d'exécution ou la vitesse de développement ou mixer les deux) et les besoins des utilisateurs sont satisfaits (ils ont une empreinte mémoire acceptable et ils ont des dépendances acceptables).
Ok je e réponds ici pour ce post et aussi pour celui plus bas sur la lourdeur.
>> dire qu'on change de plateforme à cause de ca alors qu'on a pertinement aucune idée de la légalité de l'autre plateforme relève vraiment du FUD
Si j'envisage éventuellement de changer de plateforme c'est que je pense vraiment que Gnome a rompu un contrat moral.
C'est quoi un desktop ? C'est un framework de développement (GTK+ ou Qt) et un ensemble cohérent d'applications par défaut qui se basent sur ce framework (Gnome ou KDE).
C'est ça un desktop, ni plus ni moins.
Ouvrir la possibilité à d'autres développeurs d'utiliser le framework dans le langage de leur choix (par des bindings) cela ne pose pas de problème. Mais FORCER les utilisateurs du desktop à utiliser ces applications Mono en remplacant les applis par défaut c'est une rupure du contrat moral d'origine.
Les applis par défaut de Gnome doivent se baser sur GTK+ et être en C. Si un langage de haut niveau se révèle vraiment indispensable alors il faut en choisir un (et un seul) et s'y tenir. Encore une fois cela n'interdit pas les bindings mais le applis qui reposent sur ces bindings ne doivent pas faire partie des applis par défaut de Gnome.
C'est une question de cohérence technique et c'est typiquement le genre de décision que l'on attends d'une core-team ou d'un fondation board. Ils doivent CHOISIR et s'y tenir.
Au lieu de ça on voit quoi ? On remplace une appli par défaut par une application qui dépend de Mono...et tout le monde sent bien que ce n'est que le début.
Moi ça m'énerve. J'aime Gnome, j'aime son interface simple et son HIG. Mais visiblement dans Gnome il n'y a pas de direction claire et de choix qui est fait. KDE a une vision claire de son futur alors que Gnome tatonne et empile les couches de logiciel sans choisir.
Merci de m'avoir donné ce lien très interessant. Je n'avais pas vu qu'il avait posté une réponse à mon journal de l'époque (maintenant je l'ai dans mon aggrégateur...il ne m'échappera plus ;-)
Sur le plan le plus général imagine la situation suivante dans deux ans : je lance ma machine avec Gnome 2.22 et ma conso mémoire s'emballe. En effet avec des applets en Python, en Ruby et des applis incontournables en Mono j'ai je ne sais combien de machine virtuelles qui tournent en même temps. Est-ce qu'il ne serait pas plus logique, si on veut répondre à la vraie demande d'un framework de haut niveau, de se limiter à Python ?
Pourquoi s'alourdir avec Mono (en plus des brevets Microsoft) alors que Python remplit ce besoin parfaitement ?
Que Gnome propose un binding vers C# pour les devs qui sont interessés cela ne pose aucun problème. Tant que ces applis ne deviennent pas officiellement des applis Gnome.
Par contre que Gnome commence à remplacer des applications actuelles par des applications Mono c'est très emmerdant. Moi je vois ça un peu comme une rupture de contrat moral. Je dis ça avec tristesse car j'aime beaucoup Gnome et je ne me suis jamais senti attiré par l'interface de KDE.
>> comparer F-spot a gthumb, c'est osé. Ce n'est *pas du tout* le meme type d'application
C'est _exactement_ le même type d'application.
Bien sur il y a certaines fonctions présentes chez l'un et pas chez l'autre et inversement mais rien de fondamental.
Sinon plus généralement : bien evidemment je peux toujours modifier Gnome pour avoir ce que je veux mais à la longue ça va vite devenir lourd surtout si la tendance se poursuit. Virer Tomboy pour avoir Sticky Notes à la place; Remplacer F-Spot par GThumb; Enlever Banshee et mettre Rhythmbox; Arreter Beagle...etc etc
KDE 4 arrive et il n'y aucune incertitude juridique qui assombrit son code, il va y avoir un HIG officiel pour l'uniformité, le look sera terrible et la technologie au top. A mon avis les devs de Gnome ont fait une grosse erreur avec cet ajout de Mono controversé.
>> On notera au passage l'arrivée d'une application en C# (Tomboy), qui officialise la dépendance de GNOME sur Mono et sur le binding GTK#
Tomboy est un utilitaire pour prendre des notes (une sorte de post-it electronique). Les versions précédentes de Gnome avaient pourtant l'utilitaire Sticky Notes qui répondait exactement au même besoin alors pourquoi changer ? Si Tomboy a une ou deux fonctions en plus alors pourquoi ne pas améliorer plutôt Sticky Notes ?
Le résultat c'est une dépendance à Mono. C'est très lourdingue et en plus juridiquement j'ai pas confiance.
Et tout ça n'est visiblement que le début d'une déferlante d'applications Mono : On parle déjà de l'arrivée de F-Spot dans la prochaine Ubuntu alors que GThumb (déjà présent) est une appli extraordinaire !
C'était bien la peine que les devs de Gnome du début bavent sur Qt et KDE et affirment que le C c'était ce qu'il y a de mieux.
Inutile de dire que je vais sérieusement tester le liveCD de la prochaine Kubuntu pour voir si je ne pourrais pas me faire à KDE et pouvoir ainsi switcher.
>> Programmeurs débutants du genre Linus Torvalds :)
Ce post de Linus est vraiment d'anthologie ! On sent bien le mec de caractère. J'ose même pas imaginer ce qui adviendrait si il était enfermé dans un cagibi avec Theo de Raadt....
De plus, contrairement à toi, je trouve le nouveau thème orgiginal est bien foutu.
Ubuntu a eu le courage de sortir du bleu et du gris dominant et de tenter l'orange/brun avec Ubuntu. C'est une réussite et ils font maintenant la même chose avec Kubuntu : passage du bleu classique au violet/pourpre !
>> A part pour un outil de partitionnement du disque facile à utiliser et souple, je vois pas l'interet d'un installeur graphique.
Ben déja ça m'évitera à ma prochaine install de devoir me taper une partition de swap de près de deux Go parceque je ne sais pas paramétrer l'outil ncurse ;-)
C'est assez amusant de comparer ce mail incendiaire avec l'article sur NetBSD qui vient d'être posté sur le site d'IBM.
Dans l'article de présentation d'IBM on trouve des phrases laudatives de ce style :
*NetBSD's attention to detail, well-written code, and vast portability make it a solid choice for a number of deployment scenarios.
*The system's well thought-out design allows for wide hardware support, a small footprint, stability, and security. NetBSD's unique features include a new paradigm for handling device drivers and other interesting innovations.
Autrement dit NetBSD c'est super, c'est génial, c'est un OS de qualité.
Maintenant si on lit le mail de Charles M. Hannum (un des fondateurs de NetBSD et le directeur du projet) on trouve des phrases assassines de ce style :
NetBSD is very far behind on a plethora of very important projects. Threading doesn't really work across multiple CPUs-- and is even somewhat buggy on one CPU. There is no good flash file
system. There is no file system journaling (except for LFS, which is
still somewhat experimental). Although there's been some recent work on suspend support, it's still mostly broken. Power management is very primitive.
* serious problems with the threading architecture
* terrible support for kernel modules;
* the horrible mess that is 32/64-bit compatibility, resulting in 32-bit apps often not working right on 64-bit kernels
* unbounded maintenance work due to inappropriate and rampant use of "quirk" tables and chip-specific tables
Ca fait vraiment peur cette différence de perception de la qualité du code !!
Moi je croyais que les BSD (et particulièrement NetBSD) soignaient la qualité du code avant tout...on tombe de haut !
J'ai installé la 0.9.5
Je passe sur l'interface mi-anglais/mi-français car c'est normal je pense avant la sortie officielle de Gnome.
La gestion des couvertures d'albums est bien faite et c'est vrai que l'effet de transition est sympa.
Par contre l'interface est toujours lourde. J'ai près de 5000 chansons mais je vois pas pourquoi la GUI devrait être aussi peu réactive...et en plus ça me le fait aussi avec l'ascenseur de réglage du volume donc c'est pas le nombre de chansons qui importe.
J'ai aussi noté que l'icone Rhythmbox qui apparait dans la barre en haut reste opaque même si la barre est transparente (c'est ignoble) alors qu'avant l'icone se mettait au diapason de la barre sans problèmes...
Est-ce que tu connais un moyen simple d'enregistrer, non pas un screenshot statique de mon écran, mais une petite séquence vidéo (ou un gif animé) afin que je puisse montrer le problème de lourdeur aux développeurs ?
>> Le problème, c'est avec l'hypocrisie de certains spécimens comme ce Max Spevack qui est en totale contradiction avec les propos des dirigeants.
Il n'y a pas de contradiction.
L'un affirme que Fedora n'est pas la beta de Red Hat et l'autre confirme en précisant juste que Fedora est l'alpha de Red Hat ;-)
Merci. C'est vrai que c'est pas mal d'avoir intégré la gestion des couvertures d'albums. Est-ce qu'il y a des releases notes quelque part ? Je voudrais savoir si ils ont bossé sur la réactivité de l'interface car c'est le point critique pour moi.
Effectivement je ne connaissais pas.
Le principe à l'air bien et je vais essayer. La configuration du serveur avec un fichier texte n'est quand même pas très user friendly (je me vois pas dire à ma maman de le faire....)
Les avantages sont nombreux pour Gael Duval : Il pourra légitimmement clamer partout qu'il innove et que sa distro est différente de toutes les autres. Pour le newbie le système klik est ultra-simple avec un seul fichier qui stocke tout et qu'on peut foutre à la corbeille facilement (un peu comme OSX). L'installation d'un soft se résumera à un simple clic sur un lien dans le site web d'Ulteo. Aucun risque de foutre le bordel dans son système puisque le soft n'est jamais vraiment installé (dépendances et autres bordels..)
Ultéo sera donc (selon ma boule de cristal) une mandriva ultra-minimum (le prog d'install et quelques programmes indispensables) et un large dépot Klik pour installer les softs qu'on veut.
>> Pluton quitte les rangs pour rejoindre les planètes naines composés de Sedna, Xena, Cerès et les autres.
Attention à ne pas prendre l'habitude de nommer le nouveau transneptunien Xena car ce n'est que le nom provisoire (qui est grotesque car il provient d'une série télé). L'Union Astronomique Internationale va décider de son nom définitif plus tard mais je doute qu'elle choisisse de conserver cette horreur. La norme pour les planètes ou les transnéptuniens c'est de prendre le nom d'un Dieu ou d'une divinité (Sedna est une divinité Inuit).
Merci de ta réponse.
Ce qui est bizarre c'est que si je me loggue avec un certain email cela fonctionne (il me propose l'email que j'ai déja utilisé) mais que si j'en essaye un autre cela ne marche pas...même après s'être loggué une première fois.
Etrange...Y'a des paramètres html particuliers qu'on peut ajouter ou c'est juste le bête champ texte et rien de plus ?
[^] # Re: Mono
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 2.
Mais justement !!! Y'a aucun besoin de coder un C-pot puisqu'on à déjà Eye of Gnome (pour les besoins basiques de visionnages) et Gthumb (pour la gestion d'image et la retouche basique).
A quoi bon faire entrer F-Spot dans Gnome ?? (c'est pas fait mais ça pointe à l'horizon).
>> si Gnome était limité au C, ca veut dire que dans 20 ans on serait encore à faire des appli desktop en C ?
Mais Gnome n'est justement pas fermé actuellement. Je lui reproche même d'être ouvert au quatre vents. Un compromis me semble souhaitable sur le choix d'un seul langage de haut niveau (et si possible sans qu'il soit lardé de brevets détenus par Microsoft).
>> Un bon conseil : pense à l'expérience des utilisateurs, c'est tout ce qui importe
Quand j'évoque la conso mémoire je pense à quoi à ton avis ?
[^] # Re: Mono
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 2.
Bon on va donc procéder par un exemple par l'absurde.
Tu prônes la non discrimination des langages. Très bien. Moi aussi je suis favorable aux bindings pour laisser le choix aux développeurs. Mais est-ce que Gnome doit avoir, par défaut, des applications dans tous ces langages ?
Une appli en C + Une appli en Ruby + Une appli en Python + Une appli en Mono + Une appli en Java + Une appli en OCAml + Une appli en Haskell...etc etc
C'est absurde !!
Que des bindings existent soit. Que les devs fassent ce qu'ils veulent avec leurs applis soit. Mais le projet Gnome doit CHOISIR un et un seul langage de haut niveau afin d'éviter la situation absurde décrite ci-dessus.
La non discrimination des langages c'est bien beau mais ce qu'on attends du board de la fondation Gnome c'est qu'elle fasse des choix techniques corrects et pertinents pour le futur. Là ce qu'elle nous propose c'est l'intégration d'applications dans tous les langages possibles et imaginables ?
Encore une fois le problème ce n'est pas Tomboy vs Sticky Notes. Le problème c'est qu'on ajoute des dépendances et que ces dépendances vont entrainer l'arrivée de nouveaux logiciels par défaut (F-Spot à coup sur) sans qu'il y ait eu un choix clair pour le langage de haut niveau.
La solution élégante c'est quoi ? Proposer des applications par défaut en C (comme actuellement) ou dans UN langage de haut niveau. Comme ça les besoins des développeurs sont satisfaits (ils peuvent choisir entre la vitesse d'exécution ou la vitesse de développement ou mixer les deux) et les besoins des utilisateurs sont satisfaits (ils ont une empreinte mémoire acceptable et ils ont des dépendances acceptables).
[^] # Re: Mono
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 8.
>> dire qu'on change de plateforme à cause de ca alors qu'on a pertinement aucune idée de la légalité de l'autre plateforme relève vraiment du FUD
Si j'envisage éventuellement de changer de plateforme c'est que je pense vraiment que Gnome a rompu un contrat moral.
C'est quoi un desktop ? C'est un framework de développement (GTK+ ou Qt) et un ensemble cohérent d'applications par défaut qui se basent sur ce framework (Gnome ou KDE).
C'est ça un desktop, ni plus ni moins.
Ouvrir la possibilité à d'autres développeurs d'utiliser le framework dans le langage de leur choix (par des bindings) cela ne pose pas de problème. Mais FORCER les utilisateurs du desktop à utiliser ces applications Mono en remplacant les applis par défaut c'est une rupure du contrat moral d'origine.
Les applis par défaut de Gnome doivent se baser sur GTK+ et être en C. Si un langage de haut niveau se révèle vraiment indispensable alors il faut en choisir un (et un seul) et s'y tenir. Encore une fois cela n'interdit pas les bindings mais le applis qui reposent sur ces bindings ne doivent pas faire partie des applis par défaut de Gnome.
C'est une question de cohérence technique et c'est typiquement le genre de décision que l'on attends d'une core-team ou d'un fondation board. Ils doivent CHOISIR et s'y tenir.
Au lieu de ça on voit quoi ? On remplace une appli par défaut par une application qui dépend de Mono...et tout le monde sent bien que ce n'est que le début.
Moi ça m'énerve. J'aime Gnome, j'aime son interface simple et son HIG. Mais visiblement dans Gnome il n'y a pas de direction claire et de choix qui est fait. KDE a une vision claire de son futur alors que Gnome tatonne et empile les couches de logiciel sans choisir.
[^] # Re: Mono
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 8.
Sur le plan le plus général imagine la situation suivante dans deux ans : je lance ma machine avec Gnome 2.22 et ma conso mémoire s'emballe. En effet avec des applets en Python, en Ruby et des applis incontournables en Mono j'ai je ne sais combien de machine virtuelles qui tournent en même temps. Est-ce qu'il ne serait pas plus logique, si on veut répondre à la vraie demande d'un framework de haut niveau, de se limiter à Python ?
Pourquoi s'alourdir avec Mono (en plus des brevets Microsoft) alors que Python remplit ce besoin parfaitement ?
Que Gnome propose un binding vers C# pour les devs qui sont interessés cela ne pose aucun problème. Tant que ces applis ne deviennent pas officiellement des applis Gnome.
Par contre que Gnome commence à remplacer des applications actuelles par des applications Mono c'est très emmerdant. Moi je vois ça un peu comme une rupture de contrat moral. Je dis ça avec tristesse car j'aime beaucoup Gnome et je ne me suis jamais senti attiré par l'interface de KDE.
[^] # Re: Mono
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 0.
C'est _exactement_ le même type d'application.
Bien sur il y a certaines fonctions présentes chez l'un et pas chez l'autre et inversement mais rien de fondamental.
Sinon plus généralement : bien evidemment je peux toujours modifier Gnome pour avoir ce que je veux mais à la longue ça va vite devenir lourd surtout si la tendance se poursuit. Virer Tomboy pour avoir Sticky Notes à la place; Remplacer F-Spot par GThumb; Enlever Banshee et mettre Rhythmbox; Arreter Beagle...etc etc
KDE 4 arrive et il n'y aucune incertitude juridique qui assombrit son code, il va y avoir un HIG officiel pour l'uniformité, le look sera terrible et la technologie au top. A mon avis les devs de Gnome ont fait une grosse erreur avec cet ajout de Mono controversé.
# Mono
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 6.
Tomboy est un utilitaire pour prendre des notes (une sorte de post-it electronique). Les versions précédentes de Gnome avaient pourtant l'utilitaire Sticky Notes qui répondait exactement au même besoin alors pourquoi changer ? Si Tomboy a une ou deux fonctions en plus alors pourquoi ne pas améliorer plutôt Sticky Notes ?
Le résultat c'est une dépendance à Mono. C'est très lourdingue et en plus juridiquement j'ai pas confiance.
Et tout ça n'est visiblement que le début d'une déferlante d'applications Mono : On parle déjà de l'arrivée de F-Spot dans la prochaine Ubuntu alors que GThumb (déjà présent) est une appli extraordinaire !
C'était bien la peine que les devs de Gnome du début bavent sur Qt et KDE et affirment que le C c'était ce qu'il y a de mieux.
Inutile de dire que je vais sérieusement tester le liveCD de la prochaine Kubuntu pour voir si je ne pourrais pas me faire à KDE et pouvoir ainsi switcher.
Patrick_g, un probable futur ex-gnomiste.
[^] # Re: Erreur d'une puissance de dix
Posté par patrick_g (site web personnel) . En réponse à la dépêche SPIS, l'OpenSource scientifique au service de l'exploration spatiale. Évalué à -2.
[^] # Re: Théo, à l'aide !
Posté par patrick_g (site web personnel) . En réponse au journal Un article fantastique !. Évalué à 5.
[^] # Re: ouais
Posté par patrick_g (site web personnel) . En réponse au journal printf debugging considered harmful. Évalué à 10.
Ce post de Linus est vraiment d'anthologie ! On sent bien le mec de caractère. J'ose même pas imaginer ce qui adviendrait si il était enfermé dans un cagibi avec Theo de Raadt....
[^] # Re: Ouf
Posté par patrick_g (site web personnel) . En réponse au journal Avancées de KOffice et Kubuntu. Évalué à 9.
De plus, contrairement à toi, je trouve le nouveau thème orgiginal est bien foutu.
Ubuntu a eu le courage de sortir du bleu et du gris dominant et de tenter l'orange/brun avec Ubuntu. C'est une réussite et ils font maintenant la même chose avec Kubuntu : passage du bleu classique au violet/pourpre !
[^] # Re: Rhythmbox se bouge!
Posté par patrick_g (site web personnel) . En réponse au journal Exaile!. Évalué à 2.
[^] # Re: Rhythmbox se bouge!
Posté par patrick_g (site web personnel) . En réponse au journal Exaile!. Évalué à 2.
[^] # Re: Interet ?
Posté par patrick_g (site web personnel) . En réponse au journal Debian Installer Etch Beta 3 Screenshot Tour. Évalué à 1.
Ben déja ça m'évitera à ma prochaine install de devoir me taper une partition de swap de près de deux Go parceque je ne sais pas paramétrer l'outil ncurse ;-)
[^] # Re: qualité du code
Posté par patrick_g (site web personnel) . En réponse au journal NetBSD : droit dans le mur ?. Évalué à 4.
# qualité du code
Posté par patrick_g (site web personnel) . En réponse au journal NetBSD : droit dans le mur ?. Évalué à 9.
Dans l'article de présentation d'IBM on trouve des phrases laudatives de ce style :
*NetBSD's attention to detail, well-written code, and vast portability make it a solid choice for a number of deployment scenarios.
*The system's well thought-out design allows for wide hardware support, a small footprint, stability, and security. NetBSD's unique features include a new paradigm for handling device drivers and other interesting innovations.
Autrement dit NetBSD c'est super, c'est génial, c'est un OS de qualité.
Maintenant si on lit le mail de Charles M. Hannum (un des fondateurs de NetBSD et le directeur du projet) on trouve des phrases assassines de ce style :
NetBSD is very far behind on a plethora of very important projects. Threading doesn't really work across multiple CPUs-- and is even somewhat buggy on one CPU. There is no good flash file
system. There is no file system journaling (except for LFS, which is
still somewhat experimental). Although there's been some recent work on suspend support, it's still mostly broken. Power management is very primitive.
* serious problems with the threading architecture
* terrible support for kernel modules;
* the horrible mess that is 32/64-bit compatibility, resulting in 32-bit apps often not working right on 64-bit kernels
* unbounded maintenance work due to inappropriate and rampant use of "quirk" tables and chip-specific tables
Ca fait vraiment peur cette différence de perception de la qualité du code !!
Moi je croyais que les BSD (et particulièrement NetBSD) soignaient la qualité du code avant tout...on tombe de haut !
[^] # Re: Rhythmbox se bouge!
Posté par patrick_g (site web personnel) . En réponse au journal Exaile!. Évalué à 2.
Je passe sur l'interface mi-anglais/mi-français car c'est normal je pense avant la sortie officielle de Gnome.
La gestion des couvertures d'albums est bien faite et c'est vrai que l'effet de transition est sympa.
Par contre l'interface est toujours lourde. J'ai près de 5000 chansons mais je vois pas pourquoi la GUI devrait être aussi peu réactive...et en plus ça me le fait aussi avec l'ascenseur de réglage du volume donc c'est pas le nombre de chansons qui importe.
J'ai aussi noté que l'icone Rhythmbox qui apparait dans la barre en haut reste opaque même si la barre est transparente (c'est ignoble) alors qu'avant l'icone se mettait au diapason de la barre sans problèmes...
Est-ce que tu connais un moyen simple d'enregistrer, non pas un screenshot statique de mon écran, mais une petite séquence vidéo (ou un gif animé) afin que je puisse montrer le problème de lourdeur aux développeurs ?
# Logique
Posté par patrick_g (site web personnel) . En réponse au journal Brian Stevens crache le morceau et avoue le rôle de Fedora.. Évalué à 10.
Il n'y a pas de contradiction.
L'un affirme que Fedora n'est pas la beta de Red Hat et l'autre confirme en précisant juste que Fedora est l'alpha de Red Hat ;-)
[^] # Re: Rhythmbox se bouge!
Posté par patrick_g (site web personnel) . En réponse au journal Exaile!. Évalué à 2.
[^] # Re: MPD
Posté par patrick_g (site web personnel) . En réponse au journal Exaile!. Évalué à 2.
Le principe à l'air bien et je vais essayer. La configuration du serveur avec un fichier texte n'est quand même pas très user friendly (je me vois pas dire à ma maman de le faire....)
[^] # Re: Long à scanner
Posté par patrick_g (site web personnel) . En réponse au journal Exaile!. Évalué à 2.
# Madame Irma
Posté par patrick_g (site web personnel) . En réponse au journal Ulteo s'ouvre.... Évalué à 10.
Article explicatif : http://dot.kde.org/1126867980/
Une news sur ce système : http://linuxfr.org/2005/09/18/19588.html
Les avantages sont nombreux pour Gael Duval : Il pourra légitimmement clamer partout qu'il innove et que sa distro est différente de toutes les autres. Pour le newbie le système klik est ultra-simple avec un seul fichier qui stocke tout et qu'on peut foutre à la corbeille facilement (un peu comme OSX). L'installation d'un soft se résumera à un simple clic sur un lien dans le site web d'Ulteo. Aucun risque de foutre le bordel dans son système puisque le soft n'est jamais vraiment installé (dépendances et autres bordels..)
Ultéo sera donc (selon ma boule de cristal) une mandriva ultra-minimum (le prog d'install et quelques programmes indispensables) et un large dépot Klik pour installer les softs qu'on veut.
Qui prend les paris avec moi ?
[^] # Re: date de sortie
Posté par patrick_g (site web personnel) . En réponse au journal Upstart pour remplacer sysvinit. Évalué à 4.
Mea culpa, mea maxima culpa.
# nom
Posté par patrick_g (site web personnel) . En réponse au journal Histoire d'astro (nomie|logie). Évalué à 5.
Attention à ne pas prendre l'habitude de nommer le nouveau transneptunien Xena car ce n'est que le nom provisoire (qui est grotesque car il provient d'une série télé). L'Union Astronomique Internationale va décider de son nom définitif plus tard mais je doute qu'elle choisisse de conserver cette horreur. La norme pour les planètes ou les transnéptuniens c'est de prendre le nom d'un Dieu ou d'une divinité (Sedna est une divinité Inuit).
[^] # Re: crétinos
Posté par patrick_g (site web personnel) . En réponse au message persistance des infos dans un champ email. Évalué à 3.
Ce qui est bizarre c'est que si je me loggue avec un certain email cela fonctionne (il me propose l'email que j'ai déja utilisé) mais que si j'en essaye un autre cela ne marche pas...même après s'être loggué une première fois.
Etrange...Y'a des paramètres html particuliers qu'on peut ajouter ou c'est juste le bête champ texte et rien de plus ?
# crétinos
Posté par patrick_g (site web personnel) . En réponse au message persistance des infos dans un champ email. Évalué à 3.