Posté par Obsidian .
En réponse au message 2.6.18.
Évalué à 2.
Oui, ndiswrapper propose une application portant le même nom pour l'administrer, mais il s'agit avant tout d'un module du noyau, ce qui signifie que si tu as recompile le tien, il faut également recompiler le module ndiswrapper. C'est d'ailleurs vrai pour tout ce qui utilise un module dédié.
L'exemple-type est les pilotes des cartes NVidia (et probablement ATI). A chaque fois que tu recompiles le noyau et que tu redémarres, tu te retrouves face à un "crash' du serveur X (en fait un non-démarrage, puisque le pilote spécifié dans le fichier de conf n'existe plus).
Puisque tu te poses la question, c'est une bonne idée de recompiler son noyau quand on fait du Wifi sous Linux car sa prise en charge est encore relativement restreinte et les différents acteurs du système continuent à évoluer, comme par exemple l'API Wext du noyau Linux, ce qui donne le célèbre message (heureusement bénin) :
Driver for device wlan0 has been compiled with version 20 of Wireless Extension, while this program supports up to version 19. ...
Puisque tu en es à faire chauffer le compilo, je te suggère de télécharger et reconstruire :
- Ton noyau;
- La dernière version des wireless-tools;
- La dernière version de ndiswrapper.
Tu devrais ainsi te débarrasser de quelques warnings et gagner quelques fonctionnalités sans pour autant résoudre, malheureseument, d'autres problèmes plus sérieux comme la prise en charge correcte de WPA avec les pilotes libres ...
Essaie déjà un ifconfig -a pour voir si ton interface apparaît. Si ce n'est pas le cas, c'est par là qu'il faut commencer. Un module n'est visiblement pas chargé. Un petit lspci pour tenter de retrouver son modèle devrait t'aider.
En fait, CSS2 définit que l'attribut overflow s'appliquent aux éléments de type block, et les tables n'en font clairement pas partie.
En forçant "display: block" dans "tbody", j'arrive également à mes fins avec Konqueror, et le résultat est à peu près le même du coté de Mozilla. Evidement, le rendu ne ressemble à rien puisque l'on brise le modèle de table.
IE6 ne veut rien savoir. Pas de IE7 sous la main pour tester.
Vire le "display: block" de <tbody>, ce n'est pas un mode approprié pour une table (en plus de inline, block et none, il existe des modes standard spéciaux pour les tables).
S'il n'y a pas trop de contraintes sur la table et ses autres composantes (comme des hauteurs contradictoires), ça passe sans problème (chez moi, sur Firefox et Firebird).
Par contre, c'est catastrophique sous IE.
Si tu as une imprimante laser au bureau et de quoi relier des documents, je te conseille fortement d'imprimer les spécifications du HTML 4.01 (Le document sur XHtml ne fait qu'étendre celui-ci) et celles de CSS2. Elles pèsent 340 pages chacune, mais chaque volume contient non seulement la liste des balises, mais aussi celle des attributs classés par ordre alphabétique avec, pour chacun d'un, les balises auxquelles ils s'appliquent. En outre, le contenu est généralement très détaillé et chaque référence à une notion quelquonque exposée dans un paragraphe est accompagné du numéro de page précis où elle est définie.
Notament pour le coup du tableau. D'une, ça ne fait rien du tout (ou alors, je n'ai rien compris), ensuite, ça ne permet pas d'avoir des en-têtes fixes, un peu comme quand on fige les volets dans un tableur.
C'est-à-dire que overflow n'est pas propre à un tableau en général. Ensuite, pour que cela ait du sens, il faut également que l'élément concerné ait une taille définie. Sinon, il croît avec son contenu et la directive overflow reste sans objet.
Pour les entêtes de tableaux, il existe les balises <thead>, <tbody> et <tfoot> (au moins en XHTML), à définir à l'intérieur de <table></table>. Attention, <thead> et <tfoot> doivent être définis avant <tbody>. Ceci permet d'indiquer au navigateur quelles sont les données qui forment les entêtes et pieds de table, mais le rendu reste à sa charge. Leur réplication fonctionne bien à l'impression si la CSS a été définie pour le médium printer en particulier. Je n'ai pas essayé à l'écran. Tu dois probablement pouvoir figer une entête mais pas un panneau latéral. Le HTML n'a pas non plus vocation à devenir un tableur (qui eux-mêmes ne proposent pas tous cette fonctionnalité, de toutes façons).
Tu peux également essayer de mettre un <span> avec un overflow bien défini autour des cellules que tu veux scroller. Cela reste correct d'un point de vue syntaxique, mais sémantiquement, je ne pense pas que la DTD du XHTML te laisse le faire, et cela ne passera donc sûrement pas le validateur. Très gruik, donc. A essayer pour la bidouille, mais à ne pas livrer en production.
Le coup de l'image de fond, j'ai compris le principe, mais honnêtement, je trouve ça porc.... Ceci dit, si le html était un langage propre, ça se saurait !
Moi aussi, mais à y réflechir, cela a plus de sens qu'on ne le croit. Non seulement, c'est beaucoup plus léger, mais cela passe également avec tous les navigateurs, mêmes anciens, et cela revient en somme à remplir une sorte de "formulaire préimprimé", un peu comme une copie fournissant dès le départ le lignage et la marge.
En outre, une <div class="menu"> a encore du sens, mais si l'on se retrouve à utiliser des balises particulières et à classifier des informations de manière à contourner les limitations d'affichage du navigateur, alors on se remet à lier contenu et mise en page et on brise le concept même des CSS. A ce moment, il vaut mieux quand même revenir au fond d'écran, même si c'est décevant.
Pour sa défense, je suis quand même obligé de dire que quiquonque n'a pas été concrètement confronté à ce problème en CSS ne peut savoir réellement de quoi il s'agit.
C'est loin d'être un problème con. L'ajustement précis de la hauteur d'un élément est en problème qui émaille régulièrement les forums consacrés aux CSS. D'ailleurs, une petite recherche permet déjà d'obtenir de bons éléments de réponse.
Le problème de la manchette latérale est le suivant : ton <div> est un élément à priori relatif à son container parent, ici le <body>. Or, la taille de celui-ci n'est pas connue à l'avance car il dépend de son contenu. La plupart des gens assimile le corps du document au médium qui en fait le rendu, en l'occurence le moniteur. Dans le cas d'une imprimante à flot continu (type listing), par exemple, la hauteur maximum n'est pas fixée ...
Le problème du height: 100px est qu'il va effectivement utiliser la hauteur de l'écran. Mais si le contenu du corps est plus haut que l'écran, la manchette n'ira pas plus bas pour autant. Même chose pour le contenu de la manchette qui débordera hors des frontières si il est un minimum fourni.
Moi, j'ai fini par abandonner et j'ai " résolu " le problème en trichant : J'ai affecté une image de fond répétée à <body> qui dessine une manchette trompe-l'oeil et j'ai déclaré une division transparente dont la hauteur n'est pas définie. Cette manière de faire est également la plus légère pour le navigateur.
Pour le tableau à taille fixe mais avec des barre de défilement : overflow: auto.
Le bon sens nous pousse à utiliser un Makefile par répertoire, sauf cas particuliers où il n'y a rien à compiler ou à traiter d'une manière générale dans ces dépôts.
Ensuite, on compile en général toutes les sources et ressources d'un même module en un seul *.o local, puis le Makefile du premier niveau les assemble tous avec le main pour former l'exécutable final.
Après, cela dépend un peu de ton niveau en matière de Makefile. Tu n'es pas obligé d'utiliser de règles implicites ou autres optimisations dans le genre, mais il faut au minimum écrire correctement ses dépendances (tout l'intérêt d'un Makefile).
Oui, enfin, on se tord surtout les doigts sur des claviers AZERTY.
D'un autre coté, si la plupart des symboles ont quand même du sens (telles les accolades pour définir un bloc d'instructions), il faut bien reconnaître que la plupart des lexiques des langages informatiques (américains pour la plupart) ont été conçus en fonction de ce que le clavier proposait.
Oui, et c'est même très important de le faire, parce que cela permet d'être sûr, après coup, que l'on a résolu le problème, et que l'on ne s'est pas cantonné à tatonner jusqu'à ce que l'application ait l'air de fonctionner comme attendu.
# Troll ?
Posté par Obsidian . En réponse au journal [HS] Pour un athéisme de combat. Évalué à 6.
[^] # Re: Ah bon?
Posté par Obsidian . En réponse au message probleme de connection. Évalué à 2.
La Freebox, probablement.
# Recompile
Posté par Obsidian . En réponse au message 2.6.18. Évalué à 2.
L'exemple-type est les pilotes des cartes NVidia (et probablement ATI). A chaque fois que tu recompiles le noyau et que tu redémarres, tu te retrouves face à un "crash' du serveur X (en fait un non-démarrage, puisque le pilote spécifié dans le fichier de conf n'existe plus).
Puisque tu te poses la question, c'est une bonne idée de recompiler son noyau quand on fait du Wifi sous Linux car sa prise en charge est encore relativement restreinte et les différents acteurs du système continuent à évoluer, comme par exemple l'API Wext du noyau Linux, ce qui donne le célèbre message (heureusement bénin) :
Driver for device wlan0 has been compiled with version 20 of Wireless Extension, while this program supports up to version 19. ...
Puisque tu en es à faire chauffer le compilo, je te suggère de télécharger et reconstruire :
- Ton noyau;
- La dernière version des wireless-tools;
- La dernière version de ndiswrapper.
Tu devrais ainsi te débarrasser de quelques warnings et gagner quelques fonctionnalités sans pour autant résoudre, malheureseument, d'autres problèmes plus sérieux comme la prise en charge correcte de WPA avec les pilotes libres ...
# Faire fonctionner la carte réseau, déjà.
Posté par Obsidian . En réponse au message Zenwalk + neufbox =howto ?. Évalué à 3.
Essaie déjà un ifconfig -a pour voir si ton interface apparaît. Si ce n'est pas le cas, c'est par là qu'il faut commencer. Un module n'est visiblement pas chargé. Un petit lspci pour tenter de retrouver son modèle devrait t'aider.
# Onze pour une coupe
Posté par Obsidian . En réponse au journal Les 10 commandements du linuxien. Évalué à 9.
# En voila un :
Posté par Obsidian . En réponse au message Cherche patch ACL pour noyaux 2.4 récents. Évalué à 2.
http://acl.bestbits.at/download.html
C'est pas suffisant ?
[^] # Re: C'est pas très clair
Posté par Obsidian . En réponse au message Fixer arbitrairement une taille fixe à un élement.. Évalué à 3.
http://www.w3.org/TR/html401
http://www.w3.org/TR/xhtml1/ (étend la précédente)
http://www.w3.org/TR/CSS2/
Mais je te conseille les versions imprimables :
http://www.w3.org/TR/html401/html40.ps.gz (Postscript)
http://www.w3.org/TR/html401/html40.pdf.gz (PDF)
http://www.w3.org/TR/CSS2/css2.ps.gz (Postscript)
http://www.w3.org/TR/CSS2/css2.pdf (PDF)
Elles sont plus faciles à lire et à consulter.
Bon courage pour la suite.
[^] # Re: oui et en francais ca donne quoi ?
Posté par Obsidian . En réponse au message problème de démarrage. Évalué à 3.
Pour une fois que quelqu'un est contraint d'utiliser la console, on ne va pas l'en dissuader.
[^] # Re: C'est pas très clair
Posté par Obsidian . En réponse au message Fixer arbitrairement une taille fixe à un élement.. Évalué à 2.
En forçant "display: block" dans "tbody", j'arrive également à mes fins avec Konqueror, et le résultat est à peu près le même du coté de Mozilla. Evidement, le rendu ne ressemble à rien puisque l'on brise le modèle de table.
IE6 ne veut rien savoir. Pas de IE7 sous la main pour tester.
[^] # Re: C'est pas très clair
Posté par Obsidian . En réponse au message Fixer arbitrairement une taille fixe à un élement.. Évalué à 2.
S'il n'y a pas trop de contraintes sur la table et ses autres composantes (comme des hauteurs contradictoires), ça passe sans problème (chez moi, sur Firefox et Firebird).
Par contre, c'est catastrophique sous IE.
Si tu as une imprimante laser au bureau et de quoi relier des documents, je te conseille fortement d'imprimer les spécifications du HTML 4.01 (Le document sur XHtml ne fait qu'étendre celui-ci) et celles de CSS2. Elles pèsent 340 pages chacune, mais chaque volume contient non seulement la liste des balises, mais aussi celle des attributs classés par ordre alphabétique avec, pour chacun d'un, les balises auxquelles ils s'appliquent. En outre, le contenu est généralement très détaillé et chaque référence à une notion quelquonque exposée dans un paragraphe est accompagné du numéro de page précis où elle est définie.
[^] # Re: C'est pas très clair
Posté par Obsidian . En réponse au message Fixer arbitrairement une taille fixe à un élement.. Évalué à 2.
C'est-à-dire que overflow n'est pas propre à un tableau en général. Ensuite, pour que cela ait du sens, il faut également que l'élément concerné ait une taille définie. Sinon, il croît avec son contenu et la directive overflow reste sans objet.
Pour les entêtes de tableaux, il existe les balises <thead>, <tbody> et <tfoot> (au moins en XHTML), à définir à l'intérieur de <table></table>. Attention, <thead> et <tfoot> doivent être définis avant <tbody>. Ceci permet d'indiquer au navigateur quelles sont les données qui forment les entêtes et pieds de table, mais le rendu reste à sa charge. Leur réplication fonctionne bien à l'impression si la CSS a été définie pour le médium printer en particulier. Je n'ai pas essayé à l'écran. Tu dois probablement pouvoir figer une entête mais pas un panneau latéral. Le HTML n'a pas non plus vocation à devenir un tableur (qui eux-mêmes ne proposent pas tous cette fonctionnalité, de toutes façons).
Tu peux également essayer de mettre un <span> avec un overflow bien défini autour des cellules que tu veux scroller. Cela reste correct d'un point de vue syntaxique, mais sémantiquement, je ne pense pas que la DTD du XHTML te laisse le faire, et cela ne passera donc sûrement pas le validateur. Très gruik, donc. A essayer pour la bidouille, mais à ne pas livrer en production.
Moi aussi, mais à y réflechir, cela a plus de sens qu'on ne le croit. Non seulement, c'est beaucoup plus léger, mais cela passe également avec tous les navigateurs, mêmes anciens, et cela revient en somme à remplir une sorte de "formulaire préimprimé", un peu comme une copie fournissant dès le départ le lignage et la marge.
En outre, une <div class="menu"> a encore du sens, mais si l'on se retrouve à utiliser des balises particulières et à classifier des informations de manière à contourner les limitations d'affichage du navigateur, alors on se remet à lier contenu et mise en page et on brise le concept même des CSS. A ce moment, il vaut mieux quand même revenir au fond d'écran, même si c'est décevant.
[^] # Re: C'est pas très clair
Posté par Obsidian . En réponse au message Fixer arbitrairement une taille fixe à un élement.. Évalué à 3.
C'est loin d'être un problème con. L'ajustement précis de la hauteur d'un élément est en problème qui émaille régulièrement les forums consacrés aux CSS. D'ailleurs, une petite recherche permet déjà d'obtenir de bons éléments de réponse.
Le problème de la manchette latérale est le suivant : ton <div> est un élément à priori relatif à son container parent, ici le <body>. Or, la taille de celui-ci n'est pas connue à l'avance car il dépend de son contenu. La plupart des gens assimile le corps du document au médium qui en fait le rendu, en l'occurence le moniteur. Dans le cas d'une imprimante à flot continu (type listing), par exemple, la hauteur maximum n'est pas fixée ...
Le problème du height: 100px est qu'il va effectivement utiliser la hauteur de l'écran. Mais si le contenu du corps est plus haut que l'écran, la manchette n'ira pas plus bas pour autant. Même chose pour le contenu de la manchette qui débordera hors des frontières si il est un minimum fourni.
Moi, j'ai fini par abandonner et j'ai " résolu " le problème en trichant : J'ai affecté une image de fond répétée à <body> qui dessine une manchette trompe-l'oeil et j'ai déclaré une division transparente dont la hauteur n'est pas définie. Cette manière de faire est également la plus légère pour le navigateur.
Pour le tableau à taille fixe mais avec des barre de défilement : overflow: auto.
Bon courage.
# Un makefile par répertoire.
Posté par Obsidian . En réponse au message makefile pour code divisé en modules. Évalué à 2.
Le bon sens nous pousse à utiliser un Makefile par répertoire, sauf cas particuliers où il n'y a rien à compiler ou à traiter d'une manière générale dans ces dépôts.
Ensuite, on compile en général toutes les sources et ressources d'un même module en un seul *.o local, puis le Makefile du premier niveau les assemble tous avec le main pour former l'exécutable final.
Après, cela dépend un peu de ton niveau en matière de Makefile. Tu n'es pas obligé d'utiliser de règles implicites ou autres optimisations dans le genre, mais il faut au minimum écrire correctement ses dépendances (tout l'intérêt d'un Makefile).
http://www.google.fr/search?hl=fr&q=Makefile&btnG=Re(...)
[^] # Re: pourquoi le lisp
Posté par Obsidian . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 1.
D'un autre coté, si la plupart des symboles ont quand même du sens (telles les accolades pour définir un bloc d'instructions), il faut bien reconnaître que la plupart des lexiques des langages informatiques (américains pour la plupart) ont été conçus en fonction de ce que le clavier proposait.
[^] # Re: ...
Posté par Obsidian . En réponse au journal "Si j'écrit un bon programme, pourquoi devrais-je le donner ?". Évalué à 4.
[^] # Re: BFM
Posté par Obsidian . En réponse au journal Tout le monde gagne à l'arrivée de Windows Vista !!. Évalué à 9.
[^] # Re: Sans déconner...
Posté par Obsidian . En réponse au message Labyrinthe. Évalué à 3.
Bon, Fatou : qu'est-ce qui t'ennuie ? Ou en es-tu dans ton projet ? Qu'attends-tu que l'on fasse pour toi exactement ?
(Un peu de naïveté de fait pas de mal. Parfois, on a quelques bonnes surprises ...)
[^] # Re: Ç cédille majuscule
Posté par Obsidian . En réponse au journal Que répond un codeur dont le programme ne fonctionne pas ?. Évalué à 2.
[^] # Re: IPoP
Posté par Obsidian . En réponse au journal 1er avril ? 450Go sur une feuille de papier.... Évalué à 2.
Oui, il faudra ajuster le MTU en fonction du délai du ping, mais à 450 Go par feuille, cela reste intéressant ! :-)
# IPoP
Posté par Obsidian . En réponse au journal 1er avril ? 450Go sur une feuille de papier.... Évalué à 5.
[^] # Re: Mes réponses
Posté par Obsidian . En réponse au journal Que répond un codeur dont le programme ne fonctionne pas ?. Évalué à 2.
[^] # Re: Mes réponses
Posté par Obsidian . En réponse au journal Que répond un codeur dont le programme ne fonctionne pas ?. Évalué à 2.
[^] # Re: Mes réponses
Posté par Obsidian . En réponse au journal Que répond un codeur dont le programme ne fonctionne pas ?. Évalué à 7.
[^] # Re: licence globale
Posté par Obsidian . En réponse au journal après la taxe Windows, la taxe Vivendi.. Évalué à 2.
[^] # Re: Abonnement au mois = attrape nigot !
Posté par Obsidian . En réponse au journal après la taxe Windows, la taxe Vivendi.. Évalué à 2.