Nicolas Roard a écrit 1135 commentaires

bheu... rien, je suis tombé sur l'article aujourd'hui sur libé et j'ai écrit ce mail, et t'en qu'à faire j'ai voulu le poster en journal... j'ai juste vérifié les journaux, et la dépêche m'a échappé. Mea culpa.

ah zut quoi, un peu de retenue quand même ! on se croirait sur /. :-D

pour rester dans le folklore donc, voici la réfutation: http://www.snopes.com/quotes/internet.asp

Et à titre d'information.. c'est quoi un "port natif" sous linux ? Xaw ? motif ? Qt ? Gtk ? Fox ? GNUstep ? SDL ? Wine ?

Wine, c'est juste un toolkit qui fonctionne sous X11 comme un autre... pas moins natif que Qt.

Certes, l'informatique permet bien plus facilement d'expérimenter des choses rigolotes qu'en math et en physique. Mais... informatique et math, ou informatique et physique, ne sont pas antinomiques ! pourquoi est-ce qu'on ne se servirait pas de l'informatique comme support de cours, eg simulations, etc. ? D'ailleurs, on le fait :-)

Pas autant que l'on pourrait, c'est vrai; on est encore loin du manuel d'éducation illustré pour jeunes filles, malheureusement.. et loin également du "pays des maths" de Seymour Papert et des efforts d'Alan Kay...

M'enfin il y a quand même un tas de trucs à faire _avec_ l'ordinateur comme outil d'expérimentation, dès aujourd'hui -- il y a des projets géniaux fait avec Squeak, Logo, etc.

Espérons que des choses comme le laptop à 100$ iront vers cette voie...

Ah ben si Linux dérive de Minix, hein, faudra ptet prévenir et Linus, et Andy Tanenbaum hein.. parce que je pense pas qu'ils soient au courant ! :-)

Linux n'est PAS dérivé de Minix en tant que tel (parce que sinon faudrait me dire ou sont passés les fonctionnalitées uK); et Minix n'est pas vraiment dérivé de Unix v7 non plus...

Minix a juste été utilisé comme environnement de dev, en gros...

Les liens du graph d'Éric Lévenez sont parfois un peu imprécis et tiennent plus de relations circonstancielles/inspiration que de filiation directe...

Par contre, le système des ports pour installer les logiciels est assez fastidieux et il me manquait un certain nombre de logiciels. On va me dire qu'il y a la couche de compatibilité Linux pour ça, mais c'est l'enfer avec les librairies à gérer.

Ben avec pkg_add -r ... franchement ca fait pareil qu'apt (bon je trouve apt un peu mieux quand meme, mais honnetement c'est correct).

Autre constatation, le système était bien plus gourmand en mémoire et plus lent qu'une Debian, sur un vieux Duron 1000 MHz / 733 Mo RAM.

Alors la c'est marrant parce que c'est exactement l'inverse de ma situation :)
En ce moment j'utilise un vieux portable toshiba, celeron 1ghz, 128 mb de ram...

Ubuntu etait lent avec (evidemment en collant wmaker/gnustep, j'ai pas laisse gnome), alors que FreeBSD me semble bien plus reactif ! (et encore plus avec le scheduler ule, meme si ce scheduler a des inconvenients pour d'autres utilisations).

Certes j'ai pas installe une debian brut de fonderie pour comparer, mais bon...

Et puis finalement j'aime beaucoup les *BSD niveau systeme... (sans parler de la doc.)

Ouaip, ben l'idée elle est faite hein. C'est du "ooooh les méchants communistes ils auraient ruinés à feu et à sang le chili", et pinochet était (sic) "un brave type". Même pas coupable hein, c'est vrai quoi, c'est pas sa faute au gentil pinochet si ses troupes ont torturés, il savait pas, non non, il est tout juste "responsable" mais hein si on regarde tout au fond, lui, physiquement, personnellement, il a tué quelqu'un pinochet ? ah ben on sait pas, mais vous voyez, au fond, c'est un brave gars qui c'est fait dépasser par son armée !

C'est marrant, ça me donne physiquement envie de gerber. Je pense à umberto, un ami de ma copine, un poète, qui est parti en exil au royaume-uni après avoir été torturé...

Nan mais c'est sûr, d'après FR Rideau, le salaud, c'est pas pinochet, non non, c'est umberto, qui en toute probabilité était d'après lui un commissaire politique, immonde communiste avide de sang. Au mieux, umberto est juste un "idiot utile". Ben tient. Pauvre con va.

Mais qu'il aille se faire voir ce pauvre type, moi je vais allez vomir de mon côté.

Note: Comment peut on vouloir justifier des horreurs (pinochet) par d'autres horreurs (stalinisme et autres khmer rouges) ... et après ça parle de relativisme moral... pfff..

On est pas dans un modèle théorique de jeu à somme nulle, on peut très bien condamner les deux. À trop idéaliser le libéralisme (économique) hein...

Complètement d'accord... une interface 3D a vraiment du sens (ou en aura) quand on aura des périphériques d'entrées/sorties qui exploitent vraiment la 3D (il y a d'ailleurs des travaux assez rigolo en allemagne avec un mix d'écran lenticulaires + 3D + caméras + tracking... mais bon on est loin de trouver ça partout ^_^)... mais d'ici là... une interface 2D (ou plus exactement 2D 1/2) est bien plus intéressante -- et en 2D 1/2 il y a des choses à faire (exposé par exemple est un exemple récent très pratique).

Dans les IHM rigolotes (mais potentiellement très intéressantes) y'a aussi tout ce qui est "tableau magiques" ou "ui" virtuelles (lcd avec numérisateur, multiples points de contacts, etc. qqs exemples ici: http://fredevric.free.fr/de-VRic/touchy/) ...

Enfin pour revenir sur Croquet, ce qui est vraiment intéressant ce sont les fonctionnalitées de répartition/synchronisation/découvertes...par contre l'interface est vraiment pas terrible :-)
(et pas très intuitive)... mais bon c'est la 1.0 ;-)

Oui, GNUstep avance, tranquillement... ceci dit, 30 développeurs GNUstep ... oui, plus ou moins; mais quand j'ai dit ça au fosdem (je subodore que ce chiffre vient de là, me trompes-je ?), après coup j'ai réalisé que je m'était vraiment mal exprimé (le fameux esprit d'escalier!) -- je ne voulais pas dire qu'il y a 30 devs qui bossent sur le repository gnustep aujourd'hui, mais plutôt donner un ordre d'idée de la "communauté gnustep", eg combien de devs plus ou moins actifs...

Malheureusement, tous ne travaillent pas sur les frameworks eux-mêmes.. et en plus, pour ceux qui bossent dessus, on est loin d'avoir tout le monde committant en coeur tous les soirs ;-) (dommage !)

Si c'était le cas, punaise, ça ferait longtemps que tout serait nickel :D

Sur gnustep -core lui même, il y a plutôt un coeur de 4-6 développeurs assez réguliers, mais c'est tout... (et encore, -gui est le mal aimé). Après il y a des gens qui participent plus épisodiquements, puis d'autres qui bossent sur des applis, etc.

Je sais pas pour Gtk, mais à mon avis il y a un tout petit peu plus de monde qui bosse sur Qt que sur GNUstep ;-)

pour la compilation, sourcer GNUstep.sh est (encore) nécessaire, mais pour l'exécution normalement non... en tout cas avec une version récente de gnustep.

Quand au look, ben hein.. faut voir avec camaelon non ? au pire, utiliser preferences.app pour virer le gris sombre par un gris plus léger :)

'fin bon.

J'ai aussi commencé à mettre en ligne les vidéos des talks GNUstep ayant eu lieu au fosdem:
http://www.xdev.org/fosdem2006 , pour ceux que ça intéresse...

y'a pas tout encore, mais pour le reste y'a au moins les slides. :-)

Comme rapidement dit dans l'interview, pas assez de personnes impliqués (3), pas vraiment de choses committés non plus en dehors des commits initiaux de preferences.app, terminal.app et textedit.app, et ça s'est combiné je pense avec un manque de temps de la part de tout le monde :-/ -- sans davantage de contributeurs et sans contributions, un projet libre se meurt tout doucement..

donc au final... je suis pas très convaincu que ça avance plus loin que ce qu'il y a sur le cvs actuel, même si je pense que jeff y bosse de temps en temps.. d'autant qu'une partie de trucs que personnellement je voulait à l'origine committer dans backbone se retrouve ou se retrouvera dans étoilé (camaelon, helpviewer, panel, etc). Étoilé est plus "ouvert" comme projet -- aussi bien aux idées qu'aux personnes -- et ça explique je pense que plus de personnes s'y intéressent et y participe, et que les commits soient largement plus réguliers :)

Dommage car un projet comme backbone pour un bureau très proche du bureau NeXT est une bonne idée, même si je pense qu'on obtiendra un truc très sympa avec étoilé aussi :-) -- et j'espère même "mieux".

Et puis il faut avouer aussi qu'à l'heure actuelle, en utilisant simplement GWorkspace + WindowMaker + autres applis utilisant gnustep (gnumail, terminal.app, ink ou textedit, cenon, etc..), on a *déjà* quelque chose de relativement proche d'un bureau NeXT sans plus d'efforts que ça, donc..

voila voila..

Ben oui, ce qu'on veut obtenir c'est un "bureau" quoi. Mais pas vraiment dans le même esprit que KDE/GNOME. L'idée générale c'est d'être fortement orienté composants / petites applis spécialisées qui coopèrent entre elles, pas d'usine à gaz. Plus du côté OpenDoc que Windows quoi. Et à côté de ça on a plusieurs idées concernant la gestion des fichiers / objets, l'UI, etc. Entre autre, considérer un "projet" comme un objet de premier niveau; idem pour les contacts (mail, jabber..), etc.

Pour le moment on a pas vraiment d'applications côté utilisateur (on s'est focalisé d'abord sur l'écriture des bibliothèques nécessaires et autres plugins), donc faut attendre un peu avant de tester, à moins d'être programmeur (là y'a déja de quoi s'amuser dans le repository).

Normalement une 0.1 contenant les frameworks est prévu pour très bientôt, et une 0.2 qui devrait contenir quelques applis utilisateurs est plus ou moins prévu pour fin février (fosdem).

Les trucs à implémenter sont pour la plupart du genre "dessine un bouton", "dessine le cadre d'une NSBox", etc. En gros tu reçoit une zone rectangulaire et la vue qui s'y rapporte, et à toi de dessiner dedans. Donc rien de bien difficile, et j'imagine que ça doit pas être trop compliqué de créer un thème utilisant Gtk (au pire en créant une image via Gtk et en composant cette image), mais bon en même temps je connais pas bien Gtk, donc faut voir.

ne serait-il pas possible (au moins théoriquement) d'utiliser QT ou GTK pour dessiner les widgets ?

Théoriquement, oui. Mais vu qu'on a déja un moteur de thème (camaelon), ben heu pour le moment je préfère me concentrer dessus hein :-)

Là pour le moment camaelon contient en fait deux parties:

- des categories sur les classes widgets, modifiant le code de façon à ce que toute la partie "dessin" soit effectué par une seule classe, GSDrawFunctions
- un moteur de thème pixmaps utilisant ce mécanisme pour fournir une implémentation de GSDrawFunctions qui utilise des pixmaps pour le dessin des widgets

Ca marche bien, et pas besoin de patcher quoique ce soit (merci objc). Maintenant, ce serait quand même intéressant de basculer la première partie (les modifs des widgets) directement dans le cvs gnustep, histoire que ce soit par défaut et de pas avoir d'éventuels problèmes de synchro entre les deux codes. C'est justement ce que je suis en train de faire en ce moment, et ça devrait être commité rapidement.

Une fois ce refactoring directement intégré dans le cvs, Camaelon ne sera plus qu'une implémentation donnée de GSDrawFunctions; l'implémentation par défaut de GSDrawFunctions étant tout simplement le code actuel du "thème" NeXT.

Bref pour simplifier, ça changera pas grand chose pour Camaelon, ni pour les utilisateurs de Camaelon / les gens qui veulent un thème. Mais par contre ça devrait aider/faciliter si quelqu'un veut faire une implémentation d'un thème autre qu'avec Camaelon. Exemple:

- un "thème" Windows qui utilise l'api de thème de win32, pour GNUstep/Windows, parce que bon ce serait mieux dans l'idéal qu'un thème pixmap fait avec Camaelon
- un thème qui utiliserait le moteur de thème de Gtk ou Qt
- autres thèmes "programmés" (comme le thème actuel NeXT), c'est à dire sans utiliser de pixmaps

voila voila..

Franchement, je suis entièrement d'accord avec toi.. mais bon, le problème c'est qu'il y a peu de devs sur GNUstep, et que donc le dev de GNUstep lui même passe avant le dev d'applis... et les devs qui codent des applis tendent à écrire les applis de base nécessaire pour un bureau (GNUMail, GWorkspace, Zipper, AddressBook, Vindaloo, etc) ou des applis de dev (Gorm, ProjectCenter, DataModeller, etc). Maintenant, c'est sûr que plus il y aura de personnes intéressées, plus il y aura d'applis -- d'autant que les outils de devs sont là pour aider :)

Mais pour le moment ça se mort un peu la queue, oui :-/ -- ceci dit ça ne peut que nécessairement s'améliorer, et ça s'améliore, mais lentement...

Enfin si tu as des idées d'applis géniales à implémenter, n'hésites pas à te lancer hein :-P nous on dit pas non !

Je ne connaît pas de sites regroupant des vidéos tutoriales, mais c'est une bonne idée ! surtout qu'elles sont de plus en plus courantes... (faut dire que c'est _très_ pratique pour pouvoir justement montrer quelque chose..)

Pour l'outil que j'ai utilisé, oui, c'est libre, j'avais écrit un post expliquant ça quand j'avais fait la première vidéo:

http://camaelon.blogspot.com/2005_06_01_camaelon_archive.htm(...)

bon et pour l'accent français ouaip hein n'en rajoutes pas :D je fait ce que je peux ..

si les screenshots et les vidéos utilisaient les-dits thèmes, peut-être que les gens regarderaient d'un autre oeil.

Ben heu.. les vidéos utilisent le thème Nesedah hein, pas le thème NeXT. Par contre sur gnustep.org en effet les sshots n'utilisent que le thème NeXT. Maintenant bon à priori tu n'aimes pas non plus Nesedah, que veut tu que je te dise :D -- Nesedah c'est un thème fait de façon à rester "clean" tout en étant plus "moderne", et apparemment qui plait à beaucoup -- mais évidemment on ne peut plaire à tout le monde..

Apparemment ça reste trop austère pour tes gouts.. j'imagine qu'il faudra des thèmes plus fisher price en effet, même si c'est pas du tout ce qui m'intéresse moi.. :-)
-- reste à trouver des gens pour les faire, ces thèmes..

Sinon, oui, Gorm, c'est en gros IB en libre, même si il y a des différences. Et c'est tout ce que ça te fait ? :)

J'adorerais que gnustep ait le succès qu'il mérite. Simplement, il n'attire pas.

C'est clair que les sshots rebuttent beaucoup de monde.. :-/ même si certains (rares) aiment le thème NeXT, c'est évident que beaucoup se contentent de juger de la qualité de GNUstep en se basant uniquement sur les sshots. C'est dommage, mais assez compréhensible. Ca fait raler vu qu'on dispose pourtant d'un moteur de thème, mais lui aussi sous-utilisé. Enfin bon, les choses progressent (doucement..), on verra bien..

Ben heu oui elles sont thémables avec WindowMaker... mais elles ne sont pas des applets GNUstep hein de toute façon.. WindowMaker != GNUstep

parce que j'ai pas flash parce que çapucépalibre.

Et swfplayer ? chez moi ça marche (linux/ppc) ...

En fait non, on a pas besoin de la version CVS de GNUstep pour avoir les thèmes, on a juste besoin de Camaelon, et c'est tout, pas besoin de patch. Mais la dernière version de Camaelon est en effet sur le cvs d'étoilé (http://www.etoile-project.org)... donc bon.. ceci dit on peut récupérer les tgz des builds journalières...

Maintenant, ce que fait Camaelon est deux choses:
- modifier les widgets pour que leur "dessin" soit géré par une seule classe donnée
- une implémentation de cette classe qui utilise des images pour dessiner les widgets (thèmes pixmaps)

Grâce à Objective-C on a en effet pas besoin que cette modif des widgets soit intégrée à GNUstep, vu qu'on peut remplacer du code à la volée. Cependant, ce serait mieux que ce code soit quand même intégré à GNUstep lui même (histoire de pas avoir à reporter les modifs de GNUstep dans Camaelon par exemple), et ça c'est en cours en ce moment. Même si ça ne changera pas grand chose pour l'utilisateur final :-)

Dans pas longtemps GNUstep arrivera à cela :
http://jesseross.com/clients/gnustep/ui/concepts/

Oui enfin c'est déja possible avec Camaelon, cf:
http://www.roard.com/screenshots/screenshot_ukuug2005.png
(reste 2-3 bricoles peut être à corriger, et par rapport aux dernières "versions" de Nesedah celle ci est trop lumineuse, mais bon..)

C'est le thème Nesedah de Jesse Ross (http://www.roard.com/gnustep/Nesedah.theme.tgz)

En fait si j'essaie de synthétiser... tout l'intérêt de Gorm/IB est que:

- gêrer les relations/attributs dans Gorm/IB permet d'éviter beaucoup de code "de liaison", ce qui permet de se concentrer sur le code "utile"

- ce mécanisme n'est en aucune façon limité à des objets prédéfini, mais marche avec n'importe quel objet (graphique ou non-graphique),
du moment qu'on l'a défini dans Gorm (à la main avec l'éditeur de classes ou en chargeant un .h)

- les palettes fournissent des objets prêts à l'emploi et il est facile de créer ses propres palettes

Plutôt intéressant, mais ça illustre justement les différences entre les deux modèles (Gorm/IB et les autres comme Glade). Par exemple, il n'a pas de palette contenant un objet Gecko, il crée une custom view et l'instancier "à la main". Idem, dans le source ruby il y a plein de code d'init qui serait inutile avec Gorm. Et ça impact aussi les relations entre objets; comme Glade ne "connaît" pas l'objet Gecko, tout ce qu'il peut faire c'est envoyer des signaux à l'application quand les boutons sont cliqués; on doit donc créer des méthodes dans l'appli ruby qui appellent les méthodes correspondantes de l'objet Gecko.

Sous Gorm, aucun code ne serait nécessaire.

La démo "équivalente" à celle ci sous OSX, avec InterfaceBuilder et WebKit, consiste effectivement à dnd les boutons sur une fenêtre, puis dnd l'objet WebKit, puis de linker les actions des boutons à des méthodes de l'objet WebKit. Le tout sans une ligne de code, dans InterfaceBuilder. Et on peut tester le programme sans avoir à le compiler. Une fois WebKit compilé pour GNUstep (ce qui devrait être faisable avec la prochaine release de gcc apportant *enfin!* objc++), aucun problème pour faire la même chose sous Gorm -- c'est exactement le même principe qu'avec la vidéo "custom palette" en lien de l'article.

InterfaceBuilder sous OSX est le descendant direct d'InterfaceBuilder sous NeXT/OpenStep. Je ne suis même pas sûr qu'ils aient modifié grand chose dans leur code source lors du passage OPENSTEP->Cocoa.