Outre le nettoyage de tout le code rendu obsolète au cours des 12 versions mineures de la branche 2.x, cette version apporte des changements profonds, des mises à jour technologiques et de nouvelles API pour faciliter le développement d'applications. Visible pour l'utilisateur :
- GTK+ gère désormais plusieurs périphériques de pointage et de saisie. Cela est tout spécialement utilisé sur le matériel mobile ;
- des nouveaux widgets : l'interrupteur, le sélecteur d'application et une icône à laquelle on peut assigner un numéro (ex : nouveaux messages) ;
- une amélioration du calcul de la taille des widgets selon le principe : hauteur selon la largeur, mais aussi largeur selon la hauteur. Cette amélioration a été notamment portée pour le calcul de la taille des cellules des listes. Le résultat est la simplification pour les développeurs qui veulent un bon agencement de leurs widgets, et la disparition de certains bogues d'affichage (ex : en redimensionnant un « pane »).
- abandon de l'utilisation des antiques bibliothèques de dessin de X11 pour migrer vers une solution exclusivement Cairo. Cela a grandement détaché GTK+ de concepts propres à X11.
- le nouveau moteur de style incluant une syntaxe similaire aux CSS et l'animation des transitions d'états des widgets ;
- nouvelle API pour gérer le concept d'application. Il est désormais très facile de faire une application multi-fenêtres (façon Nautilus ou Firefox) et à instance unique, de rendre l'application scriptable, etc. ;
- une liste de licences libres est prédéfinie pour la boîte de dialogue « À propos ».
Aller plus loin
- GTK+ (181 clics)
- Annonce sur le blog (30 clics)
- Explications du nouveau calcul de taille des widgets (47 clics)
- GNOME 3 (76 clics)
- GNOME francophone (166 clics)
# Un (nouvel) espoir ?
Posté par windu.2b . Évalué à 7.
Parce que, comme évoqué récemment dans ce journal[1], s'il y a bien un truc tout pourri, c'est ça !
1 http://linuxfr.org/comments/1206514.html#1206514
[^] # Re: Un (nouvel) espoir ?
Posté par karteum59 . Évalué à 4.
[^] # Re: Un (nouvel) espoir ?
Posté par xumelc . Évalué à 6.
# Questions
Posté par JGO . Évalué à 4.
1)
> Il est désormais très facile de faire une application multi-fenêtres
> (façon Nautilus ou Firefox) et à instance unique,
Pour Firefox et d'autres navigateurs, je croyais que l'objectif des prochaines releases était justement le contraire, avoir une application multi-fenêtre mais avec plusieurs processus, afin de mieux gérer un blocage dans un onglet.
2) Un programme écrit pour gtk2 peut-il être compilé et lié avec gtk3 ? Par exemple, si le sélecteur de fichiers ou la boite de sélection de couleurs sont plus jolis dans gtk3, peut-on directement en profiter ou il faut modifier le code ?
[^] # Re: Questions
Posté par monde_de_merde . Évalué à 4.
Pour le 2), http://library.gnome.org/devel/gtk/unstable/gtk-migrating-2-(...) , enjoy !
[^] # Re: Questions
Posté par BFG . Évalué à 2.
Cependant, je pense que le concept d'une instance unique de l'application par session n'est pas toujours utilisé à bon escient. Il est à mon avis utilisé pour être sûr que toutes les instances soient synchronisées dans leur options/favoris/etc. (selon ce qui fait sens pour l'application). Ce sont de fausses instances puisqu'il y en a une qui centralise ça. Même diviser en plusieurs processus ne résout pas forcément tous les problèmes puisque la centralisation reste présente.
Cela amène le problème que si l'instance centrale plante, généralement toutes les sous-instances plantent. C'est par exemple le cas de roxterm, le terminal du bureau rox ([http://roscidus.com/desktop/]). Il m'est arrivé qu'un bug causé dans un terminal ferme tous mes terminaux roxterm ! Je vois que gnome-terminal n'utilise qu'un processus également.
Pourtant, à part la facilité d'implémentation de la propagation des options, je ne vois pas ce qui justifie d'utiliser une instance unique pour un terminal. xterm ne cherche pas à synchroniser les options, mais au moins, un xterm ne fait pas planter les autres xterm.
[^] # Re: Questions
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Personnellement, j'en ai marre de ces applications qui refusent le multi-instance et les notions simples d'UNIX. Les bibliothèque et le format ELF sont là pour gérer la mémoire intelligemment.
Il y a pleins d'applications ou on ne change pas la configuration tous les quatre matins et ou avoir pas mal d'instance n'est pas génant. Je pense même qu'un navigateur comme Firefox devrait être par défaut multi-instance, il y aurait je pense bien moins de soucis s'il l'était vraiment (je ne parle pas du multi-profile qui est un truc qui ne sers à rien et qu'on devrait choisir via un drapeau -f au lancement par exemple).
[^] # Re: Questions
Posté par claudex . Évalué à 2.
Tu ne pourrais juste plus garder l'historique et les signets. C'est une grosse perte de fonctionnalité pour un navigateur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Questions
Posté par 태 (site web personnel) . Évalué à 8.
bash et zsh arrivent très bien à avoir un historique rempli par plusieurs instances. De plus, firefox stocke les signets dans une base de données. Les SGBD font en général beaucoup de travail pour permettre les transactions concurrentes. Une instance unique n'est pas la seule réponse à ce problème et, de mon point de vue, ce n'est pas la plus simple.
[^] # Re: Questions
Posté par claudex . Évalué à 10.
Si je ne me trompe pas, pour bash, il fait ça à la fermeture, ce n'est pas du tout comparable.
De plus, firefox stocke les signets dans une base de données
Sauf que SQLite n'a pas d'instance à part et qu'il ne gère pas les accès en écriture multiples.
Une instance unique n'est pas la seule réponse à ce problème et, de mon point de vue, ce n'est pas la plus simple.
Pourtant tu cite bien les bases de données qui gère cela de cette façon.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Questions
Posté par Joël Thieffry (site web personnel) . Évalué à 2.
1. Réouverture du fichier en écriture non partagée
2. Écriture des données
3. Réouverture du fichier en lecture partagée
C'est assez bourrin, il faut que le système de fichier le supporte, mais ça marche (testé pour vous à mon boulot).
[^] # Re: Questions
Posté par claudex . Évalué à 6.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Questions
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Après, c'est une gestion de la file d'attente. Tu poses un verrous, écris et enlèves le verrous. Vu le temps pour écrire dans Firefox et vu le temps de réaction humain du click click, Firefox a largement d'écrire 100 fois le fichier entre deux actions humaines... On n'est pas ici sur une problématique de serveur de contenu avec des centaines d'accès concurrent.
[^] # Re: Questions
Posté par claudex . Évalué à 6.
Tu joue sur les mots. Je parle bien sûr du point de vue de l'application qui envoie le insert.
Après, c'est une gestion de la file d'attente. Tu poses un verrous, écris et enlèves le verrous.
Génial, et quand l'instance qui a le verrou a planté tu attends indéfiniment qu'elle le libère?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Questions
Posté par Joël Thieffry (site web personnel) . Évalué à 6.
A contrario, un SGBD non embarqué (MySQL, PostgreSQL, Oracle, ...), donc en mode serveur, communique avec le client par des sockets (connexion réseau par exemple). Les demandes d'écritures peuvent être faites en parallèle, c'est au SGBD de gérer l'accès à ses fichiers suivant les verrous et les transactions. Mais au final, le serveur garde ses fichiers verrouillés en permanence, et y écrit ses données en séquence pour des raisons de performance (faire le zigzag avec les têtes de disque-dur réduit les perfs).
Quand un processus plante, le système d'exploitation libère sa mémoire, tous ses descripteurs de fichiers, tous ses verrous, etc. Je crois qu'il n'y a que les IPC qui ne sont pas libérées. En conséquence, que ce soit ton instance SQLite ou ton serveur MySQL qui plante, les verrous sur ses fichiers seront relâchés. Dans certains cas, sous certains systèmes d'exploitation, les processus plantés peuvent résider en mémoire et garder leurs verrous : c'est le système d'exploitation qui ne fait pas correctement son boulot.
[^] # Re: Questions
Posté par claudex . Évalué à 3.
Ça c'est quand ça plante et ça crash, mais moi je compte les deadlocks comme des plantages et là les ressources ne seront pas libérées.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Questions
Posté par Joël Thieffry (site web personnel) . Évalué à 1.
Si ça deadlock, les concepteurs ont raté le problème ; il faut dire que ce n'est pas évident à développer du multithread sans erreur. Dans ce cas, il est toujours possible de tuer le processus pour tout libérer.
Il est aussi possible d'écrire dans un fichier sans utiliser de verrou : je crois me rappeler que c'est le dernier processus à fermer le descripteur de fichier en écriture qui aura son contenu écrit dans le fichier (corrigez si j'ai tort). Pas vraiment utilisable pour les bases de données.
[^] # Re: Questions
Posté par claudex . Évalué à 3.
Il est évident qu'il faut tenir compte des deadlock dans une application telle que Firefox, même s'il faut tout faire pour les éviter, ils ne sont pas totalement inévitable.
Dans ce cas, il est toujours possible de tuer le processus pour tout libérer.
Et à partir de quand une instance peut décider de tuer une autre parce qu'elle mettrait trop de temps à libérer son verrou?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Questions
Posté par barmic . Évalué à 4.
Après c'est sur que sur le système de fichier c'est pas concurent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Questions
Posté par houra . Évalué à 4.
Il y a une raison à rester connecté à une base de données en permanence ?
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Questions
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
[^] # Re: Questions
Posté par houra . Évalué à 1.
nan, je cherchais un argument du genre " mot de passe utilisateur ", mais même là, il y a moyen d'être déco en permanence , non ?
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Questions
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Questions
Posté par houra . Évalué à 1.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Questions
Posté par barmic . Évalué à 5.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Questions
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: Questions
Posté par Thomas Douillard . Évalué à 10.
[^] # Re: Questions
Posté par wismerhill . Évalué à 0.
Lancé "ls 1" dans le premier, "ls 2" dans le second, véfrifié que chacun n'avait que son historique récent propre, puis fermé le premier et puis le second.
Je réouvre ou nouveau bash et en passant l'historique j'ai d'abord "ls 2" puis "ls 1" puis ma commande plus ancienne.
Donc bash gère très bien les sessions multiples, j'imagine (sans avoir vérifié dans le code) qu'il retient simplement quelles sont les commandes qui ont été ajoutée dans la session courante (par opposition à celles chargées depuis le fichier d'historique) et ne rajoute que celles-là à la fin de l'historique.
[^] # Re: Questions
Posté par claudex . Évalué à 4.
Si tu ouvre le premier, tu fais ls1, puis le second tu fais ls2, puis dans le premier tu fais ls3. Tu ferme le premier puis le second, l'historique des commandes sera ls2 puis ls3 puis ls1. Ce n'est pas vraiment pratique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Questions
Posté par Dies Irae (site web personnel) . Évalué à 10.
Ajoutez dans votre .bashrc:
shopt -s histappend
PROMPT_COMMAND='history -a'
[^] # Re: Questions
Posté par barmic . Évalué à 9.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Questions
Posté par Christophe Bliard . Évalué à 2.
[^] # Re: Questions
Posté par koxinga . Évalué à 4.
Les options utiles sont APPEND_HISTORY, INC_APPEND_HISTORY et SHARE_HISTORY (http://zsh.sourceforge.net/Guide/zshguide02.html#l18 )
[^] # Re: Questions
Posté par Christophe Bliard . Évalué à 2.
Faudrait que je lise ce Zsh Guide, même si c'est déjà un beau morceau...
[^] # Re: Questions
Posté par Sébastien Wilmet . Évalué à 8.
À part le mot « global », il n'y a pas grand chose en rapport.
Ce qui se passe avec GtkApplication (et qui se passait avec libunique qui est maintenant obsolète), c'est qu'une nouvelle instance tente de communiquer via DBus avec la première instance. Et si la première instance existe, la nouvelle instance envoie généralement juste quelques commandes, et puis termine.
> Personnellement, j'en ai marre de ces applications qui refusent le multi-instance et les notions simples d'UNIX.
Moi j'aime bien quand le fichier que j'ouvre grâce à nautilus par exemple s'ouvre dans une fenêtre existante de l'application, si cette fenêtre se trouve sur le même espace de travail.
Si ce n'était pas le cas il faudrait ouvrir tous les fichiers via l'application elle-même, ce qui peut être contraignant.
De toute façon si on veut absolument que le fichier s'ouvre dans une nouvelle fenêtre, généralement il y a des options comme --new-window.
Autre exemple : avec Gedit il y a moyen de glisser/déposer des onglets d'une fenêtre à l'autre. Si c'était des instances différentes, il faudrait recharger le fichier dans la nouvelle fenêtre, et donc le fichier devrait préalablement être enregistré avant d'être déplacé, ce qui est plutôt embêtant pour un nouveau document.
Il y a sûrement plein d'autres choses utiles, tout dépend du type d'application.
Ceux qui croient que c'est utilisé seulement pour synchroniser les préférences et autres paramètres, c'est complètement faux puisque GSettings (successeur de GConf) se charge déjà de tout ça.
[^] # Re: Questions
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Je ne vois pas ou est le problème d'avoir n instance de la même application et qu'éventuellement, le gestionnaire de fenêtre les raccrochent toutes ensemble s'il le faut via les propriétés XWindow.
Bref, plutôt que de séparer les processus et rester dans la philosophie simple d'UNIX, on programme des usines à gaz qui intègre en interne une gestion de fenêtre (onglet) avec un beau mélange de paramètre de configuration et de variables d'état...
Je pense honnêtement qu'il faudrait redonner à UNIX et aux éléments de base leur fonction première et arrêter de suivre bêtement certain OS.
[^] # Re: Questions
Posté par Sébastien Wilmet . Évalué à 3.
Si à la place de chaque onglet de chaque application c'est une instance séparée qui est créée, tu peux acheter quelques barrettes de RAM je pense…
> avec un beau mélange de paramètre de configuration et de variables d'état...
Justement avec GtkApplication tout ça est géré de manière simple.
[^] # Re: Questions
Posté par M . Évalué à 4.
Pas forcement : l'application ne gére plus les onglet. Elle est plus légère. Et comme l'OS est malin il partage la plupart des données des 2 instances avec le COW.
[^] # Re: Questions
Posté par Sébastien Wilmet . Évalué à 1.
[^] # Re: Questions
Posté par Kangs . Évalué à 3.
Mais je ne suis pas certains que dans le contexte ce soit faisable.
[^] # Re: Questions
Posté par Sébastien Wilmet . Évalué à 3.
Oui il faut que le processus fasse une copie de lui même (un fork), ce qui n'arrange pas vraiment le problème dans ce cas-ci.
[^] # Re: Questions
Posté par nicolas . Évalué à 4.
[^] # Re: Questions
Posté par nud . Évalué à 1.
Ben le problème, aussi, c'est que de nos jours, le "code" quand on parle de programmes écrits en python, ruby, mono ou autre jit quelconque, ça n'inclut guère que le code de l'interpréteur et les bibliothèques C. Tes modules python seront chargés une fois en RAM pour chaque application.
En plus la dynamicité des langages modernes n'arrange rien de ce niveau. Vu qu'il n'y a (quasiment) rien qui soit read-only, il n'y a rien qui soit partageable entre plusieurs instances.
[^] # Re: Questions
Posté par barmic . Évalué à 3.
Sinon comme navigateur qui semble fait pour te convenir il y a uzbl [www.uzbl.org].
Un autre programme qui peut t'interesser c'est urxvt qui possède un mode client/serveur.
Pour les gestionnaires de fenêtres, dwm, wmii, awesome, xmonade,... devraient te plaire, je pense.
Pour ce qui est des distributions mis à part stali, il y a archlinux et slackware (peut être aussi gentoo) qui me semble le plus suivre une philosophie épurée.
Bref tout ça pour dire que si tu veux continuer dans ta vois, il y a pas mal de choix qui te permettrait d'avoir un système comme tu le souhaite.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Questions
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Réponse tardive... j'étais à 200% dans autre chose ces derniers temps.
Ce que tu proposes est exactement ce que je fais. Je suis sous WMII avec urxvt...
Comme éditeur, en plus de vi, j'utilise nedit car léger, souple et très rapide mais il ne supporte pas l'UTF8. Dommage car il gère les sélections carrées comme j'ai pas vu d'autres programmes le faire.
J'ai essayé d'autres éditeurs graphiques, par exemple gedit ou geany, ils sont absolument insupportable ! Même sous gnome, "geany nom_fichier" t'ouvre la fenêtre sous le bureau ou geany est déjà ouvert... nedit était vraiment rapide, on pouvait en ouvrir 30 sans problème et il a même un mode serveur si on en as besoin mais qui n'est pas le mode par défaut. C'est bien plus intelligent comme fonctionnement (un peu comme vi d'ailleurs)
[^] # Re: Questions
Posté par Michaël (site web personnel) . Évalué à 0.
Et moi 600% comme tu le vois :)
Emacs gère aussi les sélections carrées (désolé, je n'ai pas pu résister!).
[^] # Re: Questions
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Dans nedit, la sélection carrée est naturelle ainsi que le déplacement de celle-ci.
Par exemple, dans geany, la sélection carrée est possible mais j'ai pas réussi à la bouger...
[^] # Re: Questions
Posté par Michaël (site web personnel) . Évalué à 1.
Je reconnais sans peine que les manipulations de sélections carrées dans Emacs ne sont pas forcément très pratiques: on peut couper et coller, en gros. Par curiosité, il y a plus de fonctions dans `nedit'? En me demandant à quoi servent les sélections carrées, je pense spontanément à l'édition de tableaux présentés dans des colonnes de largeur constante, est-ce qu'il y a autre chose?
[^] # Re: Questions
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Bref, c'est pratique et donc j'utilise. Dans les autres éditeurs, c'est pénible donc on n'utilise pas ;-)
[^] # Re: Questions
Posté par Michaël (site web personnel) . Évalué à 2.
Merci pour tes précisions!
[^] # Re: Questions
Posté par BFG . Évalué à 6.
[^] # Re: Questions
Posté par Sébastien Wilmet . Évalué à 1.
[^] # Re: Questions
Posté par BFG . Évalué à 2.
"Ceux qui croient que c'est utilisé seulement pour synchroniser les préférences et autres paramètres, c'est complètement faux puisque GSettings (successeur de GConf) se charge déjà de tout ça. "
Puis :
"Si les marque-pages sont stockés avec GSettings, oui. Mais GSettings n'est pas vraiment approprié pour stocker ce genre de choses, d'où l'utilité d'une instance unique. "
Cela me semble contradictoire.
[^] # Re: Questions
Posté par Sébastien Wilmet . Évalué à 2.
Les marques-pages sont des données, tandis que GSettings est prévu pour la première catégorie.
La même distinction est faite entre ~/.config/ et ~/.local/share/.
Donc pour une application gnome qui utilise des données et/ou certaines config un peu trop complexes à stocker dans gsettings (fichiers xml p.ex.), une instance unique est l'idéal pour ne pas avoir de problèmes de synchronisation.
[^] # Re: Questions
Posté par nud . Évalué à 1.
Ben en fait, dans le cas de chromium (et j'imagine que firefox va faire pareil), tu as un processus qui gère toutes les fenêtres et tous les onglets, puis un processus "enfant" pour gérer le contenu de chaque onglet séparément.
Donc j'imagine qu'avec Gtk+ tu pourrais faire pareil, et qu'on pourrait avoir, imaginons, une instance "parent" de gedit pour gérer toutes les fenêtres, puis un processus par document ouvert (pas sûr que ce soit pertinent cependant)
# Interrupteur
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 10.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Interrupteur
Posté par 태 (site web personnel) . Évalué à 9.
Sur une interface tactile, faire glisser un bouton est sans doute plus robuste que de juste cliquer. Si ce n'est utilisé que dans les interfaces mobiles, pourquoi pas.
[^] # Re: Interrupteur
Posté par Antoine . Évalué à 10.
Et comment on fait pour internationaliser le bouton ? Si tu mets "Marche" et "Arrêt" à la place (ce qui n'est pas forcément une bonne traduction, mais passons), ça explose le widget en largeur.
Non, franchement, c'est nul. Encore une fausse bonne idée des bozos de l'interface graphique.
[^] # Re: Interrupteur
Posté par monde_de_merde . Évalué à 1.
Et au pire il reste les symboles rond et baton...
Le vrai problème c'est "si je vois On/Marche/Baton/whatever c'est que l'interrupteur est sur On ou que si je le touche il va basculer sur On" ? C'est un widget qu'il faut associer avec mettons un texte en une teinte pale quand la fonction est à Off et en une teinte "lumineuse" ou colorée quand elle est à On.
[^] # Re: Interrupteur
Posté par Antoine . Évalué à 8.
À ce compte là, "yes" et "no" aussi, et puis tiens pourquoi pas "Open"... oh, et puis zut, faisons-y passer toute la barre de menu, z'ont qu'à apprendre l'anglais ces sagouins.
Et au pire il reste les symboles rond et baton...
Dans le genre non-intuitif, c'est pas mal, les ronds et les bâtons. Comme bouton unique sur un appareil électronique, ça ne pose pas trop problème, parce qu'on voit tout de suite si l'appareil est actuellement éteint ou allumé. Mais utilisé de façon banalisée dans une GUI, aille.
[^] # Re: Interrupteur
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: Interrupteur
Posté par CrEv (site web personnel) . Évalué à 3.
on et off c'est plutôt des états logiques, que ce soit un bouton poussoir, un bouton que tu tournes ou n'importe quoi d'autre
[^] # Re: Interrupteur
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Interrupteur
Posté par Gniarf . Évalué à 6.
et « off », c'est un phoque.
[^] # Re: Interrupteur
Posté par pasScott pasForstall . Évalué à 1.
Perso, je suis loin d'etre un fan de ce widget a la con, c'est effectivement pas clair du tout comment l'activer ni de savoir dans quel etat il est.
En fait ca marche bien sur ios parceque les gens ont prit l'habitude et qu'on le retrouve un peu partout dans les applis ios. Disons que ca tombe en marche, difficilement.
Et aussi parce que ca rend mieux visuellement qu'une checkbox (dans l'environment ios en tout cas).
A la decharge d'apple, le widget change de couleur, bleu pour on, gris pour off, une fois que t'as compris ca, ca roule. Et ca rappelle certains interrupteurs physiques du meme style.
Appliquer ca au desktop, je trouve ca assez idiot comme idee par contre.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Interrupteur
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Nouveau widget "interrupteur" [...] alors qu'une case à cocher ben tout le monde connaît, c'est clair à première vue dans quel état elle est, bref... mais pourquoi ce truc ?
Ernest H
Sur une interface tactile, faire glisser un bouton est sans doute plus robuste que de juste cliquer. Si ce n'est utilisé que dans les interfaces mobiles, pourquoi pas.
En fait c'est là l'erreur, ce devrait être un thème, pas un widget de plus.
L'objet logique à deux états "vrai/faux", "on/off", "actif/inactif", "oui/non" existe déjà sous forme de case à cocher, ce widget est un doublon !
Faire apparaitre le widget "deux états" sous forme d'une case à cocher ou d'un interrupteur, c'est un problème de thème. Le fait qu'il réagisse à un clic ou à un geste, c'est aussi une question de thème.
Enfin, le mot thème ne convient plus, ce n'est plus l'apparence visuelle, mais l'idée est la même. Tout comme sous KDE on choisissait avant entre "look windows/mac/unix" avec des raccourcis claviers qui changeaient il me semble en plus de l'apparence, on pourrait choisir entre "environnement PC classique" ou "Gadget avec écran ridicule et pas de clavier ni de souris"
On peut imaginer un objet unique "choix binaire", avec un thème "ordinateur classique" qui affiche une "case à cocher" et qui réagit à l'évènement "clic", ou un thème "gadget" qui affiche un "interrupteur" et qui réagit à l'évènement "glisser".
C'est vrai que le doigt est plus gros qu'un pointeur de souris, et qu'à cliquer sur une case, tu ne sais pas quel est l'état en dessous de ton gros doigt.
De plus, avec des gestes, tu peux faire des évènements plus précis, l'un pour activer quoi qu'il arrive (monter par exemple), et l'autre pour désactiver, ce qui serait horripilant à la souris, on a déjà trois boutons et le double clic, faut pas en rajouter ! Mais ce n'est qu'une question de thème...
D'ailleurs ce serait une très bonne piste, de " thémer " les interactions : qu'avec une souris je puisse faire un double-clic pour ouvrir un fichier, mais quand je replie le pc en mode tablette, je puisse faire un simple toucher, et pas en changeant les options du pointeur, mais en changeant de thème (avec l'orientation de l'écran qui pourrait changer, des barre d'outils avec de plus grosses icônes, etc.) ...
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Interrupteur
Posté par dinomasque . Évalué à 4.
Les deux ont leur usage propre, pourquoi vouloir n'en garder qu'un seul ?
BeOS le faisait il y a 20 ans !
[^] # Re: Interrupteur
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Si par exemple dans un circuit électrique non alimenté je met sur "on" l'interrupteur en face de ma lampe, elle ne s'allume pas.
Lorsque je vais mettre le courant, la lampe va s'allumer.
Si j'ai un écran à diode, avec autant d'interrupteurs que de diodes, je peux préparer un joli dessin lumineux qui ne s'affichera que lorsque je mettrais le courant. C'est exactement la même chose que de cocher des cases et d'appuyer sur "valider".
De même, je pourrais faire ma manipulation alors que le courant est là, et alors au fur et à mesure de mes actions sur les interrupteurs, mes lampes vont s'allumer.
L'interrupteur n'implique une réaction immédiate que parce que la logique de mon système est conçu ainsi. Je ne peux avoir un interrupteur qui implique une réaction immédiate que parce que j'ai conçu mon système ainsi.
Un pilote d'avion avant d'allumer son moteur il doit appuyer sur plein de boutons et actionner un certain nombre d'interrupteurs. Par contre, il a des boutons et divers actionneurs qu'il actionnera ou devra actionner en cours de route.
Ce qui fait que l'interrupteur implique une action immédiate ou non, c'est une question de conception du système, pas d'interrupteur.
Dans la vraie vie il n'y a pas de case à cocher, il n'y a que des interrupteurs.
Dans la vraie vie, un actionneur à deux états c'est un interrupteur.
Une case à cocher dans une IHM c'est un interrupteur. Pourquoi avoir fait visuellement des cases à cocher plutôt que des interrupteurs ? c'est une autre question, mais une case à cocher ou un interrupteur c'est la même chose : c'est une machine logique à deux états vrai/faux, oui/non, tout de suite/plus tard, toujours/jamais...
Le fait que l'action sur l'interrupteur soit prise en compte à l'exécution ou seulement après un autre évènement, c'est la conception du système qui détermine cela, pas le bouton.
Que je coche la case "couper le son" et que cela se fasse tout de suite parce qu'il faut que je réponde au téléphone, ou bien que je coche la case "éteindre l'ordinateur à la fin de la gravure" et que cela soit pris en compte effectivement à la fin de la gravure, parce que je vais me coucher, c'est l'application qui veut ça, pas le widget.
En électricité, je peux mettre mes interrupteurs en parallèle (action immédiate pour chacun) ou en série (action dans un futur lointain pour le second), par exemple. Je n'ai pas deux types d'interrupteurs pour ces deux montages.
Je dénonçais le fait que le widget "interrupteur" n'était en fait qu'un doublon pour coder en dur une apparence différente, et bien je dénonce (grave :) le fait que le widget "interrupteur" ne soit en fait qu'un doublon pour coder en dur une gestion des évènements différentes et un schéma logique différent.
De plus, dans Gnome, la philosophie c'est d'avoir des actions actives et propagées dès l'action, de ne pas avoir un bouton "valider les préférences" mais "fermer les préférences", le doublon case/interrupteur est d'autant plus idiot pour Gnome qui veut simplifier l'IHM. Au final, même si l'effet est dans un avenir lointain, la configuration est prise en compte tout de suite.
Dans Gnome il y a des cases à cocher "ne pas demander de mot de passe à la sortie de veille", ou bien "mettre en veille à l'inactivité" ou bien "couper le son", etc. Les effets sont immédiats ou dans un avenir lointain, ou soumis à d'autres évènements ou non, ce sont dans tout les cas des cases à cocher, on peut toutes les remplacer par des interrupteurs, c'est la même chose.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Interrupteur
Posté par Philippe F (site web personnel) . Évalué à 3.
Plus sérieusement, présenter une interface graphique n'est pas un exercice mathématique de réduction au plus petit dénominateur commun mais plutôt un effort pour présenter des informations de façon compréhensible. Et il y a des cas, ne t'en déplaises, où un interrupteur ON/OFF sera plus clair qu'une checkbox.
[^] # Re: Interrupteur
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Si je veux représenter une table de mixage virtuelle, par exemple, je peux vouloir représenter mes différents potards alignés sur une même tranche, et je n'aurai jamais la place de mettre des glissières sur chacun. Comme dans la réalité je mettrais des boutons qui se tournent, plus compacts. Par contre, sur cette même interface en forme de table de mixage, représenter un bouton on/off par une case à cocher ou un dessin de bouton qui s'appuie, ou un dessin de bouton haut/bas, mais alors là, peu-importe ! Même la question de la forme du widget ne tient pas ! Le problème est le même pour le retour d'information : qu'une diode soit allumée, la face "on" du bouton affichée, ou la case cochée, ça signifie la même chose.
Ce qui serait vraiment intéressant, c'est que sur un ordi je puisse cocher des cases avec ma souris, et que le même logiciel, sur une tablette tactile, je puisse actionner le bouton avec un geste. C'est une question de thème.
Là il est bien question de coder en dur le thème dans la librairie de base, même pas dans un logiciel qui prendrait ses libertés (comme un logiciel de musique, pour garder le même exemple), mais bien dans la librairie de base : dupliquer les objets, les fonctions et tout, pour une histoire de thème.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Interrupteur
Posté par téthis . Évalué à 5.
Donc, si je comprends bien, c'est un doublon du bouton à bascule (ou 2 états) : http://library.gnome.org/devel/gtk/stable/GtkToggleButton.ht(...)
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Interrupteur
Posté par dinomasque . Évalué à 3.
Jouer avec des écrans à diode c'est pas IRL, c'est un truc de nolife.
BeOS le faisait il y a 20 ans !
[^] # Re: Interrupteur
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Je vais garder ton exemple IRL de lumière. Je viens tout juste d'emménager, l'appart est neuf. J'actionne l'interrupteur de la lampe et il n'y a pas de lumière.
Je vais au compteur, je met le courant, j'ai pas eu à revenir à l'interrupteur de la lumière.
l'interrupteur dans la vraie vie ou la case à cocher dans un logiciel sont la même chose : l'état est conservé au moment de l'action. L'effet, lui peut être tout de suite ou subordonné à un évènement (bouton "valider", alimenter le circuit électrique, ouvrir le robinet, démarrer le moteur, qu'il fasse jour, dépasser une certaine température...).
Dans la vraie vie, tu remodèles pas tes boutons avec une imprimante 3D, dans un logiciel, le bouton on/off tu peux l'afficher soit comme une case à cocher, un bouton qui s'enfonce, une bascule... et appliquer les thèmes non pas en fonction de la quincaillerie qui t'a vendu le bouton, mais ton humeur ou la taille de ton écran. C'est très pratique d'unifier tout cela pour pouvoir adapter tout d'un coup.
Mon emménagement, je t'assure c'était pas un truc de nolife.
J'ai parlé d'écrans à led pour donner un exemple où on voudrait répéter l'évènement "allumer la lumière", avant de le faire vraiment (je coche, je coche, je coche, je valide). tu peux faire ça avec les guirlandes électrique de ton sapin de noël, c'est pas nolife non-plus ça de brancher sur un même sucre plusieurs guirlandes.
Pour transposer ton exemple de lampe qui s'allume pas, je garde l'exemple de l'appart : J'ai allumé le frigo, j'ai mit le courant au compteur, le frigo s'est pas allumé et j'ai gueulé. J'ai branché le frigo dans la chambre et il a fonctionné, et j'ai encore gueulé :la prise de la cuisine pour le frigo ne semble relié à aucun circuit électrique. Et là, je m'en moque que la prise soit blanche ou jaune. Si la prise était une prise carrée au lieu d'une prise ronde, ça ne résoudrait pas mon problème. Ce n'est pas en changeant la couleur de la prise que ça va résoudre mon problème, et c'est pas parce qu'elle est blanche que je m'attend à ce que le courant y parvienne.
C'est pas nolife de faire fonctionner son frigo. Que je prenne l'exemple de l'écran à led ou du frigo, qu'est ce que ça te fais.
J'ai illustré ma pensée avec l'exemple de l'écran à LED, je peux l'illustrer avec des lampes d'habitations si ça te plait, ma pensée ne change pas. Si c'est l'illustration qui ne te plait pas, change là : c'est comme un thème ;).
L'interrupteur qui contrôle l'alimentation d'une LED ou d'une lampe de chevet, c'est la même logique, je suis désolé, je peux rien y faire.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Interrupteur
Posté par BFG . Évalué à 2.
[^] # Re: Interrupteur
Posté par teoB . Évalué à 4.
Tu n'as jamais rempli de QCM ou formulaire administratif ;)
Je pense que les cases à cocher représentent plutôt un choix d'option (avec les boutons radio, à la différence que ceux-ci excluent plusieurs choix simultanés) comme sur un formulaire papier, et que les boutons représentent une action comme avec un interrupteur. L'avantage de la case à cocher informatique, est que l'on peut généralement revenir sur son choix, alors que sur le formulaire papier, la case, une fois cochée, l'est souvent définitivement.
Après c'est sûr que bouton ou case à cocher c'est toujours un objet à 2 états.
[^] # Re: Interrupteur
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Cependant dans la vrai vie la feuille n'a pas de logique et ne va pas interpréter la case à cocher, elle n'est qu'un support. Le capteur optique (ou le stagiaire) qui va analyser la paperasse il va considérer l'état de la case comme un objet à deux états.
En effet il y a différence sémantique dans le sens que la case à cocher peut être vue comme une option sur un contenu (l'exemple du formulaire) et le bouton comme une option sur une action. Mais au final dans un logiciel, poser une option sur le contenu c'est poser une option sur une action.
Dans le formulaire d'enregistrement d'OOo, cocher la case "Je suis déjà enregistré" équivaut à appuyer sur un bouton "ne m'embête pas plus longtemps ou je passe à LibreOffice".
Comme l'a relevé téthis [http://library.gnome.org/devel/gtk/stable/GtkToggleButton.ht(...)], il y a déjà un bouton bascule en plus de la case à cocher. L'avantage du bouton bascule (qui s'enfonce) est surtout de pouvoir comporter le libellé, en texte ou en image.
On voit que dans les fait, s'il y a un bouton bascule et une case à cocher, c'est déjà pour une affaire d'interface : par exemple dans un logiciel de montage audio avancé, en général le bouton "record" ne lance pas l'enregistrement, mais bascule entre le mode lecture et enregistrement. C'est super pratique parce que si on utilise un logiciel qui génère du son et un autre qui enregistre, et qu'on a un logiciel pour les contrôler en même temps, il suffit de mettre l'un en mode "enregistrement", l'un en mode "lecture" et d'appuyer sur une unique commande "play" pour que les deux démarrent en même temps, l'un en lecture, l'autre en enregistrement.
Ce genre de bascule peut être faite avec une case à cocher, en général c'est fait avec le bouton bascule parce que ça permet d'afficher un joli bouton rouge et rond qui s'allume quand on appuie dessus. On pourrait aussi afficher un bouton en forme de tige qu'on bascule, ou comme une glissière à deux états (comme dans l'iPhone), mais là on fait du thème...
Avoir des logiciels qui présentent leurs choix binaires selon trois manières différentes, case à cocher, bascule qui s'enfonce et bascule qui se déplace, c'est pas tellement dans l'esprit Gnome d'unifier les interfaces et d'offrir une ergonomie simple.
Enfin, ce n'est pas la seule chose dans gtk ou gnome qui n'est pas unifiée et qui diverge d'une appli à l'autre (par exemple les onglets, mais la raison est peut-être que ce n'est pas à l'appli de gérer le fenêtrage ;) ).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Interrupteur
Posté par teoB . Évalué à 2.
C'est juste que personnellement, je trouve que la case à cocher ne représente pas vraiment un bouton. C'est sûr que techniquement c'est la même chose, d'ailleurs on voit bien que la hiérarchie dans gtk est : GtkButton -> GtkToggleButton -> GtkCheckButton -> GtkRadioButton (et si je me souviens bien, dans GTK+ 1.2, les cases à cocher ressemblaient à des petits boutons miniatures et non à des coches que l'on peut faire sur un formulaire papier). Et donc dans plein de cas simples on peut indifféremment choisir un bouton ou une case à cocher, et d'ailleurs on constate que dans certains cas, pour une même chose, deux logiciels différents feront un choix différent.
Je pense qu'un bouton doit être une action avec une description simple ou juste une petite image qui peut tenir dans le bouton (comme ton exemple de table de mixage) qui permet d'appuyer rapidement sans avoir à trop réfléchir. Alors que pour la case à cocher, le but est d'avoir la description à l'extérieur, ça permet d'avoir une taille fixe même si l'on a à côté 5 lignes de description sur son utilité. Et généralement on lit et on réfléchit un peu avant de cocher ou décocher (comme lorsque qu'on remplit un formulaire). De plus, une case à cocher est plutôt petite et demande une certain précision pour changer son état afin de minimiser le risque d'appui accidentel ; alors que pour un bouton, il vaut mieux avoir une taille suffisante pour pouvoir cliquer dessus facilement.
Typiquement, les cases à cocher sont employées dans Préférences. On définit souvent définitivement la configuration du logiciel ou en tout cas, on passe rarement notre temps à la changer. Par contre, par exemple, la case à cocher « Aperçu » que l'on peut avoir dans Gimp, est pour moi un mauvais exemple d'utilisation, et devrait être un ToggleButton, car pour voir l'effet d'une modification, on peut souvent être amené à basculer d'un état à l'autre.
Voila pourquoi pour moi ce n'est pas une erreur d'unification d'avoir une différence case à cocher/bascule. Après enfoncer/glisser est un autre débat.
[^] # Re: Interrupteur
Posté par ElectronLibre63 . Évalué à 3.
Moi ce qui m'énerve, c'est l'utilisation d'une case pour Muet, lorsque je veux cliquer rapidement, je clique souvent à côté et je préférerais un bouton.
Je suis donc d'accord avec toi pour dire que la case à cocher ne devrait pas être utilisée comme bouton. Par contre la forme du bouton ne devrait pas être une histoire de thème.
J'ai regardé un peu les appareils qui m'entourent, et en fait globalement, il y a une différence entre un bouton qu'on enfonce (et qui reste enfoncé) et un bouton que l'on fait glisser. Le bouton qu'on enfonce sert généralement à activer/désactiver quelque chose (marche/arrêt, filtre actif/inactif, mute…). Alors que le bouton que l'on fait glisser (ou le bouton rotatif) sert à faire varier un comportement actif (AM/FM, souris gaucher/droitier, synchro sur la voie 1/ voie 2, émission sur canal A/canal B…). On peut donc très bien avoir une interface avec des boutons d'apparences différentes. D'ailleurs l'exemple du tableau de bord d'avion avait été évoqué, et c'est un exemple extrême de mélange de formes de boutons. La forme du bouton dépend plus de l'usage que de l'esthétique.
Donc pour résumer :
- la case à cocher pour remplir les formulaires (cas un peu particulier dans la vrai vie) ;
- le boutons qui s'enfonce pour activer/désactiver quelque chose ;
- le bouton à glissière pour modifier une action.
Se sont dans la vie des concepts plus ou moins différents qui ne doivent donc pas être unifiées graphiquement, mais qui informatiquement se ramènent à un choix binaire. Ces fonctions sont tellement proches (d'ailleurs comme tu le dis, ils sont dans gtk hiérarchiquement liés) qu'on peut dans certains cas utiliser indifféremment l'une de ces possibilités. Le problème n'est donc pas qu'on puisse retrouver ces différentes possibilités dans une IHM, mais plutôt que certains développeurs en perdent le sens premier et les utilisent n'importe comment.
[^] # Re: Interrupteur
Posté par nicolas . Évalué à 3.
Mais faut dire que ce sont de vrais interrupteurs… pas des trucs qui éteignent juste la led au-dessus ou l’écran d’affichage parce qu’il faut soutenir EDF. \o/
[^] # Re: Interrupteur
Posté par pititjo . Évalué à 3.
[^] # Re: Interrupteur
Posté par BFG . Évalué à 8.
[^] # Re: Interrupteur
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 10.
Un bouton gris avec marqué "OFF" dessus ça veut dire quoi ? Que si j'appuie dessus ça désactive la fonctionnalité ? Ah ben nan c'est le contraire, l'intitulé du bouton indique son état, ce qui est le contraire de ce que font tous les boutons dans les interfaces graphiques depuis des années : indiquer l'action effectuée en cliquant sur le bouton.
Un bouton marqué "Valider" ça veux dire qu'en cliquant dessus, ça valide ce qu'on a fait, pas que ça a déjà été validé, c'est juste la base quoi...
Quand à l'aspect tactile moi j'ai du m'y reprendre à plusieurs fois pour comprendre qu'il ne fallait pas juste cliquer dessus (aucune action) mais faire glisser le slider en gardant le doigt sur l'écran, c'est pas intuitif du tout, bref ça fait joli (et encore ça se discute) mais c'est un non sens. Sans compter que ça prends 3 fois plus de place à l'écran qu'une case à cocher sans en remplir le minimum de fonctionnalité : comprendre ce que ça fait dès le premier coup d'œil.
J'espère que ça va pas trop se répandre ce truc, déjà que Free ils ont trouvé ça trop cool de le mettre dans leur interface web... berk.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Interrupteur
Posté par Grunt . Évalué à 10.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Interrupteur
Posté par BFG . Évalué à 7.
Le mettre dans les composants Gtk standard est comme un encouragement à l'utiliser.
[^] # Re: Interrupteur
Posté par pasScott pasForstall . Évalué à 0.
Un bouton ne change pas d'action en cours de route (ou en tout cas pas a chaque click, et pas pour faire l'inverse de ce qu'il faisait avant).
Ton bouton valider, quand tu cliques dessus, il se transforme pas en devalider, puis valider etc.
Il valide, c'est tout.
Ce widget correspond a un glissiere physique, souvent utilisee pour verouiller un lecteur mp3 ou ce genre de trucs.
Ce qui ne correspond pas non plus a l'utilisation qu'ils en font, mais ce widget n'est pas un non sens - juste dur a lire.
Ils auraient pu remplacer par un bouton pressoire, mais ca aurais pas ete plus facile a lire - dans la vraie vie, le pressoire marche parce qu'ils sont profond et qu'on percoit tres bien la 3d, note qu'ils faut toujours avoir vu le bouton dans les deux etats (ou au moins off) ou appuyer dessus pour comprendre que c'est un pressoir.
Le probleme est pas simple, et si tu rajoutes les contraintes de place d'un iphone, ca devient un gros bordel a gerer.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
# CSS
Posté par grid . Évalué à 7.
Quelles sont les chances que cela soit compatible avec Qt qui gère ça depuis un moment ? cf. http://doc.trolltech.com/4.2/stylesheet.html
Si quelqu'un a la réponse...
[^] # Re: CSS
Posté par rewind (Mastodon) . Évalué à 10.
[^] # Re: CSS
Posté par Maclag . Évalué à 1.
Si tout se passe bien dans l'écosystème du Libre, KDE s'inspire des bonnes idées de Gnome et vice-versa.
Si KDE propose un truc en premier et que ce truc fonctionne bien, il me paraît logique que Gnome veuille s'en inspirer, et l'avantage de le faire après, c'est qu'on sait également ce qui est perfectible.
Si l'approche de KDE est déjà sans défaut, pourquoi ne pas déjà pousser dans Freedesktop? (ne serait-ce que pour susciter l'intérêt des autres acteurs et lancer le débat...)
[^] # Re: CSS
Posté par Littleboy . Évalué à 7.
Encore un qui est reste dans le monde des bisounours.
La realite, c'est que celui c'est celui qui a le plus de fric qui decide. En l'occurence, il y a un gros paquet de devs gnome payes par Redhat, ce qui leur permet de decider dans les grandes lignes de l'avenir de la plateforme.
Si l'approche de KDE est déjà sans défaut, pourquoi ne pas déjà pousser dans Freedesktop?
Parce que les mainteneurs bossent sur Gnome, que leur employeur est beaucoup plus interesse par des technos qu'ils peuvent controller a 100% et ont donc tendance a "refuser" les trucs dont ils ne veulent pas, genre en demandant quelques petites modifs, et puis encore, et encore et encore, jusqu'a ce que les mecs jettent l'eponge devant tant de mauvaise foi (demande donc a certains devs canonical ce qu'ils en pensent).
Au final ca n'empeche en rien les devs KDE de developper leur propre techno et d'essayer de la faire accepter dans freedesktop (bonne chance), mais entre les mecs qui font ca sur leur temps libre et ceux qui sont payes pour bosser dessus, c'est tres vite vu.
[^] # Re: CSS
Posté par gpe . Évalué à 6.
J'ai du mal à croire que Nokia ait moins de moyens que Redhat ...
[^] # Re: CSS
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: CSS
Posté par O'neam Anne . Évalué à -4.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: CSS
Posté par nud . Évalué à 0.
Moui bon en pratique, quand on réfléchit deux minutes, on se rend compte de plusieurs choses, notamment:
# gtk+ 3.0
Posté par Skami_18 . Évalué à -3.
# Développement itératif
Posté par Sébastien Wilmet . Évalué à 3.
Ce que tu voulais dire par là, je suppose, c'est que si on a fait la migration vers chaque nouvelle version de GTK+ 2.x, en remplaçant chaque fonctionnalité devenue au fur et à mesure obsolète par les nouvelles façons de faire, la migration de la dernière version de GTK+ 2.x vers 3.0 est facilitée. C'est bien ça ?
Voilà, si ce que je dis est correct, ça clarifie un peu cette phrase.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# Y'a que moi que ca choque ca ?
Posté par Dams Nadé (site web personnel) . Évalué à 5.
[^] # Re: Y'a que moi que ca choque ca ?
Posté par zebra3 . Évalué à 3.
C'est une putain de fonctionnalité dont je me sers sur toutes les applications à onglets (et il y en a : Epiphany, Gedit, Nautilus et le Terminal, pour citer celles qui servent 95% du temps), c'est vraiment dommage d'enlever ça.
Ils auraient au moins le laisser ça en option…
Bientôt il vont enlever le focus sur les éléments survolés par le curseur, et on se croira sous Windows.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Y'a que moi que ca choque ca ?
Posté par Antoine . Évalué à 0.
[^] # Re: Y'a que moi que ca choque ca ?
Posté par Moonz . Évalué à 3.
« This was approved in the GTK+ meeting in irc. »
[^] # Re: Y'a que moi que ca choque ca ?
Posté par Antoine . Évalué à 2.
Il faut rappeler pourquoi IRC est mauvais comme support de prise de décision :
- impossibilité de discussion asynchrone (je poste un argumentaire, Machin répond plus tard alors que je suis offline)
- impossibilité de discussion structurée (pas de fil de discussion arborescent)
- impossibilité de prendre son temps (si je veux réfléchir à mon opinion concernant un sujet, voire me documenter, pas de chance, parce que la décision sera prise avant)
- archivage en général existant
(aussi, corollaire : quelqu'un qui n'est pas à l'aise en anglais sera encore plus désavantagé par rapport à une discussion par mail, parce qu'il est difficile d'être rapide, concis et précis à la fois)
IRC c'est bien pour du support ou simplement des discussions amicales. Pas pour décider de directions de développement.
[^] # Re: Y'a que moi que ca choque ca ?
Posté par Moonz . Évalué à 3.
Ils ont peut-être (probablement même, vu les réactions) mal jugé l’importance de cette fonctionnalité du point de vue de certains utilisateurs, certes, mais en faire des dictateurs autistes qui prennent les décisions les plus importantes sans consulter personne, c’est un peu fort en café.
[^] # Re: Y'a que moi que ca choque ca ?
Posté par Antoine . Évalué à 2.
Ce n'est pas vraiment mineur puisque ça concerne le retrait d'une fonctionnalité.
Il ne s'agit pas de lancer un débat sur la BBC (qui ne sponsorise pas GTK) mais simplement de discuter le problème publiquement, par exemple sur le bug tracker, et d'attendre quelques temps, histoire que les gens aient l'occasion de donner leur avis.
mais en faire des dictateurs autistes qui prennent les décisions les plus importantes sans consulter personne, c’est un peu fort en café
Le terme dictateur est connoté, mais "autiste" semble correspondre ;)
Et je maintiens que faire de la gestion de projet sur IRC est le meilleur moyen de constituer une petite élite de super-contributeurs au détriment du reste de la communauté.
Tiens, c'est marrant, je consulte une liste Gnome par curiosité / association d'idées et je tombe sur quelqu'un qui a les mêmes critiques vis-à-vis d'IRC :
http://mail.gnome.org/archives/desktop-devel-list/2011-Febru(...)
[^] # Re: Y'a que moi que ca choque ca ?
Posté par claudex . Évalué à 6.
- impossibilité de discussion asynchrone (je poste un argumentaire, Machin répond plus tard alors que je suis offline)
- impossibilité de discussion structurée (pas de fil de discussion arborescent)
- impossibilité de prendre son temps (si je veux réfléchir à mon opinion concernant un sujet, voire me documenter, pas de chance, parce que la décision sera prise avant)
- archivage en général existant
Heureusement que tout cela est réglé par la tribune.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Y'a que moi que ca choque ca ?
Posté par Gniarf . Évalué à 2.
[^] # Re: Y'a que moi que ca choque ca ?
Posté par Antoine . Évalué à 2.
Je ne vois pas en quoi cette réponse est censée invalider mes arguments, mais qu'importe, relis le contexte du bug : il est ouvert et fermé dans la même journée. Donc on ne voit pas comment il aurait pu faire partie d'un ordre du jour « prévu et annoncé à l'avance », à moins bien sûr que le projet GTK s'amuser à programmer des réunions urgentes pour discuter du retrait d'une fonctionnalité :)
Et les autres arguments par rapport à l'inadéquation d'IRC tiennent toujours.
[^] # Re: Y'a que moi que ca choque ca ?
Posté par dinomasque . Évalué à 0.
BeOS le faisait il y a 20 ans !
[^] # Re: Y'a que moi que ca choque ca ?
Posté par gpe . Évalué à 6.
La réunion est le meilleur moyen de passer le temps en faisant croire que l'on bosse, pour le reste ...
[^] # Re: Y'a que moi que ca choque ca ?
Posté par Gniarf . Évalué à 5.
[^] # Re: Y'a que moi que ca choque ca ?
Posté par Antoine . Évalué à 3.
Je te conseille d'y participer un jour, tu verras : la culture corporate n'est pas ce qui se fait de mieux en matière d'efficacité :)
# y'a que moi que cela choque?
Posté par Albert_ . Évalué à 2.
Comparer a une version mineure de Qt cela fait leger...
http://linuxfr.org//2010/09/21/27403.html
[^] # Re: y'a que moi que cela choque?
Posté par claudex . Évalué à 5.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: y'a que moi que cela choque?
Posté par grid . Évalué à 3.
[^] # Re: y'a que moi que cela choque?
Posté par claudex . Évalué à 6.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: y'a que moi que cela choque?
Posté par grid . Évalué à 4.
l'outil de portage Qt3 vers Qt4 faisait une bonne partie du travail.
Bien évidemment, un tel portage n'aurait pas utilisé les nouveautés de Qt4. Mais si le portage a été aussi difficile, c'est uniquement parce que les devs KDE en ont profité pour casser énormément de chose dans LEUR api. Qui leur a demandé de virer konqueror au profit de dolphin ? Pas Qt en tout cas.
Aujourd'hui, ce choix peut sembler pertinent puisque KDE profite d'une archi interne bien plus propre, mais c'est sûr que ça a été long et pénible, et que pas mal de fonctionnalités ont sautés.
[^] # Re: y'a que moi que cela choque?
Posté par nud . Évalué à 0.
D'un autre côté, quand je vois la liste des nouveautés du dernier Qt, il n'y a pas grand chose de lié au scope de Gtk+, càd les widgets pour des interfaces graphiques...
Apparemment, Qt recouvre également les domaines de la glib, de gio, de WebkitGtk et plein d'autres (notamment, wrappers autours de libxml et gstreamer) et l'essentiel des nouveautés annoncées dans Qt sont liées à ces autres composants.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.