Tarnyko a écrit 445 commentaires

Bon c'est inutile, il n'en veulent pas.

Pour les conclusions de cette misérable affaire, consulter :
- le commentaire final du mainteneur sur Bugzilla ;
- la réponse du dev en chef (ou assimilé) sur la mailing list.

En gros : rien à dire techniquement, mais on ne veut pas donner cette possibilité aux utilisateurs… Moi qui trouvait exagérés les commentaires et trolls de certains sur les devs du projet, je viens d'expérimenter la chose par l'absurde ; et aux premières loges.

J'ajoute que j'ai rarement vu une telle attitude de la part d'un projet libre.
Refuser une modification demandée par une majorité sur un même bug/fil, et déjà écrite par un contributeur !

Donc devnewton va rester (à raison) loin de GNOME. Et moi aussi.
Je pense sérieusement supprimer la revue positive que je leur ai faite (au bénéfice de la bonne volonté) dernièrement.
Et un conseil à ceux qui liraient mon commentaire : tenez-vous éloignés de GTK+3. Vraiment. C'est un piège. Ce toolkit est dorénavant maintenu par des gens qui partagent les mêmes opinions, refuseront vos modifications ; et comme c'est une bibliothèque énorme, vous ne pourrez pas la forker. Vous serez enchaînés aux choix des designers.

Je teste ta possibilité (que je ne connais pas) et je reviens vers toi.
Ca va prendre un peu de temps, je vais voir si je peux répondre encore ce soir.

Ça peut être pour n'importe lequel ; mais admettons que tu aies installé Java (Oracle Java ou OpenJDK, c'est pareil dans ce cas).

Tu finis avec une commande "java" dans ton PATH, auto-complétée par le terminal ; tu lances un fichier Java avec un commande du type "java -jar monprogramme.jar".

Maintenant tu as ton fichier .jar dans les fichiers GNOME. Tu double-cliques sur le .jar pour l'ouvrir. La fenêtre "Choix des applications" s'ouvre.

"java" n'apparaît pas car il n'a pas de fichier ".desktop" requis par GNOME.
Sous Windows, tu as un bouton "Parcourir…" qui te permet de naviguer jusqu'à ton exécutable "java" et de l'associer définitivement aux .jar.
La même fonction est sous KDE et GNOME2.
Sous OSX, je ne sais pas mais il me semble qu'elle y est aussi.

Sous GNOME, tu n'as rien ! Tu n'as que la solution de créer ton propre .desktop au bon format avec l'éditeur de texte, et le mettre au bon emplacement, ce qui est hors de portée d'un néophyte.

Le dév de la ML répond que c'est à l'application Java de faire ce travail, qu'il fait patcher l'appli.
Penser à la multitude d'applications anciennes, non maintenues, non intégrées, etc… Pour un usage pratique, ça ne me paraît pas réaliste.

Ma proposition alternative d'intégrer la fonction dans Nautilus (vu qu'elle n'est apparemment pas désirée là où je l'ai mise) n'a pas reçu d'écho.

Au rapport.

J'ai pas de bonnes nouvelles. En fait, pour l'instant, je suis déception.

Aller ici pour être au courant
Discussion arrêtée là.

Je ferais un commentaire complet -et sans doute définitif- ce soir si la situation n'a pas bougé.

devnewton, Segfault et robin,

J'avais un peu de temps libre, alors j'ai écrit l'essentiel du patch, je l'ai posté avec des captures d'écran ici.

J'ai repris l'idée de Segfault pour l'autocomplétion.

Si vous voulez aider à "pousser" la modif, ce serait bien que vous interveniez sur le fil après d'éventuelles réponses des devs (en expliquant pourquoi vous en avez besoin, etc), ça ferait avancer le schmillblick.

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é