Tarnyko a écrit 490 commentaires

Suggestion très pertinente, merci à toi !

Effectivement, on pourrait demander au sélecteur de fichiers de lire le PATH (/bin:/usr/bin:/sbin, etc) et de compléter selon l'entrée de l'utilisateur (x = xcalc, xedit…).

C'est d'autant plus faisable que GTK+3 a une fonction d'autocomplétion intégrée (visible dans gtk3-demo).

Je pense que les devs GNOME ne sont pas fermés -sans quoi ils auraient fermé le bug- mais cherchent une solution élégante. Je vais voir si j'ai le temps de coder ce soir ou demain. J'espère juste ne pas me prendre un vent au final.

Tu rejoins donc l'avis initial des développeurs sur le fil dédié : c'est ton droit.
Tu suggères un contournement via une extension ou un paquet additionnel : c'est justement ce qu'une personne vient de me répondre sur ce même fil. Evidemment, il est toujours possible d'ajouter ce que l'on veut via des paquets en plus, et à ce moment ça relève de la distribution ou de l'utilisateur, plus de GNOME.

J'estime pour ma part qu'une telle fonction doit faire intégrante de l'UI. Elle était présente sous Windows 95, KDE 0.9 et GNOME 1. Elle est encore présente aujourd'hui sous Windows 7/8, KDE 4 et, à vérifier, l'explorateur OS X. Je pense (et ne suis pas le seul) qu'elle devrait être dans GNOME 3.

Ne pas oublier que la majorité des utilisateurs ne vont rien installer du tout ; ils vont juste switcher de DE.

Exactement.
Leur réponse est que si tout va bien, ça ne devrait pas arriver. Sauf que… si.
Le Java JRE d'Oracle, par exemple, n'installe pas de .desktop. Donc l'interpréteur Java n'est jamais sélectionnable. Que faire ? Contacter Oracle et leur demander de mettre un .desktop qui s'adapte à l'emplacement de l'application, parce que GNOME en a besoin dans son "Ouvrir avec" ?
J'ai propoposé d'écrire un patch à la fin du fil, mais pas question de perdre des heures s'il y a opposition de principe par contre, on verra s'il y a une réponse.

Ah ben tiens il y a déjà un bug identique, qui date de… 2011.
Et ce commentaire et celui-là sont particulièrement… intéressants.
No comment pour ma part.

Tiens, c'est vrai ça. Effectivement ce serait bien d'avoir un choix "Autre application…" qui ouvrirait un sélecteur d'exécutable direct (et puis ça coûte quasi-rien à implémenter).

Je t'ai ouvert un bug sur GNOME Bugzilla. Tu peux te rajouter en CC si tu veux recevoir les MàJ. On verra.

Pour le Alt-Tab, voir les screens de mon article (post ci-dessus), c'est définitivement le cas.
Pour la vie privée, aller dans "System Settings" -> "Privacy". Rien vu sur la géoloc par contre.

Il est possible que la version Fedora 19 ne soit pas encore 100% à jour.

Oser poster ça le vendredi ? Inconscient !

Sinon, merci pour la revue très complète.

À noter que le thème Classic n'est pas obligé d'être gris morne ; c'est une question de thème. On peut garder son style préféré en activant les extensions manuellement.

Un petit regret : GNOME avait promis de mettre un Live CD à disposition ici, mais rien encore. Du coup c'est dur de tester. Peut-être créent-ils leur propre distro LFS pour ne déplaire à personne :-) ?

J'ai écrit un petit article pour installer facilement 3.8 (enfin 3.7.9, c'est presque pareil) et activer les éléments Classic. Avec ça j'en suis très content, c'est largement prêt à l'usage à mon avis.

Merci pour ce journal concret et complet, très intéressant à lire jusqu'au bout.

Assez d'accord sur le fond ; j'applique d'ailleurs souvent la même politique que toi pour les développements sous contrat (payer plus cher pour un contenu fermé sous licence proprio).

Le dual-licensing me paraît par contre adapté pour des projets ambitieux désireux de se promouvoir eux-mêmes (MySQL, la plupart des solutions cloud…). Bien sûr ça n'a aucun intérêt en termes de dev contrat.

Merci pour ce journal concret et complet, très intéressant à lire jusqu'au bout.

D'accord avec le fond ; j'applique d'ailleurs souvent la même politique que toi pour les développements sous contrat (payer plus cher pour un contenu fermé sous licence proprio).

Le dual-licensing me paraît par contre adapté pour des projets ambitieux désireux de se promouvoir eux-mêmes (MySQL, la plupart des solutions cloud…). Bien sûr ça n'a aucun intérêt en termes de dev contrat.

Ah mais c'est pareil dans n'importe quel langage utilisant des bibliothèques externes.

J'ai conscience que tu faisais un point général, mais la réponse que j'ai faite permettrait de résoudre (au moins par le bas) ce problème.

L'API en C peut changer, des trucs deviennent obsolètes (surtout pour GTK+ ces derniers temps).

Exact. Pour éviter ce souci, les dernières versions des bibliothèques GNOME comprennent une surcouche nommée GObject-Introspection qui permet de régénérer des bindings "fiables" pour chaque nouvelle version de Vala.
Le problème se pose avec les autres biblios dont les bindings ont été écrits à la mano (GLUT par exemple).

Mais c'est valable aussi pour d'autres langages. Une solution que je préconise serait d'avoir une arborescence de paquets dédiés au langage, distincte de celle de la distro. On pourrait donc par exemple upgrader vers la dernière Ubuntu sans casser les bindings. Je songe à écrire une telle chose pour Vala, mais comme d'habitude le temps et le mécénat posent problème.

Mais non, c'est une question parfaitement légitime :-).

Je ne peux pas parler pour GNOME, mais j'ai trouvé ça ici : a quality Vala 1.0 is an important part of the future of the GNOME Platform, because it will simplify the task of creating and maintaining excellent language-neutral libraries

Je le comprends comme ça : le code Vala se transcrit en C pur, dont les librairies résultantes peuvent être réutilisées/bindées facilement… à compléter ou corriger.

PS : c'est un peu exagéré de dire qu'il y a peu de bindings. Il y en a déjà pas mal.

Super, merci à toi (et lui) ! Ma remarque était générale, mais si j'ai quelque chose de précis qui me revient en tête, je n'hésiterai pas.

Hey, j'ai reçu ce fameux mail en tant que membre du forum, et n'ai pu que constater la fermeture… La déception a d'abord été là: "Qui sait quels trésors tu aurais pu y récupérer si tu avais été mieux informé ?"

Puis j'ai réfléchi, et me suis aperçu que si je n'avais pas été mieux informé, c'est que je n'y allais plus -sur SunWizard- et depuis bien longtemps même, et donc que le webmaster avait probablement raison : toutes les bonnes choses n'ont qu'une durée de vie limitée…

Supprimé