nud a écrit 936 commentaires

  • [^] # Re: CSS

    Posté par  . En réponse à la dépêche Sortie officielle de GTK+ 3.0 !. É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.
  • [^] # Re: Questions

    Posté par  . En réponse à la dépêche Sortie officielle de GTK+ 3.0 !. É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)

  • # Crée un ticket dans le système d

    Posté par  . En réponse au message Doublon dans les tags. Évalué à 1.

    Tu peux aller dans le système de suivi (lien dans le menu en haut à droite) et ajouter un nouveau ticket. Les gestionnaires de notre bon dlfp devraient y regarder à un moment où à un autre...

  • # L'histoire est une chose, mais..

    Posté par  . En réponse à l’entrée du suivi Les anciennes URLs de commentaires tombent en 404. Évalué à 4 (+0/-0).

    J'ajouterais même que cela casse le fil de pas mal de journaux et dépèches relativement récents dans lesquels on peut trouver au sein des commentaires des liens vers d'autres commentaires...

  • [^] # Re: Ils y sont

    Posté par  . En réponse à l’entrée du suivi Bugs graphiques avec webkit. Évalué à 1 (+0/-0).

    Dans ce cas, pourquoi ne pas utiliser un élément block, sachant qu'il s'agit de toute façon des titres des sections du menu de gauche ?

  • [^] # Re: RonRonnement?

    Posté par  . En réponse à l’entrée du suivi Bugs graphiques avec webkit. Évalué à 1 (+0/-0).

    Oui, c'est cela.

    PS. La catégorie théorique de ce ticket de suivi est bien entendu "CSS" et non "Administration"

  • [^] # Re: Glade

    Posté par  . En réponse à la dépêche Gtk 2.10 est en finale. Évalué à 2.

    Toujours en développement, mais les devs ne sont pas très portés sur l'édition et la mise à jour de sites web...
  • [^] # Re: Les sales gnomes..

    Posté par  . En réponse à la dépêche Gtk 2.10 est en finale. Évalué à 1.

    > on se tape toujours des dépendances lourdingues (gnome-vfs2, etc...)

    gnomevfs en particulier n'est pas vraiment "lourdingue", il est le pendant "glib" de kioslave... et est donc un plus appréciable pour un programme comme inkscape qui peut dès lors ouvrir des fichiers distants, comme un fichier svg sur un site web. C'est un gros manque de Gimp, imho.
  • [^] # Re: Puisqu'on cause de Gnome...

    Posté par  . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 1.

    Dans les distributions à base de debian (donc ubuntu compris), y'a un machin pour définir les applis préférées, et sous debian c'est gnome-text-editor qui est appelé (basiquement, c'est un symlink, mais je ne me souviens plus du prog de debian en question...
  • [^] # Re: Puisqu'on cause de Gnome...

    Posté par  . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 3.

    Bon, à la base, cette phrase était une blague, vu que j'ai écrit le billet sur gedit lié dans l'article.

    Mais sinon, je trouve certaines de ces idées intéressantes (notamment la tabulation mixte). 'vais voir ce que je peux faire.

    Pour la puissance de la coloration, ça devrait être mieux avec gtksourceview 2, qui devrait être prêt pour 2.16.
  • [^] # Re: Puisqu'on cause de Gnome...

    Posté par  . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à -1.

    Je ne sais pas si ce que tu veux (ne pas utiliser gedit par défaut) est possible en l'état mais tu peux toujours remplir un bug.

    Pour supprimer une affectation, tu peux aller dans les propriétés d'un fichier et aller sur l'onglet "open with". Il y a un bouton "remove" qui vient à point nommé (il n'est par contre pas possible de les enlever tous, je n'en connais pas la raison)

    Mais, pourquoi ne pas utiliser gedit ? :D