Oui, c'est limite maigre. Et même toi, tu ne peux pas dire le contraire.
Si lui ne peut pas, moi je vais le faire.
Olivia Wilde a une morphologie fine (cf mon post plus haut), donc son imc idéal va être inférieur à celui d'une personne "moyenne". Os plus fin, poitrine et formes plutôt modestes (81A-58-81) naturelle. (Apparament il y a eu une upgrade de poitrine récemment - elle s'est donc plutôt fait grossir pour rentrer dans les canon de la beauté que l'inverse)
A partir de là son poid idéal à 19% de masse graisseuse et 28% de masse musculaire doit être aux alentours de 60kg, avec un poid de forme entre 52kg et 70kg.
Si on part du principe que l'on s'affaiblit en dessous de 10% de masse graisseuse et que l'on joue avec sa santé en dessous de 5%, elle sera maigre à 51kg et pathologiquement maigre à 49,5kg (oui ca va vite quand on perd du poids) si tant est qu'elle ne perde pas de muscle au passage.
Maintenant, on a quoi, une fille pas épaisse à la base. À grands coups de photoshopage on va la rendre artificiellement plus maigre encore. Et on va instituer ça en canon de beauté. C'est ça le problème que je dénonce.
Et bien tu te trompes d'exemple, et ce pour plusieurs raisons :
a) Bien que fine, Olivia Wilde n'est pas maigre - et elle n'est même pas limite médicalement parlant. Elle a de la chair sur les os.
b) Olivia Wilde a été mise en avant dans une série, c'est à dire que la version qui est connue de son visage et de son corps et une version en mouvement. Certes on peu la "photoshopper" autant que n'importe qui d'autre - mais on prend le risque de dénaturer son apparence et donc de la rendre méconnaissable. Généralement les filles qui sont connues en tant qu'atrices sont nettement moins photoshoppée que les autres.
c) La photo fait prendre des kilos. Les réglages de lumières qui effacent les défaut de la peau donnent aussi une apparence plus ronde aux personnes. Certes généralement c'est surcorrigé dans photoshop - mais uen fois d eplus pas pour les actrices. Au final si Olivia Wilde (en vrai) voulait ressembler à Olivia Wilde (en photo) elle devrait probablement prendre 4 bon kg, sans quoi elle aura les traits (notamment au niveau du cou et du pli des yeux) plus sec.
d) Tu livres un combat d'arrière garde : La mode des ultra maigres est finie (un grand merci à l'Espagne). Aujourd'hui on est dans le "everybody is beatiful", si tu ne me crois pas regarde les défilés des grandes maisons. Bien sur il y a encore beaucoup de fille longues et fines, mais on trouve de plus en plus de filles plus ronde et même des filles pas très grande ni particulièrement fine. Il y a de nouveau de la chair sous les bras et les jambes ne ressemblent plus à des tubes de plastique rose.
e) Les anoréxiques (les vraies, celles qui se mettent réellement en danger avec des taux de masse graisseuse sous les 3%) trouvent toujours une excuse. Et généralement le problème n'est pas qu'elle veulent ressembler à X ou à Y mais qu'elle sont fondamentalement mal dans leur peau au point de vouloir disparaitre/s'alléger/se rendre fragile etc. Une fille qui fait de l'anoréxie et qui vous explique que c'est pour devenir manequin vous ment (et dans 90% des cas se ment à elle même). Certes les manequins rachitiques donnent une mauvaise image et les confortent dans leur démarche - mais ils ne sont pas la cause première d'un comportement anoréxique.
Les physiques du genre de celui d'Olivia Wilde pris en exemple ici ne sont pas "normaux", ce n'est pas la majorité du genre. Loin de là.
Si, vu la morphologie de la demoiselle, son poids est parfaitement normal. Elle a des attaches fines (poignets et chevilles), une poitrine plutôt modeste (en terme de distance entre la base du sein et le mamelon), sur les photos récentes, à moins qu'elle ne lève les bras on ne voit pas ses cotes, et elle ne semble pas particulièrement musclé (ce qui rajoute artificiellement du poids). A la louche je dirais un petit 15% de masse corporelle graisseuse. Ce qui est faible (la moyenne pour une femme étant plutôt vers 20%) mais pas alarmant (on prend des risques pour sa santé aux alentours de 5% et moins)
Donc à la louche (et aux approximation retouches photoshop près) Olivia Wilde a un poids qui correspond complètement à sa morphologie.
Après j'imagine que le trait marquant de son visage étant ses pommettes, elle ne peut pas trop prendre de poids de peur de les effacer, mais elle est loin de la zone rouge, elle doit même pas être dans la zone orange (de peu certes, mais je pense sincèrement que son poids actuel n'a aucune influence sur sa santé, même pas une petite fragilité immunitaire).
Par contre il est clair que son ossature et sa silhouette lui permettent un poids relativement faible, et c'est sur qu'une personne ayant des os plus lourds ou une taille de bonnet supérieure ne pourront pas atteindre son poids sans prendre de risque avec leur santé. Je déconseille notamment très fort à Penelope Cruz de tenter la même chose. Quand elle le fait les épaules sont saillantes, les genoux cagneux, bref c'est pas joli.
Toutes mes excuses pour cette analyse pompeuse et bétaillère de ces dames, mais il est difficile de parler strictement du physique sans passer par la case objectification.
Devoir installer 3 outils pour 3 fonctions que l'on utilise toujours ensemble, ce n'est pas très simple stupid.
Mais qu'il ne faille qu'un seul client unifié c'est une chose, ca n'enlève rien au fait que les serveurs doivent eux être disjoints.
Je ne vois pas pourquoi un problème dans mon agenda devrait m'empécher de lire mes mails.
Si tu veux un exchange like (mais en version qui marche) il y a citadel : http://www.citadel.org/
Il fait serveur mail, calendrier, carnet d'adresse, XMPP chat, webmail, notes, BBS board etc.
Et en plus il est pas mal de ce que j'ai pu tester. Bon je ne suis pas allé en prod avec lui - j'aime trop dovecot et je configure mon LDAP de façon un peu particulière…
Un widget, c'est un objet conceptuel que tu peux décrire dans un langage structuré, aussi compliqué soit il, sans avoir besoin de code. C'est juste un ensemble d'états et de propriétés, auxquelles tu peux lier des actions.
Et une balise c'est juste un espace vide et des indications.
La différence majeure entre une balise et un widget c'est que la balise est "idiote". Une balise image par exemple, si l'image cible n'existe pas - ben j'ai quand même un espace de 240px.400px qui est vide (et dans lequel le navigateur va déssiner uen croix rouge ou un fichier brisé pour me signifier qu'il n'a pas trouvé le contenu)
Une balise est par essence innerte. Si je remplace ma balise image par un champs texte ou par un objet video, la page s'affiche pareil.
Pire si j'agis en javascript pour modifier la cible de ma balise et la remplacer par une cible valide, ben l'image s'affiche.
Un widget c'est de la logique. Si je demande à ouvrir un widget nautilus vers un site FTP inexistant le widget ne sera pas créé. Ca me renverra un message d'erreur. Derrière je ne peux plus changer la cible de mon widget puisqu'il n'a jamais été créé.
Même chose pour certains widgets image. Pas de bras, pas de chocolat.
Mais encore une fois, je ne pense pas que les défauts que tu soulèves remettent en question fondamentalement l'usage de CSS.
Dans le cadre de GTK3 si. On ne pourra jamais utiliser les CSS pour des fonctions de theming dans GTK3 sauf à modifier GTK3 en profondeur. Cette modification consisterait à couper chaque widget en deux : d'un coté la partie graphique/placeholder/rendu et de l'autre la logique. Mais ca revient à créer un autre toolkit complètement.
Dans le cadre d'un nouveau toolkit, la question de la pertinance se pose. Autant les CSS pour la mise en forme du contenu peuvent se justifer, autant pour le contenant ca peut devenir lourd très vite. Le point le plus important pour que les CSS tournent bien est de garder le coté inerte du balisage (pas de retour en CSS => pas de logique). Mais alors il faut cabler chaque bouton, chaque zone de saisie, chaque slider a la mano. En plus il faut aussi se palucher les flux trop gros pour tenir en mémoire d'un coup. Ca allourdi le code, mais c'est faisable (et même déjà fait - jquery-ui, mootools et YUI le prouve.)
_Et là, je ne vois pas où ça pose un problème, ce n'est pas à toi d'ajouter des sélecteurs, ça serait plutôt au moteur de thème de t'exporter des classes _
Il va avoir du mal à choisir les bonnes. A moins d'être très intelligent ET de lire mes pensées. Parceque pour deviner que je veux mettre les mêmes fontes dans le menu et dans les info-bulles mais pas dans les pop-up d'alerte il faut y aller.
Surtout que quand on en arrive à des besoins aussi compliqués que ce que tu décris
Besoins compliqués ? L'exemple que j'ai donné c'est un éditeur de texte, du type de ceux qu'on demande d'écrire en deuxième année d'école d'info. Un éditeur de texte c'est quand même pas compliqué. Un navigateur web ou un logiciel de simulation 3D temps réel je dis pas, mais un éditeur de texte…
Je ne vois pas pourquoi tu dis non. ce n'est pas parce qu'un widget est plus qu'un élément d'un langage de markup que ça n'en est pas un.
Ok tu te sens d'écrire un truc du genre
if </b>
Moi pas.
C'est pas le contenu, c'est la forme du contenu.
La forme du contenu, c'est le contenu. Sinon c'est de l'information brute. Le truc c'est que la mise en page du contenu dépend à la fois de l'appli elle-même et des traitements qu'elle fait que des CSS GTK3. Et comme le DOM est en vrac il n'y a pas possibilité de tracer la séparation. C'est comme si dans OpenOffice ton texte s'ouvrait différament en fonction de ton choix de thème. C'est idiot.
pourquoi CSS n'est il pas adapté
J'ai déjà répondu aussi. Un widget N'EST PAS un balisage. Je donne plus d'exemple pour que tu saisisses le problème, mais ca ne passe pas apparament.
CSS est un descripteur de mise en forme qui fonctionne par selection. Si on fait plus que de la mise en forme et/ou que l'on ne dispose pas de sélecteurs puissants (en l'occurence les deux dans GTK3) il faut autre chose. CSS n'est pas fait pour décrire l'ensemble de ce que peut être un widget. A partir de là il ne peut pas le sélectionner dans toutes les nuaunces et donc il ne peut pas le peindre correctement. Même en HTML c'est javascript qui s'occupe de ce boulot. Et c'est pas en rajoutant des sélecteurs attributs par paquets de 50 (elem:was_left_clicked_20_seconds_ago_but_lightly:was_originally_created_elsewhere_then_imported_here) qu'on va résoudre le problème. Bien au contraire.
Qui a parlé de transformer le CSS en widget ? Les widgets jouent un peu le rôle des balises HTML, et le CSS sert à définir le style.
Non.
En HTML on a trois choses : le balisage, le contenu et la selection. Un widgets a en plus des états, des relations et de façon générale toute uen logique cablée qui influence son comportement. C'est pour celà qu'en CSS gnome on passe son temps à définir des dizaines de comportement CSS en fonction de tout une palanquée d'attributs.
Pour que les paradigmes se recoupent il faudrait que GTK3 fonctionne comme javascript, c'est à dire qu'il utilise les mêmes sélecteurs CSS que la mise en forme. (Et ca ne serait pas une bonne idée du tout.)
_Je n'appelle pas ça influencer le contenu, c'est justement le mettre en forme. _
Mais la mise en forme ca influence le contenu. Si l'utilisateur a décidé de mettre la barre d'outil en vertical à gauche et de tripler la taille du texte j'ai le choix entre mettre à la poubelle ses préférences (ce qui est la solution retenue par toutes les applis GTK3 que j'ai pu croiser) ou prendre le risque que mon interface explose.
Pour bien faire il faudrait une fois de plus que le rendu CSS GTK3 soit fluide, et que l'on dispose d'un retour sur l'interface du même type que celui dont on dispose en javascript - et qui permette de récupérer, d'analyser et de modifier la mise en page à la volée. Gnome-shell permet (un peu) ce genre de choses, mais une appli standard ne dispose pas de framework standard pour effectuer ces opérations. On y va à coup d'introspection et on prie.
_ Le fait que tu ne choisisses pas les classes n'a rien à voir avec l'utilisation de CSS, mais plutôt avec le fait que les widgets sont déjà définis et que GTK3 n'est pas un toolkit modulaire permettant d'ajouter des widgets. Ce que tu critiques est je pense voulu. Une classe par widgets, pour assurer l'uniformité du thème._
Mais je veux pas ajouter de widgets, je veux simplement une méthode simple qui me permette d'utiliser mes bouttons dans les partie spécifiques de mon appli et les bouttons standards dans les parties génériques.
Un exemple tout con : je veux faire un éditeur de texte dans lequel j'ai un arbre de navigation et une fenêtre de saisie d'un certain type pour les langages procéduraux et un autre arbre de navigation avec une autre fenêtre de saisie pour les langages fonctionnels. De plus je rajoute ou j'enlève des éléments à mon arbre en fonction du fait que le langae soit objet ou non. A cela j'ajoute une fenêtre de saisie en dessous pour l'accès console et une autre fenêtre en affichage seul pour la sortie de compilation/le debug.
Si je pouvais créer des classes ca prendrait 10 secondes à faire, mais comme je ne peux pas je suis OBLIGE de me trimballer des sélecteurs de 100 pieds de long pour distinguer entre mes différents éléments qui déscendent tous du même widget. Et si je veux créer une fenêtre en double pan pour les diffs et les merge ? Encore un selecteur. Et si je veux que l'utilisateur puisse détacher la fenêtre de debug pour la passer sur l'écran d'à coté ? Encore un autre sélecteur. Et dans chaque selecteur je refais TOUTE la CSS spécifique à l'élément. Donc le jour ou je veux changer le comportement de mon élément il faut que j'aille modifier mes CSS à 14 endroits différents. C'est EXACTEMENT ce que le CSS est supposé éviter.
_ Pourquoi veut tu un DOM ?_
Déjà parceque ca me permet de savoir quels éléments vont hériter de mes modifs CSS et quels sont ceux qui vont passer au travers. C'est fondamental quand on fait un thème ou une interface de savoir ce qui va être impacté. Je veux que mon boutton "fermer" soit en rouge violent sur la fenêtre qu'il ne faut surtout pas fermer a moins d'être sur à 100% de son coup, par contre je ne veux pas qu'il soit en rouge violent au niveau de la fenêtre d'aide qui peut elle être fermée quand on veut. Le DOM est ce qui me permet de savoir QUEL comportement je modifie quand je n'ai pas envie de les modifier tous.
Ce que tu demandes, c'est ce que GTK3 ne te fournit pas, mais encore une fois, non parce qu'il utilise CSS, mais parce que ce n'est pas son but.
Je te rassure, GTK3 fourni tout un tas d'outils qui permettent de faire des modifications d'aspect en fonction du fonctionnel sans que ca n'impacte l'ensemble des widgets du même nom sur toute l'appli. Sinon ca ne servirait pas à grand chose. On ne peut juste pas accéder simplement a ces fonctions depuis les CSS parceque les deux méthodes d'accès (par classe spécifique utilisateur et par parcours de l'arbre DOM) ne sont pas implémentées correctement.
Tu ne peux pas faire de manipulation complexe, de créer des thèmes par widgets, etc, etc, mais c'est assumé.
Assumé est un bien grand mot. Ils (les devs Gnome) disent qu'il ne faut pas créer de moteurs de thème, qu'il ne faut pas faire d'introspection pour des raisons de décorations, qu'il ne faut pas faire des sous groupements de widgets par fonction etc. Tu dois tout pouvoir faire avec du SVG et des CSS. Alors du coup tu essayes, tu y arrives pas et tu vas lire leur code poru savoir comment eux ils ont fait. Réponse : Ils ont créés des moteurs de thème custom dans lesquels il font des sous groupes de widgets, ils font de l'introspection à tire larigo, ils utilisent du png pour les images sans arrêt….
Sur Gnome-Shell ? On va carrément chercher un interpreteur ECMASCRIPT. Sur Nautilus ? On créé un widget custom par fonction et par sous fonction.
Si même eux n'arrivent pas à respecter leur truc sur des aspect fondamentaux du produit, je vois pas comment moi j'arriverai à faire quelque chose de propre.
En somme tu râles parce que GTK3 n'est pas aussi puissant que tu le souhaiterais
Non je rale parceque je me prend tous les inconvennients d'un sucre syntaxique assez lourd (les objest CSS) sans aucun des avantages. Pas de réutilisabilité au sein de mon appli, pas de selecteur simple, pas de DOM donc pas d'éléments cibles facile à atteindre. A chaque instant ou j'utilise les CSS GTK3 j'ai l'impression qu'on m'a donné une perceuse pour planter des clous. C'est proche du besoin en effet, mais makgré tout complètement à coté de la plaque.
GTK3 assume l'utilisation d'un sous-ensemble de CSS, je ne vois pas en quoi c'est un problème en soi tant que c'est documenté.
Alors déjà le tant que c'est documenté on y est pas encore.
Ensuite comme les CSS ne sont pas respectés par l'équipe Gnome elle-même on a des glitch dans tous les sens (variables en fonction du moteur de style utilisé) - donc même documenté il y aurait des chausse-trappes partout.
Et pour finir utiliser les CSS parceque "c'est trop cool, tout le monde connait, tout le monde sait s'en servir" avant de sortir une version limité autant au niveau des éléments, que des attributs et avec en prime un format différent pour les valeurs acceptable c'est idiot.
Sélectionner mes éléments avec des elem:active:insensitive:hoover:focus ca n'est intuitif pour aucun dev CSS. Ne pas pouvoir créer des classes et les réorganiser ca n'est intuitif pour aucun dev CSS.
Quitte à faire un autre langage, autant en faire vraiment un autre - là cet hybride est juste un piège qui va faire croire aux devs qu'ils peuvent rentrer dans le code directement (et qui va les accueillir avec un grand coup de batte de base-ball dans les gencives).
Pour résumer ton commentaire, tu dis que GTK3 ne répond pas à tout tes besoins et ne te permet pas une aussi grande souplesse qu'un site web
Je n'ai pas dit ça du tout. J'ai dit que GTK3 CSS ne permet pas de faire du GTK3. GTK3 et CSS sont sur deux paradigmes différents, ils ne peuvent totu simplement pas travailler ensemble de façon efficace pour faire du theming. Ca n'est juste pas possible. L'un des deux doit évoluer pour pouvoir dialoguer pleinement avec l'autre. Idéalement GTK3 devrait évoluer pour coller parfaitement au CSS du W3C (ou même à un sous ensemble de ces CSS) puisque c'est le but avoué de tout ce tintouin. Sauf que bien sur, à chaque fois qu'il y a un soucis c'est soit une verrue, soit une modif des specs CSS GTK3.
en quoi ne pas utiliser CSS, (GTK2 par exemple) améliorerait les choses que tu ne peux pas faire ?
Ben je n'utilise plus correctement CSS en GTK3 (et je ne m'en porte que mieux), l'utilisateur devrait déjà être content de conserver sa déco de fenêtre intacte. Je fais mes déco dans des scope volatils au moment du refresh. Mes feuilles css redéfinissent à peut près tous les widgets demon appli (et elles sont elles mêmes écrasées par les css dynamiques des scope précédamment évoqué). Pour tous les trucs un peu complexe (genre un slider qui est légèrement plus gros ou plus rouge que les autres) je donne un grand de coup de hache dans le moteur de thème etc.
C'est moche hein ? Mais tu sais le pire ? Tout le monde fait comme moi, même au sein du projet Gnome.
A part le rejet pur et simple, as tu un réel argument pour ne pas utiliser CSS dans GTK ?
Dans l'ordre :
a) C'est pas fait pour ça - Il existe certes des bibliothèques (le plus souvent en javascript) qui permettent de transformer certains éléments CSS en widgets, mais le CSS est un descripteur de style, c'est à dire qu'il sert à normaliser la mise en forme du contenu. S'en servir pour du contenant ne fait pas sens. Cela fait d'autant moins sens que GTK3 possède déjà un moteur de style qui lui est propre - et qu'une partie du fonctionnement interne est inaccessible depuis les CSS, le role de CSS dans le cadre du thème est donc batard :
- Il peut influencer le contenu (via margin , padding, font etc.) mais pas complètement le mettre en forme
- Il peut faire le thème mais pas complètement (il n'y a pas de "retour" en CSS - il faudra donc de toute façon écrire de la logique hors CSS pour le comportement avancé des widgets)
- Il rend le test des applications très complexe : comme les CSS GTK3 ne gèrent pas (encore ? apparament ca ne sera pas fait) l'ajustement automatique de la taille, un élément rendu trop grand par une CSS innapropriée sera tronqué. Comme il est décommandé de créer son propre moteur de theme, on arrive à des situations ou la barre de menu peut avoir été décalé sur le coté alors que vos widgets dans cette barre sont en long. Au final soit on force un thème complet ou presque dans l'appli (mais alors les préférences utilisateurs sont détruites) soit on prévoit 12 gazillons de possibilités (barre verticale à droite dans un système d'écriture droite à gauche), le tout avec le moteur standard, avec unico et avec adwaita pour faire bonne mesure.
b) C'est pas moi qui choisi les classes
La force de CSS est que l'on peut décrire une foultitude de classe de façon à faire passer des sélecteurs pour les modifier ou les manipuler si besoin est. Sauf que là les classes sont pour la plupart prédéfinie, et c'est préférable vu que l'on altère plus le contenant que le contenu. Mais du coup on arrive au point ou l'on est coincé dans sa capacité à choisir ou à disposer des classes. le résultat est que l'on se retrouve à créer des sélecteurs en pagaille sur des propriétés.
Vous voulez une image spéciale quand on est grisé une radio box dans un menu d'une fenêtre ? rien de plus simple il suffit de créer le sélecteur
.frame.menu.menuitem.radio:active:insensitive (pour la version cochée)
.frame.menu.menuitem.radio:insensitive (pour la version décochée)
.frame.menu.menuitem.radio:inconsistent:insensitive (pour la version qu'on sait pas encore si elle est cochée ou pas)
Faire un thème pour le moindre widget prend trois pages de déclaration, la seule solution pour ne pas avoir des sélecteurs à rallonge c'est de passer par le nom du widget créé. Par exemple faire une cascade sur NautilusWindow - ah oui mais dans ce cas là on perd l'avantage majeur du CSS : séparation de la logique et du rendu. Pas grave, les thèmes officiels Gnome ne passent quasiment que par des sélecteurs par nom du widget.
c) Il est ou mon DOM ?
Pour pouvoir utiliser les CSS correctement, voire intelligemment il faut connaitre au moins vaguement le DOM, c'est à dire savoir à quel niveau se trouve tel ou tel élément. Dans GTK3 non seulement je ne comprend pas le DOM, mais en plus je ne sais même pas ou se trouve le mien. C'est peut être moi qui suis mal comprenant mais…
J'écris une appli, je fais son css pour elle, j'importe les css GTK3 de base et je tente de respecter le au maximum les préférences utilisateur. Bon à un moment j'ai besoin de permettre à l'utilisateur de naviguer dans les fichiers locaux - pas de soucis j'invoque un widget nautilus et AAAHHH… Mais qu'est-ce qui se passe. Qui est la fenêtre active ? Je suis dans un widget donc ça devrait toujours être moi, mais qu'est-ce qui se passe au niveau du thème ? gnome-application.css fait de l'override forcé du thème mais est-ce que mon widget est bien le fils de mon appli ? Est-ce que les composants de mon widgets sont tous les fils de leur père ? Et si je branche un clef usb après avoir appelé mon widget ?
Et une fenêtre non modale ? C'est une parente de ma fenêtre principale ? Elle hérite des thèmes ? De tous les thèmes ?
Le pire c'est qu'à chaque fois que vous commencer à connaitre (parce que comprendre c'est pas possible) il y a un bug report qui est traité et qui "corrige" un comportement absurde par un autre comportement non moins absurde dans la cascade des styles.
Et puis il y a le SVG. Qui apporte son lot d'élément DOM, mais pas tout à fait comme le DOM SVG html. On pourrait écrire des pages et des pages la dessus.
d) Le CSS change - et GTK3 ?
Déjà sur du pur HTML le W3C se fout sur la gueule en permanence pour savoir ce qui rentre dans CSS et ce qui ne rentre pas. En faisant le choix du CSS GTK3 va se retrouver à plus ou moins long terme à devoir choisir entre deux choses désagréables
1 - suivre le W3C quoi qu'il arrive même si les nouvelles CSS partent dans des directions qui n'apportent rien à un système de thème
2 - maintenir et faire évoluer une version des CSS qui ne sera pas supporté par le W3C.
Ca a déjà commencé. Bonne chance pour faire mumuse avec du z-index ou du float sous GTK3, la taille des éléments est définie en points sans unité précisée (encore que l'em semble être supporté pour les fontes dans les dernières versions - mais c'est pas documenté), et les sélecteurs par nom du widget c'est assez fort…
C'est donc un langage qui ressemble à du CSS, mais qui n'est pas (du tout) du CSS. Ni dans l'esprit (mélange fond forme, DOM tordu, sélection par attributs en pagaille) ni dans la lettre (manque pleins de choses puissantes, subtiles nuances sur les choses restantes).
Donc dans ton moteur de recherche de fichiers tu peux taper par exemple vmcoincoin/main.c ou zino/main.c ?
Effectivement, quand tu sais déjà ou le fichier se trouve tu peux rentrer suffisament d'informations pour permettre au système de recherche de le trouver très rapidement.
le raisonnement part du constat qu'après tout, dans un monde de fichiers indexés, pourquoi aurait-on besoin d'un explorateur de fichier alors qu'un moteur de recherche suffit pour 99% des cas d'utilisation (= chercher un fichier) ?
Il suffit juste de ne pas avoir plusieurs fichiers portant le même nom dans la zone de recherche. Mais bon qui serait assez bête pour donner exactement le même nom à plusieurs fichiers différents ?
Bon je vous laisse, j'ai mon main.c qui compile plus quand je fais un make, faut que je regarde si le problème ne vient pas de configure…
Quand je vois les livres photos qui trainent dans les bibliothèques de mes amis (oui j'aime bien fouiller pendant les soirées), je peux facilement affirmer que les vérifications sont probablement ultra sommaires.
Sommaire certes, pour 40€ on va pas déranger un expert chromato non plus. C'est aussi moche que les photos développées en une heure chez speeddev'30, mais les photos développées en une heure ça convient à beaucoup de gens.
Une impression quadrichromie mal réglée c'est quand même nettement plus moche. Le rouge est orange, le noir est gris moyen, les bleus sont ternes etc. De quoi transformer une photo de famille en réunion des dépressifs anonymes.
A priori, vu ce que j'observe, on peut dire que le traitement qui filtre les applications en fonction du critère de recherche est fait dans le thread destiné à l'affichage…
Je pense plutot qu'ils essayent de faire les choses de façon synchrone, c'est à dire de bloquer l’exécution du javascript jusqu'à ce que la requête de recherche renvoi un résultat. Si l'index est mal foutu, la quantité de données trop grosse, la machine lente ça génère un freeze.
Question à laquelle je ne peux donner une réponse…
Le javascript est hard-threaded, c'est à dire qu'il a été décidé à l'avance ce qui serait pris en charge par tel ou tel thread.
Sur la plupart des implémentations il y a (tres grosso-modo) un thread pour les évènements utilisateurs, un thread pour les évènements système (les gros les lourds, pas les alarmes ou les ticks d'horloge), un thread qui dessine, un qui fait du bruit et un qui essaye tant bien que mal de coordoner tout ça.
Ce type de gestion est très pratique pour les évènements dissociés comme on en trouve sur le web, mais très très couteux quand on veut faire de synchrone. La question qui revient en boucle en JS c'est comment faire un sleep() ? Et juste après c'est comment savoir si tel élément a bien été créé/détruit/exécuté/joué jusqu'au bout. Assez vite tu te retrouves à créer des callbacks dans tous les sens et à déclencher des éléments virtuels en pagaille également (un grand classique étant de mémoriser que l'utilisateur a clické quelque part dans un coin et à attendre que l'élément X soit prêt pour simuler un click virtuel à l'endroit que l'utilisateur a clické quelques millisecondes trop tôt).
En web (ou l'utilisateur a l'habitude d'attendre quelque peu et n'hésite pas à cliquer à nouveau) ca passe. En desktop c'est l'horreur sur une machine trop peu puissante ou trop chargée.
et passes par un imprimeur tiers. Ce ne sera pas forcément moins économique et tu auras toute la liberté que tu voudras.
Oui, sauf qu'un imprimeur "grand public" il prend en charge pas mal de problèmes pour toi, notamment au niveau des couleurs et des fonds perdus. Il vérifie que tu n'as pas fait de conneries et généralement il t'avertit gentiment si tu veux faire un beau rouge pétant sur fond vert fluo. Un imprimeur pro qui travaille à l'épreuve (pas de bon à tirer) ou en série limité (BAT facturé à chaque fois) il imprime les couleurs que tu lui donnes. Vient pas te plaindre si ta belle photo de camion pompier sur fond de verdure et de ciel bleu s'est subitement transformée en pastel.
Personnellement pour les livres de qualité avec des couleurs chiantes que j'ai pas envie de régler pendant des heures, comme j'ai la chance (et le malheur) d'être parisien je passe par un labo photo (en l’occurrence Negatif+ ) probablement le dernier labo photo pro abordable de la capitale (Si vous en connaissez d'autres, je suis preneur).
Je suis en couple depuis plusieurs années avec Madoka de Kimagure Orange Road, et c'est vrai que ca me ferai plaisir que l'Etat me permette d'officialiser mon union. J'ai peur que ma famille s'en prenne à mes posters et mes goodies si il venait à m'arriver quelque chose…
Autant systemd est une hérésie qui mérite le mépris le plus profond de la part de tout bon linuxien (Et même des windowsiens avertis, quand je leur explique qu'il s'agit d'une espèce de meta-DCOM unique et centralisateur ils me regardent comme si j'étais devenu fou. Alors que c'est pas moi qu'il faut soigner), autant grub2 est nécessaire pour plusieurs raisons :
1) Le ridicule ca va bien 5 minutes :
Il s'agit peut être de features qui intéressent 3% des gens, mais c'est vrai que les 3% de gens qui voulaient du VFS chiffré sur la partition racine commenceaient sérieusement à se demander si on se foutait pas de leur gueule. Preloader, bootloader, chainboot, chainloader, preboot, extractions du kernel en mémoire vive, chargement des modules et enfin boot. Avec à chaque mise à jour la légère apréhension qui va bien à se demander dans quel état on va retrouver son boot.
2) C'est pas plus mal de booter un vrai file system :
Si on omet légèrement EXT4, qui est un FS dont on a bien du mal à dire si il est moderne ou ancien tant il est optimisé dans les coins (pan), la plupart des fs dit "modernes" (ZFS, HammerFS par exemple) ou des pseudofs (LVM2, gvinum/gpart, luks et autre) utilisent une couche d'abstraction qui n'est pas vraiment compatible avec les techno de grub. Bon en bricolant ca finissait par passer d'une façon ou d'une autre, mais bonjour les pirouettes.
3) Et si je veux 6 partitions actives ?
La limite de 4 partitions actives est un poil dépassée. J'étais déjà un poil à l'étroit dedans quand les disques faisaient 20Go, alors maintenant qu'ils font 1,5To ca me gave d'autant plus, surtout vu ce qui a été dit précédemment, quand j'ai déjà une partition pour le /boot, une pour le / et une pour mon vrai système de données encapsulé dans du LVM et éventuellement chiffré, je me retrouve à devoir acheter un disuqe supplémentaire ou mettre le swap dans le LVM si je veux garder mon autre OS (Freebsd, mais c'est pareil avec windows). GPT permet de repousser cette limite, seulement grub a besoin d'un MBR classique alors on se retrouve une fois de plus à faire des pirouettes.
4) Les systèmes UEFI/GPT only arrivent.
Dans peu de temps, grâce à windows8 (un bonheur n'arrive jamais seul) on aura du secure bidule à tous les étages, et je suis prêt à parier que le secure bidule en question va exiger d'ici deux ans maximum une partoche GPT ou un boot UEFI (ou les deux). Et là ça va commencer à devenir compliqué de mettre des MBR hybrides signés (merci Red Hat), surtout si on veut garder le windows préinstallé. Bien sur il restera toujours la possibilité de vérifier que votre carte mère est compatible grub (sous reserve d'upgrade de firmware à la con) sur les sites spécialisées, mais personnellement quand je fais mes courses j'ai déjà le catalogue des cartes wifi compatible avec mes systèmes (3 tomes avec les numéros de séries- parceque des fois le constructeur il change la puce mais pas la référence) et le catalogue des ACPI qui sont fonctionnelles (4 tomes, avec numéros de série ET de firmware). Donc si je peux éviter de me trimbaler en plus le catalogues des cartes qui tolèrent le boot MBR hybride ca m'arrange (et tant pis pour mon osteo qui aime bien que je me trimballe avec 20 tomes sur moi en toute circonstance).
En vrac je vous épargne le boot de partoche avec des secteurs 4k/8k/16k, la reprise suspend on disk de partitions cryptées, la regen de pool ZFS en vrac etc.
Pour finir bien que grub2 soit officiellement encore en beta il est relativement fonctionnel au moment ou les distribs commencent à l'adopter (plus que systemd par exemple qui a forcé trois réécritures de DBus à lui tout seul, et on va rester gentil et pas parler de pulseaudio). Il est également relativement non intrusif (si on veut remettre lilo ou l'ancien grub à la place, pas besoin de désinstaller la moitié du système d'abord).
On va donc dire que grub2 est un peu vert pour une adoption aussi massive, mais que ca se comprend quand même.
Choix est un bien grand mot. Sur les dernières versions de dev Gnome 3 il te faut systemd, udev, udisk2 et consors.
A partir de là soit tu intègres toute la clique, soit tu patches Gnome 3 dans tous les sens, soit tu laisses tomber.
Slack a complètement laissé tombé Gnome, parcequ'ils ne veulent pas toute la clique.
ArchLinux ne veut pas de systemd, mais est obligé de le faire rentrer petit à petit pour permettre à Gnome (et autres) de continuer à marcher raisonnablement.
Debian resiste, mais du coup leur version de Gnome 3 en testing est pour le moins spéciale.
On finit par arriver à des cas absurdes ou pour faire fonctionner des programmes userland, on est amené à mettre à jour kernel et système (apparament avec udisk2, changer la version du bootloader pour grub2 est fortement recommandé).
systemd n'est ni sobre, ni épuré, et il ne plaît clairement pas au maximum de gens… de quoi tu parles alors ?
Nous sommes d'accord que systemd n'est ni sobre ni épuré. Je faisais juste allusion au fait que si un jour une distrib décide de faire un thème jaune fluo sur fond rose, tout le monde hurlera, et tout le monde comprendra pourquoi c'est idiot.
Si la même distrib décide de mettre par défaut et de façon inamovible systemd, lumberjack, pulseaudio ou autre, il y a 50% des utilisateurs qui trouvent ça normal et qui défendent becs et ongles la solution.
Bonjour, j'ai installé trois versions différentes de la même distribution sur la même racine, et bien bizarrement ça ne marche pas. C'est forcement la faute du logiciel Y et certainement pas de la façon dont j'ai réalisé les installations.
Clairement, ça me rappelle le gars qui sur une Debian stable avait voulu tester la dernière version de Gnome3. Le con, il avait pas mis à jour udisk en udisk2 et il utilisait un vieux DBus. Toutes ses partitions vfs sont parties en vrille on a mis 3 jours à tout récupérer.
Ou encore le mec qui voulait utiliser file roller sur XFCE sans remonter toute la couche gnome avec. Dès qu'il fait un glisser déposer depuis une archive vers le bureau il locke complètement son xorg. Comme si on pouvait installer un programme de gestion des archives sans installer evolution-server d'abord !
Je vous jure, il y a des utilisateurs des fois…
Enfin du moment que c'est clair pour tout le monde que sous Linux il faut pas s'amuser à compiler ou à installer soi-même des packages d'une autre distribution, tout va bien. C'est pas comme si c'était un système ouvert non plus.
Le thèmes par défaut par définition est sensé plaire au maximum de gens, il doit donc être sobre et épuré.
C'est marrant comme certaines choses semblent totalement naturelles quand on parle du thème visuel par défaut, et comme ces même choses vous font passer pour un odieux réac, réfractaire à tout changement quand on parle de systemd ou network manager…
Je ne suis pas spécialiste en droit, donc, je ne m'étendrais pas.
Je ne suis pas spécialiste en droit, mais la cour de cassation ne donne pas raison ou tort à l'une ou l'autre des parties, elle analyse un jugement et rend son verdict sur la validité ou non de celui-ci.
Donc elle n'a pas donné raison à HP, elle a statué que les arguments utilisés par la cours d'appel n'étaient pas valable.
C'est quand même très mauvais signe, mais ca n'est pas encore de l'enfoncage de clou dans le cercueil.
[^] # Re: Les jolies nimages ! Un commentaire de plus
Posté par Kaane . En réponse au journal Asile équatorien accordé à Julian Assange. Évalué à 7.
Oui, c'est limite maigre. Et même toi, tu ne peux pas dire le contraire.
Si lui ne peut pas, moi je vais le faire.
Olivia Wilde a une morphologie fine (cf mon post plus haut), donc son imc idéal va être inférieur à celui d'une personne "moyenne". Os plus fin, poitrine et formes plutôt modestes (81A-58-81) naturelle. (Apparament il y a eu une upgrade de poitrine récemment - elle s'est donc plutôt fait grossir pour rentrer dans les canon de la beauté que l'inverse)
A partir de là son poid idéal à 19% de masse graisseuse et 28% de masse musculaire doit être aux alentours de 60kg, avec un poid de forme entre 52kg et 70kg.
Si on part du principe que l'on s'affaiblit en dessous de 10% de masse graisseuse et que l'on joue avec sa santé en dessous de 5%, elle sera maigre à 51kg et pathologiquement maigre à 49,5kg (oui ca va vite quand on perd du poids) si tant est qu'elle ne perde pas de muscle au passage.
Maintenant, on a quoi, une fille pas épaisse à la base. À grands coups de photoshopage on va la rendre artificiellement plus maigre encore. Et on va instituer ça en canon de beauté. C'est ça le problème que je dénonce.
Et bien tu te trompes d'exemple, et ce pour plusieurs raisons :
a) Bien que fine, Olivia Wilde n'est pas maigre - et elle n'est même pas limite médicalement parlant. Elle a de la chair sur les os.
b) Olivia Wilde a été mise en avant dans une série, c'est à dire que la version qui est connue de son visage et de son corps et une version en mouvement. Certes on peu la "photoshopper" autant que n'importe qui d'autre - mais on prend le risque de dénaturer son apparence et donc de la rendre méconnaissable. Généralement les filles qui sont connues en tant qu'atrices sont nettement moins photoshoppée que les autres.
c) La photo fait prendre des kilos. Les réglages de lumières qui effacent les défaut de la peau donnent aussi une apparence plus ronde aux personnes. Certes généralement c'est surcorrigé dans photoshop - mais uen fois d eplus pas pour les actrices. Au final si Olivia Wilde (en vrai) voulait ressembler à Olivia Wilde (en photo) elle devrait probablement prendre 4 bon kg, sans quoi elle aura les traits (notamment au niveau du cou et du pli des yeux) plus sec.
d) Tu livres un combat d'arrière garde : La mode des ultra maigres est finie (un grand merci à l'Espagne). Aujourd'hui on est dans le "everybody is beatiful", si tu ne me crois pas regarde les défilés des grandes maisons. Bien sur il y a encore beaucoup de fille longues et fines, mais on trouve de plus en plus de filles plus ronde et même des filles pas très grande ni particulièrement fine. Il y a de nouveau de la chair sous les bras et les jambes ne ressemblent plus à des tubes de plastique rose.
e) Les anoréxiques (les vraies, celles qui se mettent réellement en danger avec des taux de masse graisseuse sous les 3%) trouvent toujours une excuse. Et généralement le problème n'est pas qu'elle veulent ressembler à X ou à Y mais qu'elle sont fondamentalement mal dans leur peau au point de vouloir disparaitre/s'alléger/se rendre fragile etc. Une fille qui fait de l'anoréxie et qui vous explique que c'est pour devenir manequin vous ment (et dans 90% des cas se ment à elle même). Certes les manequins rachitiques donnent une mauvaise image et les confortent dans leur démarche - mais ils ne sont pas la cause première d'un comportement anoréxique.
[^] # Re: Les jolies nimages ! Un commentaire de plus
Posté par Kaane . En réponse au journal Asile équatorien accordé à Julian Assange. Évalué à 10.
Les physiques du genre de celui d'Olivia Wilde pris en exemple ici ne sont pas "normaux", ce n'est pas la majorité du genre. Loin de là.
Si, vu la morphologie de la demoiselle, son poids est parfaitement normal. Elle a des attaches fines (poignets et chevilles), une poitrine plutôt modeste (en terme de distance entre la base du sein et le mamelon), sur les photos récentes, à moins qu'elle ne lève les bras on ne voit pas ses cotes, et elle ne semble pas particulièrement musclé (ce qui rajoute artificiellement du poids). A la louche je dirais un petit 15% de masse corporelle graisseuse. Ce qui est faible (la moyenne pour une femme étant plutôt vers 20%) mais pas alarmant (on prend des risques pour sa santé aux alentours de 5% et moins)
Donc à la louche (et aux approximation retouches photoshop près) Olivia Wilde a un poids qui correspond complètement à sa morphologie.
Après j'imagine que le trait marquant de son visage étant ses pommettes, elle ne peut pas trop prendre de poids de peur de les effacer, mais elle est loin de la zone rouge, elle doit même pas être dans la zone orange (de peu certes, mais je pense sincèrement que son poids actuel n'a aucune influence sur sa santé, même pas une petite fragilité immunitaire).
Par contre il est clair que son ossature et sa silhouette lui permettent un poids relativement faible, et c'est sur qu'une personne ayant des os plus lourds ou une taille de bonnet supérieure ne pourront pas atteindre son poids sans prendre de risque avec leur santé. Je déconseille notamment très fort à Penelope Cruz de tenter la même chose. Quand elle le fait les épaules sont saillantes, les genoux cagneux, bref c'est pas joli.
Toutes mes excuses pour cette analyse pompeuse et bétaillère de ces dames, mais il est difficile de parler strictement du physique sans passer par la case objectification.
[^] # Re: Contacts et Cie
Posté par Kaane . En réponse au journal Pour Microsoft, IMAP est un vieux protocole…. Évalué à 6.
Devoir installer 3 outils pour 3 fonctions que l'on utilise toujours ensemble, ce n'est pas très simple stupid.
Mais qu'il ne faille qu'un seul client unifié c'est une chose, ca n'enlève rien au fait que les serveurs doivent eux être disjoints.
Je ne vois pas pourquoi un problème dans mon agenda devrait m'empécher de lire mes mails.
Si tu veux un exchange like (mais en version qui marche) il y a citadel : http://www.citadel.org/
Il fait serveur mail, calendrier, carnet d'adresse, XMPP chat, webmail, notes, BBS board etc.
Et en plus il est pas mal de ce que j'ai pu tester. Bon je ne suis pas allé en prod avec lui - j'aime trop dovecot et je configure mon LDAP de façon un peu particulière…
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Kaane . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 3.
Un widget, c'est un objet conceptuel que tu peux décrire dans un langage structuré, aussi compliqué soit il, sans avoir besoin de code. C'est juste un ensemble d'états et de propriétés, auxquelles tu peux lier des actions.
Et une balise c'est juste un espace vide et des indications.
La différence majeure entre une balise et un widget c'est que la balise est "idiote". Une balise image par exemple, si l'image cible n'existe pas - ben j'ai quand même un espace de 240px.400px qui est vide (et dans lequel le navigateur va déssiner uen croix rouge ou un fichier brisé pour me signifier qu'il n'a pas trouvé le contenu)
Une balise est par essence innerte. Si je remplace ma balise image par un champs texte ou par un objet video, la page s'affiche pareil.
Pire si j'agis en javascript pour modifier la cible de ma balise et la remplacer par une cible valide, ben l'image s'affiche.
Un widget c'est de la logique. Si je demande à ouvrir un widget nautilus vers un site FTP inexistant le widget ne sera pas créé. Ca me renverra un message d'erreur. Derrière je ne peux plus changer la cible de mon widget puisqu'il n'a jamais été créé.
Même chose pour certains widgets image. Pas de bras, pas de chocolat.
Mais encore une fois, je ne pense pas que les défauts que tu soulèves remettent en question fondamentalement l'usage de CSS.
Dans le cadre de GTK3 si. On ne pourra jamais utiliser les CSS pour des fonctions de theming dans GTK3 sauf à modifier GTK3 en profondeur. Cette modification consisterait à couper chaque widget en deux : d'un coté la partie graphique/placeholder/rendu et de l'autre la logique. Mais ca revient à créer un autre toolkit complètement.
Dans le cadre d'un nouveau toolkit, la question de la pertinance se pose. Autant les CSS pour la mise en forme du contenu peuvent se justifer, autant pour le contenant ca peut devenir lourd très vite. Le point le plus important pour que les CSS tournent bien est de garder le coté inerte du balisage (pas de retour en CSS => pas de logique). Mais alors il faut cabler chaque bouton, chaque zone de saisie, chaque slider a la mano. En plus il faut aussi se palucher les flux trop gros pour tenir en mémoire d'un coup. Ca allourdi le code, mais c'est faisable (et même déjà fait - jquery-ui, mootools et YUI le prouve.)
_Et là, je ne vois pas où ça pose un problème, ce n'est pas à toi d'ajouter des sélecteurs, ça serait plutôt au moteur de thème de t'exporter des classes _
Il va avoir du mal à choisir les bonnes. A moins d'être très intelligent ET de lire mes pensées. Parceque pour deviner que je veux mettre les mêmes fontes dans le menu et dans les info-bulles mais pas dans les pop-up d'alerte il faut y aller.
Surtout que quand on en arrive à des besoins aussi compliqués que ce que tu décris
Besoins compliqués ? L'exemple que j'ai donné c'est un éditeur de texte, du type de ceux qu'on demande d'écrire en deuxième année d'école d'info. Un éditeur de texte c'est quand même pas compliqué. Un navigateur web ou un logiciel de simulation 3D temps réel je dis pas, mais un éditeur de texte…
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Kaane . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 3. Dernière modification le 13 août 2012 à 16:44.
Je ne vois pas pourquoi tu dis non. ce n'est pas parce qu'un widget est plus qu'un élément d'un langage de markup que ça n'en est pas un.
Ok tu te sens d'écrire un truc du genre
Moi pas.
C'est pas le contenu, c'est la forme du contenu.
La forme du contenu, c'est le contenu. Sinon c'est de l'information brute. Le truc c'est que la mise en page du contenu dépend à la fois de l'appli elle-même et des traitements qu'elle fait que des CSS GTK3. Et comme le DOM est en vrac il n'y a pas possibilité de tracer la séparation. C'est comme si dans OpenOffice ton texte s'ouvrait différament en fonction de ton choix de thème. C'est idiot.
pourquoi CSS n'est il pas adapté
J'ai déjà répondu aussi. Un widget N'EST PAS un balisage. Je donne plus d'exemple pour que tu saisisses le problème, mais ca ne passe pas apparament.
CSS est un descripteur de mise en forme qui fonctionne par selection. Si on fait plus que de la mise en forme et/ou que l'on ne dispose pas de sélecteurs puissants (en l'occurence les deux dans GTK3) il faut autre chose. CSS n'est pas fait pour décrire l'ensemble de ce que peut être un widget. A partir de là il ne peut pas le sélectionner dans toutes les nuaunces et donc il ne peut pas le peindre correctement. Même en HTML c'est javascript qui s'occupe de ce boulot. Et c'est pas en rajoutant des sélecteurs attributs par paquets de 50 (elem:was_left_clicked_20_seconds_ago_but_lightly:was_originally_created_elsewhere_then_imported_here) qu'on va résoudre le problème. Bien au contraire.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Kaane . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 7.
Qui a parlé de transformer le CSS en widget ?
Les widgets jouent un peu le rôle des balises HTML, et le CSS sert à définir le style.
Non.
En HTML on a trois choses : le balisage, le contenu et la selection. Un widgets a en plus des états, des relations et de façon générale toute uen logique cablée qui influence son comportement. C'est pour celà qu'en CSS gnome on passe son temps à définir des dizaines de comportement CSS en fonction de tout une palanquée d'attributs.
Pour que les paradigmes se recoupent il faudrait que GTK3 fonctionne comme javascript, c'est à dire qu'il utilise les mêmes sélecteurs CSS que la mise en forme. (Et ca ne serait pas une bonne idée du tout.)
_Je n'appelle pas ça influencer le contenu, c'est justement le mettre en forme. _
Mais la mise en forme ca influence le contenu. Si l'utilisateur a décidé de mettre la barre d'outil en vertical à gauche et de tripler la taille du texte j'ai le choix entre mettre à la poubelle ses préférences (ce qui est la solution retenue par toutes les applis GTK3 que j'ai pu croiser) ou prendre le risque que mon interface explose.
Pour bien faire il faudrait une fois de plus que le rendu CSS GTK3 soit fluide, et que l'on dispose d'un retour sur l'interface du même type que celui dont on dispose en javascript - et qui permette de récupérer, d'analyser et de modifier la mise en page à la volée. Gnome-shell permet (un peu) ce genre de choses, mais une appli standard ne dispose pas de framework standard pour effectuer ces opérations. On y va à coup d'introspection et on prie.
_ Le fait que tu ne choisisses pas les classes n'a rien à voir avec l'utilisation de CSS, mais plutôt avec le fait que les widgets sont déjà définis et que GTK3 n'est pas un toolkit modulaire permettant d'ajouter des widgets. Ce que tu critiques est je pense voulu. Une classe par widgets, pour assurer l'uniformité du thème._
Mais je veux pas ajouter de widgets, je veux simplement une méthode simple qui me permette d'utiliser mes bouttons dans les partie spécifiques de mon appli et les bouttons standards dans les parties génériques.
Un exemple tout con : je veux faire un éditeur de texte dans lequel j'ai un arbre de navigation et une fenêtre de saisie d'un certain type pour les langages procéduraux et un autre arbre de navigation avec une autre fenêtre de saisie pour les langages fonctionnels. De plus je rajoute ou j'enlève des éléments à mon arbre en fonction du fait que le langae soit objet ou non. A cela j'ajoute une fenêtre de saisie en dessous pour l'accès console et une autre fenêtre en affichage seul pour la sortie de compilation/le debug.
Si je pouvais créer des classes ca prendrait 10 secondes à faire, mais comme je ne peux pas je suis OBLIGE de me trimballer des sélecteurs de 100 pieds de long pour distinguer entre mes différents éléments qui déscendent tous du même widget. Et si je veux créer une fenêtre en double pan pour les diffs et les merge ? Encore un selecteur. Et si je veux que l'utilisateur puisse détacher la fenêtre de debug pour la passer sur l'écran d'à coté ? Encore un autre sélecteur. Et dans chaque selecteur je refais TOUTE la CSS spécifique à l'élément. Donc le jour ou je veux changer le comportement de mon élément il faut que j'aille modifier mes CSS à 14 endroits différents. C'est EXACTEMENT ce que le CSS est supposé éviter.
_ Pourquoi veut tu un DOM ?_
Déjà parceque ca me permet de savoir quels éléments vont hériter de mes modifs CSS et quels sont ceux qui vont passer au travers. C'est fondamental quand on fait un thème ou une interface de savoir ce qui va être impacté. Je veux que mon boutton "fermer" soit en rouge violent sur la fenêtre qu'il ne faut surtout pas fermer a moins d'être sur à 100% de son coup, par contre je ne veux pas qu'il soit en rouge violent au niveau de la fenêtre d'aide qui peut elle être fermée quand on veut. Le DOM est ce qui me permet de savoir QUEL comportement je modifie quand je n'ai pas envie de les modifier tous.
Ce que tu demandes, c'est ce que GTK3 ne te fournit pas, mais encore une fois, non parce qu'il utilise CSS, mais parce que ce n'est pas son but.
Je te rassure, GTK3 fourni tout un tas d'outils qui permettent de faire des modifications d'aspect en fonction du fonctionnel sans que ca n'impacte l'ensemble des widgets du même nom sur toute l'appli. Sinon ca ne servirait pas à grand chose. On ne peut juste pas accéder simplement a ces fonctions depuis les CSS parceque les deux méthodes d'accès (par classe spécifique utilisateur et par parcours de l'arbre DOM) ne sont pas implémentées correctement.
Tu ne peux pas faire de manipulation complexe, de créer des thèmes par widgets, etc, etc, mais c'est assumé.
Assumé est un bien grand mot. Ils (les devs Gnome) disent qu'il ne faut pas créer de moteurs de thème, qu'il ne faut pas faire d'introspection pour des raisons de décorations, qu'il ne faut pas faire des sous groupements de widgets par fonction etc. Tu dois tout pouvoir faire avec du SVG et des CSS. Alors du coup tu essayes, tu y arrives pas et tu vas lire leur code poru savoir comment eux ils ont fait. Réponse : Ils ont créés des moteurs de thème custom dans lesquels il font des sous groupes de widgets, ils font de l'introspection à tire larigo, ils utilisent du png pour les images sans arrêt….
Sur Gnome-Shell ? On va carrément chercher un interpreteur ECMASCRIPT. Sur Nautilus ? On créé un widget custom par fonction et par sous fonction.
Si même eux n'arrivent pas à respecter leur truc sur des aspect fondamentaux du produit, je vois pas comment moi j'arriverai à faire quelque chose de propre.
En somme tu râles parce que GTK3 n'est pas aussi puissant que tu le souhaiterais
Non je rale parceque je me prend tous les inconvennients d'un sucre syntaxique assez lourd (les objest CSS) sans aucun des avantages. Pas de réutilisabilité au sein de mon appli, pas de selecteur simple, pas de DOM donc pas d'éléments cibles facile à atteindre. A chaque instant ou j'utilise les CSS GTK3 j'ai l'impression qu'on m'a donné une perceuse pour planter des clous. C'est proche du besoin en effet, mais makgré tout complètement à coté de la plaque.
GTK3 assume l'utilisation d'un sous-ensemble de CSS, je ne vois pas en quoi c'est un problème en soi tant que c'est documenté.
Alors déjà le tant que c'est documenté on y est pas encore.
Ensuite comme les CSS ne sont pas respectés par l'équipe Gnome elle-même on a des glitch dans tous les sens (variables en fonction du moteur de style utilisé) - donc même documenté il y aurait des chausse-trappes partout.
Et pour finir utiliser les CSS parceque "c'est trop cool, tout le monde connait, tout le monde sait s'en servir" avant de sortir une version limité autant au niveau des éléments, que des attributs et avec en prime un format différent pour les valeurs acceptable c'est idiot.
Sélectionner mes éléments avec des elem:active:insensitive:hoover:focus ca n'est intuitif pour aucun dev CSS. Ne pas pouvoir créer des classes et les réorganiser ca n'est intuitif pour aucun dev CSS.
Quitte à faire un autre langage, autant en faire vraiment un autre - là cet hybride est juste un piège qui va faire croire aux devs qu'ils peuvent rentrer dans le code directement (et qui va les accueillir avec un grand coup de batte de base-ball dans les gencives).
Pour résumer ton commentaire, tu dis que GTK3 ne répond pas à tout tes besoins et ne te permet pas une aussi grande souplesse qu'un site web
Je n'ai pas dit ça du tout. J'ai dit que GTK3 CSS ne permet pas de faire du GTK3. GTK3 et CSS sont sur deux paradigmes différents, ils ne peuvent totu simplement pas travailler ensemble de façon efficace pour faire du theming. Ca n'est juste pas possible. L'un des deux doit évoluer pour pouvoir dialoguer pleinement avec l'autre. Idéalement GTK3 devrait évoluer pour coller parfaitement au CSS du W3C (ou même à un sous ensemble de ces CSS) puisque c'est le but avoué de tout ce tintouin. Sauf que bien sur, à chaque fois qu'il y a un soucis c'est soit une verrue, soit une modif des specs CSS GTK3.
en quoi ne pas utiliser CSS, (GTK2 par exemple) améliorerait les choses que tu ne peux pas faire ?
Ben je n'utilise plus correctement CSS en GTK3 (et je ne m'en porte que mieux), l'utilisateur devrait déjà être content de conserver sa déco de fenêtre intacte. Je fais mes déco dans des scope volatils au moment du refresh. Mes feuilles css redéfinissent à peut près tous les widgets demon appli (et elles sont elles mêmes écrasées par les css dynamiques des scope précédamment évoqué). Pour tous les trucs un peu complexe (genre un slider qui est légèrement plus gros ou plus rouge que les autres) je donne un grand de coup de hache dans le moteur de thème etc.
C'est moche hein ? Mais tu sais le pire ? Tout le monde fait comme moi, même au sein du projet Gnome.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Kaane . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 10.
A part le rejet pur et simple, as tu un réel argument pour ne pas utiliser CSS dans GTK ?
Dans l'ordre :
a) C'est pas fait pour ça - Il existe certes des bibliothèques (le plus souvent en javascript) qui permettent de transformer certains éléments CSS en widgets, mais le CSS est un descripteur de style, c'est à dire qu'il sert à normaliser la mise en forme du contenu. S'en servir pour du contenant ne fait pas sens. Cela fait d'autant moins sens que GTK3 possède déjà un moteur de style qui lui est propre - et qu'une partie du fonctionnement interne est inaccessible depuis les CSS, le role de CSS dans le cadre du thème est donc batard :
- Il peut influencer le contenu (via margin , padding, font etc.) mais pas complètement le mettre en forme
- Il peut faire le thème mais pas complètement (il n'y a pas de "retour" en CSS - il faudra donc de toute façon écrire de la logique hors CSS pour le comportement avancé des widgets)
- Il rend le test des applications très complexe : comme les CSS GTK3 ne gèrent pas (encore ? apparament ca ne sera pas fait) l'ajustement automatique de la taille, un élément rendu trop grand par une CSS innapropriée sera tronqué. Comme il est décommandé de créer son propre moteur de theme, on arrive à des situations ou la barre de menu peut avoir été décalé sur le coté alors que vos widgets dans cette barre sont en long. Au final soit on force un thème complet ou presque dans l'appli (mais alors les préférences utilisateurs sont détruites) soit on prévoit 12 gazillons de possibilités (barre verticale à droite dans un système d'écriture droite à gauche), le tout avec le moteur standard, avec unico et avec adwaita pour faire bonne mesure.
b) C'est pas moi qui choisi les classes
La force de CSS est que l'on peut décrire une foultitude de classe de façon à faire passer des sélecteurs pour les modifier ou les manipuler si besoin est. Sauf que là les classes sont pour la plupart prédéfinie, et c'est préférable vu que l'on altère plus le contenant que le contenu. Mais du coup on arrive au point ou l'on est coincé dans sa capacité à choisir ou à disposer des classes. le résultat est que l'on se retrouve à créer des sélecteurs en pagaille sur des propriétés.
Vous voulez une image spéciale quand on est grisé une radio box dans un menu d'une fenêtre ? rien de plus simple il suffit de créer le sélecteur
.frame.menu.menuitem.radio:active:insensitive (pour la version cochée)
.frame.menu.menuitem.radio:insensitive (pour la version décochée)
.frame.menu.menuitem.radio:inconsistent:insensitive (pour la version qu'on sait pas encore si elle est cochée ou pas)
Faire un thème pour le moindre widget prend trois pages de déclaration, la seule solution pour ne pas avoir des sélecteurs à rallonge c'est de passer par le nom du widget créé. Par exemple faire une cascade sur NautilusWindow - ah oui mais dans ce cas là on perd l'avantage majeur du CSS : séparation de la logique et du rendu. Pas grave, les thèmes officiels Gnome ne passent quasiment que par des sélecteurs par nom du widget.
c) Il est ou mon DOM ?
Pour pouvoir utiliser les CSS correctement, voire intelligemment il faut connaitre au moins vaguement le DOM, c'est à dire savoir à quel niveau se trouve tel ou tel élément. Dans GTK3 non seulement je ne comprend pas le DOM, mais en plus je ne sais même pas ou se trouve le mien. C'est peut être moi qui suis mal comprenant mais…
J'écris une appli, je fais son css pour elle, j'importe les css GTK3 de base et je tente de respecter le au maximum les préférences utilisateur. Bon à un moment j'ai besoin de permettre à l'utilisateur de naviguer dans les fichiers locaux - pas de soucis j'invoque un widget nautilus et AAAHHH… Mais qu'est-ce qui se passe. Qui est la fenêtre active ? Je suis dans un widget donc ça devrait toujours être moi, mais qu'est-ce qui se passe au niveau du thème ? gnome-application.css fait de l'override forcé du thème mais est-ce que mon widget est bien le fils de mon appli ? Est-ce que les composants de mon widgets sont tous les fils de leur père ? Et si je branche un clef usb après avoir appelé mon widget ?
Et une fenêtre non modale ? C'est une parente de ma fenêtre principale ? Elle hérite des thèmes ? De tous les thèmes ?
Le pire c'est qu'à chaque fois que vous commencer à connaitre (parce que comprendre c'est pas possible) il y a un bug report qui est traité et qui "corrige" un comportement absurde par un autre comportement non moins absurde dans la cascade des styles.
Et puis il y a le SVG. Qui apporte son lot d'élément DOM, mais pas tout à fait comme le DOM SVG html. On pourrait écrire des pages et des pages la dessus.
d) Le CSS change - et GTK3 ?
Déjà sur du pur HTML le W3C se fout sur la gueule en permanence pour savoir ce qui rentre dans CSS et ce qui ne rentre pas. En faisant le choix du CSS GTK3 va se retrouver à plus ou moins long terme à devoir choisir entre deux choses désagréables
1 - suivre le W3C quoi qu'il arrive même si les nouvelles CSS partent dans des directions qui n'apportent rien à un système de thème
2 - maintenir et faire évoluer une version des CSS qui ne sera pas supporté par le W3C.
Ca a déjà commencé. Bonne chance pour faire mumuse avec du z-index ou du float sous GTK3, la taille des éléments est définie en points sans unité précisée (encore que l'em semble être supporté pour les fontes dans les dernières versions - mais c'est pas documenté), et les sélecteurs par nom du widget c'est assez fort…
C'est donc un langage qui ressemble à du CSS, mais qui n'est pas (du tout) du CSS. Ni dans l'esprit (mélange fond forme, DOM tordu, sélection par attributs en pagaille) ni dans la lettre (manque pleins de choses puissantes, subtiles nuances sur les choses restantes).
Voilà…
[^] # Re: bonne idée
Posté par Kaane . En réponse au journal Webcrise: appel à contribution. Évalué à 10.
Ou alors la catastrophe ultime : la migration vers GNOME 3. Mais là je crains que le génie civil ne sera pas suffisant.
Surtout que si tu n'endigues pas la migration très vite, les boutons de l'interface disparaissent un à un.
[^] # Re: A fond
Posté par Kaane . En réponse au journal La fin de la vue en arborescence dans Nautilus ?. Évalué à 10.
Quand tu sais où est le fichier tu n'as pas à le chercher !
C'est bien une réaction de power user ça…
[^] # Re: A fond
Posté par Kaane . En réponse au journal La fin de la vue en arborescence dans Nautilus ?. Évalué à 6.
Donc dans ton moteur de recherche de fichiers tu peux taper par exemple vmcoincoin/main.c ou zino/main.c ?
Effectivement, quand tu sais déjà ou le fichier se trouve tu peux rentrer suffisament d'informations pour permettre au système de recherche de le trouver très rapidement.
[^] # Re: A fond
Posté par Kaane . En réponse au journal La fin de la vue en arborescence dans Nautilus ?. Évalué à 10.
le raisonnement part du constat qu'après tout, dans un monde de fichiers indexés, pourquoi aurait-on besoin d'un explorateur de fichier alors qu'un moteur de recherche suffit pour 99% des cas d'utilisation (= chercher un fichier) ?
Il suffit juste de ne pas avoir plusieurs fichiers portant le même nom dans la zone de recherche. Mais bon qui serait assez bête pour donner exactement le même nom à plusieurs fichiers différents ?
Bon je vous laisse, j'ai mon main.c qui compile plus quand je fais un make, faut que je regarde si le problème ne vient pas de configure…
[^] # Re: Gnome et le menu des applications figé
Posté par Kaane . En réponse au journal GNOME 4.0 et GNOME OS prévus pour 2014 : abandon du pc, (même si on en était pas loin avec Gnome3). Évalué à 1.
Pourquoi essaieraient-ils de faire cela ?
Pour que les suggestions apparaissent au fur et à mesure que tu tapes…
[^] # Re: scribus ou laidout ?
Posté par Kaane . En réponse au journal Une alternative à PhotoWeb pour Linux??. Évalué à 1.
Quand je vois les livres photos qui trainent dans les bibliothèques de mes amis (oui j'aime bien fouiller pendant les soirées), je peux facilement affirmer que les vérifications sont probablement ultra sommaires.
Sommaire certes, pour 40€ on va pas déranger un expert chromato non plus. C'est aussi moche que les photos développées en une heure chez speeddev'30, mais les photos développées en une heure ça convient à beaucoup de gens.
Une impression quadrichromie mal réglée c'est quand même nettement plus moche. Le rouge est orange, le noir est gris moyen, les bleus sont ternes etc. De quoi transformer une photo de famille en réunion des dépressifs anonymes.
[^] # Re: Gnome et le menu des applications figé
Posté par Kaane . En réponse au journal GNOME 4.0 et GNOME OS prévus pour 2014 : abandon du pc, (même si on en était pas loin avec Gnome3). Évalué à 2.
A priori, vu ce que j'observe, on peut dire que le traitement qui filtre les applications en fonction du critère de recherche est fait dans le thread destiné à l'affichage…
Je pense plutot qu'ils essayent de faire les choses de façon synchrone, c'est à dire de bloquer l’exécution du javascript jusqu'à ce que la requête de recherche renvoi un résultat. Si l'index est mal foutu, la quantité de données trop grosse, la machine lente ça génère un freeze.
[^] # Re: Gnome et le menu des applications figé
Posté par Kaane . En réponse au journal GNOME 4.0 et GNOME OS prévus pour 2014 : abandon du pc, (même si on en était pas loin avec Gnome3). Évalué à 10. Dernière modification le 30 juillet 2012 à 22:50.
Question à laquelle je ne peux donner une réponse…
Le javascript est hard-threaded, c'est à dire qu'il a été décidé à l'avance ce qui serait pris en charge par tel ou tel thread.
Sur la plupart des implémentations il y a (tres grosso-modo) un thread pour les évènements utilisateurs, un thread pour les évènements système (les gros les lourds, pas les alarmes ou les ticks d'horloge), un thread qui dessine, un qui fait du bruit et un qui essaye tant bien que mal de coordoner tout ça.
Ce type de gestion est très pratique pour les évènements dissociés comme on en trouve sur le web, mais très très couteux quand on veut faire de synchrone. La question qui revient en boucle en JS c'est comment faire un sleep() ? Et juste après c'est comment savoir si tel élément a bien été créé/détruit/exécuté/joué jusqu'au bout. Assez vite tu te retrouves à créer des callbacks dans tous les sens et à déclencher des éléments virtuels en pagaille également (un grand classique étant de mémoriser que l'utilisateur a clické quelque part dans un coin et à attendre que l'élément X soit prêt pour simuler un click virtuel à l'endroit que l'utilisateur a clické quelques millisecondes trop tôt).
En web (ou l'utilisateur a l'habitude d'attendre quelque peu et n'hésite pas à cliquer à nouveau) ca passe. En desktop c'est l'horreur sur une machine trop peu puissante ou trop chargée.
[^] # Re: scribus ou laidout ?
Posté par Kaane . En réponse au journal Une alternative à PhotoWeb pour Linux??. Évalué à 7.
et passes par un imprimeur tiers. Ce ne sera pas forcément moins économique et tu auras toute la liberté que tu voudras.
Oui, sauf qu'un imprimeur "grand public" il prend en charge pas mal de problèmes pour toi, notamment au niveau des couleurs et des fonds perdus. Il vérifie que tu n'as pas fait de conneries et généralement il t'avertit gentiment si tu veux faire un beau rouge pétant sur fond vert fluo. Un imprimeur pro qui travaille à l'épreuve (pas de bon à tirer) ou en série limité (BAT facturé à chaque fois) il imprime les couleurs que tu lui donnes. Vient pas te plaindre si ta belle photo de camion pompier sur fond de verdure et de ciel bleu s'est subitement transformée en pastel.
Personnellement pour les livres de qualité avec des couleurs chiantes que j'ai pas envie de régler pendant des heures, comme j'ai la chance (et le malheur) d'être parisien je passe par un labo photo (en l’occurrence Negatif+ ) probablement le dernier labo photo pro abordable de la capitale (Si vous en connaissez d'autres, je suis preneur).
[^] # Re: Grub2 vs Grub1 : Quel est le problème ?
Posté par Kaane . En réponse au journal Arch et le tournant. Évalué à 3.
C'est une hyperbole ou tu as vraiment un fichier à jour de références de matériel qui marche ?
Malheureusement c'est une hyperbole, je fais aussi joujou avec des tableaux
mais cadeau quand même :
http://www.freebsd.org/relnotes/CURRENT/hardware/support.html#WLAN
C'est pour FreeBSD, mais tout fonctionne sous Linux aussi.
Ca fait un tableau de plus pour faire joujou avec…
[^] # Re: Encore un effort...
Posté par Kaane . En réponse au journal "droit au mariage à tous les couples sans distinction de sexe ni de genre". Évalué à 7.
Imaginaires non plus.
Je suis en couple depuis plusieurs années avec Madoka de Kimagure Orange Road, et c'est vrai que ca me ferai plaisir que l'Etat me permette d'officialiser mon union. J'ai peur que ma famille s'en prenne à mes posters et mes goodies si il venait à m'arriver quelque chose…
[^] # Re: Grub2 vs Grub1 : Quel est le problème ?
Posté par Kaane . En réponse au journal Arch et le tournant. Évalué à 1.
Une adoption aussi massive, on parle toujours des utilisateurs arch ?
Non plutôt d'une adoption massive par les distribs en fait. Il reset plus grand monde sur grub de base…
[^] # Re: Grub2 vs Grub1 : Quel est le problème ?
Posté par Kaane . En réponse au journal Arch et le tournant. Évalué à 10.
Autant systemd est une hérésie qui mérite le mépris le plus profond de la part de tout bon linuxien (Et même des windowsiens avertis, quand je leur explique qu'il s'agit d'une espèce de meta-DCOM unique et centralisateur ils me regardent comme si j'étais devenu fou. Alors que c'est pas moi qu'il faut soigner), autant grub2 est nécessaire pour plusieurs raisons :
1) Le ridicule ca va bien 5 minutes :
Il s'agit peut être de features qui intéressent 3% des gens, mais c'est vrai que les 3% de gens qui voulaient du VFS chiffré sur la partition racine commenceaient sérieusement à se demander si on se foutait pas de leur gueule. Preloader, bootloader, chainboot, chainloader, preboot, extractions du kernel en mémoire vive, chargement des modules et enfin boot. Avec à chaque mise à jour la légère apréhension qui va bien à se demander dans quel état on va retrouver son boot.
2) C'est pas plus mal de booter un vrai file system :
Si on omet légèrement EXT4, qui est un FS dont on a bien du mal à dire si il est moderne ou ancien tant il est optimisé dans les coins (pan), la plupart des fs dit "modernes" (ZFS, HammerFS par exemple) ou des pseudofs (LVM2, gvinum/gpart, luks et autre) utilisent une couche d'abstraction qui n'est pas vraiment compatible avec les techno de grub. Bon en bricolant ca finissait par passer d'une façon ou d'une autre, mais bonjour les pirouettes.
3) Et si je veux 6 partitions actives ?
La limite de 4 partitions actives est un poil dépassée. J'étais déjà un poil à l'étroit dedans quand les disques faisaient 20Go, alors maintenant qu'ils font 1,5To ca me gave d'autant plus, surtout vu ce qui a été dit précédemment, quand j'ai déjà une partition pour le /boot, une pour le / et une pour mon vrai système de données encapsulé dans du LVM et éventuellement chiffré, je me retrouve à devoir acheter un disuqe supplémentaire ou mettre le swap dans le LVM si je veux garder mon autre OS (Freebsd, mais c'est pareil avec windows). GPT permet de repousser cette limite, seulement grub a besoin d'un MBR classique alors on se retrouve une fois de plus à faire des pirouettes.
4) Les systèmes UEFI/GPT only arrivent.
Dans peu de temps, grâce à windows8 (un bonheur n'arrive jamais seul) on aura du secure bidule à tous les étages, et je suis prêt à parier que le secure bidule en question va exiger d'ici deux ans maximum une partoche GPT ou un boot UEFI (ou les deux). Et là ça va commencer à devenir compliqué de mettre des MBR hybrides signés (merci Red Hat), surtout si on veut garder le windows préinstallé. Bien sur il restera toujours la possibilité de vérifier que votre carte mère est compatible grub (sous reserve d'upgrade de firmware à la con) sur les sites spécialisées, mais personnellement quand je fais mes courses j'ai déjà le catalogue des cartes wifi compatible avec mes systèmes (3 tomes avec les numéros de séries- parceque des fois le constructeur il change la puce mais pas la référence) et le catalogue des ACPI qui sont fonctionnelles (4 tomes, avec numéros de série ET de firmware). Donc si je peux éviter de me trimbaler en plus le catalogues des cartes qui tolèrent le boot MBR hybride ca m'arrange (et tant pis pour mon osteo qui aime bien que je me trimballe avec 20 tomes sur moi en toute circonstance).
En vrac je vous épargne le boot de partoche avec des secteurs 4k/8k/16k, la reprise suspend on disk de partitions cryptées, la regen de pool ZFS en vrac etc.
Pour finir bien que grub2 soit officiellement encore en beta il est relativement fonctionnel au moment ou les distribs commencent à l'adopter (plus que systemd par exemple qui a forcé trois réécritures de DBus à lui tout seul, et on va rester gentil et pas parler de pulseaudio). Il est également relativement non intrusif (si on veut remettre lilo ou l'ancien grub à la place, pas besoin de désinstaller la moitié du système d'abord).
On va donc dire que grub2 est un peu vert pour une adoption aussi massive, mais que ca se comprend quand même.
[^] # Re: thème « pro »
Posté par Kaane . En réponse au journal La prochaine Debian sera toute belle. Évalué à 5.
c'est quand même le choix de pas mal de distros.
Choix est un bien grand mot. Sur les dernières versions de dev Gnome 3 il te faut systemd, udev, udisk2 et consors.
A partir de là soit tu intègres toute la clique, soit tu patches Gnome 3 dans tous les sens, soit tu laisses tomber.
Slack a complètement laissé tombé Gnome, parcequ'ils ne veulent pas toute la clique.
ArchLinux ne veut pas de systemd, mais est obligé de le faire rentrer petit à petit pour permettre à Gnome (et autres) de continuer à marcher raisonnablement.
Debian resiste, mais du coup leur version de Gnome 3 en testing est pour le moins spéciale.
On finit par arriver à des cas absurdes ou pour faire fonctionner des programmes userland, on est amené à mettre à jour kernel et système (apparament avec udisk2, changer la version du bootloader pour grub2 est fortement recommandé).
[^] # Re: thème « pro »
Posté par Kaane . En réponse au journal La prochaine Debian sera toute belle. Évalué à 10.
systemd n'est ni sobre, ni épuré, et il ne plaît clairement pas au maximum de gens… de quoi tu parles alors ?
Nous sommes d'accord que systemd n'est ni sobre ni épuré. Je faisais juste allusion au fait que si un jour une distrib décide de faire un thème jaune fluo sur fond rose, tout le monde hurlera, et tout le monde comprendra pourquoi c'est idiot.
Si la même distrib décide de mettre par défaut et de façon inamovible systemd, lumberjack, pulseaudio ou autre, il y a 50% des utilisateurs qui trouvent ça normal et qui défendent becs et ongles la solution.
C'est troublant.
[^] # Re: Normal quoi
Posté par Kaane . En réponse au journal Pourquoi je quitte KDE (désolé, c'est dimanche). Évalué à 6.
Bonjour, j'ai installé trois versions différentes de la même distribution sur la même racine, et bien bizarrement ça ne marche pas. C'est forcement la faute du logiciel Y et certainement pas de la façon dont j'ai réalisé les installations.
Clairement, ça me rappelle le gars qui sur une Debian stable avait voulu tester la dernière version de Gnome3. Le con, il avait pas mis à jour udisk en udisk2 et il utilisait un vieux DBus. Toutes ses partitions vfs sont parties en vrille on a mis 3 jours à tout récupérer.
Ou encore le mec qui voulait utiliser file roller sur XFCE sans remonter toute la couche gnome avec. Dès qu'il fait un glisser déposer depuis une archive vers le bureau il locke complètement son xorg. Comme si on pouvait installer un programme de gestion des archives sans installer evolution-server d'abord !
Je vous jure, il y a des utilisateurs des fois…
Enfin du moment que c'est clair pour tout le monde que sous Linux il faut pas s'amuser à compiler ou à installer soi-même des packages d'une autre distribution, tout va bien. C'est pas comme si c'était un système ouvert non plus.
[^] # Re: thème « pro »
Posté par Kaane . En réponse au journal La prochaine Debian sera toute belle. Évalué à 10.
C'est marrant comme certaines choses semblent totalement naturelles quand on parle du thème visuel par défaut, et comme ces même choses vous font passer pour un odieux réac, réfractaire à tout changement quand on parle de systemd ou network manager…
# Pas encore autorisé
Posté par Kaane . En réponse au journal La vente liée est autorisée en France. Évalué à 10.
Je ne suis pas spécialiste en droit, donc, je ne m'étendrais pas.
Je ne suis pas spécialiste en droit, mais la cour de cassation ne donne pas raison ou tort à l'une ou l'autre des parties, elle analyse un jugement et rend son verdict sur la validité ou non de celui-ci.
Donc elle n'a pas donné raison à HP, elle a statué que les arguments utilisés par la cours d'appel n'étaient pas valable.
C'est quand même très mauvais signe, mais ca n'est pas encore de l'enfoncage de clou dans le cercueil.