Et voilà. Lorsque firefox quittera, la session X se terminera et ce sera ton gestionnaire de connexion (KDM en l'occurence) qui s'appercevra de la déconnexion. Un petit coup de javascript pour mettre firefox en plein écran et hop autant de RAM en plus pour naviguer.
Sinon, pour lancer une commande externe en JavaScript, même signé, je ne pense pas que ça soit possible. En tous les cas, j'avais cherché à faire un truc dans le genre, mais j'ai laissé tombé, vu que je n'ai absolument rien trouvé. La signature, il me semble, sert juste à accéder à certaine partie critique du navigateur. Ça serait de toute façon un tel nid potentiel de trou de sécurité, que c'est pas plus mal que ça n'existe pas.
Si j'avais la motivation, je réécrirais complètement la gestion colorimétrique de cups, d'autant plus qu'au taf j'ai tout le matériel qu'il faut pour générer des profils ICC de bonne qualité (spectro). Le CM dans cups est vraiment nullissime. Mais le problème, c'est qu'il y a aussi les applications qui doivent coopérer un petit peu (mais le plus gros boulet, c'est de loin cups).
Mon conseil : utiliser une postscript couleur (je sais c'est pas donné, mais au moins c'est l'imprimante qui fera la conversion).
Fait aussi gaffe avec les threads perl. Ça ne fonctionne pas vraiment comme les threads POSIX. Ça ressemble plus à un fork, qu'à un pthread_create. Par défaut, les threads ne voient pas les variables des autres "threads", il faut explicitement les partager (attribut "shared" ou l'instruction "share"). J'ai trouvé ça plutôt étrange au début. Sans compter que certaines opérations ne fonctionnent pas sur les variables partagées (splice), j'ai aussi eu des cas où tout l'interpréteur perl bloquait sur un appel Win32 (package Win32::Services de mémoire). Bref, les threads en perl ça m'a laissé un arrière goût de bidouille.
Sinon, pour le message d'erreur, je confirme qu'il te faudra recompiler perl.
Ben, justement, je l'ai installé à partir de rien. Il n'y a pas d'extension, aucune configuration exotique, juste un firefox sorti de la boite.
D'ailleurs c'était assez amusant, j'étais en train de faire une démo à distance sur une machine où il n'y avait que IE, et pouf à chaque fois que je le lançais il me coupait la connexion :-( J'ai mis alors le renard de feu, et celui-là plantait lorsque je créais ce foutu tableau en DHTML. Murphy était avec moi sur ce coup là, pas de doute ....
Arf, j'ai utilisé la version Windows du jour, je n'ai pas encore testé sous Linux. En tous cas, je viens encore de le télécharger sur mon Win XP de mon home chez moi : ben ça crash toujours autant. Au boulot, il y avait du Windows 2000 (mais je ne pense pas que ça influt).
Euh, je ne sais pas si tu as regardé le code source de la page, mais la css tiens en 5 lignes de code ....
Pour le bugzilla, j'avoue avoir la flemme de créer un compte . Donc, non, je n'ai pas encore soumis un bug report. J'aimerais juste savoir si d'autres ont aussi se problème avant.
C'est le premier bloc que ta machine va lire au démarrage, on y place en général le programme d'amorçage du système (ou plutôt un pointeur vers ...). Il n'y a que Microsoft qui s'entête à ne reconnaître que ses foutus rejetons, sous Linux ils sont un peu plus coopératifs.
Posté par pierthi .
En réponse au message Windows98.
Évalué à 2.
Que faire ?
Donner ce message d'erreur !
Bah sinon, taper "lilo" en ligne de commande (avec les droits administrateurs), devrait remettre en état le MBR de ton disque, dès fois qu'il était endommagé par les petits lutins. Ça fait quand même belle lurette que Windows 98 et Linux savent cohabiter. Le seul intérêt de réinstaller Windows, c'est lorsqu'il se sera auto-détruit.
Je te rapelle qu'en réinstallant Windows, ce dernier aura la gentillesse de te flinguer ton MBR en te rendant inaccessible ton systèmre Linux, il faudra que tu remettes les CD mandrake d'origine pour le restaurer.
Pour passer de KDE à gnome, il suffit de se déloguer, tu va retomber sur l'écran de connexion (j'imagine que tu utilises l'autologin de la mandriva), puis tu pourras choisir ton environnement dans un menu déroulant. Quand tu redémarreras, ça sera de nouveau celui-ci qui apparaîtra.
C'est bien beau de chambouler toutes les lettres, mais quid des raccourcis clavier dans les applications ?
Au hasard Ctrl+[CVX] pour le copier/coller, qui sont quand même assez bien placé sur un clavier "standard". J'ose même pas imaginer la torture que ça doit être sous Emacs un tel clavier (ou pire vi :-), sans parler de toutes ces applications qui ne permetent pas de redéfinir les touches ...
Donc, voilà, j'aimerais bien savoir si ça a posé problème à ceux qui ont adopté un tel clavier ...
Mouais, pas la peine de chercher les poux non plus, hein ...
C'est clair que l'horloge est un élément primordial du système hein ... Pour le splash screen clair qu'ils auraient du refaire un moteur 3d en 48ko (non-strippé et symbole de debug actif) tournant sur un P100 avec 8Mo de RAM. Ben voyons.
Quant à XRender et composite, si ça fait pratiquement un an qu'on attend une version un peu près stable, c'est que ça ne doit pas être facile d'accès. Et pourquoi taper sur les devs de E17, ceux de KDE et de Gnome pourraient aussi s'y mettre, non mais ...
#page :
- margin-left : si tu veux centrer ton div avec une largeur fixe de 750px, met plutôt margin-left et margin-right à auto. De cette manière les marges seront calculées pour automatiquement centrer ton document dans le contenant (la fenêtre du navigateur en l'occurence). Le mieux est de ne pas spécifier de largeur, mais de spécifier une marge gauche et droite : comme ça ton contenu s'adaptera à la largeur de la fenêtre du navigateur : c'est mieux pour l'accessibilité.
- position : absolute. J'aurais rien mis ici et laisser ton élément dans le flot normal.
Les autres #div
- position : idem. Pas la peine de les mettre absolute. À moins que tu voulais dire "fixed" (marche pas sous IE, qui l'interprète comme absolute), pour conserver par exemple ton menu quelque soit l'endroit où tu scrolles ton document.
Ah oui, Objective C ! Je l'avais oublié celui-là. Bon, faut dire qu'à part ce qui tourne autour d'[Open|Next]Step, je ne connais pas beaucoup de cas où il a été utilisé en production. Je ne connais pas trop la productivité qu'on peut atteindre avec. Surtout que sous Windows, il a l'air quasiment inexistant, donc forcément ça limite un peu l'intérêt.
Sinon pour compléter encore un peu le descriptif, j'avais oublié les points suivants :
Perl :
- Extensions (package) écrit dans d'autres langages que perl sont assez gores à développer.
Python (résumé des commentaires - on a dit dicaïdor) :
+ Syntaxe simple et intuitive
+ Rapide avec Pyrex (pas trop testé) ?
+ Bibliothèque standard complète, extension facile à intégrer (même dans d'autres langages ?).
- Lent, voire très lent, en interprété.
Javascript :
+ Approche objet très sympa. Mon préféré, de loin.
+ Framework HTML DOM v2 assez bien fait (mais ne couvre pas tout, volontairement).
- Fortement associé au Web.
- Internet Explorer
- Pas d'arithmétique entière (on peut contourner avec pas mal de bidouille).
C# :
- windows.forms : c'est un peu l'équilavent de SWT de java, detenu par Microsoft (pas normalisé, changements en douce, éventuellement brevets). Cela dit, les devs de mono ont l'air sacrément enragé.
- "This program cannot be run under dos mode" Mouhahahaha.
4D :
+ Cross plateforme Mac OS 1.0 à Mac OS X et Windows 95 à XP (sans doute même 3.1, avec interface native).
- La version Windows est nulle (Force à utiliser une interface MDI : beurk).
Realbasic :
- La version Linux/GTK2 ne fonctionne que sur x86 évidemment (avec pas mal de limitations dans le framework).
Pour les dicaïdors qui arpentent ce site, je pense qu'il peut-être intéressant de résumer vite fait les avantages / inconvénients des langages actuels. Veuillez laisser les trolls au vestiaire, s'il vous plait :
C :
+ Complètement rodé
+ Peut tout faire
- On doit tout faire
- Framework souvent (très) pénible
-/+ Doc : le pire cotoie souvent le meilleur
C++ :
+ Vraie couche objet
- Portabilité douteuse
- Syntaxe (souvent) imbitable
- Framework bas niveau
c# :
+ Bon framework
- Une partie du framework est détenu par Microsoft
Perl :
+ Très bonne portabilité (Windows / et quasiment tous les Unix)
+ Framework intéressant (CPAN)
+ Documentation (du moins la v5.8)
- Subtilité syntaxique à consommer avec modération
- Pas d'API graphique unifiée (Windows / Unix)
Java :
+ Framework excellent
+ Rapide sous Windows
- Lent sous Linux (en attendant gcj)
- Lourd (JRE à déployer, pas dans toutes les distribs Linux, en attendant gcj)
- Consomme beaucoup de RAM
Caml :
+ Syntaxe logique
+ Rapide
- élitiste, peu de compétences (par rapport aux autres langages, hein)
-/+ Framework ?
Alleé zou dans la foulée, quelques langages proprios :
4D :
+ Simple et productif
+ Excellente intégration des services webs (HTTP, XML, XSL) avec une base de données.
+ Documentation exhaustive, avec tutoriel et exemple de code abondants, libre d'accès.
- Syntaxe nullissime (dépendante de la locale ...)
- Lent, cher et ultra proprio (il y eu des efforts pour la v2004)
- bug, bug, bug, bug, bug, bug, bug, et encore des bugs.
Realbasic :
+ Simplissime et productif
+ Framework très sympa (cross plateforme Linux GTK2 / Mac OS X / Windows)
+ Entreprise très réactive
- Format des fichiers propriétaires.
-/+ Doc
Visualbasic :
+ Simple et productif
- Bug, bug, bug, bug.
- Lourd à déployer (dll et co)
- Syntaxe nullissime (dépendante de la locale ...)
- Documentation
C'est un peu près tout ce que j'ai du testé (python, caml) ou du mettre en production un jour (le reste), et si on pouvait compléter les autres (genre PHP, ruby, ...). tout ça pour dire, que j'attends toujours le langage idéal qui pourrait convenir à tous les besoins. Techniquement qu'on ne vienne pas me dire que c'est infaisable ...
<avis perso>gcj a le potentiel de tout déchirer</avis perso>
Bon, ok, il existe un thème XP/2000/3.1 pour GTK sous Windows. C'est vrai que ça a nettement plus de gueule comme ça, que le look par défaut. Mais au risque de passez pour un enculeur de mouche, l'intégration des wxWidgets est bien mieux foutue que GTK : il utilise directement l'API Win32 qui dessine le widget et controle son comportement sous Windows (et Mac OS X, et ...). Je mettrais ma tête à couper que sous GTK tout est refait de A à Z. Résultat, quand Longhorn sortira ou qu'un nouveau thème sous XP est dispo, une appli GTK jurera encore une fois. Sans parler des dialogues non standard (sélecteur de fichier à la gnome), et je parirai même qu'il y a des différence de comportement entre les widgets GTK et ceux de Windows. Je n'ai pas testé d'appli GTK sous Mac OS X, mais je pense que ça doit être encore plus fragrant, même avec le meilleur thème du monde possible.
En tous les cas, j'aurai fait pareil qu'eux si j'avais à bien intgérer une appli sous Windows, Linux et Mac OS X (faut dire que ça courre pas les rues les toolkits cross-plateforme).
Bah, à voir les scrineshoutes des wxWidgets, je dirais l'intégration dans Windows et Mac OS X, en utilisant le look natif du système d'exploitation. Ben ouais, GTK c'est mignon, mais en dehors de Linux, ça jure un peu.
Ah ben tiens, moi aussi j'ai installé une Ubuntu récemment. Bon, elle aura duré deux semaines, je l'ai remplacé par une Mandriva LE2005. J'avais pourtant fait une installation en mode "boulet" : suivant, suivant, suivant, reboot. Les détails que j'ai trouvés chiant :
- Tiens à l'installation il ne m'a pas demandé si j'avais une connexion ADSL. J'ai du passé par ppoe-config en root, paumé dans /usr/sbin. J'ai du manquer quelque chose ...
- Grub en mode console 80x24 blanc sur noir. Bon, faut pas avoir le blues.
- l'OSD ne fonctionnait pas avec mplayer !! J'avais pourtant installé le package avec les fontes (en fait tous les packages commençant par mplayer* dans synaptic). Et compilé sans la moindre optimisation même en i686. Recompilation manuelle (2x fois plus rapide, quand même sur un p4).
- Gnome il est mignon, y a pas à dire. Plus rapide que KDE. Même si nautillus a subi une sacré cure d'amaigrissement (d'un point de vue fonctionnel). Par contre, il y avait une écriture continue sur le DD (genre quelques Ko par sec), alors que la machine ne faisait strictement rien (qui semblait provenir de gconf en jouant avec les kill -9). Bon, ben, retour sous XFCE.
- UTF8. Bon, ok, UTF8 c'est l'avenir. C'est de loin ce qui a foutu la plus grosse pagaille sur ma machine. Avec une super feature qui purge argc et argv de certains programmes que j'ai du forcer en iso8859 (apparemment dans certaines lib X11, Xt il me semble, mais après une journée à débugger, j'ai laissé tomber). Franchement une cohabitation me parait plus que nécessaire.
- ntp ne fonctionnait pas. Pas de synchronisation et le daemon quittait au bout d'un quart d'heure. Bon, c'était à la fin, la petite goute d'eau qui a fait déborder le vase. Je n'avais plus vraiment l'énergie de mettre les mains dans le camboui.
Sinon, les trucs que j'avais bien aimé :
- synaptic. Très bien foutu ce gestionnaire de package.
- très bonne reconnaisance du matériel : sans faute.
D'ailleurs suis-je le seul à avoir remarquer que gecko dans Mozilla (sans doute dans le renard de feu aussi) sous Windows s'adapte thème choisi (Playskool XP ou Windows classique), pour les widgets n'ayant aucun style personnalisé.
Si le moche est ce que recherche certains, ce sympa bien de ne pas l'imposer à d'autres qui essaieraient d'avoir un bureau un tant soit peu homogène.
Linux deviendrait-il le parent pauvre pour l'intégration des LL ?
Moi je fais partie des rares personnes à bien aimer la XLib
Mouarf, toi, tu n'as jamais du approcher les X Input Method, les X Output Method, les X Output Context et les X Input Context. C'est ce qui permet par exemple de gérer la saisie des touches composites, comme les accents latins (et non, les keysyms seuls ne suffisent pas) ou les caractères chinois et co. Ok, c'est complet, mais niveau masturbation intellectuelle, ils ont fait très très fort. Tellement fort d'ailleurs que xorg envisage de simplifier voire virer complètement tout ce beau foutoir. Il me semble que c'était Keith Packard lui même qui avait sorti un article au vitriol de ce coté obscur de la Xlib. Argh, retrouve plus le lien ...
À part ça, c'est vrai que la Xlib contient pas mal de concept intéressant. J'ai vraiment bien aimé l'architecture objet de Xt (infiniment mieux foutu que celui de GTK). Mais ça reste très bas niveau, et quand tu veux faire les choses de manière vraiment portable (saisie de chaines, dessin sur du TrueColor, PseudoColor, Palette, Monochrome, chargement d'images, UTF-8, XFT, etc, etc ...), les lignes de codes croissent exponentiellement.
Bah, des resource sur la Xlib, ce n'est pas ce qui manque. Cela dit, le manuel dont tu fais mention, ne me parait pas super complet et encore moins didactique. Pour un autre un peu plus complet il y a http://www.hezt.net/~larson/frekko/Xlib/contents.html(...)
Bon, ça reste bas niveau, il faut s'accrocher (pour la partie XIM [Chapitre 13], je te conseille d'éloigner tout objet contendant de ta machine, on sait jamais ... ;-).
Les mots-clés magiques pour google sont : "SUPER-UX Xlib Programming Manual" (sans le SUPER-UX, il y a pas mal de bruit).
Sinon, tu as l'intention de reprogrammer QT ou GTK ? Parce que sinon, vaut mieux se tourner vers un de ces toolkits, tant la programmation Xlib est pénible.
Excellent, j'ai l'impression de lire une description de Mac OS X. En tous les cas, merci, tu m'as convaincu d'essayer Gnome 2.10. Je suis même certain que KDE ne vas plus faire long feux sur ma machine.
J'avais aussi laissé tombé gnome pour ses revirements multiples, son coté sous-produit de KDE et la petite touche "usine à gaz". Je suis content de voir qu'ils ont l'air d'avoir bien rectifié le tir.
Ce que je reproche à KDE, c'est de ne pas savoir faire des choix : on propose tout pour satisfaire les habitudes de tout le monde, quitte à avoir une interface lourdingue au possible (konqueror est effectivement un cas d'école). Mais bon, les habitudes ça se change. Gnome semble avoir fait des choix et les assume, quitte à ne pas plaire (dans un premier temps) à tout le monde.
Ah ben moi je trouve que c'est un choix extrêmement mauvais.
Clairement, ça amuse qui de revoir son driver tous les six mois parce que l'API a complètement changée ? Se replonger dans les docs (quand il y en a, et vu que ça change souvent, il faut encore prier pour qu'elles soient à jour), retoucher le code, juste pour que ça fonctionne comme avant.
Apple à réussi à fournir une API relativement évolutive et assez générique (IOKit), je doute que sur Windows, la compatibilité soit flinguée à chaque rc. À mon avis le Hurd pourra enfoncer Linux à ce niveau.
Il me semble que Linus n'a jamais voulu s'occuper de ça. Pour lui, une API stable passe forcément par un organisme (Posix, ISO, ....). En attendant ce jour très lointain et hautement hypothétique, je salut le courage de tous ceux qui s'investisse là dedans. Je l'ai fait il y a un ou deux ans, et je n'ai clairement pas trouvé ça fun.
Bon, je précise ma pensée, parce que je ne me trouve pas très clair.
Quand on a compris que le but du Web c'est de mettre en page (CSS) de l'information (XHTML, HTML), je pense qu'on a compris ce qu'est et surtout ce que sera le Web. Et même mieux : ce qu'on peut s'attendre à y trouver, et ce qu'il ne devrait pas y être.
L'exemple du son d'Arno est typique de quelqu'un qui n'a pas tout a fait saisi les implications des technologies Web. Il y a tellement de façon de faire pour intégrer le son (façon table de mixage, façon simple musique d'ambiance), sans parler de l'accessibilité (et oui encore), car si un webmaster peut à la limite en avoir rien à foutre, le W3C doit prendre en compte ces cas de figures : et là on se rend compte qu'on s'arrache bien vite les cheveux si on veut bien faire les choses.
L'exemple du SVG est à double tranchant : on peut l'utiliser pour représenter des images vectorielles pour compléter un texte (très intéressant donc), comme faire une mise en page avec ça (et là on retombe sur les dérives du tout flash).
Le web n'a pas les mêmes priorités, ni les mêmes ambitions que le flash et je pense que le W3C ne tient surtout pas à répéter les erreurs du passé avec un langage fourre tout, aux résultats aléatoires, bien souvent décevants et exténuant à adapter sur chaque configuration. Ça impose des compromis, soit on l'accepte, soit on va voir ailleurs.
Mouais, j'ai l'impression que beaucoup de webmasters se sentent frustrés par les technos XHTML/CSS/JavaScript parce que ça ne fait pas autant de chose que Flash, Illustrator ou 3D Studio Max. J'ai l'impression qu'ils veulent appliquer le monde de la PAO (où tout est calibré : couleurs, positions, polices, dimensions) au monde du Web (où le media de sortie est complètement imprévisible).
Je me doute bien que pour une large majorité de webmasters, l'accessibilité aux mal-voyants n'est qu'un délire de geeks pour venir pleunicher que le site passe mal sur d'autres navigateurs. Pourquoi j'irai me casser la tête pour une infime minorité : autant coder tout en dur pour la majorité.
P...n je ne comprends vraiment pas où est le malaise : XHTML donne un sens à l'info, CSS la met en page, JavaScript pour un peu d'interactivité. Et il y en a pour raler qu'on ne peut pas piloter le grille-pain pour imprimer la météo sur les toasts ? Ben, non, ce n'est pas le but.
Dire du mal des CSS est peut-être un exercice original, cela serait mieux avec des arguments qui tiennent la route
Bah, je trouve que les critiques envers CSS sont assez justes. C'est (parfois) assez pénible de positionner les éléments d'une page en CSS pur. Sans parler d'IE avec son support merdique des PNG (rien qu'avec ça on pourrait déjà bien s'amuser) ou de l'attribut fixed et de son modèle de boîte foireux. Il y a de quoi s'énerver, surtout lorsqu'en bouillie HTML on arrive à faire des trucs sympa sans trop d'efforts (au hasard les layouts avec tables).
Mais bon, le Web évolue. Quand on voit la direction qu'il prenait vers la fin 2000, il y avait de quoi être pessimiste. Ce n'est pas encore parfait, certes, mais il y a déjà largement de quoi s'amuser avec ce qu'il y a.
[^] # Re: Non !
Posté par pierthi . En réponse au message un lien web qui envois une commande systeme. Évalué à 4.
Édite simplement ton .xsession ou .xinitrc en mettant
#!/bin/sh
firefox http://ma.page.oueb/(...)
Et voilà. Lorsque firefox quittera, la session X se terminera et ce sera ton gestionnaire de connexion (KDM en l'occurence) qui s'appercevra de la déconnexion. Un petit coup de javascript pour mettre firefox en plein écran et hop autant de RAM en plus pour naviguer.
Sinon, pour lancer une commande externe en JavaScript, même signé, je ne pense pas que ça soit possible. En tous les cas, j'avais cherché à faire un truc dans le genre, mais j'ai laissé tombé, vu que je n'ai absolument rien trouvé. La signature, il me semble, sert juste à accéder à certaine partie critique du navigateur. Ça serait de toute façon un tel nid potentiel de trou de sécurité, que c'est pas plus mal que ça n'existe pas.
# Il était une fois ...
Posté par pierthi . En réponse au message Impression couleur sous Linux avec imprimante HP. Évalué à 2.
Si j'avais la motivation, je réécrirais complètement la gestion colorimétrique de cups, d'autant plus qu'au taf j'ai tout le matériel qu'il faut pour générer des profils ICC de bonne qualité (spectro). Le CM dans cups est vraiment nullissime. Mais le problème, c'est qu'il y a aussi les applications qui doivent coopérer un petit peu (mais le plus gros boulet, c'est de loin cups).
Mon conseil : utiliser une postscript couleur (je sais c'est pas donné, mais au moins c'est l'imprimante qui fera la conversion).
# Thread perl
Posté par pierthi . En réponse au message les threads .... Évalué à 3.
Sinon, pour le message d'erreur, je confirme qu'il te faudra recompiler perl.
[^] # Re: oui mais non ...
Posté par pierthi . En réponse au message Crash de Firefox 1.0.6. Évalué à 2.
D'ailleurs c'était assez amusant, j'étais en train de faire une démo à distance sur une machine où il n'y avait que IE, et pouf à chaque fois que je le lançais il me coupait la connexion :-( J'ai mis alors le renard de feu, et celui-là plantait lorsque je créais ce foutu tableau en DHTML. Murphy était avec moi sur ce coup là, pas de doute ....
[^] # Re: oui mais non ...
Posté par pierthi . En réponse au message Crash de Firefox 1.0.6. Évalué à 2.
[^] # Re: Bugzilla
Posté par pierthi . En réponse au message Crash de Firefox 1.0.6. Évalué à 2.
Pour le bugzilla, j'avoue avoir la flemme de créer un compte . Donc, non, je n'ai pas encore soumis un bug report. J'aimerais juste savoir si d'autres ont aussi se problème avant.
[^] # Re: Suggestions ...
Posté par pierthi . En réponse au message Windows98. Évalué à 2.
Wikipedia et google sont aussi là pour t'aider ...
http://fr.wikipedia.org/wiki/Master_boot_record(...)
C'est le premier bloc que ta machine va lire au démarrage, on y place en général le programme d'amorçage du système (ou plutôt un pointeur vers ...). Il n'y a que Microsoft qui s'entête à ne reconnaître que ses foutus rejetons, sous Linux ils sont un peu plus coopératifs.
# Suggestions ...
Posté par pierthi . En réponse au message Windows98. Évalué à 2.
Donner ce message d'erreur !
Bah sinon, taper "lilo" en ligne de commande (avec les droits administrateurs), devrait remettre en état le MBR de ton disque, dès fois qu'il était endommagé par les petits lutins. Ça fait quand même belle lurette que Windows 98 et Linux savent cohabiter. Le seul intérêt de réinstaller Windows, c'est lorsqu'il se sera auto-détruit.
Je te rapelle qu'en réinstallant Windows, ce dernier aura la gentillesse de te flinguer ton MBR en te rendant inaccessible ton systèmre Linux, il faudra que tu remettes les CD mandrake d'origine pour le restaurer.
Pour passer de KDE à gnome, il suffit de se déloguer, tu va retomber sur l'écran de connexion (j'imagine que tu utilises l'autologin de la mandriva), puis tu pourras choisir ton environnement dans un menu déroulant. Quand tu redémarreras, ça sera de nouveau celui-ci qui apparaîtra.
[^] # Re: Question conne ...
Posté par pierthi . En réponse au message Dvorak contre Dvorak-fr contre Azerty. Évalué à 2.
Au hasard Ctrl+[CVX] pour le copier/coller, qui sont quand même assez bien placé sur un clavier "standard". J'ose même pas imaginer la torture que ça doit être sous Emacs un tel clavier (ou pire vi :-), sans parler de toutes ces applications qui ne permetent pas de redéfinir les touches ...
Donc, voilà, j'aimerais bien savoir si ça a posé problème à ceux qui ont adopté un tel clavier ...
[^] # Re: e17 c'est vraiment bien mais...
Posté par pierthi . En réponse au journal E17 - Build script. Évalué à 2.
C'est clair que l'horloge est un élément primordial du système hein ... Pour le splash screen clair qu'ils auraient du refaire un moteur 3d en 48ko (non-strippé et symbole de debug actif) tournant sur un P100 avec 8Mo de RAM. Ben voyons.
Quant à XRender et composite, si ça fait pratiquement un an qu'on attend une version un peu près stable, c'est que ça ne doit pas être facile d'accès. Et pourquoi taper sur les devs de E17, ceux de KDE et de Gnome pourraient aussi s'y mettre, non mais ...
# W3C, CSS2, Chapitre 8 et 9
Posté par pierthi . En réponse au message [CSS] bordure et position absolute. Évalué à 3.
Il y a pas mal de trucs qui clochent dans ta css.
#page :
- margin-left : si tu veux centrer ton div avec une largeur fixe de 750px, met plutôt margin-left et margin-right à auto. De cette manière les marges seront calculées pour automatiquement centrer ton document dans le contenant (la fenêtre du navigateur en l'occurence). Le mieux est de ne pas spécifier de largeur, mais de spécifier une marge gauche et droite : comme ça ton contenu s'adaptera à la largeur de la fenêtre du navigateur : c'est mieux pour l'accessibilité.
- position : absolute. J'aurais rien mis ici et laisser ton élément dans le flot normal.
Les autres #div
- position : idem. Pas la peine de les mettre absolute. À moins que tu voulais dire "fixed" (marche pas sous IE, qui l'interprète comme absolute), pour conserver par exemple ton menu quelque soit l'endroit où tu scrolles ton document.
Petit exemple sur http://perso.b2b2c.ca/tpierron/test.html(...)
La clé c'est d'utiliser margin-left et margin-right à auto pour centrer tes éléments. Bref relis les chapitres en question ...
[^] # Re: Le bilan
Posté par pierthi . En réponse au journal Le C++ du futur. Évalué à 1.
Sinon pour compléter encore un peu le descriptif, j'avais oublié les points suivants :
Perl :
- Extensions (package) écrit dans d'autres langages que perl sont assez gores à développer.
Python (résumé des commentaires - on a dit dicaïdor) :
+ Syntaxe simple et intuitive
+ Rapide avec Pyrex (pas trop testé) ?
+ Bibliothèque standard complète, extension facile à intégrer (même dans d'autres langages ?).
- Lent, voire très lent, en interprété.
Javascript :
+ Approche objet très sympa. Mon préféré, de loin.
+ Framework HTML DOM v2 assez bien fait (mais ne couvre pas tout, volontairement).
- Fortement associé au Web.
- Internet Explorer
- Pas d'arithmétique entière (on peut contourner avec pas mal de bidouille).
C# :
- windows.forms : c'est un peu l'équilavent de SWT de java, detenu par Microsoft (pas normalisé, changements en douce, éventuellement brevets). Cela dit, les devs de mono ont l'air sacrément enragé.
- "This program cannot be run under dos mode" Mouhahahaha.
4D :
+ Cross plateforme Mac OS 1.0 à Mac OS X et Windows 95 à XP (sans doute même 3.1, avec interface native).
- La version Windows est nulle (Force à utiliser une interface MDI : beurk).
Realbasic :
- La version Linux/GTK2 ne fonctionne que sur x86 évidemment (avec pas mal de limitations dans le framework).
# Le bilan
Posté par pierthi . En réponse au journal Le C++ du futur. Évalué à 8.
C :
+ Complètement rodé
+ Peut tout faire
- On doit tout faire
- Framework souvent (très) pénible
-/+ Doc : le pire cotoie souvent le meilleur
C++ :
+ Vraie couche objet
- Portabilité douteuse
- Syntaxe (souvent) imbitable
- Framework bas niveau
c# :
+ Bon framework
- Une partie du framework est détenu par Microsoft
Perl :
+ Très bonne portabilité (Windows / et quasiment tous les Unix)
+ Framework intéressant (CPAN)
+ Documentation (du moins la v5.8)
- Subtilité syntaxique à consommer avec modération
- Pas d'API graphique unifiée (Windows / Unix)
Java :
+ Framework excellent
+ Rapide sous Windows
- Lent sous Linux (en attendant gcj)
- Lourd (JRE à déployer, pas dans toutes les distribs Linux, en attendant gcj)
- Consomme beaucoup de RAM
Python :
+ Syntaxe sympathique et simple
- Lent ?
- Framework ?
Caml :
+ Syntaxe logique
+ Rapide
- élitiste, peu de compétences (par rapport aux autres langages, hein)
-/+ Framework ?
Alleé zou dans la foulée, quelques langages proprios :
4D :
+ Simple et productif
+ Excellente intégration des services webs (HTTP, XML, XSL) avec une base de données.
+ Documentation exhaustive, avec tutoriel et exemple de code abondants, libre d'accès.
- Syntaxe nullissime (dépendante de la locale ...)
- Lent, cher et ultra proprio (il y eu des efforts pour la v2004)
- bug, bug, bug, bug, bug, bug, bug, et encore des bugs.
Realbasic :
+ Simplissime et productif
+ Framework très sympa (cross plateforme Linux GTK2 / Mac OS X / Windows)
+ Entreprise très réactive
- Format des fichiers propriétaires.
-/+ Doc
Visualbasic :
+ Simple et productif
- Bug, bug, bug, bug.
- Lourd à déployer (dll et co)
- Syntaxe nullissime (dépendante de la locale ...)
- Documentation
C'est un peu près tout ce que j'ai du testé (python, caml) ou du mettre en production un jour (le reste), et si on pouvait compléter les autres (genre PHP, ruby, ...). tout ça pour dire, que j'attends toujours le langage idéal qui pourrait convenir à tous les besoins. Techniquement qu'on ne vienne pas me dire que c'est infaisable ...
<avis perso>gcj a le potentiel de tout déchirer</avis perso>
Mes 2 cents.
[^] # Re: GTK / WxWidgets?
Posté par pierthi . En réponse à la dépêche Sortie d'Amaya 8.8 et 9.2. Évalué à 4.
Bon, ok, il existe un thème XP/2000/3.1 pour GTK sous Windows. C'est vrai que ça a nettement plus de gueule comme ça, que le look par défaut. Mais au risque de passez pour un enculeur de mouche, l'intégration des wxWidgets est bien mieux foutue que GTK : il utilise directement l'API Win32 qui dessine le widget et controle son comportement sous Windows (et Mac OS X, et ...). Je mettrais ma tête à couper que sous GTK tout est refait de A à Z. Résultat, quand Longhorn sortira ou qu'un nouveau thème sous XP est dispo, une appli GTK jurera encore une fois. Sans parler des dialogues non standard (sélecteur de fichier à la gnome), et je parirai même qu'il y a des différence de comportement entre les widgets GTK et ceux de Windows. Je n'ai pas testé d'appli GTK sous Mac OS X, mais je pense que ça doit être encore plus fragrant, même avec le meilleur thème du monde possible.
En tous les cas, j'aurai fait pareil qu'eux si j'avais à bien intgérer une appli sous Windows, Linux et Mac OS X (faut dire que ça courre pas les rues les toolkits cross-plateforme).
[^] # Re: GTK / WxWidgets?
Posté par pierthi . En réponse à la dépêche Sortie d'Amaya 8.8 et 9.2. Évalué à 1.
[^] # Re: GTK / WxWidgets?
Posté par pierthi . En réponse à la dépêche Sortie d'Amaya 8.8 et 9.2. Évalué à 3.
# Ubuntu Hoary
Posté par pierthi . En réponse au journal Ubuntu 5.04 vs WinXP SP2. Évalué à 9.
- Tiens à l'installation il ne m'a pas demandé si j'avais une connexion ADSL. J'ai du passé par ppoe-config en root, paumé dans /usr/sbin. J'ai du manquer quelque chose ...
- Grub en mode console 80x24 blanc sur noir. Bon, faut pas avoir le blues.
- l'OSD ne fonctionnait pas avec mplayer !! J'avais pourtant installé le package avec les fontes (en fait tous les packages commençant par mplayer* dans synaptic). Et compilé sans la moindre optimisation même en i686. Recompilation manuelle (2x fois plus rapide, quand même sur un p4).
- Gnome il est mignon, y a pas à dire. Plus rapide que KDE. Même si nautillus a subi une sacré cure d'amaigrissement (d'un point de vue fonctionnel). Par contre, il y avait une écriture continue sur le DD (genre quelques Ko par sec), alors que la machine ne faisait strictement rien (qui semblait provenir de gconf en jouant avec les kill -9). Bon, ben, retour sous XFCE.
- UTF8. Bon, ok, UTF8 c'est l'avenir. C'est de loin ce qui a foutu la plus grosse pagaille sur ma machine. Avec une super feature qui purge argc et argv de certains programmes que j'ai du forcer en iso8859 (apparemment dans certaines lib X11, Xt il me semble, mais après une journée à débugger, j'ai laissé tomber). Franchement une cohabitation me parait plus que nécessaire.
- ntp ne fonctionnait pas. Pas de synchronisation et le daemon quittait au bout d'un quart d'heure. Bon, c'était à la fin, la petite goute d'eau qui a fait déborder le vase. Je n'avais plus vraiment l'énergie de mettre les mains dans le camboui.
Sinon, les trucs que j'avais bien aimé :
- synaptic. Très bien foutu ce gestionnaire de package.
- très bonne reconnaisance du matériel : sans faute.
Mais bon, au final retour sous Mandrake.
[^] # Re: Un FireFox moins cloche
Posté par pierthi . En réponse au journal Un Firefox moins moche. Évalué à 2.
Si le moche est ce que recherche certains, ce sympa bien de ne pas l'imposer à d'autres qui essaieraient d'avoir un bureau un tant soit peu homogène.
Linux deviendrait-il le parent pauvre pour l'intégration des LL ?
[^] # Re: XLib
Posté par pierthi . En réponse au message Programmation Xlib. Évalué à 3.
Mouarf, toi, tu n'as jamais du approcher les X Input Method, les X Output Method, les X Output Context et les X Input Context. C'est ce qui permet par exemple de gérer la saisie des touches composites, comme les accents latins (et non, les keysyms seuls ne suffisent pas) ou les caractères chinois et co. Ok, c'est complet, mais niveau masturbation intellectuelle, ils ont fait très très fort. Tellement fort d'ailleurs que xorg envisage de simplifier voire virer complètement tout ce beau foutoir. Il me semble que c'était Keith Packard lui même qui avait sorti un article au vitriol de ce coté obscur de la Xlib. Argh, retrouve plus le lien ...
À part ça, c'est vrai que la Xlib contient pas mal de concept intéressant. J'ai vraiment bien aimé l'architecture objet de Xt (infiniment mieux foutu que celui de GTK). Mais ça reste très bas niveau, et quand tu veux faire les choses de manière vraiment portable (saisie de chaines, dessin sur du TrueColor, PseudoColor, Palette, Monochrome, chargement d'images, UTF-8, XFT, etc, etc ...), les lignes de codes croissent exponentiellement.
# Xlib
Posté par pierthi . En réponse au message Programmation Xlib. Évalué à 2.
Bon, ça reste bas niveau, il faut s'accrocher (pour la partie XIM [Chapitre 13], je te conseille d'éloigner tout objet contendant de ta machine, on sait jamais ... ;-).
Les mots-clés magiques pour google sont : "SUPER-UX Xlib Programming Manual" (sans le SUPER-UX, il y a pas mal de bruit).
Sinon, tu as l'intention de reprogrammer QT ou GTK ? Parce que sinon, vaut mieux se tourner vers un de ces toolkits, tant la programmation Xlib est pénible.
[^] # Re: Pourquoi pas KDE?
Posté par pierthi . En réponse au journal Gnome ou KDE ou....quoi ?. Évalué à 1.
J'avais aussi laissé tombé gnome pour ses revirements multiples, son coté sous-produit de KDE et la petite touche "usine à gaz". Je suis content de voir qu'ils ont l'air d'avoir bien rectifié le tir.
Ce que je reproche à KDE, c'est de ne pas savoir faire des choix : on propose tout pour satisfaire les habitudes de tout le monde, quitte à avoir une interface lourdingue au possible (konqueror est effectivement un cas d'école). Mais bon, les habitudes ça se change. Gnome semble avoir fait des choix et les assume, quitte à ne pas plaire (dans un premier temps) à tout le monde.
[^] # Re: Juste une question
Posté par pierthi . En réponse à la dépêche Nouveau rebondissement dans l'affaire du pilote PWC. Évalué à 2.
Ah ben moi je trouve que c'est un choix extrêmement mauvais.
Clairement, ça amuse qui de revoir son driver tous les six mois parce que l'API a complètement changée ? Se replonger dans les docs (quand il y en a, et vu que ça change souvent, il faut encore prier pour qu'elles soient à jour), retoucher le code, juste pour que ça fonctionne comme avant.
Apple à réussi à fournir une API relativement évolutive et assez générique (IOKit), je doute que sur Windows, la compatibilité soit flinguée à chaque rc. À mon avis le Hurd pourra enfoncer Linux à ce niveau.
Il me semble que Linus n'a jamais voulu s'occuper de ça. Pour lui, une API stable passe forcément par un organisme (Posix, ISO, ....). En attendant ce jour très lointain et hautement hypothétique, je salut le courage de tous ceux qui s'investisse là dedans. Je l'ai fait il y a un ou deux ans, et je n'ai clairement pas trouvé ça fun.
[^] # Re: PAO
Posté par pierthi . En réponse au journal Un article intéressant sur (X)HTML/CSS. Évalué à 4.
Quand on a compris que le but du Web c'est de mettre en page (CSS) de l'information (XHTML, HTML), je pense qu'on a compris ce qu'est et surtout ce que sera le Web. Et même mieux : ce qu'on peut s'attendre à y trouver, et ce qu'il ne devrait pas y être.
L'exemple du son d'Arno est typique de quelqu'un qui n'a pas tout a fait saisi les implications des technologies Web. Il y a tellement de façon de faire pour intégrer le son (façon table de mixage, façon simple musique d'ambiance), sans parler de l'accessibilité (et oui encore), car si un webmaster peut à la limite en avoir rien à foutre, le W3C doit prendre en compte ces cas de figures : et là on se rend compte qu'on s'arrache bien vite les cheveux si on veut bien faire les choses.
L'exemple du SVG est à double tranchant : on peut l'utiliser pour représenter des images vectorielles pour compléter un texte (très intéressant donc), comme faire une mise en page avec ça (et là on retombe sur les dérives du tout flash).
Le web n'a pas les mêmes priorités, ni les mêmes ambitions que le flash et je pense que le W3C ne tient surtout pas à répéter les erreurs du passé avec un langage fourre tout, aux résultats aléatoires, bien souvent décevants et exténuant à adapter sur chaque configuration. Ça impose des compromis, soit on l'accepte, soit on va voir ailleurs.
[^] # Re: PAO
Posté par pierthi . En réponse au journal Un article intéressant sur (X)HTML/CSS. Évalué à 5.
Je me doute bien que pour une large majorité de webmasters, l'accessibilité aux mal-voyants n'est qu'un délire de geeks pour venir pleunicher que le site passe mal sur d'autres navigateurs. Pourquoi j'irai me casser la tête pour une infime minorité : autant coder tout en dur pour la majorité.
P...n je ne comprends vraiment pas où est le malaise : XHTML donne un sens à l'info, CSS la met en page, JavaScript pour un peu d'interactivité. Et il y en a pour raler qu'on ne peut pas piloter le grille-pain pour imprimer la météo sur les toasts ? Ben, non, ce n'est pas le but.
Dire du mal des CSS est peut-être un exercice original, cela serait mieux avec des arguments qui tiennent la route
Bah, je trouve que les critiques envers CSS sont assez justes. C'est (parfois) assez pénible de positionner les éléments d'une page en CSS pur. Sans parler d'IE avec son support merdique des PNG (rien qu'avec ça on pourrait déjà bien s'amuser) ou de l'attribut fixed et de son modèle de boîte foireux. Il y a de quoi s'énerver, surtout lorsqu'en bouillie HTML on arrive à faire des trucs sympa sans trop d'efforts (au hasard les layouts avec tables).
Mais bon, le Web évolue. Quand on voit la direction qu'il prenait vers la fin 2000, il y avait de quoi être pessimiste. Ce n'est pas encore parfait, certes, mais il y a déjà largement de quoi s'amuser avec ce qu'il y a.
# Message d'erreur ?
Posté par pierthi . En réponse au message ca menerve!!!!!. Évalué à 3.
Déjà si tu commençais par donner le message d'erreur affiché par xorg, je pourrais peut-être te donner un commencement de solution.
Au hasard tu n'aurais pas tenté d'installer une accélération OpenGL et (mal) modifié ton /etc/X11/xorg.conf ?