• # Geant

    Posté par  (site web personnel) . Évalué à 6.

    Rien d'autre a ajouter.

  • # Look

    Posté par  . Évalué à 5.

    Le seul truc qui me gêne dans GNUStep c'est le look.
    Je sais pas pour vous mais je trouve ça hideux :/
    Y a-t-il des thèmes style Plastik, Lipstik (KDE quoi) ou Industrial (GNOME) ?
    Mais sinon ça a l'air super...

    • [^] # Re: Look

      Posté par  (site web personnel) . Évalué à 5.

      oui, il y a des thèmes... (Nicolas me corrigera si je dis des bétises)

      il suffit de regarder http://www.roard.com/camaelon/(...) où l'on voit la même appli avec un thème différent ;-)

      • [^] # Re: Look

        Posté par  (site web personnel) . Évalué à 10.

        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..)

  • # très belle démo !!

    Posté par  (site web personnel) . Évalué à 4.

    super ta démo de Gorm ! franchement, c'est très attirant !!! ne devoir coder que le minimum pour ce genre d'appli, c'est l'essentiel !

    même un débutant peut faire des applis utiles sans trop de bug relativement facilement !

    en plus, je ne connaissais pas vnc2swf, merci Nicolas !

    • [^] # Re: très belle démo !!

      Posté par  (site web personnel) . Évalué à 5.

      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...

      • [^] # Re: très belle démo !!

        Posté par  (site web personnel) . Évalué à 3.

        trop fort !!!
        et ben, je vois que le projet avance !
        y'a tout plein de nouveautés... [depuis le DEA !]

        en tout cas, je pense que ça devrait intéresser du monde ce genre d'appli ! car je trouve que c'est ce qu'il manque cruellement sous linux... (bien que ça arrive par petit bout maintenant !)

        PS : [ma thèse avance bien... et toi, la tienne ?]

        • [^] # Re: très belle démo !!

          Posté par  (site web personnel) . Évalué à 1.

          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 ;-) ]

  • # Yay!

    Posté par  . Évalué à 5.

    Très bonne idée, ce genre de petite démo. Parfait pour démontrer (normal, pour une démonstration) les atouts de GNUstep, mais ça pourrait aussi bien servir à faire des tutoriaux "animés".

    Seul léger inconvénient, probablement lié à Flash, c'est modérement beau chez moi (ça "bave" étrangement). Si je me souviens bien de l'architecture de GNUstep, il n'y aurait pas moyen d'avoir un backend qui écrirait directement dans un fichier vidéo? Je ne sais pas du tout quelle difficulté ça représente, d'autant que si on veut pouvoir voir quelque-chose il faudrait surement deux backends (celui que je viens de décrire plus un "normal") en parallèle, et je doute que ça soit supporté.

    Enfin c'était juste une idée à la con du vendredi soir ;)

    • [^] # Re: Yay!

      Posté par  (site web personnel) . Évalué à 3.

      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..)

      • [^] # Re: Yay!

        Posté par  . Évalué à 4.

        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).

        Sauf erreur de ma part, gflashplayer est le lecteur non-libre fourni par Macromedia.

        De plus, se cantonner au Flash pour ce genre de choses alors qu'en plus d'être non-libre c'est pas parfaitement adapté (à la base, c'est fait pour du graphisme vectoriel interactif, pas des vidéos), c'est un peu balot. Même sans entrer dans mon délire de backend-encodeur, il suffit théoriquement d'un coup de xvidcap pour avoir le même résultat en vidéo.

        Après, rejouer les vidéos dans le système d'aide ne devrait pas être (trop) compliqué, et ça pourrait apporter un gros plus (à ceux qui ont une bonne bande passante).

        • [^] # Re: Yay!

          Posté par  (site web personnel) . Évalué à 2.

          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 ;-)

  • # Vraiment cool

    Posté par  . Évalué à 5.

    clair que c'est super cool ..

    quand tu vois Qt Designer à coté .. c'est pas vraiment la même chose :)

    j'ai de plus en plus en vie de m'y mettre moi ....

    Mais lacher mon bon vieux C++ arff dur dur :)

    PS : et vive l'iut d'aix même si maintenant feneuille est à la retraite ;(

    • [^] # Re: Vraiment cool

      Posté par  (site web personnel) . Évalué à 3.

      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).

    • [^] # Re: Vraiment cool

      Posté par  . Évalué à 2.

      Je trouve gorm assez proche du Designer de Qt 4... Ou l'inverse :)
      Drag and drop des widgets notamment...
      Mais y'a pas toutes les technos de GNUStep

      • [^] # Re: Vraiment cool

        Posté par  . Évalué à 4.

        Je trouve gorm assez proche du Designer de Qt 4... Ou l'inverse :)

        Plutot l'inverse alors vu que QT4 vient à peine de sortir en beta si je ne m'abuse (enfin ptet que je m'abuse, je ne connait rien à QT) :)
        En tout cas c'est extrement proche de Xcode sur Mac, ce genre d'outils existait-il déjà à l'epoque Nextstep ? Je sais que l'API vient de là, mais est ce que c'etait déjà aussi evolué pour les outils de developpement ?

  • # Mouais...

    Posté par  . Évalué à 5.

    C'est un Delphi en moins puissant/fonctionnel quoi... En tout cas, pour avoir programmé sous Delphi auparavant, je dirais que Gorm cette démonstration de Gorm n'a rien d'exceptionnel. Mais bon, c'est libre, c'est toujours ça :-)

    Sinon, pour ceux qui voudrait programmer avec un Delphi-Like libre sous Linux, je rappelle qu'il y a le projet Lazarus, basé sur FreePascal, qui permet d'avoir l'équivalent d'un Delphi 2 (bon, on est encore loin d'un Delphi 7 sous Windows, c'est vrai, mais c'est toujours mieux qu'un Kylix), mais c'est déjà bien plus avancé/fonctionnel que Gorm je dirais.

    La page du projet Lazarus :
    http://www.lazarus.freepascal.org(...)

    Les scrineshautes :
    http://www.lazarus.freepascal.org/modules.php?op=modload&name=S(...)

    L'un des gros avantages de Lazarus, c'est aussi qu'il tourne sous Windows, donc le code est facilement exportable d'une plateforme à une autre. Autre gros avantage, c'est qu'il est possible de compiler du code écrit sous Delphi avec très peu de modifications sous Lazarus, donc la migration d'applications est envisageable.

    • [^] # Re: Mouais...

      Posté par  . Évalué à 4.

      Pardon, j'ai oublié une partie très importante de ma phrase lorsque je parlais de la portabilité de l'application. Lazarus fonctionne sur Linux, sur Windows, ET sur MacOS.

      D'ailleurs, c'est le scrineshaute de l'application sous MacOS qui est véritablement le plus joli :-)

      http://www.lazarus.freepascal.org/modules/Screenshots/screenshot/ma(...)

    • [^] # Re: Mouais...

      Posté par  (site web personnel) . Évalué à 2.

      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 :-)

      • [^] # Re: Mouais...

        Posté par  . Évalué à 3.

        Bon, c'est vai que j'ai peut-être parlé un peu vite, surtout que tout ce que je connais de Gorm c'est cette présentation au demeurant très sympa :-)

        Cela dit, il faudrait que je fasse le même genre de présentation avec Delphi pour illustrer ce que je veux dire. Pour être un peu plus précis, faire le même projet sous Delphi prend bien moins d'étapes et de manipulations :-)

        • [^] # Re: Mouais...

          Posté par  (site web personnel) . Évalué à 6.

          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..)..

          • [^] # Re: Mouais...

            Posté par  (site web personnel) . Évalué à 6.

            Je vais donc dire quelques mots de Delphi que j'utilise depuis une éternité (depuis delphi 2 pour les connaisseurs). Il y a sûrement les mêmes avantages dans Visual Basic, mais comme je ne l'ai jamais utilisé...

            En gros, le principe, c'est une classe par fenêtre.
            Dans la fenêtre, tu places des composants (boutons, textedit, ...) fournis ou créés par tes soins. Le truc pratique, c'est quand tu double-cliques sur un composant, tu te retrouves dans le code de la classe avec une belle en-tête de fonction déjà créé et il ne te reste qu'à mettre le code correspondant à l'évènement (par exemple, le double-clique dans l'IDE sur un bouton correspond au clique lors de l'exécution).
            Ensuite, la liste des autres évènements se fait dans un éditeur d'évènements/propriétés (double clique en face d'une case vide ou sélection suivant les fonctions dont le type correspond).

            Bien évidemment, tu n'as absolument rien à faire comme code pour la gestion affichage d'un bouton ou liaison fonction/méthode. Mais tu peux toujours le faire à la main si tu veux (utile pour la création de composant dynamique par exemple).

            Pour le placement automatique, tu as une propriété qui te permet de fixer, comme en Java, si tu veux le composant aligné en haut, en bas, au milieu, à gauche... Par contre, tu peux également les laisser comme tu les as mis lors de la composition de ton interface.

            Les fonctionnalités de delphi ne se résument pas qu'à ça (il y a l'auto-complétion de code, gestion des BD, gestion de déploiement dans les versions enterprise, etc...), mais là, j'ai présenté les fonctions dont tu as besoin pour faire la petite calculatrice.

            • [^] # Re: Mouais...

              Posté par  (site web personnel) . Évalué à 5.

              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..

  • # y en a marre du Flash bordel !

    Posté par  . Évalué à -4.

    c'est pas libre cette daube. Il faut arrêter de faire des vidéos avec. On peut pas les lire !

    • [^] # Re: y en a marre du Flash bordel !

      Posté par  . Évalué à 4.

      Moi j'approuve,

      sur mon ordinateur portable (Athlon Mobile 1.2Ghz = 256Mo de RAM + 256Mo de swap) c'est une horreur.

      Il m'a fallut un temps fou (au moins 5 minutes) pour que le fichier swf soit chargé dans le lecteur depuis le disque dur.

      Bien sûr, toute la RAM et toute la SWAP était pleine ($ free -m), le processeur tournait au max (=> ventilo bruyant).

      Enfin, pour finir, c'était d'une lenteur abominable, j'ai arrêter de regarder quand le design de l'application commençait à se faire.

      Donc, une petite vidéo aurait été beaucoup plus appropriée. Et, faut-il le rappeler, une vidéo c'est fait pour montrer un film, flash non.

  • # gif ?

    Posté par  (site web personnel) . Évalué à 2.

    A propos de vnc2swf, y aurait-il pas un moyen de faire plutôt du vnc2gif_animé ?

    Je me dis qu'en diminuant le nombre de couleurs du gif on doit pouvoir faire des animations qui prennent moins de place que le flash, non ?
    Et qui sont lisibles partout.

    • [^] # Re: gif ?

      Posté par  (site web personnel) . Évalué à 1.

      http://home.schleef.org/blog/20050129.1(...)
      une piste à creuser...

    • [^] # Re: gif ?

      Posté par  (site web personnel) . Évalué à 3.

      bon, j'ai trouvé un moyen :

      - sur la machine à enregistrer, on lance x11vnc
      - sur la machine qui enregistre (qui peut être la même), on lance
      vncrec -record film.vnc
      - puis on extrait le film vnc en images xpm avec
      vncrec -movie film.vnc
      - on convertit tous les fichiers xpm en gif avec
      mogrify -format gif *xpm
      - puis on réunit tous ces gif en une animation avec:
      gifsicle --optimize *gif > animation.gif

      Le probleme est que "vncrec -movie" est lent.
      Et mogrify est encore plus lent. troooooooooooop lent.
      Je ne comprends pas pourquoi il met presque 30s pour convertir un pauvre xpm de 640x480 en gif...

    • [^] # Re: gif ?

      Posté par  . Évalué à 3.

      flash permet de faire passer du son aussi, même si ce n'est pas utilisé ici.

  • # En parlant de Gorm

    Posté par  . Évalué à 3.

    Cela fait un moment que je suis bloqué dans le portage d'une de mes applis de Mac OS X vers GNUstep pour la raison suivante :

    Je n'arrive pas à créer un .gmodel contenant un NSView comme unique objet (et non pas un NSWindow). Pourtant j'ai bien la version 0.8 de Gorm et j'ai lu sur un document du projet GNUstep que c'était possible à partir de cette version.

    Si quelqu'un a une idée de comment faire ?

    • [^] # Re: En parlant de Gorm

      Posté par  (site web personnel) . Évalué à 4.

      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.

  • # GF

    Posté par  . Évalué à 3.

    Le truc qui m'a toujours empêché de continuer plus avant l'exploration de GNUstep (encore que je ne suis pas sûr de piouvoir y amener grand'chose), c'est le problème du gestionnaire de fenêtres. Je me suis habitué à Sawfish et je n'ai jamais trouvé un autre gestionnaire de fenêtres qui me convienne.
    Or, pour utiliser GNUstep sans WindowMaker, il faut rajouter un dock (c'est même une idée que je préfère plutôt que de confier le dock au gestionnaire). Et j'ai un peu de mal avec GSDock.
    Je sais, c'est un peu co1n, mais bon (d'autant que gdomap et gdnc se lancent encore au démarrage de ma machine, tiens) ...

    • [^] # Re: GF

      Posté par  (site web personnel) . Évalué à 2.

      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é..

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.