Sortie officielle de GTK+ 3.0 !

Posté par (page perso) . Modéré par Sylvain Rampacek.
Tags :
42
12
fév.
2011
Gnome
Huit ans après la 2.0, l'équipe de développement vient livrer la troisième version majeure de la bibliothèque graphique GTK+. Issue du logiciel de traitement d'images GIMP, GTK+ est la bibliothèque graphique servant de base aux environnements de bureau GNOME et XFCE. Cette version est une brique fondamentale du futur GNOME 3.0 prévu pour le mois d'avril prochain.

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 »).
Sous le capot :
  • 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 ».
Par ailleurs, grâce au développement itératif, le passage à GTK+ 3.0 se voit facilité pour les développeurs.
  • # Un (nouvel) espoir ?

    Posté par . Évalué à 7.

    Y a-t-il des chances de voir (dans un avenir assez proche) ce nouveau widget "sélecteur d'application" dans Firefox, Eclipse, ... ?
    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
  • # Questions

    Posté par . Évalué à 4.

    Bonjour, merci pour cette news intéressante ! Questions :

    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 (page perso) . Évalué à 4.

      Pour ton 1) ce n'est pas antithétique. Une instance peut être découpé en plusieurs processus, chaque gérant une fenêtre, ou plus ou moins ou ce que tu veux. Ceci dit je ne sais pas à quel niveau gtk3 intervient ni ce qu'elle permet exactement.

      Pour le 2), http://library.gnome.org/devel/gtk/unstable/gtk-migrating-2-(...) , enjoy !
      • [^] # Re: Questions

        Posté par . Évalué à 2.

        Pour le 1, il semblerait que ce que propose Gtk/Glib ([http://library.gnome.org/devel/gio/unstable/GApplication.htm(...)]) est de limiter à une application par session graphique. On peut bien entendu lancer des processus qui gravitent autour d'un processus qui, lui, sera unique par session.

        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 (page perso) . Évalué à 5.

          Je dirais même plus, ce concept d'application globale a pour base le concept de variable globale très mauvais pour beaucoup de chose et bon pour très peu de chose...

          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 (page perso) . Évalué à 2.

            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

            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 (page perso) . Évalué à 8.

              > Tu ne pourrais juste plus garder l'historique et les signets.

              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 (page perso) . Évalué à 10.

                bash et zsh arrivent très bien à avoir un historique rempli par plusieurs instances.

                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 (page perso) . Évalué à 2.

                  Je crois que SQLite gère les accès multiples de manière grossière :
                  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 (page perso) . Évalué à 6.

                    C'est ce que je dis, il n'accepte pas d'écriture multiple.

                    « 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 (page perso) . Évalué à 1.

                      Il n'y a jamais d'écriture multiple... même avec une base de données !

                      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 (page perso) . Évalué à 6.

                        Il n'y a jamais d'écriture multiple... même avec une base de données !

                        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 (page perso) . Évalué à 6.

                          C'est simple : SQLite est un SGBD sous forme de bibliothèque embarquée ; elle écrit directement dans son fichier, et ne connaît pas les autres instances qui pourraient écrire dessus.
                          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 (page perso) . Évalué à 3.

                            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.

                            Ç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 (page perso) . Évalué à 1.

                              OK, c'est pas vraiment la définition générale de plantage, mais comme tu veux. Par contre je comprends pas pourquoi je me suis fait inutiler sur ma réponse pourtant pédagogique.

                              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 (page perso) . Évalué à 3.

                                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.

                                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 . Évalué à 4.

                        Tu simplifie énormément le fonctionnement d'une base de données. Quasiment tout les SGBD sont transactionnels, ils implémentent différentes manières de gérer la concurence, plus ou moins optimistent. Il y en à même qui n'utilisent pas de verrous.

                        Après c'est sur que sur le système de fichier c'est pas concurent.

                        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: Questions

                  Posté par . Évalué à 4.

                  En ce qui concerne le SGBD, pourquoi ne pas clore la connexion au SGBD après chaque demande ?

                  Il y a une raison à rester connecté à une base de données en permanence ?

                  Sedullus dux et princeps Lemovicum occiditur

                  • [^] # Re: Questions

                    Posté par (page perso) . Évalué à 3.

                    Postgresql permet d'envoyer des signaux au client. Garder la connexion ouverte peut aussi améliorer les performances (surtout la réactivité de l'application), même si en local, ça doit être très négligeable.

                    Envoyé depuis mon lapin.

                    • [^] # Re: Questions

                      Posté par . Évalué à 1.

                      euh, c'est du domaine de quelques ms hein connect() et disconnect() en local...
                      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 (page perso) . Évalué à 2.

                    Parce que SQLite n'est pas un SGBD à proprement parlé, c'est juste une bibliothèque qui permet de manipuler un fichier. Tenter d'écrire à plusieurs instances en même temps peut introduire de grosses latences.

                    « 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 . Évalué à 1.

                      Merci. Effectivement, ça , c'est un risque pour un logiciel de cette taille.

                      Sedullus dux et princeps Lemovicum occiditur

                    • [^] # Re: Questions

                      Posté par . Évalué à 5.

                      Si si c'est un SGBD (R même), il est juste pas client/serveur.

                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                    • [^] # Re: Questions

                      Posté par (page perso) . Évalué à 2.

                      SQLite est conçu pour fonctionner en monoposte avec un seul utilisateur à la fois. Pour ceux qui l'ont connu, c'est comme Access (interface conviviale, plantages nombreux). Dans mon entreprise, ceux qui avaient développé une application avec ce logiciel et voulaient en étendre l'usage à d'autres utilisateurs ont eu de gros déboires. Tout simplement parce que ce n'est pas fait pour ça !
              • [^] # Re: Questions

                Posté par . Évalué à 10.

                bash ? il fait n'importe quoi avec l'hsitorique ou alors la gestion a chéngé recemment. Si tu ouvres deux shells, et que tu les fermes successivement seul l'historique du deuxième est accessibles aux futures sessions, si je me trompe pas.
                • [^] # Re: Questions

                  Posté par . Évalué à 0.

                  Je viens de faire le test, j'ai ouvert deux bash (vérifié que la dernière commande d'historique est la même).
                  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 (page perso) . Évalué à 4.

                    C'est parce que ton test est trop simpliste, bash garde l'historique mais il ne le fusionne pas, il ajoute l'un à l'autre, de plus il ne le fait qu'à la fermeture.

                    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 (page perso) . Évalué à 10.

                      C'est hors sujet par rapport à la dépêche, mais il y a un 'hack' pour permettre a bash de mettre à jour l'historique après chaque commande (en fait a chaque fois qu'il affiche le prompt) ce qui permet d'avoir un seul bash_history mis à jour quel que soit le nombre de bash concurrents.
                      Ajoutez dans votre .bashrc:

                      shopt -s histappend
                      PROMPT_COMMAND='history -a'
          • [^] # Re: Questions

            Posté par (page perso) . Évalué à 8.

            > Je dirais même plus, ce concept d'application globale a pour base le concept de variable globale très mauvais pour beaucoup de chose et bon pour très peu de chose...

            À 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.

            « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

            • [^] # Re: Questions

              Posté par (page perso) . Évalué à 10.

              Les applications doivent maintenant gérer les multi-fenêtre, un mode serveur... Tout cela parce que la plupart des gestionnaires de fenêtre ne savent pas gérer les onglets correctement. Au final, peu de gestionnaire de fenêtre ont repris les idées de PWM.

              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 (page perso) . Évalué à 3.

                Une application avec des onglets, pour toi, c'est une usine à gaz… Hum. Faut quand même pas pousser la philosophie UNIX à l'extrême.

                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.

                « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

                • [^] # Re: Questions

                  Posté par . Évalué à 4.

                  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…
                  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 (page perso) . Évalué à 1.

                    Jamais entendu parlé du COW, tu sais donner un lien ? Le web n'est pas vraiment mon ami sur ce coup-là.

                    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

                    • [^] # Re: Questions

                      Posté par . Évalué à 3.

                      http://fr.wikipedia.org/wiki/Copy-On-Write

                      Mais je ne suis pas certains que dans le contexte ce soit faisable.
                      • [^] # Re: Questions

                        Posté par (page perso) . Évalué à 3.

                        > Mais je ne suis pas certains que dans le contexte ce soit faisable.

                        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.

                        « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

                        • [^] # Re: Questions

                          Posté par . Évalué à 4.

                          Arrêtez moi si je me trompe, mais je crois que le copy-on-write s’applique aux données du programme. Par contre lorsque qu’on lance de multiples instances d’un même processus le code reste identique, et bien évidement on ne va pas charger en mémoire plusieurs fois le même code. Il reste la question des données du programme : mais je crois que lorsque l’utilisation des onglets se justifie la place en mémoire occupée par ce qui est réellement différent entre les onglets, c’est-à-dire le document en lui-même, et très largement supérieur à ce qu’il y a en commun, ce qui peut être préférences, agencement de l’interface graphique, historique, etc. Ce qui me gêne le plus c’est le temps de lancement de l’application à chaud, un gros travail doit être fait à ce niveau là, pour que l’utilisation des onglets du gestionnaire de fenêtre ne soit pas handicapant.
                          • [^] # Re: Questions

                            Posté par . É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 . Évalué à 3.

                Peut être que ceci https://linuxfr.org//2010/04/18/26749.html t'interesseras. Notamment surf.
                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.

                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: Questions

                  Posté par (page perso) . É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 (page perso) . Évalué à 0.

                    Réponse tardive... j'étais à 200% dans autre chose ces derniers temps.

                    Et moi 600% comme tu le vois :)

                    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.

                    Emacs gère aussi les sélections carrées (désolé, je n'ai pas pu résister!).

                    • [^] # Re: Questions

                      Posté par (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 2.

                          • Décalage d'un colonne d'un tableau, inversion de colonne...
                          • Décalage de code à droite ou à gauche...
                          • Suppression d'une colonne
                          • ...

                          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 . Évalué à 6.

              GSettings peut informer directement toutes les instances du navigateur qu'une autre instance du navigateur vient d'ajouter un marque-page ?
              • [^] # Re: Questions

                Posté par (page perso) . Évalué à 1.

                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.

                « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

                • [^] # Re: Questions

                  Posté par . Évalué à 2.

                  Je ne comprends pas, vous dites d'abord :
                  "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 (page perso) . Évalué à 2.

                    Il faut distinguer « préférences et autres paramètres » et « données ».

                    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.

                    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

    • [^] # Re: Questions

      Posté par . Évalué à 1.

      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.

      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 (page perso) . Évalué à 10.

    Nouveau widget "interrupteur" : c'est que moi ou ce truc est un non sens d'ergonomie ? C'est pas clair, on vois pas du premier coup d'œil quel est l'état du machin, on comprends pas ce qu'il faut faire, est-ce qu'il faut cliquer et maintenir appuyé le bouton pour faire glisser l'interrupteur pour aller dans le sens qu'on veux ? 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 ?

    « 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 (page perso) . Évalué à 9.

      Ce n'est pas que toi. Ce genre de truc fleurit sans doute parce que les iphonistes se sont habitués et donc savent que si on voit "On", c'est que le bouton est sur "Off" (ou est-ce le contraire) et puis c'est vrai qu'à défaut d'être compréhensible et ergonomique, c'est joli.

      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 . Évalué à 10.

        Ce genre de truc fleurit sans doute parce que les iphonistes se sont habitués et donc savent que si on voit "On", c'est que le bouton est sur "Off" (ou est-ce le contraire)

        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 (page perso) . Évalué à 1.

          On et Off c'est quand même un peu internationnal.

          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 . Évalué à 8.

            On et Off c'est quand même un peu internationnal.

            À 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 (page perso) . Évalué à 1.

              En plus « on » et « off » ça désigne les positions physiques d'un bouton-poussoir. Lorsqu'il s'agit d'une glissière, ça ne convient plus.
        • [^] # Re: Interrupteur

          Posté par . Évalué à 1.

          Apple a resolu le pb de la localization en remplacant on/off par O et |, un peu comme certains interupteurs. Ce qui est vraiment horrible, en plus de pas comprendre si on veut dire "sur on" ou "allume le", maintenant on sait meme pas ce que le symbole veut dire.

          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 (page perso) . Évalué à 10.

        BohwaZ
        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 . Évalué à 4.

          Il y a tout de même une importante différence sémantique entre les 2 : l'interrupteur indique une réaction immédiate (activer/désactiver un truc); la case à cocher indique qu'une réaction aura lieu dans un futur plus lointain.

          Les deux ont leur usage propre, pourquoi vouloir n'en garder qu'un seul ?

          BeOS le faisait il y a 15 ans !

          • [^] # Re: Interrupteur

            Posté par (page perso) . Évalué à 3.

            Quittons le monde du logiciel, et faisons une promenade IRL :

            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 (page perso) . Évalué à 3.

              Oui, et comme presque tout les langages sont turing complet, pourquoi ne pas en choisir un genre le brainfuck et laisser tomber tous les autres ?

              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 (page perso) . Évalué à 3.

                Pourquoi pas, dans le sens où par exemple dans beaucoup de logiciels audio on a des représentations visuelles en forme de potard à tourner ou de faders à glisser. On pourrait représenter tout ça par de simples glissières. En effet, dans la réalité ça ferait une interface énorme, et c'est bien pour cela que dans la vraie vie on ne le fait pas non plus, et que les boutons ont des formes différentes.

                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 . Évalué à 5.

                >Et il y a des cas, ne t'en déplaises, où un interrupteur ON/OFF sera plus clair qu'une checkbox.

                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 . Évalué à 3.

              IRL si on active l'interrupteur de la lampe et qu'il n'y a pas de lumière on gueule.

              Jouer avec des écrans à diode c'est pas IRL, c'est un truc de nolife.

              BeOS le faisait il y a 15 ans !

              • [^] # Re: Interrupteur

                Posté par (page perso) . Évalué à 2.

                Si tu coche la case "mute" de ta carte son, et que le son ne se coupe pas, tu ne gueules pas ?

                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 . Évalué à 2.

                Si je lis entre les lignes, BeOS a inventé les boutons on/off ?
            • [^] # Re: Interrupteur

              Posté par . Évalué à 4.

              Dans la vraie vie il n'y a pas de case à cocher, il n'y a que des interrupteurs.

              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 (page perso) . Évalué à 3.

                Là j'accepte plus volontiers l'argument que celui du nolife :)
                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 . Évalué à 2.

                  Je n'entrais pas dans le débat bouton poussoir/bouton à glissière. Car je suis plus ou moins d'accord avec toi, que c'est plus une affaire de thème.
                  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 . Évalué à 3.

                    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
                    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 . Évalué à 3.

                      Toi t’as pas de vieux appareils… mes parents ont eu pendant longtemps un vieux magnétoscope : boutons à bascule (haut marche/bas arrêt) pour activer/désactiver, peut-être parce qu’il n’y avait pas de led/écran d’affichage à l’époque et que ça permettait de voir d’un coup d’œil ou on en était, et bouton poussoir pour varier un comportement actif (play/pause etc.). Idem sur l’ampli.

                      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 . Évalué à 3.

      À vue de nez je dirais que c'est pour faire comme l'iPhone. Sur les interfaces mobiles ça a peut-être un intérêt. Dans certains cas c'est peut être plus clair que les toggle buttons.
      • [^] # Re: Interrupteur

        Posté par . Évalué à 8.

        Il y a les bonnes vieilles cases à cocher quand il n'y a pas de conséquence "lourde" immédiate, et les boutons qui peuvent rester enfoncés quand l'action a un effet immédiat.
      • [^] # Re: Interrupteur

        Posté par (page perso) . Évalué à 10.

        Sur une interface tactile c'est pas plus pertinent...

        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 . Évalué à 10.

          Le bouton est-il "pertinent" ou "inutile", that is the question..

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Interrupteur

          Posté par . Évalué à 7.

          "J'espère que ça va pas trop se répandre ce truc"
          Le mettre dans les composants Gtk standard est comme un encouragement à l'utiliser.
        • [^] # Re: Interrupteur

          Posté par . Évalué à 0.

          Ben justement, c'est pas un bouton, c'est une glissiere.
          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 (page perso) . Évalué à 7.

    >>> le nouveau moteur de style incluant une syntaxe similaire aux CSS et l'animation des transitions d'états des widgets ;

    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 . Évalué à 10.

      Ben comme d'habitude (cf dcop/dbus), GNOME va pousser de force son propre format dans freedesktop en disant qu'il est top plus mieux, et ensuite Qt s'adaptera alors qu'il avait fait le truc en premier.
      • [^] # Re: CSS

        Posté par . Évalué à 1.

        Ooooh le joli appel au Troll!

        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 . Évalué à 7.

          Si tout se passe bien dans l'écosystème du Libre, KDE s'inspire des bonnes idées de Gnome et vice-versa.

          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 . Évalué à 6.

            Il me semblait que qt était maintenant dans le giron de Nokia, non ?
            J'ai du mal à croire que Nokia ait moins de moyens que Redhat ...
            • [^] # Re: CSS

              Posté par . Évalué à 3.

              En ce moment, la grande question est: ont-il l'envie de développer Qt ? (Cf. le deal récent avec MS)
            • [^] # Re: CSS

              Posté par . Évalué à -4.

              Qt est dans le giron de Nokia, mais pas KDE, et je ne suis pas sûr que Nokia s'intéresse autant que Red Hat a des projets comme FreeDestop.
          • [^] # Re: CSS

            Posté par . Évalué à 0.

            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).

            Moui bon en pratique, quand on réfléchit deux minutes, on se rend compte de plusieurs choses, notamment:

            1. À la manière des éléments HTML (ou XUL, fwiw), Qt et Gtk utilisent les noms des classes. Ce serait pour le moins étrange de styler un GtkButton en utilisant QtButton dans le thème...
            2. le fonctionnement de Qt et de Gtk est très différent (et accessoirement très différent de ce qu'un navigateur fait), donc les fonctionnalités supportées ne sont pas identiques et pas toujours complètement identiques avec le résultat qu'on aurait dans un navigateur. Si tu s/Qt/Gtk/ dans un thème Qt, tu peux être sûr que Gtk ne sera pas à même d'offrir un rendu correct "out of the box"
            3. Je soupçonne que RedHat et les autres se contrefichent du format utilisé pour les thèmes, qui ont somme toute une portée très limitée (voir point 1). Cela n'a rien de commun avec dbus ou autres éléments plus bas dans la stack.
  • # gtk+ 3.0

    Posté par (page perso) . Évalué à -3.

    Y'a de quoi s'amuser, on dirait, dans cette nouvelle version :-)
  • # Développement itératif

    Posté par (page perso) . Évalué à 3.

    « Par ailleurs, grâce au développement itératif, le passage à GTK+ 3.0 se voit facilité pour les développeurs. »

    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.

    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

    • [^] # Re: Développement itératif

      Posté par (page perso) . Évalué à 3.

      Oui.

      Mais effectivement, je voulais exprimer deux idées dans la même phrase.

      En outre, je pense aussi que le choix de faire des livraisons fréquentes est meilleur que de faire des « aperçu technologiques » ou des alpha. Python fait le même choix.

      Dans les dernières version de GTK+ 2.X, on pouvait déjà utiliser des technos GTK+3.0. D'où la légèreté de cette version 3.0 finale.

      3.0, c'est surtout un jalon. L'important dans GTK+3.0 n'est pas tant les nouvelles fonctionnalités, que le fait qu'elle seront garanties pour toute la durée de vie de la branche 3.X.

      On n'est ici vraiment loin de la logique Vista ou Qt/KDE.
  • # Y'a que moi que ca choque ca ?

    Posté par (page perso) . Évalué à 5.

    • [^] # Re: Y'a que moi que ca choque ca ?

      Posté par . Évalué à 3.

      Ah non, il y a moi aussi.
      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 . Évalué à 0.

      Mort de rire, d'enlever une fonctionnalité en moins de 24 heures sans la moindre discussion préalable. Ils sont vraiment graves :-o
      • [^] # Re: Y'a que moi que ca choque ca ?

        Posté par . Évalué à 3.

        > sans la moindre discussion
        « This was approved in the GTK+ meeting in irc. »
        • [^] # Re: Y'a que moi que ca choque ca ?

          Posté par . Évalué à 2.

          J'imagine que les utilisateurs de fonctionnalités gtk ne se retrouvent pas régulièrement sur IRC pour vérifier lors des "GTK+ meetings" que l'on ne va pas les retirer subrepticement.

          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 . Évalué à 3.

            C’est pas une direction de développement mais un choix mineur concernant la suite à donner à un bug report comme ils en ont probablement une dizaine par jour. Ils ne vont pas non plus lancer un débat public sur la BBC pour un rapport de bug mineur perdu parmi des milliers d’autres.
            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 . Évalué à 2.

              C’est pas une direction de développement mais un choix mineur concernant la suite à donner à un bug report comme ils en ont probablement une dizaine par jour. Ils ne vont pas non plus lancer un débat public sur la BBC pour un rapport de bug mineur perdu parmi des milliers d’autres.

              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 (page perso) . Évalué à 6.

            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


            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 . Évalué à 2.

            tu m'amuses assez. tu n'as jamais participé à une réunion de ta vie, réunion prévue et annoncée à l'avance, avec un ordre du jour précis, réunion que tu auras préparée et lors de laquelle tu te contenteras pour beaucoup de répondre oui ou non ? et pour les points que tu tiens à soulever et qui semblent bloquants ou pertinents aux autres, qu'une objection soit notée et discutée sur un media plus approprié avant la réunion suivante ?
            • [^] # Re: Y'a que moi que ca choque ca ?

              Posté par . Évalué à 2.

              tu m'amuses assez. tu n'as jamais participé à une réunion de ta vie, réunion prévue et annoncée à l'avance, avec un ordre du jour précis, réunion que tu auras préparée et lors de laquelle tu te contenteras pour beaucoup de répondre oui ou non

              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 . Évalué à 0.

                Tes arguments sont invalides parce qu'un réunion (en face à face, au téléphone, en visio, par IRC, etc.) est LE meilleur moyen qu'on ait trouvé jusqu'à présent pour prendre une décision dans un projet.

                BeOS le faisait il y a 15 ans !

                • [^] # Re: Y'a que moi que ca choque ca ?

                  Posté par . Évalué à 6.

                  Ah bon ? On ne doit pas fréquenter les mêmes réunions alors... ;)
                  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 . Évalué à 3.

                  Comment font tous les projets logiciel libre, à ton avis ? Il y en a très peu qui font des réunions.
                  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 . Évalué à 2.

    On parle d'une version majeur de Gtk et il n'y a que ca comme nouveaute?
    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 (page perso) . Évalué à 5.

      Comme expliqué plus haut, le développement de GTK3.0 s'est fait au fur et à mesure des évolution de la série 2.x, cela marque juste un support des API jusqu'au moins la fin de la version 3. Ça devrait éviter les mauvaises surprises comme avec KDE 4.0.

      « 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 (page perso) . Évalué à 3.

        les mauvaises surprises avec KDE4.0 n'ont que peu de rapport avec Qt4. Les devs KDE ont remis tout à plat lors du passage à Qt4, mais ils n'auraient très bien pu faire que le strict nécessaire.
        • [^] # Re: y'a que moi que cela choque?

          Posté par (page perso) . Évalué à 6.

          L'API a quand même fort changé entre Qt3 et Qt4, le portage n'était pas trivial non plus.

          « 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 (page perso) . Évalué à 4.

            Désolé, mais c'est faux, regarde http://doc.qt.nokia.com/4.0/porting4.html
            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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.