romu a écrit 179 commentaires

Merci, c'est bien vu en effet, même si ça reste dommage et probablement en contradiction avec la volonté d'attirer des développeurs venant d'autres horizons.

D'ailleurs, à ma connaissance GJS est basé sur SpiderMonkey, le moteur "ancienne" génération de Mozilla. Y-a-t-il volonté de passer sur IonMonkey, le nouveau ?

J'enlève une autre coquille de la même phrase qui devient :
"Or GObject Introspection est utilisé pour tous les langages."

Tout d'abord merci Etienne, tes dépêches sur Gnome sont toujours passionnantes !

A titre personnel, je connais peu JS, même si j'essaie de m'y mettre, notamment en faisant quelques scripts shell avec NodeJs.

Il y a quelques mois, il y avait eu une longue discussion sur le net, sur un blog anglophone, concernant le dev d'applications Gnome et mon commentaire avait été repris concernant l'environnement global de développement. (voir ici http://jewelfox.dreamwidth.org/33061.html)

Aujourd'hui, je ne sais pas trop comment cela a évolué, je salue néanmoins cette décision de l'équipe Gnome, mais…

• je trouve dommage que Gnome fasse du "faux" Js, tout du moins du Js que l'on est pas habitué à manipuler. Exemples :

-- la librairie standard Js de Gnome n'a rien à voir avec la librairie standard que l'on trouve partout ailleurs. Truc tout con, et vraiment basique, l'objet "console" n'existe pas, il faut appeler la fonction globale "print". C'est tout bête, mais le développeur Js un peu "newbie" comme moi qui débarque avec la doc du MDN dans la tête, bne il est perdu.

-- même remarque pour le "packaging", avec GJS la gestion des espaces de noms se fait avec "import" et l'organisation physique de fichiers dans des dossiers, mais pourquoi ne pas reprendre les principes de CommonJs, avec par exemple le mot clé "require", qui sont maintenant largement répandus et maîtrisés ?

-- contrairement à @liberforce, je trouve justement dommage qu'il existe 50 manières de faire les choses (un peu moins en fait hein !). Rien que pour écrire une classe, ça change. Soit on fait du "vrai" Js :

function MaClasse() {...}

Soit on fait du "Gnome" :

const MaClasse = new Lang.Class({...})

Sauf que cette 2é méthode n'est pas documenté, qu'il faut lire le code de Gnome-shell pour comprendre qu'il y a des fonctions héritées comme "_init" pour le constructeur (d'après ce que j'ai compris du code), qu'il y a des champs plus ou moins implicites comme "Name" dont on ne sait pas vraiment à quoi ils servent, etc.

• Il y a clairement un souci avec la doc qui est faite pour le C. Une approche certainement intéressante serait de reprendre les principes du MSDN avec des onglets par langage

• Enfin, il y a un vrai souci d'environnement de développement, Anjuta est juste une souffrance pour du Js, et MonoDevelop ne le supporte pas, du moins la 3.0.3, ça marchait toujours pas, ou alors je suis une bille ce qui est toujours possible.

Le monde Js évolue très vite, notamment grâce (ou à cause de) à l'explosion du JS côté serveur, de nouvelles API apparaissent. Ca n'engage bien sur que moi, mais je trouverais intelligent de la part de l'équipe Gnome de reprendre ces APIs à leur compte pour vraiment faciliter la vie des développeurs, après, tout ne sera bien sur pas possible, mais ce serait déjà un bon début.

"Hors GObject Introspection est utilisé pour tout les langages." -> "Or GObject Introspection est utilisé pour tout les langages."

Super idée, merci. Manque juste un flux RSS sur le site pour qu'on puisse s'abonner et ce sera parfait.

Bonjour,
Je fais parti de ceux qui n'aime pas Unity, je le trouve carrément plus lourd (en teme de ressources) que Gnome Shell et bien moins avancé. C'est franchement moins pratique à l'usage.

Et plus je vois passer les versions d'Ubuntu, plus je vois qu'on ajoute des "lens" et autre fioritures au Dash qui me fait maintenant l'effet d'une grosse usine à gaz, bien loin de la simplicité de Gnome.

Bon, m'en vais tester Ubuntu Gnome Remix de ce pas moi.

Valide est mort, la dernière release a presque 18 mois.

Je complète mon propos en disant que si je parle de Vala, c'est parce que j'ai l'impression qu'on le présente plus ou moins comme le langage officiel de dev pour Gnome. Et que de plus en plus d'applis sont faites avec (celles de Yorba entre autres).

Merci pour ta réponse.

C'est avec Gedit que je bidouille aussi de mon côté. Je suis juste surpris, qu'en 2012, sur une plateforme qui se veut moderne, y ait pas au moins un débogueur fonctionnel. Font comment les devs de Gnome ? Ils déboguent le C généré par le compilo Vala ? Ils bossent encore à la trace ?

Idem pour les test unitaires, ça peut palier l’absence d'un débogueur, mais le dernier commit sur valadate date de…3 ans !

Perso, j'ai vraiment envie de développer quelques trucs pour Gnome, mais franchement, faut être sacrément motivé.

Bonjour,
Tout d'abord un grand merci pour cette dépêche, y a eu du boulot à l'évidence. Moi je fais partie des fans de Gnome, j'ai donc hâte de tester cette 3.6.

Par contre, cette dépêche ne concerne que le point du vue de l'utilisateur, et y a quasiment rien pour les développeurs. Du coup, je pose ici quelques questions qui me viennent car j'essaie de me mettre au dev Gnome :
- y a un IDE avec un débogueur fonctionnel pour Vala ? J'ai testé Anjuta et, de mémoire, le débogueur ne fonctionnait pas du tout.
- même question pour Vala mais pour l'environnement de tests, y-a-t-il un module de tests unitaires "officiel" avec la doc qui va bien ?

J'étais parti sur Gjs à l'origine (je n'ai pas complètement abandonné d'ailleurs), et jsunit fonctionne très bien pour les applis Gjs, mais j'ai plus d'expérience en C# qu'en Js, et de plus, on ne peut pas faire de librairies avec Gjs.

Merci.

Ok, je détaille.

L'image de Nautilus qui apparaît dans le billet de OMG! Ubuntu! que je cite, est une capture réalisée avec le thème par défaut de Ubuntu, Ambiance. Bien sur, maintenant que Canonical a annoncé qu'ils ne migreraient pas sur cette version, ils ne vont pas de fouler pour améliorer les choses.

Maintenant, côté Gnome, les choses sont différentes il me semble, puisque le thème officiel est Adwaita. Et je n'ai aucun doute que fonctionnalités et design graphique seront cohérents. Suffit d'aller voir ce billet pour constater que ça a une autre gueule que ce qui a été montré jusque là, enfin, c'est mon opinion.

Eh oui, certains gueulent au premier mot lu, sans chercher plus loin.

Un évènement m'a récemment fait tiquer et me semble symptomatique des réactions épidermiques concernant Gnome 3, qui sont pour beaucoup, injustifiées.

Le site OMG! Ubuntu! a récemment fait un billet pour présenter les changements à venir dans Nautilus, ceux qui sont mentionnés dans le billet de William Jon McCann cité dans la dépêche.

Ce billet présentait les changements avec une description plus ou moins détaillée et la sacro-sainte capture d'écran de l'application concernée, ici, Nautilus. Et bien entendu, les devs se concentrant sur les fonctionnalités, ils n'ont que peu prêté attention au design graphique. De même pour Canonical qui n'a pas encore intégré ce nouveau Nautilus dans sa charte graphique (et apparemment ils ne veulent pas le faire, mais ce n'est pas l'objet ici).

2 choses me choquent dans cette affaire :
- le site OMG! Ubuntu! qui titre "New look Nautilus…" alors que le look n'est bien sur pas (encore) le sujet en version alpha,
- tous les commentaires du billet dont beaucoup disent, en substance : "c'est moche, je vais changer de crêmerie".

Et tout ça, sans que personne parmi les intervenants ne semble prendre un peu de recul pour dire : "ok, c'est une version alpha, laissons les devs et graphistes bosser, on verra à la sortie officielle".

Voilà, Gnome me semble actuellement la paroisse sur laquelle il est bon de taper, comme KDE en son temps j'imagine.

Bonjour,
Merci tout d'abord à l'équipe Gnome, car je suis un grand fan de leur boulot, personnellement j'adore Gnome 3.

Et merci à l'auteur de cette dépêche qui m'a fait me sentir célèbre avec la reprise de mes commentaires par Taryn Fox !

Et oui, je maintiens, développer pour Gnome c'est bien si on baigne déjà dedans, sinon, quelle galère !

Bonjour,
J'ai fait parti des, rares, qui ont acheté feu BeOS 5 Pro en son temps. C'est vrai que ça marchait du tonnerre. Pour les curieux, je suggère simplement d'aller sur YouTube et de chercher BeOS pour voir les vieilles vidéos de l'époque. Même aujourd'hui, je ne suis pas sur qu'on ait des OS aussi rapides.

Maintenant, l'eau a coulé sous les ponts depuis BeOS, et l'ergonomie se standardise plutôt plus que moins. Regardons simplement les évolutions Windows, OSX, Unity ou Gnome pour voir que les grands principes ergonomiques sont posés et commun à tous. Citons par exemple, les navigateur de fichiers, panneaux de conf, barre de tâches/dock.

Qu'on le veuille ou non ces principes sont là, et massivement adoptés. C'est surement pourquoi j'arrive à migrer des gens sur Ubuntu qui ne connaissent presque rien à l'informatique.

Alors même si je trouve le principe de Haiku sympatique, j'ai quand même de gros doutes concernant son succès, une parce que ça fait 10 ans que l'initiative a commencé et que les progrès sont lents quand ils sont rapides par ailleurs ; et de deux, pour le souci de l'ergonomie vraiment différente de BeOS/Haiku. Sans compter que du temps où je l'utilisais, naviguer dans une arborescence avec une cascade de 10 menus droits, j'ai jamais trouvé ça efficace.

Espérons qu'il en sorte du bon quand même.

Oups oui, bien vu, merci.

Perso c'est bien le mode miroir (RAID1, donc, je corrige) qui m'intéresse le plus. Mais l'autre est intéressant pour ceux qui veulent avec un max de place...gratos.

Finalement, si tu crées un compte sur toutes ces plateformes, tu as à ta disposition une place non négligeable...si tu arrives à agréger. Après, on peut faire pareil sans agréger, et c'est effectivement plus sur pour les données, mais un outil qui te fait ça tout seul, rend les choses plus faciles , il l bosse pour toi.

Bonjour,
J'ai été en contact par mail avec le codeur de Syncany car j'attends depuis longtemps un truc comme ça, et j'avais quelques fonctionnalités à lui suggérer, à priori, il avait lui aussi les mêmes idées, ça tombe bien.

Syncany va donc prochainement, si tout va bien, implémenter une sorte de fonction RAID, qui pourrait être proposée selon 2 principes :
- type RAID0, ou miroir, là, on pourra déclarer des dossiers à gérer en miroir et leur contenus sera donc dupliqué sur les différents Cloud spécifiés, c'est la solution "sécurité maximum",
- type RAID1, ou agrégation, là c'est la solution "espace maximum", où là, on pourra agréger les différents Cloud pour avoir un seul grand espace, unifié, de stockage.

Voili.

...qu'on le veuille ou non tous les OS actuels ont adoptés un paradigme de navigation similaire : un liste ou un arbre à gauche, le contenu du dossier sélectionné à droite.

Quan j'utilisais BeOS, j'étais déjà perturbé par cette navigation tout au clic droit, je ne suis pas sur qu'un OS qui s'éloigne à ce point du paradigme, qui fait quand même consensus, rencontre un vif succès.

Cela dit ce n'est qu'une appli à coder pour adopter les mêmes "us et coutumes".

Disons qu'en matière d'ergonomie c'est assez proche, l'interface de traitement de Lightrooom et RawTherapee sont assez similaires.

En matières de fonctionnalités, il manque a RawTherapee la retouche locale, introduite par Lightzone et maintenant disponibles sur Bibble 5 et Lightroom 2.

A noter que cette fonctionnalités avait été annoncée par le développeur de RawTherapee pour la version 3.

C'est pas un retour de 10 ans en arrière, c'est encore la seule solution aujourd'hui pour avoir une appli qui s'intègre parfaitement dans l'environnement sur lequel elle s'exécute.

Je connaissais pas aTunes, merci pour le lien.

Et puis j'ai triché, je connais une excellente appli dont la GUI est en Swing, Lightzone (la seule appli que j'ai achetée pour Linux) :
http://www.lightcrafts.com/products/

Je reconnais volontiers qu'on peut faire des GUI valables avec Java, mais on se refait pas, je préfère Mono sur mon Linux.

Tu me montres une vraie appli avec une vraie GUI écrite en Java et je change mon opinion au sujet de Java sur le poste de travail.

Attention : "vraie appli" = PAS un IDE (ce serait trop facile).

Je ne pense pas (avis perso) que le but de .Net soit de concurrencer Java. Pour une simple raison : la vision stratégique de Microsoft avec .Net va bien au délà de la simple exécution d'un programme avec un VM.

.Net pour Microsoft, c'est (ou ce sera bientôt) :
- un moyen de rénover complètement l'API Win32
- d'avoir un shell object excellentissime (Powershell pour ceux qui connaissent pas),
- de permettre l'intégration fusionnelle des applis écrites en C# v3 avec les bases de données SQL Server via LINQ,

--> Bref un truc très large et qui embrasse tout l'univers Microsoft et qui va déboucher prochainement sur...un OS .Net (donc nous voyons les prémices avec Singularity, et dont les recherches se poursuivent avec Midori).

Après ça leur permet effectivement de concurrencer Java sur les sites web, mais aussi Flash avec Silverlight.

J'ai pas d'actions chez MS pour info.

Moi aussi j'utilise un truc dans le genre "xcalib" :
- faut récupérer les sources,
- faut recompiler,
- faut que le driver graphique supporte la chose
- dès qu'on modifie un truc dans le Xorg.conf, faut le redémarrer.

Bref c'est l'âge de pierre des interfaces, désolé.

Mais ta remarque "c'est de ne pas être obligé d'installer et d'utiliser un environnement graphique" est très juste et je ne serais pas vraiment surpris que le problème vienne de là : on veut tout faire faire à Linux, du serveur sans interface au poste de travail et fatalement, on se retrouve donc sur le plus petit dénominateur commun à toutes ces utilisations.

Non je n'ai rien calculé.

Bien évidemment ma remarque ne compte que dans une optique "Linux sur le poste de travail de tout un chacun", et dans cette optique, ça me fait un peu l'impression d'utiliser un bazooka pour écraser une mouche le serveur X.

Idée excellente que cette dépêche car je vais enfin pouvoir poser la question qui me taraude depuis que j'uilise Linux (3 ans).

Est ce que vraiment faire une image de ce qui doit être affiché et l'envoyer via un socket sur un serveur qui lui va l'envoyer à la CG n'est pas un peu obsolète aujourd'hui ?

Il me semble, merci de me corriger si je me trompe, que cela a été pensé il y a bien longtemps du temps des terminaux déportés.

Ne gagnerait on pas énormément en performances et en ressources en faisant ce que font Windows et Mac : une couche graphique au plus près du matériel ?

J'ai osé poster cette idée sur le "brainstorm" Ubuntu, autant dire que je me suis fait pourrir par les intégristes Unixiens de tout poils. Mais je persiste, sans compter tous les aspects où Linux est en retard (gestion à chaud des changements de paramètres, gestion des profils couleurs...).