J'ai vu Millenium Actress et surtout Tokyo Godfather au dernier Forum des Images. J'espère que le dernier sortira en France en salles car c'est vraiment un film génial, aussi bien d'un point de vue de qualité d'animation que de scénario.
A voir sous aucun prétexte si vous en avez l'occasion.
Tu oublies Porco Rosso oublié dans un tiroir pendant pas mal d'années et le simple délai entre les premières sorties des films au japon et leur disponibilité ailleurs. :-)
De plus, les investissements dont tu parles ne représente qu'une partie très mineure de la réalisation d'un film. Les investissements pour Lauta n'auraient jamais eu lieu sans le succès de Mononoke et Chihiro.
Bon, je ne cherche pas à défendre une théorie quelconque de conspiration. A vrai dire, je m'en fiche un peu. Mais tes arguments ne sont pas très convaincants pour démontrer son peu de crédibilité.
Au passage, beaucoup d'arguments en faveur de la "rétention" des oeuvres de Miyazaki par Buena Vista durant les années 90 sont justement sur Nausicaa. Fouinez. :-)
Ca, je ne conteste pas que beaucoup de choses dépendent avant tout de notre niveau d'appréciation. Mais je pense aussi qu'on a maintenant tendance à décrier Disney par défaut parce que l'on a vu et revu leurs films et qu'on connait bien leurs petites ficelles.
Le côté "comédies musicales" ne me gêne pas forcément (c'est après tout un choix) si effectivement je trouve la musique bien composée et que son arrivée dans le film n'est pas spécialement choquante : le Roi Louis dans le Livre de la Jungle ou "tout le monde veut devenir un cat" sont des moments que j'aime beaucoup, d'autant plus qu'ils sont remarquablement animés. Le génie dans Aladin, par contre..... :-(
D'un point de vue purement technique d'animation, ces films sont vraiment très bons. Les personnages sont très vivants et leur animation est très dynamique. Il y a pleins de petits détails dans les mouvements d'un Edgar, d'un Baloo ou d'une Duchesse. On a tellement vu ces films qu'il est parfois difficile de les regarder d'un oeil neuf, mais je t'assure que les gars derrière étaient drolement talentueux.
D'autre part, j'adore Miyazaki, mais qand on aura vu et revu ses films, je sais qu'on entendra des esprits chagrins dire qu'ils en ont marre de Miyazaki et de ses éternelles petites filles confrontées à la dure réalité de la vie et forcées par les évènements à grandir et à devenir des adultes. Ses films sont également bourrés de tics et de redondances. Combien de temps faudra-t-il, à ton avis, pour que cela passe de l'état de "marque de fabrique" à celui de "petites ficelles"?
Ca dépend. Des films comme les 101 dalmatiens, le Livre de la Jungle, les Aristochats ou Blanche-Neige sont absolument remarquables d'animation. La réalisation est impeccable et la musique est généralement de très haut vol.
Les navets de Disney de l'ère Eisner (i.e. ces 15 dernières années) ne doivent pas faire oublier que cette boite a produit de véritables chefs d'oeuvres d'animation.
Les mauvaises langues disent que Buena Vista a acheté tous les droits de distribution des films de Miyazaki pour mieux les enterrer, de peur qu'ils fassent trop d'ombre aux derniers navets de Disney et que maintenant que Disney a décidé de raccrocher la production de films d'animation 2D, du coup ils se font du blé en ressortant au compte-goutte tous les films de Gibhli.
Bizarre, ça me parait assez crédible en fait...
Qu'est-ce que tu appelles des "logiciels fait en java"?
Mon expérience d'utilisateur avec :
1/ les installateurs Oracle
2/ les installateurs IBM
3/ L'interface graphique Java de Novell 6
4/ Les développements actuels de ma boite pour faire une interface Java à notre soft (pourtant peu complexe)
tendent à me faire croire une chose : Java c'est très bien pour plein de trucs SAUF une interface graphique. Une bête interface avec juste une dizaine d'écrans monte rapidement à des occupations mémoire de l'ordre de 90-100Mo. Faire tout un environnement façon KDE en java me parait totalement irréaliste : ce n'est pas 2Go de RAM qu'il faudrait mais 10 fois ça. Et avec une réactivité tout juste passable.
Il n'y a rien d'étonnant à ce que le 'Java Desktop' de Sun soit essentiellement un Gnome avec un VM Java chargé en permanence. Je doute qu'on ait atteint un point où l'on peut encore se passer des langages compilés pour faire un environnement graphique.
A moins d'utiliser un système de type PyQT qui est vraiment surprenant de simplicité et de vélocité. Mais une bonne partie reste compilée donc ca ne compte pas.
Je n'ai rien affirmé de tel, je ne faisais que répondre à la question concernant PSI.
Ceci étant dit, je ne connais pas sur le bout des doigts la GPL, mais est-ce que ca marche effectivement dans ce sens?
Ce que je veux dire c'est que pour se lier avec une librairie sous GPL, il faut être GPL, soit. Mais si tu fais du code qui se lie en dynamique avec une librairie non compatible GPL, est-ce qu'il ne peut pas tout de même être GPL? Après tout, tu fournis les sources de ton code et tu donnes bien le droit à tout le monde de le réutiliser, pour peu qu'il soit réutiliser dans un code GPL.
Apparemment, PSI a reçu une license pour windows gracieusement de la part de trolltech. D'après Justin Karneges sur dot.kde :
"I just want to mention that the Psi project (http://psi.affinix.com/(...)) receives Qt/Windows for free. Trolltech gave us 3 commercial licenses, including support and upgrades, provided that we only use it for open source work.
I don't know how common it is for Trolltech to do this. Maybe it helped that I was a Qt customer in the past. Maybe we're the only such project. In any case, if you have a popular and dedicated free software project, you might try asking them to help you out. :)"
J'ai pas eu de problème personnellement avec le driver nv mais ca ne veut pas dire grand chose.
Par contre, je rappelle que nv a été complètement réécrit pour XFree86 4.4 et pour Xorg, et qu'il est censé être beaucoup plus performant.
Donc, mieux vaudrait refaire quelques tests maintenant avant de continuer une quelconque comparaison nv/nvidia en 2D.
Ce que je voulais décrire comme situation, c'est juste une situation de ce type (lilo ou kernel foireux) où tu démarres ta machine sur un CD (Slackware, par exemple), monte ton disque et passes en chroot pour faire quelques manipulations. Si ces dernières nécessitent un accès à des devices, je suppose qu'il est nécessaire qu'un répertoire /dev standard soit présent, non? Où alors comme udev fonctionne en espace utilisateur, est-il possible de le démarrer à ce moment, pour peu que le kernel du CD de boot le supporte?
Je sais que tu peux créer tes devices à la main, mais c'est une solution un peu... basique.
Imaginons que je démarre ma machine sur CD-Rom, que je monte une partition de disque dur qui était préalablement sous udev.
Je fais un chroot, genre pour réecrire LILO. Comment ça se passe?
Il suffit de voir la polémique actuelle entre chercheurs et gouvernement pour comprendre que ce dernier a clairement ciblé son clientellisme.
Cela dit, les gouvernements précédents n'avaient pas eux non plus fait les efforts nécessaires en matière de recherche. Mais l'actuel semble n'avoir aucune capacité de vision à moyen terme. Ils ne savent que poser les bases d'un état policier et faire du déficit pour baisser les impots.
>- Est-ce qu'un OS 64 bits peut faire tourner les processus 32 bits ? Si les
> types changent (int, long) pour passer de 32 à 64 bits, le prototype des
> appels systèmes change aussi.
Oui. Le système doit être 64bits mais les programmes peuvent encore être en 32bits. La conversion se fait plus ou moins à la volée.
Ce n'est pas nouveau d'ailleurs : Solaris et AIX font tourner depuis plus de 5 ans des applis 32bits sur un OS 64bits.
> - Quel est l'intérêt d'être compatible 32 bits pour les processeurs 64 bits ?
> Acheter une architecture 64 bits pour faire tourner un OS 32 bits n'a
> strictement aucun intérêt.
Pour les plateformes payantes, migrer tous tes logiciels est couteux. Donc, tu les migrent petit à petit selon les besoins.
Pour les systèmes libres, soyons clairs, il y a pas mal de projets qui ne sont pas encore totalement "prêts" pour le 64bits. C'est sympa de pouvoir continuer à les utiliser en 32bits jusqu'à ce que le code soit nettoyé.
C'est vrai pour SpecCPU2000, qui n'est pas multithread, mais pas pour Spec_rateCPU, qui lui consiste à lancer, si j'ai bien compris, un paquet de SpecCPU en parallèle, utilisant donc le multiprocessing/multicore/multithreading.
Cela permet aussi de comparer les performances d'une quadri-Opteron et d'une quadri-Itanium.
L'anialiasing (par Freetype), la 3D (par GLX/Mesa/drivers), ca existe déjà dans XFree. Les fonctionnalités du type réduction de fenêtre, c'est du domaine du WM/DE. Cela peut très bien se faire maintenant tout de suite.
Ce que j'entends le plus régulièrement dire à propos de XFree pour montrer qu'il n'est pas "à la mode", ce sont 1/ les histoires de tranpsparence qui permettrait d'avoir des ombres sous les fenêtres et des menus transparents à la MacOSX rapides ; 2/ les performances en 3D médiocres par rapport à Windows.
Le 1/, c'est visuel, c'est utile (oui, l'ombre sous les fenêtres, je trouve clea utile pour la lisibilité d'un desktop) mais ça reste encore du domaine un peu du gadget. Le 2/, c'est plus problématique, les constructeurs n'aidant pas.
Pour le reste, je suis évidemment d'accord avec toi, mais il me parait malheureux de relancer le débat de la Core Team alors qu'elle a été dissoute en décembre 2003. L'équipe de XFree tache actuellement de s'ouvrir, alors laissons les un peu tranquilles.
Cette histoire de license, je pense qu'ils ne l'avaient juste pas anticipé sous cet angle. Ils vont la modifier pour être de nouveau compatibles, je ne vois pas où est le problème.
Oui. C'est d'ailleurs une honte quand on voit que la plupart des critiques portent sur des trucs débiles à la MacOS (transparence, ombres,etc) alors que XFree supporte depuis belle lurette un paquet de fonctionnalités dont Windows/Mac sont toujours à rêver, export display, pour n'en citer qu'un.
Je n'ai rien contre les trucs un peu jacky, mais cela me parait un peu court pour que leur absence face d'un projet aussi poussé que XFree un "truc à la traine".
Ce que je pense que le projet aurait besoin, c'est peut-être d'un peu de rationnalisation : je n'ai rien contre les utilitaires X, mais ont-ils besoin d'être dans la même distribution ou même dans le même projet?
Il vaudrait mieux qu'il y ait d'une part XFree86 et les pilotes vidéos, et d'autres part les outils s'appuyant sur ce framework. Cela permetterait peut-être d'avoir des releases plus régulières et mieux centrées.
Disney, comme Dreamworks après Sinbad, a fermé ses studios de productions de films d'animation 2D. Soit disant que seule la 3D rapporte de nos jours.
Par contre, les animateurs du studio de floride de Disney vont apparemment remonter une structure.
Donc, des studios d'animations aux US, tu en as en fait plus que 2, Pixar et Dreamworks, qui ne feront que de la 3D, et éventuellement un autre en cours de mise en place. Disney ne fera plus que de la distribution, des parcs d'attraction et des jouets.
Autrement dit, c'est une boite qui va couler. Merci Eisner.
Développe.
Je suis un programmeur plutôt genre gros nase (globalement, j'ai fais du fortran durant mes études de physique). Je me suis mis à Python et avec PyQT, j'ai pu coder une application graphique à peu près décente en environ un mois de boulot pas vraiment acharné, apprentissage du langage et de l'API PyQT inclus.
En quoi est-ce donc "lourd à programmer"?
Qu'est-ce que XUL (donc les exemples d'utilisation actuels genre Mozilla sont pas vraiment révélateurs de grandes possibilités suplémentaires par rapport aux autres toolkits) peut changer à ça?
Je ne dis pas que tu as tort mais ne connaissant pas XUL, je n'en vois pas trop l'avantage pour le moment.
Bien d'accord. J'attends encore le réalisateur français de la trempe de Jim Jarmush ou d'Atom Egoyan.
Même dans les films moins cons (genre "le goût des autres"), la réalisation reste tout de même très plate. A croire que les français ne connaissent que le plan américain, ce qui ne manque pas de sel dans la discussion présente....
Oui, d'ailleurs il y a un film animé de Kon Satochi qui les met en scène. Ca s'appelle Tokyo Godfathers et j'espère qu'il sortira en salle en France car c'est un véritable chef d'oeuvre.
Etonnant ce que tu dis sur l'ide-scsi. J'utilise mon graveur chez moi en ide-scsi sur kernel 2.6 depuis le début des test-* sans souci.
Cela dis, je vais passer en mode packet, je pense, vue que l'évolution a l'air d'aller dans ce sens.
[^] # Re: Kiki, la petite sorcière
Posté par Richard Van Den Boom . En réponse à la dépêche Kiki, la petite sorcière. Évalué à 1.
On peut pas être bon partout. :-)
Richard
[^] # Re: Kiki, la petite sorcière
Posté par Richard Van Den Boom . En réponse à la dépêche Kiki, la petite sorcière. Évalué à 1.
A voir sous aucun prétexte si vous en avez l'occasion.
Richard
[^] # Re: Kiki, la petite sorcière
Posté par Richard Van Den Boom . En réponse à la dépêche Kiki, la petite sorcière. Évalué à 3.
De plus, les investissements dont tu parles ne représente qu'une partie très mineure de la réalisation d'un film. Les investissements pour Lauta n'auraient jamais eu lieu sans le succès de Mononoke et Chihiro.
Bon, je ne cherche pas à défendre une théorie quelconque de conspiration. A vrai dire, je m'en fiche un peu. Mais tes arguments ne sont pas très convaincants pour démontrer son peu de crédibilité.
Au passage, beaucoup d'arguments en faveur de la "rétention" des oeuvres de Miyazaki par Buena Vista durant les années 90 sont justement sur Nausicaa. Fouinez. :-)
Richard
[^] # Re: Kiki, la petite sorcière
Posté par Richard Van Den Boom . En réponse à la dépêche Kiki, la petite sorcière. Évalué à 1.
Le côté "comédies musicales" ne me gêne pas forcément (c'est après tout un choix) si effectivement je trouve la musique bien composée et que son arrivée dans le film n'est pas spécialement choquante : le Roi Louis dans le Livre de la Jungle ou "tout le monde veut devenir un cat" sont des moments que j'aime beaucoup, d'autant plus qu'ils sont remarquablement animés. Le génie dans Aladin, par contre..... :-(
D'un point de vue purement technique d'animation, ces films sont vraiment très bons. Les personnages sont très vivants et leur animation est très dynamique. Il y a pleins de petits détails dans les mouvements d'un Edgar, d'un Baloo ou d'une Duchesse. On a tellement vu ces films qu'il est parfois difficile de les regarder d'un oeil neuf, mais je t'assure que les gars derrière étaient drolement talentueux.
D'autre part, j'adore Miyazaki, mais qand on aura vu et revu ses films, je sais qu'on entendra des esprits chagrins dire qu'ils en ont marre de Miyazaki et de ses éternelles petites filles confrontées à la dure réalité de la vie et forcées par les évènements à grandir et à devenir des adultes. Ses films sont également bourrés de tics et de redondances. Combien de temps faudra-t-il, à ton avis, pour que cela passe de l'état de "marque de fabrique" à celui de "petites ficelles"?
Richard
[^] # Re: Kiki, la petite sorcière
Posté par Richard Van Den Boom . En réponse à la dépêche Kiki, la petite sorcière. Évalué à 2.
Les navets de Disney de l'ère Eisner (i.e. ces 15 dernières années) ne doivent pas faire oublier que cette boite a produit de véritables chefs d'oeuvres d'animation.
Richard
[^] # Re: Kiki, la petite sorcière
Posté par Richard Van Den Boom . En réponse à la dépêche Kiki, la petite sorcière. Évalué à 2.
Bizarre, ça me parait assez crédible en fait...
Richard
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par Richard Van Den Boom . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 3.
Mon expérience d'utilisateur avec :
1/ les installateurs Oracle
2/ les installateurs IBM
3/ L'interface graphique Java de Novell 6
4/ Les développements actuels de ma boite pour faire une interface Java à notre soft (pourtant peu complexe)
tendent à me faire croire une chose : Java c'est très bien pour plein de trucs SAUF une interface graphique. Une bête interface avec juste une dizaine d'écrans monte rapidement à des occupations mémoire de l'ordre de 90-100Mo. Faire tout un environnement façon KDE en java me parait totalement irréaliste : ce n'est pas 2Go de RAM qu'il faudrait mais 10 fois ça. Et avec une réactivité tout juste passable.
Il n'y a rien d'étonnant à ce que le 'Java Desktop' de Sun soit essentiellement un Gnome avec un VM Java chargé en permanence. Je doute qu'on ait atteint un point où l'on peut encore se passer des langages compilés pour faire un environnement graphique.
A moins d'utiliser un système de type PyQT qui est vraiment surprenant de simplicité et de vélocité. Mais une bonne partie reste compilée donc ca ne compte pas.
Richard.
[^] # Re: Une longue interview de Trolltech
Posté par Richard Van Den Boom . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
Ceci étant dit, je ne connais pas sur le bout des doigts la GPL, mais est-ce que ca marche effectivement dans ce sens?
Ce que je veux dire c'est que pour se lier avec une librairie sous GPL, il faut être GPL, soit. Mais si tu fais du code qui se lie en dynamique avec une librairie non compatible GPL, est-ce qu'il ne peut pas tout de même être GPL? Après tout, tu fournis les sources de ton code et tu donnes bien le droit à tout le monde de le réutiliser, pour peu qu'il soit réutiliser dans un code GPL.
Richard
[^] # Re: Une longue interview de Trolltech
Posté par Richard Van Den Boom . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
"I just want to mention that the Psi project (http://psi.affinix.com/(...)) receives Qt/Windows for free. Trolltech gave us 3 commercial licenses, including support and upgrades, provided that we only use it for open source work.
I don't know how common it is for Trolltech to do this. Maybe it helped that I was a Qt customer in the past. Maybe we're the only such project. In any case, if you have a popular and dedicated free software project, you might try asking them to help you out. :)"
Richard.
[^] # Re: Ca marche !!!!
Posté par Richard Van Den Boom . En réponse à la dépêche Sortie de X Window System X11R6.7 de X.Org. Évalué à 2.
Par contre, je rappelle que nv a été complètement réécrit pour XFree86 4.4 et pour Xorg, et qu'il est censé être beaucoup plus performant.
Donc, mieux vaudrait refaire quelques tests maintenant avant de continuer une quelconque comparaison nv/nvidia en 2D.
Richard.
[^] # Re: Comment ça se passe avec chroot?
Posté par Richard Van Den Boom . En réponse à la dépêche Udev atteint la maturité. Évalué à 1.
Merci, c'est ce que je voulais savoir.
Richard
[^] # Re: Comment ça se passe avec chroot?
Posté par Richard Van Den Boom . En réponse à la dépêche Udev atteint la maturité. Évalué à 1.
Je sais que tu peux créer tes devices à la main, mais c'est une solution un peu... basique.
Richard
# Comment ça se passe avec chroot?
Posté par Richard Van Den Boom . En réponse à la dépêche Udev atteint la maturité. Évalué à 1.
Je fais un chroot, genre pour réecrire LILO. Comment ça se passe?
Oui, je sais, c'est le même problème avec devfs.
Richard.
[^] # Re: Et l'Europe?
Posté par Richard Van Den Boom . En réponse à la dépêche Super ordinateur en Espagne. Évalué à 10.
Cela dit, les gouvernements précédents n'avaient pas eux non plus fait les efforts nécessaires en matière de recherche. Mais l'actuel semble n'avoir aucune capacité de vision à moyen terme. Ils ne savent que poser les bases d'un état policier et faire du déficit pour baisser les impots.
Richard
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par Richard Van Den Boom . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 2.
> types changent (int, long) pour passer de 32 à 64 bits, le prototype des
> appels systèmes change aussi.
Oui. Le système doit être 64bits mais les programmes peuvent encore être en 32bits. La conversion se fait plus ou moins à la volée.
Ce n'est pas nouveau d'ailleurs : Solaris et AIX font tourner depuis plus de 5 ans des applis 32bits sur un OS 64bits.
> - Quel est l'intérêt d'être compatible 32 bits pour les processeurs 64 bits ?
> Acheter une architecture 64 bits pour faire tourner un OS 32 bits n'a
> strictement aucun intérêt.
Pour les plateformes payantes, migrer tous tes logiciels est couteux. Donc, tu les migrent petit à petit selon les besoins.
Pour les systèmes libres, soyons clairs, il y a pas mal de projets qui ne sont pas encore totalement "prêts" pour le 64bits. C'est sympa de pouvoir continuer à les utiliser en 32bits jusqu'à ce que le code soit nettoyé.
Richard
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par Richard Van Den Boom . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 2.
Cela permet aussi de comparer les performances d'une quadri-Opteron et d'une quadri-Itanium.
Richard
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par Richard Van Den Boom . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 3.
Richard
[^] # Re: Le retour de XFree86 4.3 dans Mandrake Linux 10.0 Release Candidate 1
Posté par Richard Van Den Boom . En réponse à la dépêche Du rififi pour XFree. Évalué à 3.
Ce que j'entends le plus régulièrement dire à propos de XFree pour montrer qu'il n'est pas "à la mode", ce sont 1/ les histoires de tranpsparence qui permettrait d'avoir des ombres sous les fenêtres et des menus transparents à la MacOSX rapides ; 2/ les performances en 3D médiocres par rapport à Windows.
Le 1/, c'est visuel, c'est utile (oui, l'ombre sous les fenêtres, je trouve clea utile pour la lisibilité d'un desktop) mais ça reste encore du domaine un peu du gadget. Le 2/, c'est plus problématique, les constructeurs n'aidant pas.
Pour le reste, je suis évidemment d'accord avec toi, mais il me parait malheureux de relancer le débat de la Core Team alors qu'elle a été dissoute en décembre 2003. L'équipe de XFree tache actuellement de s'ouvrir, alors laissons les un peu tranquilles.
Cette histoire de license, je pense qu'ils ne l'avaient juste pas anticipé sous cet angle. Ils vont la modifier pour être de nouveau compatibles, je ne vois pas où est le problème.
Richard
[^] # Re: Le retour de XFree86 4.3 dans Mandrake Linux 10.0 Release Candidate 1
Posté par Richard Van Den Boom . En réponse à la dépêche Du rififi pour XFree. Évalué à 5.
Je n'ai rien contre les trucs un peu jacky, mais cela me parait un peu court pour que leur absence face d'un projet aussi poussé que XFree un "truc à la traine".
Ce que je pense que le projet aurait besoin, c'est peut-être d'un peu de rationnalisation : je n'ai rien contre les utilitaires X, mais ont-ils besoin d'être dans la même distribution ou même dans le même projet?
Il vaudrait mieux qu'il y ait d'une part XFree86 et les pilotes vidéos, et d'autres part les outils s'appuyant sur ce framework. Cela permetterait peut-être d'avoir des releases plus régulières et mieux centrées.
Richard
[^] # Re: Pixar quitte Disney
Posté par Richard Van Den Boom . En réponse à la dépêche Pixar quitte Disney. Évalué à 2.
Par contre, les animateurs du studio de floride de Disney vont apparemment remonter une structure.
Donc, des studios d'animations aux US, tu en as en fait plus que 2, Pixar et Dreamworks, qui ne feront que de la 3D, et éventuellement un autre en cours de mise en place. Disney ne fera plus que de la distribution, des parcs d'attraction et des jouets.
Autrement dit, c'est une boite qui va couler. Merci Eisner.
Richard
[^] # Re: Vivement qu'on arrete de s'enfoncer
Posté par Richard Van Den Boom . En réponse à la dépêche GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration. Évalué à 3.
Je suis un programmeur plutôt genre gros nase (globalement, j'ai fais du fortran durant mes études de physique). Je me suis mis à Python et avec PyQT, j'ai pu coder une application graphique à peu près décente en environ un mois de boulot pas vraiment acharné, apprentissage du langage et de l'API PyQT inclus.
En quoi est-ce donc "lourd à programmer"?
Qu'est-ce que XUL (donc les exemples d'utilisation actuels genre Mozilla sont pas vraiment révélateurs de grandes possibilités suplémentaires par rapport aux autres toolkits) peut changer à ça?
Je ne dis pas que tu as tort mais ne connaissant pas XUL, je n'en vois pas trop l'avantage pour le moment.
Richard.
[^] # Re: Lost in translation
Posté par Richard Van Den Boom . En réponse à la dépêche Lost in translation. Évalué à 1.
Même dans les films moins cons (genre "le goût des autres"), la réalisation reste tout de même très plate. A croire que les français ne connaissent que le plan américain, ce qui ne manque pas de sel dans la discussion présente....
Richard
[^] # Re: Lost in translation
Posté par Richard Van Den Boom . En réponse à la dépêche Lost in translation. Évalué à 1.
Richard
[^] # Re: Kernel 2.6.0 annoncé stable
Posté par Richard Van Den Boom . En réponse à la dépêche Le noyau Linux 2.6.0 annoncé stable. Évalué à 3.
Cela dis, je vais passer en mode packet, je pense, vue que l'évolution a l'air d'aller dans ce sens.
Richard
[^] # Re: drivers wacom
Posté par Richard Van Den Boom . En réponse à la dépêche Le noyau Linux 2.6.0 annoncé stable. Évalué à 1.
Richard