Tarnyko a écrit 478 commentaires

L'article m'a donné envie de découvrir Cairo-Dock ; installé sur la dernière Ubuntu (13.04), c'est joli, rapide même sans l'accélération 3D, très configurable… Personnellement, je suis assez fan de la vue "Raccourcis" de l'explorateur de fichier (déploie les partitions, CD, dossiers perso… dans une petite vignette).

Beau travail, continuez comme ça !

Tu as deux approches.

• patcher le code de ton côté et fournir une version alternative via un PPA par exemple ; c'est ce que fait le PPA GTK+3 Broadway pour Ubuntu (simple recompile ici, mais on pourrait faire n'importe quoi) ;

• coder un module externe via la fonction gtk_module_init (), intercepter les événements qui t'intéressent pour modifier le comportement final. Exemple de module connu et exemple d'utilisation. L'utilisateur ou le launcher de l'application doivent activer explicitement le module via la ligne de commande.

Pour reprendre l'exemple de mon patch, la 1ère approche est mille fois plus facile mais la 2ème plus élégante (et moins sujette au shitstorm…). Pour l'instant la version patchée tourne (bien) sur mon ordinateur, je fais rien mais si des gens me demandent je peux réfléchir à placer des binaires quelque part.

Pour être tout à fait honnête, et en dehors du nettoyage du code, il y a deux très bonnes choses dans GTK+3 :

• la gestion des thèmes Windows est intégrée, et non plus déléguée à un module externe (wimp). Sous GTK+2 il ne fonctionnait que sous quelques versions ; 2.20 ne l'avait pas par exemple et donc c'était moche. Maintenant c'est maintenu en core, et à l'usage sur les versions récentes de Win, c'est même assez joli.

• Broadway. Une fonction sous-exploitée mais qui fait rêver -elle vend presque GTK+3 à elle toute seule. Il suffirait d'un projet à succès l'exploitant pour garantir une longue vie au toolkit.

A la base c'est une bonne techno. Mais l'influence d'une équipe de design sur ce qui est censément un toolkit généraliste est par contre un point polémique.

Merci de ton soutien sur ton post précédent. Pour moi l'incident est clos, je suis passé à autre chose.

Liberforce,

Ah c'était toi :-O ?
Je m'excuse si mon commentaire a pu paraître un peu rude, je réagissais en même temps à beaucoup de sh*t/troll, et tu as subi un dégât collatéral.

Sauf qu'à ma connaissance, tu n'es pas mainteneur officiel GTK.
Fournir une version officielle d'un installateur GTK pour Windows indiquerait que c'est à nouveau officiellement supporté, et qu'il y a un mainteneur actif.

Tu soulèves des points pertinents ; effectivement tout ça est vrai. Je te contacte par mail pour davantage d'explications.

Merci d'être constructif, c'est assez rare sur les forums et commentaires, tu peux compter sur mon retour. On a un projet à faire avancer dans notre intérêt à tous.

Irréaliste.

Liberforce,
Merci de te renseigner un peu avant de faire des points généraux.

Depuis le retrait de Tor Lillqvist du poste de mainteneur GTK Windows, personne n'a pris le relais pour faire le boulot

Merci de se renseigner un peu avant de faire des points généraux.

Je suis l'actuel repreneur du travail de Tor Lillqvist. Lien vers mes dépôts GTK+3 win32.

On peut du coup se demander pourquoi mon travail n'est pas -pour l'instant- publiquement accessible, par exemple sur le site officiel ?

Réponse : l'inertie du projet est juste énorme.
La bonne volonté ne suffit pas ; pour faire un parallèle, c'est comme d'arriver avec tous les papiers requis dans une administration, mais selon les cas, face à un fonctionnaire trop occupé ou à un guichet vide.

J'ajoute que j'ai quand même bon espoir de voir mes bundles sur le site officiel d'ici peu.

Ah mais rien.
Il dit simplement lui-même "I'd advocate against Mozilla, Libreoffice, XFCE or LXDE to switch to GTK 3".
Je précise que j'ai un énorme respect pour cet homme.

Ils feraient mieux de lire ça avant, alors (auteur : main dev GTK+)

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.