Nicolas Roard a écrit 1135 commentaires

\o/ yean sur linuxfr !

.. bon ceci dit, trop de café, pas bon ! (nico qui s'est mis un peu au thé ;-)

Enfin si c'est *juste* les couleurs, on peut les changer directement à partir du panneau de Preferences hein ! :-)

http://www.nongnu.org/backbone/images/screenshots/preferences-4.png(...)

inclu sur le cd ...

oui, pour les couleurs, je bosse dessus (sisi promis), et je compte releaser d'ici le fosdem (juré craché !) Camaelon 2 tout beau tout propre. Un screenshot du thème de base : http://www.roard.com/screenshots/screenshot_theme44.png(...)

une préversion de Camaelon 2 est sur http://www.roard.com/gnustep/,(...) mais 1) il faut le cvs gnustep (un bug dans le clipping a été corrigé hier) 2) le code est un peu bordélique 3) libérer la mémoire du cache graphique ? késako ? :-)

Donc me reste à finir ça, nettoyer le code et releaser le tout. Espérons pour la semaine prochaine, au pire avant le fosdem de toute façon.

Mais bon vala, ça bouge quoi, maintenant que j'ai pris un peu le temps de bosser dessus..

Heuuuuu oui les articles.. j'ai 2-3 idées, mais c'est le temps qui me manque..

Hm, mais pourquoi absolument le dock ? tu peux très bien utiliser tes applis GNUstep sans dock..

Bon certes un dock c'est sympa, on est d'accord, mais c'est pas indispensable. Tiens sinon j'ai entendu dire que sous xfce ça marche très bien aussi, mais pas testé..

Ben, tu vas dans l'éditeur de classe, tu clique sur ta NSView, et tu l'instancie... elle apparaitra dans le panneau des instances.. C'est ce que tu veux ?

greg a pas encore gêré le simple drag'n drop d'une vue (de la même façon qu'on dnd une fenêtre ou un nspanel), mais l'instanciation direct marche.

oops m'a trompé, la vidéo en real media c'est celle-ci :
http://www.openstep.se/next/videos/nextstep256.rm(...)

C'est plutôt proche de InterfaceBuilder que de XCode hein :-P
(InterfaceBuilder c'est le programme sous mac out tu crée .. ton interface, XCode c'est le gestionnaire de projet/éditeur de code).

Gorm est un équivalent à InterfaceBuilder, en effet, et est assez proche (de la même façon que ProjectCenter est assez proche de ProjectBuilder, le prédécesseur de XCode).

Sinon oui, bien sûr qu'InterfaceBuilder existait sur NeXTSTEP !! c'était même un peu un des gros intérêts hein !

IB a été le premier constructeur graphique d'interface, et on a pas fait mieux depuis, d'ailleurs ^_^

Il a été créé par un français, Jean-Marie Hullot:
http://www.levenez.com/NeXTSTEP/Personnes.html(...)

les applis de dev sous NeXTSTEP: http://www.levenez.com/NeXTSTEP/Apps.html(...)

un screenshot d'IB sur NeXT: http://www.levenez.com/NeXTSTEP/InterfaceBuilder.jpg(...)
deux exemples de prog avec IB : http://www.levenez.com/NeXTSTEP/IB_ex2.html(...)
et http://www.levenez.com/NeXTSTEP/IB_ex1.html(...)

Enfin une vidéo RealMedia montrant la prog sous NeXT, à voir:
http://stupid.metalgear.org/NS_beta_Promo_vid.mp4(...)

À noter que toutes ces démos sont facilement réalisables avec GNUstep !

Vi, je vois mieux -- ça a l'air d'être assez semblable à Visual Basic (ou l'inverse, VB est semblable à Delphi ;-)

Mais bon, ça ne marche bien comme approche que pour des interfaces classiques textfields/boutons.. (ce qui est quand même pratique, y'a tout un tas de softs qui n'ont pas besoin de plus)

exemple: http://www.roard.com/screenshots/screenshot_visuslices.png(...)

l'histogramme, la visu en coupe et la vue 3D sont des custom views, mais tout est gêré/connecté dans Gorm.. par exemple j'ai une instance de la classe Volume (oui, c'est de la visualisation volumétrique) dans mon Gorm, et chaque vue l'utilise (même principel pour la gestion des matériaux). Quand je bouge le slider sur la vue en coupe, ça envoie un message directement à la custom view, etc.

je trouve que l'approche Gorm est beaucoup plus générique..

vi tu as raison, gflashplayer est le lecteur non-libre fourni par Macromedia !
je remets pas la main sur le projet que j'avais vu, il s'agissait d'un player autonome de fichiers flash, fait avec GNOME.

On pourrait faire un player basé sur http://www.swift-tools.net/Flash/(...) ou http://www.schleef.org/swfdec/(...) (et avec Ming pour la génération, on fait un éditeur simple orienté "films fait en flash" ;-) -- sans rire ce serait rudement pratique. Un volontaire dans la salle ? :-)

Sinon ben il me semble que swf lui même est ouvert, mais que par contre les outils de créations flash de macromedia sont bien évidemment propriétaire.. mais rien n'empêche d'utiliser des outils libres.

Je sais pas si c'est autant inadapté que ça fait -- parce que beaucoup de gens ont flash, et accessoirement, ça prends pas tant de place (pour ma démo, grosso modo 1mo/min ! pour du 800x600 c'est pas mal..).

Bon enfin, on pourrait avoir les deux hein ;-) (lecture vidéo ET flash ;-)

oui, mais faire la même présentation avec VisualBasic prends aussi moins de temps...
(ceci dit, les lignes de guide pour le positionnement, ça rulez! de même que la gestion du redimensionnement, pas montré dans la démo, mais qui est bien différente des gestions habituelles)

La différence c'est qu'ici, j'ai un objet controleur/modèle qui est clairement découplé de mes objets graphiques (ie la logique métier est séparée), ce qui d'ailleurs a un avantage immédiat par exemple pour gêrer correctement l'internationalisation (ie, on peut au besoin faire des gui différentes pour accomoder les différentes langues).

L'autre énorme différence, c'est que je manipule directement les objets (j'ai créé directement une classe MyController dans Gorm, je l'instancie, et je link cet objet à mes autres objets, ici des NSTextfields et je link l'action du NSButton sur mon controleur). Tout le code gêrant ça (que j'aurait pu éventuellement taper) est supprimé.

Un fichier .gorm est en fait juste la sérialisation du graph d'objets... donc quand tu charge un fichier .gorm, ça désérialize tous tes objets (= remets les valeurs qui étaient positionnées) et réétablit toutes les connections entre objets (entre parenthèse, on est pas limité à un fichier .gorm par application hein..). Toujours ça de moins à coder. L'autre truc cool, c'est que tu n'est absolument pas limité aux objets "standard" fournis par GNUstep -- la preuve ici j'utilise bien un objet de la classe "MyController". Faire tes propres widgets et te créer une palette d'objet personalisé (avec inspecteurs et tout) est pas bien compliqué.. et ce peux aussi être des objets non-graphique, comme MyController...

Par exemple dans une appli que j'ai créé récemment pour le boulot, j'ai codé mes classes normalement, mais au lieu de créer mes instances à la main et de gêrer tout le truc, j'ai créé mes instances et gêré toutes les relations directement dans Gorm. Ben c'est clairement pratique et plus souple :-)

Sous OSX, ils ont par exemple introduits une classe très cool, NSController. En gros dans le design pattern Modèle-Vue-Controleur, tu sépares en trois objets: un objet modèle (logique métier), un objet vue (interface graphique, ie, ce que Gorm permet de créer très simplement) et un objet controleur, qui fait la "glue" entre la vue et le modèle (vu que très souvent cette glue est simple et donc un peu rébarbative à coder). Ben NSController est dispo dans une palette d'InterfaceBuilder (Gorm est la même chose qu'IB), et tu instancie ton controleur, etc.

Dans mon exemple le controleur et le modèle ne font qu'un, parce que l'exemple est trivial. L'intérêt par contre, et contrairement aux approches à la visual basic, c'est que cette approche monte très bien en charge (c'est à dire que faire une interface graphique complexe est beaucoup plus pratique de cette façon que quand ton code mélanges tout).

Bref. Gorm (ou IB) ne sont pas "juste" des constructeurs d'interface graphique. Fondamentalement, ils sont plutôt des modeleurs de relations inter-objets... ce qui a un tas de répercussions intéressantes.

Bon maintenant, je répète que je connais pas vraiment Delphi, et il est fort probable que Delphi apporte des trucs très sympas aussi (j'en ai entendu du bien..)..

Heu oui, mais GNUstep est multi-plateforme, et tourne sous linux, bsd, solaris, windows et mac...

bon ok le backend graphique windows est un peu alpha, mais ça tourne quand même hein :-P http://www.roard.com/screenshots/gnustep-windows.png(...)

et bon.. sous Mac, GNUstep tourne avec X11, bien sûr, mais tu peux aussi directement recompiler ton application GNUstep sous Cocoa, vu que Cocoa et GNUstep sont deux implémentations de la même API (OpenStep).

Par contre, est-ce que tu pourrait expliquer en quoi Gorm est moins fonctionnel et moins avancé ? connaissant très bien OpenStep/Cocoa et bien évidemment GNUstep, je vois pas trop comment on peut dire que c'est moins fonctionnel et moins puissant (en toute honnêteté c'est ce que j'ai vu de mieux au niveau archi), mais comme justement je ne connais pas bien Delphi.. j'ai ptet loupé un gros truc.

Bref, s'il y a quelque chose qui manque, ça peut s'implémenter :-) et du coup ça m'intéresse !! mici :-)

ah heu et qui c'est au fait ? :-) (et oui je sais pas comment ils font les étudiants maintenant s'ils ont plus carcou au programme !)

ben idéalement, tu pourrait utiliser ObjC comme "langage glue" pour faire des composants haut-niveau, et garder ton backend en C++ (ce qui suivant les cas est une bonne idée, C++ est pratique pour du code optimisé, alors qu'ObjC est idéal pour programmer objet, avoir différents composants qui discutent entre eux, et entre autre pour faire une GUI).

Maintenant, faudrait que gcc inclue le bridge ObjC/C++, ce qui faciliterait les choses (vu que ça permet de mixer du code ObjC et C++ dans le même source), mais à priori ça va pas passer pour gcc 4.0 (il y a des chances qu'il y soit, mais il y a de fortes chances qu'il ne soit pas vraiment fonctionnel.. enfin.. on verra.. au pire pour gcc 4.1).

C'est clair que ça pourrait servir à faire des tutoriaux animés !

faire un player de fichiers flashs basique permettant de lire ce genre de démo ne devrait pas être bien trop compliqué (d'autant qu'il y a déja un projet gnome qui le fait, il me semble, gflashplayer ou un nom similaire).

Sinon, oui, on pourrait imaginer un backend qui fasse ça, si tu te sens ;-)
(y'a quelqu'un qui voulait bosser sur un backend qui enregistrerait tous les évèvement NSEvent et les rejoueraient.. mais bon.. dans ce cas ça ne marcherait que pour une seul appli..)

Mais bon, j'aimerais bien inclure la possibilité d'avoir du flash dans l'aide en ligne, je pense que ça serait très sympa ! (hmm on pourrait aussi simplement générer une floppée d'image, et faire un format bateau qui rejoue ça, ou directement utiliser de la vidéo..)

Vi c'est clair, l'intérêt de Gorm est que comme on bosse réellement sur les objets, on peut facilement se créer ses propres palettes d'objets réutilisables (pas nécessairement des objets graphiques d'ailleurs). Enfin..

[ben sinon ma thèse avance, oui ;-) ... hm.. d'ailleurs j'utilise GNUstep, ça me fait gagner un temps fou ;-) ]

De rien sylvain :-) [comment ça va d'ailleurs ? la thèse avance ?]

Et encore, attends que le EOF builder soit releasé, ça sera super sympa pour faire une appli lié à une base de donnée ! -- d'autant que là, on verra d'autant mieux l'avantage que peut avoir GNUstep et l'utilisation du design pattern MVC: tu fait ta base, tu branche une appli graphique par dessus, et tu réutilise tes objets pour faire un frontend web avec GNUstepWeb...

EOF est un framework permettant le mapping objet/relationnel, de façon assez intelligente... GNUstep l'implémente avec GDL2 (GNUstep Database Library 2..), mais faut se taper le fichier de mapping à la main (ou le faire de façon programmé, comme dans l'article de ludovic: http://sophos.ca/~ludovic/lj_article_apr_04/article.html(...) )

une appli graphique pour facilement mapper tes objets sur ta base faciliterait bien les choses -- et justement y'a un gus qui est en train de bosser dessus. Mais bon... pas sorti encore :-/

Enfin, ça progresse quoi...

ben des thèmes, oui et non..

le look de GNUstep est modifiable facilement maintenant... *pour un programmeur*. Faire un thème "programmé" est assez simple.

Maintenant, il n'y a pas de thème manager au sens KDE/GNOME.

Enfin. C'est pas tout à fait vrai -- il y en a un, Camaelon 2, qui fait exactement ça, et qui fonctionne avec des pixmaps. Un exemple: http://www.roard.com/screenshots/screenshot_theme41.png(...)

\begin{mea_culpa}
Mais, ce n'est toujours pas releasé. Et c'est ma faute, vu que c'est moi qui le développe, mais que le temps libre, c'est pas trop ça, et qu'en plus les thèmes c'est pas ce que je préfère à coder (surtout que moi, le thème NeXTSTEP de base, j'aime bien !!). Mais bon, vu l'état actuel de Camaelon, je vais essayer de me motiver pour sortir ça très rapidement, car il manque vraiment pas grand chose. Normalement avant le Fosdem au plus tard...
\end{mea_culpa}

(oui oui je sais ça fait au moins un an que je dit que je vais le sortir très bientôt tout de suite... mais hein..)

Quand on connaît MetaFont, c'est loin d'être idiot :-)

Certains font des choses admirables avec MetaFont/MetaPost:

http://www-math.univ-poitiers.fr/~phan/m3Dplain.html(...)
http://melusine.eu.org/syracuse/metapost/(...)
http://www-math.univ-poitiers.fr/~phan/metapost.html(...)

Le choix des thèmes qui s'intègre ne résoud que le problème d'intégration visuelle, pas d'ergonomie.

Les thèmes, non. Les fichiers interface, oui. Comme expliqué précédemment, les fichiers "interface" sont bien plus que la description visuelle de l'UI, et tout ça est fait à partir de Gorm, ce qui est quand même vachement pratique. Ce que je n'ai pas (ré)expliqué, c'est que tu peux avoir un fichier d'interface *par* language -- ce qui permet de justement faire mieux coller l'UI aux spécificités d'un language (par exemple, le fait que le français ait des mots généralement plus longs que l'anglais...) -- un programme GNUstep étant organisé dans un répertoire (un "bundle") contenant, en plus du (ou des) binaires, les ressources utilisées par le programme.

À terme, pour l'intégration KDE/GNOME/Windows/etc., on devrait étendre ce mécanisme. Du coup, tu auras d'un côté un thème, pour avoir "l'intégration visuelle" dont tu parle, et tu pourras avoir un autre fichier UI pour résoudre le problème d'ergonomie.

Effectivement, pour le moment, ce n'est pas encore possible -- mais ça en soit ce n'est pas foncièrement difficile à faire (comme je l'ai dit.. c'est déja le cas pour les langages) maintenant qu'on a un GNUstep qui commence à bien tourner.

GNUstep n'est pas la solution ultime qui enlarge ton penis, mais y'a très clairement des possibilitées très intéressantes. Maintenant, personne ne t'oblige à y jeter un coup d'oeil.

Vi, je pense pas que les modifs a faire soient vraiment importantes, et le programme n'est pas tres gros. C'est juste que j'ai pas le temps de le faire ... (deja trop de choses en cours, pfiou..)

Oui, c'est surement une possibilite -- mais pas pour Lynkeos. Il ne se sert de Quicktime que comme "conteneur" de plusieurs images...
par contre pour un programme qui veut rapidement integrer une video, ca doit etre faisable.

Tant que j'y suis, et comme j'ai une machine pour 2-3 jours sur mon bureau avec windows, du coup j'ai teste (ben oui ca fait un bail que j'ai pas approche une machine windows de pres ;-) -- c'est pas dramatiquement complique a installer (m'enfin on cracherait pas sur un installeur tout fait, c'est clair), et les applis gnustep tournent pas trop mal (honnetement, d'apres ce que j'avais lu sur l'etat du backend window la derniere fois que je m'y etait un peu penche, je m'attendait a pire.. bon faut dire ca remonte a longtemps :-P).

J'ai rapidement compile deux-trois applis, voici un screenshot pour ceux que ca interesse: http://www.roard.com/screenshots/gnustep-windows.png(...) -- les applis detonnent pas tant que ca (ok, apres un tour dans Preferences.app pour changer les couleurs, j'avoue :-) -- et faire un theme XP ne devrait pas poser de problemes..)

Bon par contre le backend GDI il est pas encore au niveau de backart, hein...

En regardant un peu plus, .. ca marche pas chez moi :-/

Et comme Lynkeos utilise NSMovie (un fontend Cocoa pour quicktime) un peu partout (c'est a dire que son "unite de travail" ce sont des films, en fait...), ben c'est chiant. En y allant a la hache, ca compile, m'enfin, ca fait plus grand chose :)
Avec une separation plus claire Quicktime/non Quicktime, ou en ajoutant une classe d'abstraction, on doit pouvoir l'utiliser sans trop de problemes sous linux (d'autant qu'il utilise pas franchement des capacitees fabuleuses de quictime: il utilise juste le fait de traiter une serie d'image comme un film) mais en l'etat, c'est un chouilla plus de boulot que de recompiler, vu qu'il faut modifier l'architecture du programme pour faire ca proprement... et j'ai pas trop le temps :) (d'autant que je vois que vaguement a quoi sert le programme :)
M'enfin s'il y a un courageux, ou si vous arrivez a convaincre les auteurs de faire une version "sans quicktime" .. c'est toujours le probleme quand on utilise un truc proprio :-/

Hé, mais ça a l'air d'être ça en plus ! (en tout cas y'a un quicktime.h ;-)
Très intéressant ! m'en vais tester tout ça :-)
Espérons qu'ils ont implémentés les fonctions utilisées par lynkeos..
Merci!