saltimbanque a écrit 960 commentaires

il y aura toujours Qt et KDE.

et clutter et efl

Le sujet c'est qu'aussitôt que McCann est confronté à un souci dans son utilisation du bureau alors il change complètement de point de vue

McCann prend des choix particuliers. Sur le terminal j'y vois aussi une incohérence, et une trop grande influence de son besoin.

Finalement il n'y a pas la moindre étude du retour des utilisateurs, de leurs attentes ou de de leurs besoins

c'est conclure trop loin. Même au sujet de ce designer là. Surtout, il y a en d'autres. Il n'y a pas si longtemps, aday travaillait à refondre le tweak tool pour le rendre plus utilisable.

Je reviens au sujet. Effectivement, gtk+ est devenu The GNOME Toolkit, de facto. Parce que seul GNOME y contribue. Quoi de choquant? GNOME fait gtk+ et décide gtk+ : simplissime méritocratie. Logique.

Je pense qu'ils ont créé leur propre librairie entre autres, avec ce soucis de thread proprement détectés. Ensuite c'est de l'interface, mais s'ils ont bien fait les choses le regroupement en conversation est plus complexe que simplement basé sur des titres (genre Re:Paf le chien)

Mêmes raisons pour essayer, et même constat : fluide et pauvre. Pas mal d'efforts sur des raccourcis claviers, par ex. pour archiver on peut utiliser "suppr." ou "a" ou "backspace" ; mais je n'ai pas trouvé comment naviguer aisément.

A noter que par rapport à evolution, hors la question de fluidité, l'intérêt est dans leur librairie imap qui montre des conversations. Pareil à ce sujet, je n'ai pas encore trouvé les raccourcis qui vont avec, ça va se finir dans le code source si ça continue :/

n'y a t-il pas moyen d'"underclocker" cpu & gpu si ceux ci sont plus gourmands que la batterie ne le permet? (je ne peux pas tester ici, dsl)

Que préfère tu dans l'interface OSX?

Ca parait plus fluide, plus rapide

finder me p$ les c*. Ce truc est ignoble (i*gnom*inie?). Tout est plus rapide ailleurs, que ce soit gnome shell, kde, windows…

plus soigné.

pleinement d'accord. Autant sur l'interface plus finalisée que sur le QA. Sur la cohérence. Sur un peu tout. C'est le point fort.

Et il n'y a pas ce champ "Rechercher" et cette logithèque usine à gaz derrière.

Exposé a sans doute lancé la mode, il y'a belle lurette, mais depuis le gnome shell l'explose

Le Appstore? nan franchement je lacherai pas ma box pour cette horreur. (compiler ses app sous mac? mon appstore refuse d'installer xcode (enfin il prétend l'installer et ne fais rien) et donc je n'ai pas make, mais bon là je pars h.s.)

Bon j'arrête avec ma vie on s'en fiche. Les designers de gnome ont clairement chippé des idées à droite à gauche : osx bien sûr mais aussi ios, android, windows. Xerox =). Tout en gardant certains acquis Unix (bon bon vi je sé, hormis le clic milieu…)

Que préfère tu dans l'interface OSX?

gtk_signal_connect_object (GTK_OBJECT (button), "clicked",
                     GTK_SIGNAL_FUNC (gtk_widget_destroy),
                 GTK_OBJECT (window));

Fort heureusement, si tu te trompes sur les objets, à l’exécution, ça te dira "Invalid cast from Window to Button"

C'est donc surtout chiant pour le typage des fonctions. On peut parfois éviter le cast mais c'est vrai que ça revient un peu au même, une fonction void obscure_func (GObject* button, void* data) n'aide pas des masses.

hmm j'ai répondu avant le commentaire proposant un standard freedesktop.

$ xdg-browse --select toto/titi.tar.xz toto/

Au vu du millier de fm sous Linux… autant avoir une interface: soit elle est là et on est sûr que ça marche, soit elle n'est pas là et on ouvre un dossier seulement. Au moins on est sûrs.

l'option --select a été proposée a Nautilus, mais Cosimo a préféré intégrer la fonctionnalité sous la forme nautilus /chemin/fichier.ext.

Donc Nautilus peut gérer cela sans passer par dbus. Le passage par dbus s'explique par différents gestionnaires de fichiers qui n'ont pas le même comportement et vont chercher à ouvrir le fichier plutôt que de le montrer.

en attendant pas sûr que Konqueror implémente l'interface dbus. Donc oui,…

Et dans la série documentation merveilleuse

Camel.Imap : "I should really add more detail here, but I just don't care - I barely understand the code either"

ah, à propos du NIH, je retrouve l'une des explications de Jim Nelson, à partir de
“You Should Improve Thunderbird / Evolution / (my favorite email app)”

J'aurai adoré qu'ils contribuent à ça : https://www.guadec.org/session/evolution-as-email-service-for-the-gnome-desktop/.

Mais je sais qu'ils ont regardé le code de EDS avant de choisir de bâtir depuis zéro. Je pense que ça représente un certain investissement en temps et que ce n'est pas pour rien hélas.

Quand à se baser carrément sur evolution, là je pense que ce n'était pas du tout faisable. Ils ne visent pas la même chose. Tout comme Shotwell est très bien, mais ne correspond pas forcément à tout le monde.

Récemment, Red Hat a parlé de mettre du monde sur Evolution pour le moderniser un peu, mais en visant vraiment spécifiquement l'entreprise (et pour pallier à la mort de Thunderbird plus que pour le fun).

Vala est un bon langage pour débuter dans GNOME, je dirais

On compte quand même plusieurs projets d'envergure en vala. Donc geary, et à première vue même leur implémentation IMAP est en vala.

Si y'en a 10000 comme toi je comprend que dans la plupart des boites abuse finisse par être géré par Dave Null !

je ne comprends pas. Il donne probablement de l'argent (donc du temps…), il accepte de recevoir des informations, de les lire. Il peut certainement s'enquérir de pourquoi il reçoit un courriel avec tel émetteur.

J'imaginais vraiment qu'avec un outil (http://www.phplist.com/ ?) adapté et peut être du prêt d'infrastructure cela ne posait pas de difficulté. En quelque sorte, je suis déçu!, à un bémol près, effectivement le suivi lui peut justifier des ressources importantes. L'envoi lui-même ne devrait pas (au royaume des bisounours).

Bon après, j'ai aussi tiqué en lisant presta, en sachant que je suis sensible au sujet de la répartition des dépenses par les assos, et que je ne vois pas dans la prestation de service une garantie de qualité (le contrat permettant j'espère certaines garanties, au sens légal, mais pas 'certitude de travail bien fait')

Ce qui m'échappe : pourquoi passer par un presta, juste pour envoyer un email? Leur outlook ne permet pas de mettre assez de destinataires? ils veulent mettre des photos en lien plutôt qu'en dur dans le mail - mais amnesty a son site pour ça non?

Je ne suis pas contre la professionnalisation des associations, mais passer par un presta pour ça m'embête. Je préfèrerai que ce soit un barbu bénévole - pour envoyer des emails, je suis /sûr et certain/ qu'on en trouve, ou alors je rate d'autres difficultés dans la tâche à accomplir.

fais ou ne fais pas. il n'y a pas d'essai

j'espère qu'ils nous feront de bons messages d'erreur

$ git push --rebase
Chris'!, ça a pas d'bon sens lé!

breveter les gens?

A voir si la what the fuck s'inscrit dans la démarche formalisée en ce sondage sous la sémantique d'"on s'en fout", ou si nous considérons ici ladite licence comme affirmation de puissance du libre dont l'esprit surpasse même l'esprit des lois?

Le système d'init/boot, en temps que d'utilisateur et développeur, je n'ai que très rarement un contact direct avec.

Si tu as envie que ça reste comme ça, je te déconseille formellement systemd.

du pdv de l'utilisateur, je n'ai pas plus de contact qu'avant. L'utilisateur n'a pas de besoin de man systemctl. Même les simples trucs ci dessous je les découvre aujourd'hui.

http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet

après je ne développe pas de démon (vim existe déjà).

Dire que systemd devient nécessaire alors que ce n'était pas annoncé, ça se tient. Dans ce cas prends en toi à toutes les distro qui adoptent systemd, puis prends en toi à Greg Kroah-Hartman.