Linux? - Page 45

et comment tu les remplaces?

Sally (./1313) :
En fait globalement ce qui me surprend sous mac c'est que ça semble assez difficile de tout faire à la souris (sans passer par les menus j'entends), je ne sais pas trop pourquoi mais j'imaginais plutôt l'inverse. J'ai l'habitude de me passer très largement du clavier pour plein de trucs, mais sous mac le choix a l'air d'être souvent entre raccourci clavier et menu, d'ailleurs les préférences permettent de définir des raccourcis clavier mais pas des raccourcis souris.
(Enfin j'ai vu qu'on peut associer des actions exposé aux boutons, le seul problème c'est qu'il faudrait que ces actions ne se déclenchent que si le pointeur n'est pas sur une fenêtre sinon ça empêche d'utiliser la souris normalement c'est pas très utilisable du coup )

Si ça peut te consoler, c'est également difficile de tout faire au clavier (mais déjà, tu peux associer un raccourci clavier à n'importe quelle entrée de menu, c'est un gros avantage). Je trouve que Windows permet davantage de choses au clavier, même si certaines sont moins bien fichues.

Brunni (./1316) :
Nil> Oué en multi-écran peut être. Et encore, il faut que les écrans ne soient pas trop grands, sinon la distance à parcourir d'un écran à l'autre pour la moindre opération devient chiante... c'est comme l'histoire de la barre de menus d'OS X qui n'apparaît que au sommet de l'écran principal. Le jour où on sera payé au kilomètre parcouru à la souris on fera fortune.

Bof, ça dépend de ce qu'il y a sur les palettes, de ce qui est accessible via des raccourcis claviers, de la façon d'organiser, etc.
Typiquement, moi j'ai ça comme ça (c'est un peu moins vrai pour The Gimp, mais carrément pour les DAWs) :
[Ecran 1 : [Palettes d'information][Palettes avec boutons]][Ecran 2 : [Fenêtres de travail actives]]
Les fenêtres de travail inactives peuvent êtres soit sur l'écran 1, soit sur l'écran 2 en fonction de mes besoins (si j'ai besoin de voir en parallèle, de faire des allers/retours...).

Ouais enfin, y'a des cas où les faire non-modales est bien chiant à gérer question code, alors que ça n'apporte pas grand-chose à l'utilisateur.

Godzil (./1317) :
Sinon non c'est un bug de l'utilisateur. Si tu met ta palette par dessus la fenetre, c'est normal qu'elle la couvre!

J'avais envie de mettre la palette là parce que je travaillais sur une partie de mon document qui n'était pas sous cette palette. Et parce que je ne sais jamais où les foutre ces palettes, j'ai un petit écran (15"4, 1600x900) et je dois les placer au pixel et en plus elles se redimensionnent suivant les cas.

Ca m'étonne de toi Godzil, qui est pourtant très pointilleux sur les UI. Normalement si on sort un concept il faut faire en sorte qu'il soit le moins flou possible et que par nature il évite à l'utilisateur de faire des erreurs. Les palettes ne m'empêchent pas, au contraire me poussent à faire des erreurs (du moins des choses non-souhaitables).

C'est un peu comme si je décidais par exemple de dire dans mon gestionnaire de fichiers que la touche Enter efface un fichier sans récupération possible. Serait-il justifié qu'un utilisateur qui le fait par erreur se plaigne, ou c'est lui le con, il a demandé explicitement d'effacer le fichier et c'est ce que le système a fait?

Le probleme, c'est que dans ce cas le save/open dialog en question n'est PAS modal, vu qu'il est intégré a la fenetre. Ce n'est vraioment pas un bug, sinon ça voudrait dire qu'il faut faire passer la fenetre a un niveau supérieur a la palette, ce qui ne serait pas correct.

Brunni (./1325) :
me poussent à faire des erreurs (du moins des choses non-souhaitables).

Comme quoi ? elles t'on effacé ton disque ? Elles t'on renommé ton fichier ?

Quand a effacer un fichier en appuyant sur la touche enter, pourquoi pas apres tout, c'est qu'une histoire de convention.

squalyl > par des trucs qui ont quelques limitations mais pas tant. Par exemple ça devrait *toujours* être possible de minimiser ou de déplacer une fenêtre (bon là sous mac je viens de tester et déplacer est possible, c'est déjà ça, mais pourquoi pas minimiser ? je peux avoir besoin de voir ce qu'il y a en-dessous non ? et pourquoi pas redimensionner ? pourquoi pas scroller ? pourquoi pas sélectionner et copier du texte ? (en fait c'est souvent ce dernier point qui m'embête, ça m'arrive régulièrement de vouloir copier-coller du texte depuis une fenêtre de l'application vers une boîte de dialogue modale, et la seule solution c'est fermer la boîte, copier et rouvrir))

Godzil (./1326) :
Le probleme, c'est que dans ce cas le save/open dialog en question n'est PAS modal, vu qu'il est intégré a la fenetre. Ce n'est vraioment pas un bug, sinon ça voudrait dire qu'il faut faire passer la fenetre a un niveau supérieur a la palette, ce qui ne serait pas correct.

Ça pourrait être modal par rapport au reste de de l'application (c'est généralement comme ça sous Windows, et je ne vois pas les problèmes que ça pose, bien au contraire).

C'est quasi jamais modal sous Linux/XFCE, et ça change la vie !

Je vois pas en quoi c'est tant un problème les dialogues modaux. Par exemple pas besoin de chercher plus loin que le formulaire de post:
[URL=http://img412.imageshack.us/i/img030o.png/][IMG]http://img412.imageshack.us/img412/592/img030o.png[/IMG][/URL]

On peut discuter sur le fait de faire un dialogue, mais si on en fait un il vaut mieux qu'il soit modal! Si on voulait faire dans l'élégance on l'intégrerait à la page avec un joli effet de transparence, et il se fermerait lorsque la page a effectivement été réceptionnée. Mais quoi qu'il en soit, il vaut mieux qu'il soit modal (avec une possibilité de le fermer).
Et pour le truc d'enregistrement non-modal alors qu'il recouvre 80% de la surface de travail du document, pour moi ce n'est pas bien. Comme de toute façon l'interactivité est bloquée, mieux vaut par exemple décolorer l'arrière plan (cf. mon screenshot), au moins tu remarques qu'il y a qqch à faire et tu évites de te perdre. Note que dans le cas d'Apple le dialogue est en fait modal, mais intégré à la fenêtre. Donc il ne bloque pas totalement l'application (il est toujours possible d'utiliser les palettes pour travailler sur un document que tu ne vois même pas), mais il est modal à la fenêtre principale.
Pour les tâches plus compliquées par contre c'est discutable, par exemple si tu avais tapé un nom de fichier avec plein de caractères hindi en UTF-42 et que tu penses à ce même moment que tu voudrais faire encore une modif avant d'enregistrer, alors il faudrait pouvoir passer le dialogue en arrière-plan. Mais comme c'est un use case peu commun, et que le presse papiers (Klipper dans mon cas, qui stocke les 10 derniers éléments) s'en charge très bien au besoin, il vaut mieux à mon sens faire un dialogue modal que prendre le risque d'avoir des fenêtres inutiles et du travail incomplet.

Ben typiquement, avec FF sous Windows (et MacOS ?), quand tu as besoin de consulter un mot de passe dans la bibliothèque des mots de passe, tu doit faire Outils > Préférences [hop, 1ère fenêtre modale], Sécurité, Mots de passe enregistrés [Hop, 2nde fenêtre non modale]... Passons sur le fait qu'on ne puisse pas copier dans cette fenêtre, mais je me retrouve obligé de noter dans un bloc note l'identifiant et le mot de passe en question, de refermer les deux boites, puis de taper mon mot de passe (en espérant que je ne me sois pas trompé/qu'il n'y en ait pas deux).
Sous Linux (XFCE), une fois la seconde fenêtre modale ouverte, je referme la première (donc je gagne de la place), et je la fais glisser sur un autre écran ; j'ai donc tout le loisir de copier (manuellement ) et de coller à la volée autant de fois que je veux l'information qui m'intéresse...

Quant aux alertes js, c'est infernal, rien ne peut les arrêter, et comme elles ne sont pas considérées comme un script bloqué, pour peu qu'une page soit merdique, ça peut t'emmener à tuer ton navigateur sauvagement pour qu'il te redemande quels onglets tu veux restaurer...

Brunni (./1330) :
Je vois pas en quoi c'est tant un problème les dialogues modaux.

Ben je l'ai expliqué pourtant, ça t'empêche de manipuler ta fenêtre comme tu veux (et en particulier de la virer en la minimisant) tant que tu n'en as pas fini avec la boîte de dialogue. Que l'application devienne non-interactive tant qu'on n'a pas fini ok, mais que la fenêtre elle-même soit complètement bloquée, non. Et d'autre part ne pas pouvoir écrire ou faire des actions sur la fenêtre ne devrait pas empêcher de lire et éventuellement, pour ce faire, de scroller, ni de copier du texte, il n'y a pas de raison.

Nil : Je crois qu'Opéra permet de bloquer les popups JS d'un onglet, peut-être qu'il existe une extension Firefox qui fait pareil ?

Sally : ah, mais quand je disais "modal" je voulais dire "non-interactif selon ta définition", hein (il n'y a pas de raison d'empêcher de minimiser l'application, c'est juste que le reste de l'appli sera pas accessible tant que la fenêtre restera ouverte). Quant à continuer à utiliser l'appli dans un mode "restreint", là ça demande davantage de code.

Godzil (./1310) :
En meme temps sous tous autre OS, c'est la meme chose, une paloette de ce type passe par dessus les fenetres de l'application (bon ok,sauf linux, mais linux ne sais pas gerer correctement les fenetres et ce type de fenetre n'existe pas sous X11)

Euh si, GNU/Linux gère le always-on-top avec un WM conforme aux specs de X.org et freedesktop.org (genre KWin ou Metacity). Et KWin permet aussi de le désactiver de force si la fenêtre l'utilise abusivement (ainsi que de changer de force pratiquement tous les autres paramètres d'une fenêtre). Mais par défaut, il respecte ce que l'application lui demande.

Brunni (./1311) :
Ben non justement, ce type d'interface ne se retrouve que sous Mac (ou ceux qui ont repris l'idée, comme GIMP), et c'est tout le concept de ces palettes flottantes que je critique, justement pour ces raisons.

Les fenêtres flottantes de GIMP ne sont pas always-on-top (c'est peut-être pour ça que Godzil croit que ce concept n'existe pas sous GNU/Linux, mais c'est juste GIMP qui a choisi de ne pas l'utiliser), et à mon avis c'est mieux comme ça (je déteste le always-on-top!).

Pour le problème des dialogues modaux, le choix de rendre un dialogue modal est souvent de la paresse d'implémentation: c'est plus simple de tout bloquer quand on attend une réponse que de gérer ça de manière asynchrone.

Mais effectivement, souvent des dialogues sont modaux quand ils n'ont pas besoin de l'être, les applications KDE utilisent souvent des dialogues modaux et parfois ça m'agace pour les raisons déjà citées (genre si je veux copier un morceau de texte pour le coller dans le nom de fichier).

Nil> En fait sous firefox c'est plus compliqué et plus débile.
Certains des popups qui s'ouvrent depuis la fenêtre d'options ne sont pas modaux : c'est le cas des mots de passes enregistrés. Il suffit d'ouvrir les options, ouvrir les mots de passes et fermer les options pour pouvoir utiliser le navigateur en même temps que la fenêtre des mots de passe .
(D'autres popups sont modaux, d'autres remplacent des popups déjà ouverts, il y a même la fenêtre de gestion des extension qui est modale quand elle est ouverte depuis les options et non modale quand elle est ouverte depuis le menu outil ²)
sally, les fenêtres modales, c'est infernal

Sinon y a un truc que je me demande, peut être que quelqu'un saura m'aider, mais j'ai l'impression que "des parties de GNOME" tournent sur mon système, et je ne sais pas comment ils sont lancés et comment les arrêter au besoin. Par exemple, si je lance gnome-power-statistics (l'outil démarré lorsqu'on clique sur la batterie dans la barre système de GNOME):

[URL=http://img697.imageshack.us/i/img032.png/][IMG]http://img697.imageshack.us/img697/8373/img032.png[/IMG][/URL]

Il a logué l'état de la batterie depuis la dernière fois que je l'ai lancé, mais pas avant. Il a donc dû lancer un démon qui journalise ça, mais je ne vois pas lequel ça peut être

Essaie un coup de "top", puis quelques coups de "sudo modprobe -r servicedemerde"...

(Ta batterie file bien vite )

Au fait… https://admin.fedoraproject.org/updates/hplip-3.10.6-1.fc13, https://admin.fedoraproject.org/updates/hplip-3.10.6-1.fc12
L'imprimante multifionction de Yoshi Noir (cf. ./464, ./465) est gérée par Fedora 12 et 13 depuis hier.

YN> Non dans top y a rien, forcément c'est pas un démon qui va consommer bcp de RAM ou de CPU
Pour la batterie c'est normal, on n'a pas le même hard ni la même utilisation (j'étais à 30W à ce moment, contre 12W en idle - ce qui est déjà énorme, et c'était ma critique principale sur cette machine quand j'en ai fait une mini-review dans un topic après l'avoir reçue)
Il est vraiment bon cet utilitaire, KDE est totalement à la ramasse à ce niveau, par défaut il n'affiche même pas l'autonomie restante, sous prétexte que c'est trop imprécis
Pour le démon si jamais c'était upowerd:

florian@florian-laptop:~/Téléchargements$ ps -A >before
florian@florian-laptop:~/Téléchargements$ gnome-power-statistics 
florian@florian-laptop:~/Téléchargements$ ps -A >after
florian@florian-laptop:~/Téléchargements$ diff before after 
227c227
<  2337 ?        00:00:04 foobar2000.exe
---
>  2337 ?        00:00:05 foobar2000.exe
234c234,237
<  2436 pts/1    00:00:00 ps
---
>  2441 ?        00:00:00 upowerd
>  2483 ?        00:00:00 gvfsd
>  2489 ?        00:00:00 gvfs-fuse-daemo
>  2494 pts/1    00:00:00 ps
florian@florian-laptop:~/Téléchargements$ 

A part ça Kevin, toi qui connais bien le sujet, est-ce que tu as déjà vu des bug-reports/plaintes à propos de la lenteur de KWin?
Je dis ça parce que je n'arrive pas à trouver, pourtant il semble clair à l'utilisation que l'environnement ralentit avec le temps: par exemple si j'ouvre 50 fenêtres Dolphin, puis que j'ouvre Firefox ou Chrome (fenêtre maximisée) et que j'utilise la barre de défilement, le défilement est nettement moins fluide lorsque les fenêtres sont ouvertes. Une fois les fenêtres Dolphin fermées, cela redevient normal.
Dans ces cas, l'utilisation CPU de KWin et Xorg est excessivement élevée. Compiz, en revanche, ne ralentit pas dans ces cas (en fait il se permet d'être plus fluide que KWin avec 1 seule fenêtre ouverte), et l'utilisation CPU du processus 'compiz' reste faible. Celle de Xorg en revanche est similaire.
Bref ces observations me font dire que:
* Soit KWin considère toute fenêtre comme ayant un canal alpha, signifiant que redessiner la zone client d'une fenêtre suite à une mise à jour de son contenu implique de redessiner tout ce qu'il y a en arrière-plan
* Soit, basé sur la forte utilisation du CPU me semblant anormale pour un compositer, l'algo de mise à jour de l'affichage ou de gestion des objets graphiques est mauvais, et il rame lorsqu'il y en a beaucoup.
Ca te dit quelque chose?

En tous cas si le graphe des ressources de ma machine devait m'inspirer quelque chose ce serait plutôt un jeu de motocross à 3 niveaux de difficulté qu'un système sain
[URL=http://img841.imageshack.us/i/img034.png/][IMG]http://img841.imageshack.us/img841/115/img034.png[/IMG][/URL]

Intéressant... http://www.nvidia.fr/object/linux-display-amd64-260.19.04-driver-fr.html
-> Support d’OpenGL 4.1 pour les GPU Quadro Fermi, GeForce GTX 4xx et plus
Je ne sais pas qui disait qu'on était encore à la version 1 d'OpenGL pour Linux, mais apparemment ce driver propriétaire fait avancer les choses au moins

C'est plus haut dans ce topic: ./1075 (p36) ./1086 et suivants (p37, p38)
Avec plusieurs drivers libres, vu qu'OpenGL 2 (défini en 2004) ne fonctionne pas, on en est toujours à OpenGL 1. Avec le driver propriétaire Nvidia, on peut profiter des dernières technologies.

Lionel> Ok Bon dommage quand même qu'il soit fermé, mais ça m'a l'air d'être la moins mauvaise solution (la meilleure étant Windows, grâce à DirectX ).
Rhoooo comment ça poutraiiillle! Le nouveau driver de nVidia permet de:
* régler la façon dont le tramage de l'écran de laptop est réalisé (aucun, statique ou dynamique)
* limiter l'espace de couleur (utile pour ceux qui ont du RGBLED)


[Edit] Je confirme que sans tramage on voit vraiment le bending, et le "pixel walk" est toujours là. Mes excuses à GoldenCrystal

Il supporte enfin xrandr ou pas ? (c'est le seul truc qui fait que je ne re-bascule pas)

http://yfrog.com/f/61xsyoj/

kernel panic: attempting to kill init.

C'est partout pareil, mais on dirait celui qui est a place d'it en descendant de la 6 ^^

non celui la est a hotel de ville

source : http://www.gizmodo.fr/2010/09/16/panique-de-noyau-dans-le-metro.html

Comme quoi tout se ressemble

Bon au moins vu le message d'erreur c'est pas trop l'OS qui passe pour un con (filesystem merdé), juste un pauvre disque dur qui vient de finir sa route monotone ^^
Ce qui aurait été marrant c'aurait été que le plantage soit lié à la carte graphique nVidia par exemple