10 ans d'OpenStep

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
19
oct.
2004
GNUstep
C'est aujourd'hui le dixième anniversaire de la publication des spécifications OpenStep. Il s'agissait à l'origine d'un projet commun de NeXT et Sun pour définir un environnement de développement d'applications standard, multiplateforme, faisant du "write once compile everywhere" (ne coder qu'une fois, compiler partout) une réalité, et cet esprit est toujours présent grâce aux communautés GNUstep, NeXT et Apple -- GNUstep étant une implémentation de la Free Software Foundation de ce standard (NdM : sous GPL/LGPL), et Apple Cocoa un descendant direct de l'implémentation originale de NeXT. Les programmeurs peuvent ainsi développer et déployer leurs programmes sur MacOSX, Linux, BSD, Solaris, et même avec un peu d'effort, sous Windows.

Ce standard solide et bien défini s'ancre doucement mais sûrement dans le paysage du développement logiciel, et permet de programmer des applications en quelques heures au lieu de jours, semaines ou jamais, en utilisant une API de développement qui n'a pas nécessité de modifications significatives depuis dix ans, car particulièrement bien faite, simple et qui répond aux besoins des programmeurs...

Aller plus loin

  • # :)

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

    OpenStep sera peut etre un jour le troisiseme vrai environnement capable de rivaliser avec KDE et GNOME :) C'est tout le bien qu'on lui souhaite :)

    Bon anniversaire!
    • [^] # Re: :)

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

      Un jour peu être mais pas avant encore 10 ans :o)

      À part un joujou pour codeur, GNUStep n'a pas interressé grand monde jusqu'à présent.
      Je sais l'API rox, toussa... mais la GUI est laide et il n'y a pas ou presque d'applications codées pour exploiter l'environnement même si d'après certains GNUMail.app rox KMail/Evolution.
      Au contraire de KDE et Gnome qui sont homogènes, qui offrent une API tout aussi propre, comportent un bon nombre d'applications et qui ont une large communauté d'utilisateurs. Et ce dernier point fera toujours la différence...
      • [^] # Re: :)

        Posté par  . Évalué à 6.

        mais la GUI est laide
        Inutile de relancer le troll ;)

        Pour un resumé des episodes precedents :
        http://linuxfr.org/2004/06/14/16526.html(...)
        • [^] # Re: :)

          Posté par  . Évalué à 4.

          >> mais la GUI est laide
          > Inutile de relancer le troll ;)

          Tu veux un argument ? Y'a pas de section « screenshots » sur leur site !
          • [^] # Re: :)

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

            vi, entre autre à cause du flou artistique pour définir GNUstep -- desktop, environnement de prog, etc? -- perso moi je considère que c'est un environnement de dev, pas un desktop. Un desktop basé sur GNUstep, il y a quelques projets:
            http://www.nongnu.org/backbone/(...)
            http://home.gna.org/garma/(...)
            .. ou là il y a des sections "screenshots" ;-)
            m'enfin je suis d'accord que le "marketing" du projet GNUstep lui-même est un peu faiblard, pour être gentil, et on essaie de changer ça en ce moment...
            • [^] # Re: :)

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

              Rassure-toi, le meme flou exite pour definir KDE ou Gnome. Voyons, KDE, c'est kdelibs + kdebase ? Ou bien kdelibs + kdebase + kdenetwork + kdepim + kdeutils + ... ? Si je fait touner KDE avec Firefox, openoffice, evolution, gaim, ... es-ce encore KDE ?
          • [^] # Re: :)

            Posté par  . Évalué à 3.

            Une liste de screenshots est sans intérêt. Le plus intéressant c'est d'avoir un screenshot par application, au moins tu sais ce que tu regardes...

            Il y a aussi une brochure de présentation...

            Va voir là : http://gnustep.org/experience/apps.html(...)
            et : http://gnustep.org/information/Booklet.pdf(...)

            Ensuite, GNUstep n'est pas un desktop, mais un environnement de développement, donc ce n'est pas comparable.
            • [^] # Re: :)

              Posté par  . Évalué à 1.

              Puis ca permet de booster le traffique vers la seul application basé sur l'environnement GNUstep, j'ai nomé GNUmail... ( Non j'ai bien jeté un oeil du coté des liens morts de experience apps, c'est du plus belle effet, 6 liens mort sur 10 ).

              Franchement c'est quand même trés fort GNUstep, ils arrivent a avoir moin apps qu'un envrionement/OS comme Plan9.

              C'est pas tous ca mais j'ai mon portage du Hurd sous multidesk OS a effectué moi ;-)
            • [^] # Re: :)

              Posté par  . Évalué à 1.

              Au même titre que GNOME : GNU Network Object Model Environment. Je me trompe ?

              Il me semble qu'il ne fait que fournir un desktop, à l'origine.
              Effectivement, cette part du projet prend de l'ampleur, pour ma plus grande joie (I luv it) et mon plus grand regret (ça devrait être clairement séparé...)
          • [^] # Re: :)

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

            Ben c'est marrant, parceque moi je n'ai même pas eu besoin de la trouver la section "screenshots".

            En première page du site gnustep tu as une toute petite image, et si tu cliques dessus, ça te montre un exemple d'environnement gnustep...
      • [^] # Re: :)

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

        > bon nombre d'applications et qui ont une large communauté d'utilisateurs. Et ce
        > dernier point fera toujours la différence...

        Je pense que le nombre d'utilisateur Cocoa n'a rien a envié à celle de KDE ou Gnome.
        Pareil pour le nombre d'applications ou de développeurs
      • [^] # Re: :)

        Posté par  . Évalué à 10.

        > Je sais l'API rox, toussa... mais la GUI est laide

        sigh...

        (les goûts et les couleurs... la gui est belle, cohérente, "useable", sobre, le reste ce n'est que parce que les gens sont devenus allergique au gris et les icônes ont vielli)

        >et il n'y a pas ou presque d'applications codées pour exploiter l'environnement même si >d'après certains GNUMail.app rox KMail/Evoluti

        sigh...

        non GNUMail ne "rox" pas evolution (a la rigueur kmail) mais on pouvait dire de même de Gnome 1.0 et kde 1. ben vi, le travail est long, y a eu des déboires, des gens se sont d'avantage intéressé à gnome ou kde, etc etc

        personne ne dit le contraire : GNOME ET KDE sont de loin plus avancés que GNUStep

        mais mais mais , GNUStep est une BONNE fondation, une BONNE technologie
        et NON CE N'EST PAS PRET pour le DESKTOP de Mr TOut le monde

        mais TOUTE infrastructure (gnome, c# , cocoa, java etc) sont des "jouets" pour développeurs, TOUTE ont besoin qu'au début des gens "dingues" s y mettent pour crédibiliser la plateforme, sortent de VRAIS applications, etc

        notons que gnustep a un (petit) jeu de logiciels. y a pas que gnumail dans la vie.

        >Au contraire de KDE et Gnome qui sont homogènes, qui offrent une API tout aussi

        l'ergonomie de openstep est infiniment plus codifié et stricte que KDE ,et Gnome a encore besoin d'un HIG 2.0 pour clarifier non plus bêtement le "look", mais aussi le Feel (quel menu, quel genre de boite de dialogues, etc)

        en particulier parce que openstep peut tout simplement s'appuyer sur celle de nextstep ou se mettre à jour sur celle de apple cocoa.

        > propre, comportent un bon nombre d'applications et qui ont une large communauté >d'utilisateurs. Et ce dernier point fera toujours la différence...

        y a longtemps, un vieux avec une barbe me disait exactement les même raisons pour lesquelles Gnome/kde n'avait pas d'avenir, y avait déjà trop de gens embringué dans XLib et Motif et quitte à tout refaire, autant se plier au règne windows et faire du MFC en C++


        evidemment y a PEU de changes (ou malchances selon votre humeur) que gnustep soit un jour une plateforme populaire, tout simplement parce que gnome (ou kde) ont atteint dans une très grande part l'attente d'un bureau opensource CONVIVIAL

        il est maintenant plus "rapide" d'améliorer gnome, que de contribuer à peaufiner gnustep et faire tout plein d'applications. Gnustep a raté son rendez vous avec l'histoire y a quelques années. a moins d'un soudain débarquement de développeurs avide de coder du objective C comme des oufs et de distributions importants qui se découvrent une passion gnustep, je vois pas.

        mais qui c'est ce que réserve l'avenir.

        En attendant, il est vrai que je préfère apprendre et utiliser Cocoa sur mac os X avec Xcode et interface builder. clairement le meilleur langage, la meilleur API (cohérente et archi-complète) et outils de developpements que j'ai eu le plaisir d'utiliser. Ha si les outils de gnustep étaient aussi avancés, avec 150 développeurs dessus. j'ai clairement pas les compétences pour débugguer le backend gnustep xlib ou accéler leur version du interface builder, bref, jsuis dépendant de la venu de vrai hacker de talent.

        faute de "mieux", Gnome est de plus en plus un excellent bureau et l'Histoire continue.


        MAIS Ne donnez pas de faux arguments, on disait LA MEME CHOSE DE GNOME 1 et KDE 1 y a des années !!! et regardez finalement le chemin parcouru. ne parlez pas trop dans l'affirmatif absolu.
        • [^] # Re: :)

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

          (les goûts et les couleurs... la gui est belle, cohérente, "useable", sobre, le reste ce n'est que parce que les gens sont devenus allergique au gris et les icônes ont vielli)

          Bof, un des avantages du logiciel libre est quand meme un personnalisation poussée. il suffit de voir le nombre de theme sur les sites comme kde-look, gnome-look. Il y a des tonnes de bureaux, de wm... Il y en a pour tout les gouts.


          l'ergonomie de openstep est infiniment plus codifié et stricte que KDE ,et Gnome a encore besoin d'un HIG 2.0 pour clarifier non plus bêtement le "look", mais aussi le Feel (quel menu, quel genre de boite de dialogues, etc)


          C'est aussi un défaut, quand on voit le menu détaché, personellement je ne connait rien de plus chiant. Il faut avoir wmaker(un wm qui n'a plus évolué depuis 2002) pour que ça soit utilisable. Il y avait bien un patch qui circulait a une époque, mais il n'a jamais été commité à ma connaissance. Il faudrait pouvoir laisser le choix à l'utilisateur.

          autant se plier au règne windows et faire du MFC en C++

          Quand meme pas, Les MFC, c'est "un peu" de la merde
        • [^] # Re: :)

          Posté par  . Évalué à 4.

          >mais qui c'est ce que réserve l'avenir.

          mais qui *sait* ce que réserve l'avenir.

          D'habitude je ne suis pas specialement stricte sur l'orthographe, mais celle la elle pique un peu! Bon vue la taille de ton poste, tu as du aller un peu vite :-)
        • [^] # Re: :)

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

          > non GNUMail ne "rox" pas evolution (a la rigueur kmail) mais on pouvait dire de même de Gnome 1.0 et kde 1.

          Yeps. Sauf que KDE a commence il y a 8 ans, ce qui doit bien faire 7 ans pour Gnome. En 7 ans, on a fait beaucoup plus que GnuStep en 10 ans et ca ne fait que s'acceerer (cote Gnome + KDE) . Ou en sera-t-on dans 10 ans ?
          • [^] # Re: :)

            Posté par  . Évalué à 3.

            On parle des 10 ans d'OpenStep. Pas des 10 ans de GNUStep !
      • [^] # Y'a pas le GUI dans la Re: :)

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

        Au risque de me repeter, GNUstep permet aussi de faire des applis/outils en ligne de commande et des applis web (avec GNUstepWeb par exemple: http://www.GNUstepWeb.org(...) ).

        Un exemple de site en GNUstep+GNUstepWeb+gdl2:
        CyberDVDFilm: http://www.cyberdvdfilm.com(...)

        Manuel
  • # IHM

    Posté par  . Évalué à 3.

    Au fait nicolas, ca donne quoi ton projet permettant d'améliorer l'apparence de l'interface utilisateur ?

    J'avais lu sur les forums officiels que certaines personnes commencaient a vouloir changer les choses a ce niveau (apparence, icones, ...). Qu'en est-il aujourd'hui ?
    • [^] # Re: IHM

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

      Concernant le moteur de thème, j'ai pas eu le temps de bosser dessus depuis quelque temps (pas eu le temps de bosser sur GNUstep non plus..), et je recommence juste à coder dessus -- avec dans l'idée de faire une nouvelle release très bientôt. Pfiou j'ai un problème moi, à faire du release early, release often :-)
      Sinon en gros, la majorité de ce que je voulais modifier pour -gui est commité, donc il ne reste "plus" qu'à finaliser le moteur lui-même, ce qui devrait être assez rapide.

      Concernant les icones, ça progresse, c'est en bonne voie. On a fait un guideline avec quentin pour les icones, et on est en pourparler avec quelques graphistes (d'ailleurs je viens de recevoir les deux premières icones dans ma bal aujourd'hui.. ;-)
      http://www.quentinmathe.com/gnustep/documentation/UI/icons/(...)
    • [^] # Re: IHM

      Posté par  (Mastodon) . Évalué à 4.

      L'url peut-être:
      http://www.roard.com/camaelon(...)

      Le site de gnustep en parle dans la réponse au bouquin de Aaron Hillegass.
      http://www.gnustep.org/resources/BookClarifications.html(...)
  • # cocoa et "write once compile everywhere"?

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

    Est ce qu'on peut vraiment dire que cocoa respecte les spécifications openstep et permet donc le "write once compile everywhere"?

    Si je me souviens bien, il y avait une série d'extensions proriétaires a apple, comme NSDrawer et NSToolBar. Qu'en est il aujourd'hui? Est ce qu'apple a retiré ces extensions ou les gardent il pour empecher les gens de porter des applications vers gnustep?
  • # enlarge your penis

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

    "permet de programmer des applications en quelques heures au lieu de jours, semaines ou jamais"

    On peut avoir des arguments ? En quoi cette plateforme, surement superbe, permet-elle de développer plus rapidement une application ? qui de plus s'intègrera dans tous les environnements sur toutes les plateformes ? Parcque bon, celà fait quand meme longtemps que ca se saurait si ce saint graal avait été atteind...

    Sinon ben bon anniversaire, et contrairement à ce qui est dit plus haut, celà peut-etre très beau, cf Cocoa.
    • [^] # Re: enlarge your penis

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

      C'est faux, si c'était le cas, gnustep serait utilisable depuis des années :)
      • [^] # Re: enlarge your penis

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

        mouaif, sauf qu'on peut ptet imaginer aussi que pour avoir un systeme qui fait gagner vachement de temps aux developpeurs, ledit systeme doit fournir un max de trucs deja fait -- et que donc ledit systeme est lui, plutot long a coder. Ce qui est le cas avec GNUstep, tout etait a implementer avant de pouvoir vraiment tirer partie du systeme pour developper des applis..

        On peut aussi se dire que malgres tout, c'est quand meme plutot efficace, si tu regardes le peu de developpeurs qui ont bosses dessus et ce qui existe aujourd'hui (meme si c'est pas parfait).

        Concernant le dev rapide d'appli avec OpenStep, c'est en effet en general plus rapide a coder qu'avec d'autres trucs -- en particulier grace a InterfaceBuilder/Gorm, selon mon experience et selon l'avis de ceux qui ont essayes :-)
        Maintenant c'est sur que par exemple Qt est une tres bonne lib, et que donc la difference de rapidite entre un dev fait avec OpenStep et un dev fait avec Qt est moins flagrante qu'il y a dix ans (et quelque part, encore heureux !).

        Reste que l'on developpe tres rapidement en utilisant OpenStep, ca, c'est une evidence. Et que je pense que ca reste plus rapide pour developper une appli graphique que nombre d'autres solutions. Ce serait bien cool que l'editeur EOF graphique soit enfin release, ca serait pas mal pour les bases de donnes aussi.. :) m'enfin bon..
        • [^] # Re: enlarge your penis

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

          Mais c'est bien gentil de dire que tout est déjà présent dans GNUStep, qu'il n'y a besoin de rien recoder, et blablabla c'est mieux que les autres solutions, mais perso des plateformes comme ça j'en connais pas mal, par exemple Java ou Mono pour ne pas les citer. Alors en quoi GNUStep enlarge plus mon penis qu'une autre solution ?
          Et quel IDE permet de tirer pleinement partie de cette plateforme ? Parcque bon, question productivité, on peut y aller à coup de Visual Studio, et là aussi tu vas pouvoir anlarger ton penis en encore moins de temps...

          Sérieux je veux des arguments.
          • [^] # Re:

            Posté par  . Évalué à 6.

            Y'a un IDE qui s'appelle ProjectCenter, et un créateur d'interface qui s'appelle Gorm. Ces deux outils sont les équivalents de XCode et InterfaceBuilder de Cocoa.

            Pour le reste, le framework est bien plus petit et bien mieux étudié (à mon avis, enfin pas seulement le mien...). Contrairement à d'autres environnements, il n'y a pas de doublons parmi les classes, ce qui te permet de trouver beaucoup plus rapidement ce qu'il te faut également. Le système de délégué apporte également beaucoup de comfort pour la gestion des listes et des tables.
            Pour parler également du langage, ce qui permet d'accélérer considérablement le développement dans certains cas, c'est l'extension de classes grâce aux catégories...

            Sinon, pour ne pas parler de .NET avec lequel j'ai développé quelques trucs, quand tu as un bug dans ton programme sous GNUstep, tu ne fonces pas directement sur Internet pour voire si un bug du framework a été reporté...
            En général, quand il y a une erreur, c'est toi le responsable et du coup tu n'as qu'à regarder dans ton code.
            • [^] # Re: Re:

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

              J'ajoute que ce qui est VRAIMENT top (a mon avis), c'est bien le constructeur d'interface, Gorm. Car c'est plus qu'un simple constructeur d'UI -- il travaille directement avec les objets (un fichier interface etant simplement les objets utilises serialises sur disque). Donc tu ne fait pas que positionner tes widgets, tu as en meme temps toutes les relations inter-objets sauvegardes, leurs parametres, etc (et tu fait ca a partir de Gorm, bien sur). Du coup, ca te fait sauter pas mal de code que tu devrait te taper sinon (et ce n'est pas de la generation de code, justement).

              Vu qu'on travaille avec des objets, tu peux aussi te creer tes propres palettes d'objets (pas forcement graphiques) a utiliser dans Gorm et les lier avec ton programme, les instancier, etc. Gorm permet egalement de creer rapidement des objets quelconques et genere le code Objective-C dans ce cas.

              Ajoutons que du coup, tu peux tester l'interface de ton programme 'en live' sans meme qu'il soit necessaire de compiler quoi que ce soit -- les objets sont instancies a la volee et ca roule. Pratique pour tester rapidement le fonctionnement.

              Bref, on fait de prog orientee objet et ca se sent. Et de plus, le framework graphique (AppKit), est vraiment particulierement bien fichu. vraiment. Il est tres tres rare qu'on ait besoin par exemple de deriver une classe; on utilise plutot des objets delegues, etc.

              Un truc qui a mon avis serait vraiment proche de la perfection, ce serait de finir le bridge Squeak<->ObjectiveC ... on aurait alors l'avantage de Smalltalk ET l'avantage du framework OpenStep et des outils associes :-)
              • [^] # Re: Re:

                Posté par  . Évalué à 3.

                Un truc qui a mon avis serait vraiment proche de la perfection, ce serait de finir le bridge Squeak<->ObjectiveC ... on aurait alors l'avantage de Smalltalk ET l'avantage du framework OpenStep et des outils associes :-)

                Ça ne serait pas possible en partant de StepTalk ?
          • [^] # Re: enlarge your penis

            Posté par  . Évalué à 2.

            Au fait va faire un tour sur le site http://www.gnustep.org,(...) ça évitera des commentaires inutiles.
            • [^] # Re: enlarge your penis

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

              Je viens de lire l'introduction du projet GNUStep et notamment le paragraphe concernant les "avantages" de GNUStep.
              Ben, à part le fait qu'il sont apparement plutôt fier du fait que le framework n'a quasiment pas bougé depuis 10 ans (ce dont je m'en fou pas ma à vrai dire, ce uqi compte pour moi, c'est ce que je peux faire maintenant et si je peux toujours faire tourner ce que j'avais fait avant), je n'ai vraiment rien vu de spécial qui fait que cette plateforme roxe largement J2EE ou .NET.
              Donc bref, c quoi qui enlarge mon penis ?
              • [^] # Re: enlarge your penis

                Posté par  . Évalué à 1.

                Effectivement, je suis d'accord avec toi. Ces trois plate-formes sont tres similaires, ont chacunes leurs avantages et leurs inconvenients. Elles sont toutes des bonnes solutions et il n'y en n'a pas une qui est meilleur que l'autre.

                Sans trop rentrer dans le troll, je pense que GNUStep pour l'instant est tout de meme une solution a ne pas ecarter. En effet .NET sous unix (cad mono) commence a peine a etre exploitable (pour les perfos c'est pas encore ca), et Java a quelques problemes de licences qui, sans trop vouloir etre extremiste, pose un reel probleme d'independance de ce types d'applications.

                On se retrouve donc avec 3 plate-formes differentes, a faire le choix entre les perfos, et les problemes de licences. C'est a toi de decider apres ce qui est prioritaire pour toi en misant sur l'une de ces technos en esperant peut etre qu'a l'avenire les choses changeront dans le bon sens.

                J'ai volontairement ecarté Gnome et KDE qui ne sont pas multiplate-forme ainsi que Mozilla qui est plus destiné a de "petites" appli ou a des appli web.
                • [^] # Re: enlarge your penis

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

                  Maintenant, question à 2 euros, que me propose GNUStep pour m'intégrer à l'existant ? Je peux facilement utiliser GTK ou Qt ? Nan parcque en l'absence d'environnement comme Gnome ou KDE pour GNUStep, je ne peux qu'envisager GNUStep sur plateforme MacOSX...
                  C'est pas le tout de promettre l'interopérabilité, mais si celà doit se faire au détriment de l'ergonomie parcqu'il n'y a pas d'intégration voilà quoi...
                  • [^] # Re: enlarge your penis

                    Posté par  . Évalué à 2.

                    Je ne vois pas le rapport avec Gtk ou Qt...
                    Quand tu développes en Objective-C, tu utilise le framework GNUstep... Tu vas pas chercher du Gtk ou du Qt. Sinon, développes pas en Objective-C...

                    A part ça, GNUstep fonctionne très bien sous KDE ou Gnome.

                    Cependant, pour conserver les principes d'OpenStep, WindowMaker est le plus adapté. D'autre part il me semble qu'un environnement est en train d'être développé en Objective-C (WindowMaker est développé en C...).

                    Tu me diras que WindowMaker n'est pas bien (il démarre en 2 secondes, y'a pas une jolie image avec des icônes qui clignotent pendant 20 minutes avant de pouvoir travailler :-)), mais il rempli sa mission qui est d'être un window manager et efficacement.
                    • [^] # Re: enlarge your penis

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

                      Quand tu développes en Objective-C, tu utilise le framework GNUstep...
                      Ah bon le langage est limité à la plateforme ? (???)

                      Je ne vois pas le rapport avec Gtk ou Qt...
                      Ben si, moi j'en vois 1 : si j'ai envie d'intégrer une appli écrite en Objective-C dans un environnement Gnome ou KDE. S'il n'y a aucune possibilité d'intégration de cette plateforme aux environnements existant, je comprends nettement mieux pourquoi personne n'utilise NeXTStep en dehors de l'environnement MacOSX qui a été développé pour...

                      C'est gentil la portabilité
                      C'est gentil un beau langage
                      C'est gentil une belle plateforme super puissante et performante qui n'a pas bougé depuis 10 ans et qui va grandement augmenter ma productivité

                      Mais si je ne peux même pas concevoir une application desktop qui s'intègre ailleur que dans un environnement dédié, ben je dis que c'est normal que ce soit au même stade depuis 20 ans.

                      Un projet comme Mono a l'avantage de ne pas promettre systématiquement la portabilité, ils préfèrent supporter plusieurs environnement (Windows, Gnome et Cocoa) et promettre la portabilité de ce qui DOIT etre portable (bref, pas l'interface)
                      • [^] # Re: enlarge your penis

                        Posté par  . Évalué à 3.

                        Tu veux dire quoi par s'intégrer ?

                        Quand j'ouvre n'importe quelle application Gnome, KDE ou GNUstep, il se passe la même chose. L'application s'ouvre, fonctionne et c'est tout. Je ne vois pas ce que tu veux de plus ?

                        Ce qui gère l'intégration des applications c'est la couche window manager de la Xlib. Quand tu ouvres une appli, le window manager est mis au courant et reçois les infos utiles. C'est tout ce dont tu as besoin et ça marche.

                        Pour le copier/coller, c'est pareil, tu peux copier depuis GNUstep et coller dans du Gnome, et inversement...

                        Ensuite, si tu parles de boutons dans les menus, je sais pas ou autre chose, tu peux mettre un bouton qui lance une appli GNUstep sur ton KDE...

                        Plutôt que de chercher des poux dans la tête de GNUstep, essaye et vérifie que ça fonctionne c'est tout.

                        préfèrent supporter plusieurs environnement (Windows, Gnome et Cocoa) et promettre la portabilité de ce qui DOIT etre portable (bref, pas l'interface)

                        Mais vraiment n'importe quoi... depuis quand l'interface n'a pas besoin d'être portable ? Surtout pour un truc comme Mono, dont le but est quand même de créer des applications interactives...

                        Ensuite il me semble qu'il y a une bibliothèque GtkSharp commune à tous les environnements...
                        • [^] # Re: enlarge your penis

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

                          tu ne comprends pas du tout ce que j'entend par intégration...

                          T'as sûrement remarqué, on peut faire tourner une application KDE sous Gnome et inversement. Tu trouves pas qu'il y a de nombreux problèmes d'incohérence d'ergonomie entre les interfaces ? Pourquoi à ton avis on trouve des applications gMachin et kMachin si une seule suffisait ?

                          Pourquoi KDE existe ? pourquoi Gnome existe ? S'il n'y avait aucune différence, que la seule était le window mamager, y'a longtemps que les projets auraient fusionné...

                          Je parle d'ergonomie, il y a des chartes graphiques à respecter dans chaque environnement, et aussi une charte d'ergonomie (nom des menu, emplacement des boutons, format d'une fenêtre de conf, accessibilité, etc.)

                          Je cherche pas des poux à GNUStep, je m'apercois juste que c'est normal que ce projet en soti toujours à ce stade (pas utilisé).

                          Mais vraiment n'importe quoi... depuis quand l'interface n'a pas besoin d'être portable ?
                          Depuis que de nombreux programmeurs croivent que Java & Co vont résoudre tous les problèmes de portabilité, se sont ensuite rendu compte que y'avait un problème d'intégration visuelle (en partie résolu avec des thèmes utilisant les toolkit natifs) et maintenant un autre problème : intégration ergonomique, et là je ne connais aucun toolkit qui peut se vanter d'être portable tout en respectant l'intégration.

                          Icaza le dit clairement, la portabilité c'est bien, mais pas au détriment de l'interface.
                          Mono propose GTK# pour utiliser GTK. Après le fait est que GTK tourne sous MacOSX et Windows, celà peut être une solution portable efficace lorsqu'on ne se soucis pas de faire un soft de qualité (on veut juste qu'il marche partout).
                          Après Mono marche très bien avec les WinForms sous Windows, et ils bossent d'arrache pied sur Cocoa#, sachant que Qt# est existe également. A ton avis pourquoi ils s'amusent avec tous ces toolkit ? Pour faire joli ?
                          • [^] # Re: enlarge your penis

                            Posté par  . Évalué à 3.

                            Bon, je suis d'accord en partie. Mais les trois projets sont différents et s'intègrent à leur propre environnement.

                            application KDE sous Gnome et inversement. Tu trouves pas qu'il y a de nombreux problèmes d'incohérence d'ergonomie entre les interfaces ?

                            Dans l'un de tes commentaires précédent, on pouvait lire :

                            que me propose GNUStep pour m'intégrer à l'existant ? Je peux facilement utiliser GTK ou Qt ? Nan parcque en l'absence d'environnement comme Gnome ou KDE pour GNUStep

                            GNUstep s'intègre parfaitement à WindowMaker.

                            Si tu ne cherches pas des poux, dis moi où tu veux en venir ?

                            et maintenant un autre problème : intégration ergonomique, et là je ne connais aucun toolkit qui peut se vanter d'être portable tout en respectant l'intégration.

                            C'est pas tout à fait vrai car Kde permet par exemple d'utiliser des menus à la Apple après une simple configuration. Donc, sur Apple les menus d'applications Qt seront "ergonomique" par rapport au reste des applications.

                            Pour obtenir une meilleure intégration, il faudra multiplier les types de fenêtres prédéfinies genre dialogue etc. Chaque implémentation dans un environnement aura son dialogue, etc. spécifique.
                            • [^] # Re: enlarge your penis

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

                              GNUstep s'intègre parfaitement à WindowMaker.
                              Vi mais comme tu me l'as gentiment fait remarqué dans un de mes commentaires précédents, pour moi l'existant desktop actuellement c'est Gnome et KDE. WindowMaker voilà quoi.
                              Ca sert à rien d'avoir une plateforme portable si elle ne s'intègre pas dans les environnements les plus utilisés, surtout pour une plateforme desktop.
                              "C'est super portable, mais on vous conseille d'utiliser WindowMaker"
                              youpi.

                              Donc, sur Apple les menus d'applications Qt seront "ergonomique" par rapport au reste des applications.
                              Youpi alors t'as trouvé une astuce de KDE pour ressembler à Apple et tu crois avoir contredis ma affirmation qui dit que les applications 100% portables s'intègre très mal lorsqu'elle change d'environnement.
                              Moi je veux rien configurer, je veux utiliser mon application de la même manière que j'utilise les autres applications de mon environnement, sans de voir m'adapter aux particularités "ergonomiques" issue de l'environnement initial de développement.

                              Pour obtenir une meilleure intégration, il faudra multiplier les types de fenêtres prédéfinies genre dialogue etc.
                              Dans la plateforme ? Oui c'est une solution, mais on perd une grosse partie des spécificités de chaque plateforme en se contentant des points communs. Ou alors on en est rendu à "imiter" certains composants absent de tel ou tel environnement.
                              Et puis il ne faut pas oublier qu'il n'y a pas que les fenêtre prédéfinies qui demandent de l'intégration, c'est tout l'interface qui doit être pensée en conséquence.

                              A l'heure actuelle, la seule solution est de faire une application ou la couche de présentation est bien différenciée du reste de l'application, et de réécrire cette couche pour chaque environnement cible. C'est la seule manière d'avoir une solution de qualité, on se contentera de la portabilité de s autres couches.

                              J'espère que tu comprends mieux pourquoi je trouves que cette plateforme est jolie mais a oublié le principal objectif de toute solution desktop : l'intégration. Je crois que c'est une des principales causes de ce qui lui arrive. Heuresement que MacOSX l'utilise, parcque sinon j'y verrais pas beaucoup d'intérêt...
                              • [^] # Re: enlarge your penis

                                Posté par  . Évalué à 0.

                                Moi je veux rien configurer, je veux utiliser mon application de la même manière que j'utilise les autres applications de mon environnement, sans de voir m'adapter aux particularités "ergonomiques" issue de l'environnement initial de développement.

                                Tu es donc le client idéal pour GNUstep, la plateforme qui homogènise le plus l'ergonomie des applications.
                              • [^] # Re: enlarge your penis

                                Posté par  . Évalué à 3.

                                Ne le prend pas mal! Timaniac mais si tu perdais un peu
                                ton habitude de mettre des Vi partout ca serait appréciable
                                Avec ce petit "Vi" on t'imagine derrière ton clavier prendre un air un peu arrogant limite à faire passer tes interlocuteurs pour des c...

                                Mais je me trompe peut-être , c'est peut-être parce que tu fais de la pub pour ton nouveau projet de portage de Vi sous Mono ;-)
                                • [^] # Re: enlarge your penis

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

                                  oué je porte Vi sous Mono :-)
                                  Nan je m'étais jamais rendu compte qu'on pouvait interpréter ce mot comme ça, il n'y a aucune arrogance derrière en tout cas :)
                          • [^] # Re: enlarge your penis

                            Posté par  . Évalué à 5.

                            GNUStep propose un look&feel trés différent de ce qui existe actuellement sous Linux. Cela n'a riens à voir avec GNOME ni KDE. Ca se rapproche plutot de ce qui existe sous macOS.
                            Cette ergonomie à était trés "pensée" à la base, aprés c'est une question de gout. Donc effectivement une application GNUStep qui démarre sous KDE, sa fait aussi "tache" qu'une application GNOME.
                            Par contre le look&feel de GNUStep n'est _complet_ que si l'on utilise un windowmanager de type WindowMaker, en gros, GNUStep est alors dans son element.

                            je m'apercois juste que c'est normal que ce projet en soti toujours à ce stade (pas utilisé)
                            Je ne vois pas trop pourquoi ... par-ce-que sont ergonomie est trop differentes des poids lours que sont GNOME et KDE?
                            Ce n'est que depuis trés récemment que l'on peut avoir un bureau KDE ou GNOME trés unifié et sans une application qui fait tache au milieu car il n'existe pas d'equivalent sous G ou K.
                            Il y a quelques années, tout etait depareillé et on avait des applis gnome; kde, motif et TCL/TK en même temps.
                            Maintenant il est vrai que cela risque de "choquer" maintenant avec le niveau d'intégration que certains desktop on, mais normalement tu est sencé utilisé le desktop de GNUSTEP: GWorkspace.

                            Maintenant Mono :
                            On sait tous que tu trouve cette plateforme super-geniale, qu'elle roxe tout ca mais bon, qu'est-ce-que ca viens faire?
                            Pour l'instant un framework _complet_ existe pour étres utilisé avec obj-c, c'est GNUStep.
                            Le nombres d'autres framework ou bibliothèques (comme QT ou GTK) accessible directement via l'obj-c (par bibnding ou autres) est trés limité (surtout en IHM : je n'en vois pas d'autres!). Mais personne ne t'interdit de le faire.
                            Donc effectivement, vouloir ecrire une application qui s'intègre à KDE ou GNOME en obj-c, c'est moins evident, mais cela n'a rien a voir avec GNUStep.

                            Autres choses, et pour rentrer un peu plus dans ton troll, obj-c est un excellent langage pour réutiliser l'existant: interfacage direct avec le C, interfacage direct avec le C++ (bon OK, l'equipe de GCC à encore ca dans le TODO mais Apple le fait trés biens), et quelques possibilitées du langages qui n'existent pas ailleur (category, protocol). Ca c'est vnu langage proposant _vraiment_ quelques chose (pas comme c#).

                            Enfin, GNUStep n'est pas la pour enlarger ton p*, ni même faire croitre ton CA de 250% cette anné, ni même étres 'in' ou flashy branché, et encore moins d'etre sexy ou 'aware'.
                            Le but c'est d'implémenter des compcept qui, mêmes si ils ont été définis il y a lontemps, sont reconnus (Apple les utilisent!) et sont toujours d'actualité voir en avance même comparé avec d'autres plateforme soit-disant moderne comme mono ou java (en particulier les objets distribués)
                            • [^] # Re: enlarge your penis

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

                              Attention je ne veux pas troller sur Objective-C, je ne connais absolument pas ce langage, je me demandais juste si les APIs dispo étaient limité à GNUStep

                              Je me rend bien compte que la plateforme GNUStep a été pensée dans un nouvel environnement, peut être innovant (j'ai pas testé je ne jugerai donc pas).

                              Mais voilà, ce que je trouve dommage dans GNUStep, c'est qu'elle propose trop de nouveauté et pas assez de possibilité d'intégration dans l'existant. Tu le dis toi même, utiliser GTK ou Qt pour la partie graphique tout en conservant la plateforme GNUStep, c'est pas l'idéal et y'a pas beaucoup de bindings.

                              J'ai pris l'exemple de mono parceque je connais bien cette plateforme, et que bien entendu je cherche à comparer une nouveauté (même s'il elle a 10 ans) avec ce que je connais.

                              La news dit clairement que GNUStep ca roxe, et beaucoup ont l'air de se demander pourquoi elle n'est pas utilisé. Je lis partout que un des gros avantage de rapidité de développement (notamment sur leur site), c'est la portabilité. Mais tu le dis toi même, elle n'est pas bien utile pour l'interface puisque c'est GWorkspace son environnement de prédilection.

                              Moi je veux une plateforme qui me propose un environnement mais qui me propose aussi de m'intégrer dans les autres environnement. Je trouves celà beaucoup plus important dans le cadre d'une portabilité.
                              • [^] # Re: enlarge your penis

                                Posté par  . Évalué à 2.

                                Mais voilà, ce que je trouve dommage dans GNUStep, c'est qu'elle propose trop de nouveauté et pas assez de possibilité d'intégration dans l'existant.

                                Tu délires ?

                                GNUstep est une implémentation libre d'OpenStep qui a 10 ans aujourd'hui.
                                NeXTstep a été ouvert et est devenu OpenStep. NeXTstep existe depuis au plus tard 1992, soit au moins 12 ans.

                                GNUstep apporte des nouveautés vieilles de 12 ans...

                                Quand on te dit que si les specs. OpenStep n'ont pas bougé depuis 10 ans, c'est parce qu'OpenStep était ultra-innovant et bien foutu...
                                • [^] # Re: enlarge your penis

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

                                  désolé d'avoir déliré, j'aurai du employer le terme de "ultra-innovation" plutôt que "nouveauté". Enfin j'ai compris et t'aurais du comprendre que j'avais compris :)

                                  Mais celà ne change rien à ce que je dis, celà ne sert à rien de proposer quelque chose d'innovant si c'est pour faire table rase de l'existant.

                                  Pour moi j'associerai désormais TrucStep à la plateforme de MacOSX, mais en aucun cas j'associerai cette plateforme à un choix de portabilité parcque celà s'intègre nul part (ou tout de moins rien n'est fait dans ce sens)

                                  Bon maintenant je vais aller chercher moi même ce qu'il y a d'innovant dans cette plateforme (désolé, je ne vais pas comparer avec ce qu'il y avait y'a 10 ans mais avec ce qu'il y a maintenant) puisque personne veut m'expliquer concrêtement ce que ces superbres APIs vont m'offrir de mieux.
                                  • [^] # Re: enlarge your penis

                                    Posté par  . Évalué à 2.

                                    Bon maintenant je vais aller chercher moi même ce qu'il y a d'innovant dans cette plateforme (désolé, je ne vais pas comparer avec ce qu'il y avait y'a 10 ans mais avec ce qu'il y a maintenant) puisque personne veut m'expliquer concrêtement ce que ces superbres APIs vont m'offrir de mieux.

                                    On a donné pourtant pas mal de pistes sur les choses innovantes (le langage, les outils de développement etc.)...

                                    C'est pourtant clair. T'as du mal à comprendre. Rien n'a bougé depuis 10 ans, rien du tout.

                                    Si tu ne comprends toujours pas, GNUstep est un clône d'OpenStep.
                                    Il ne fait donc pas table rase sur l'existant, mais il s'inspire d'un autre existant que celui que tu connais...
                                    Pourquoi voir du côté de Gtk ou Qt alors qu'OpenStep se suffit à lui même.

                                    La seule chose qui ait changé, c'est uniquement pour apple qui a mis de belles couleurs partout.
                                    • [^] # Re: enlarge your penis

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

                                      On a donné pourtant pas mal de pistes sur les choses innovantes
                                      vi mais ce ne sont que des pistes, un peu comme dans les mails "enlarge your penis", mais csuffit pas dire c'est innovant pour que ca le soit.

                                      Je veux des exemples concrêt qui me montre que 1 plateforme a de nette avantages par rapport à une autre.

                                      le langage
                                      Pour moi le langage c'est une question de goût, un langage ne doit pas être dépendant d'une plateforme, et une plateforme ne doit surtout pas dépendre d'un langage.

                                      les outils de développement
                                      Pareil je veux une comparaison avec ce que propose les autres plateformes.

                                      Rien n'a bougé depuis 10 ans, rien du tout.
                                      Ca je sais mais je m'en fou :) Je veux comparer la plateforme maintenant, pas y'a 10 ans. J'écris pas un livre d'histoire, j'essai de savoir quel potentiel a cette plateforme actuellement vis-à-vis de ses promesses.

                                      Il ne fait donc pas table rase sur l'existant, mais il s'inspire d'un autre existant que celui que tu connais...
                                      Celà revient au même : si je suis obligé de faire table rase de MON existant pour aller vers un autre celà va être très rédibitoire. Je veux bien qu'on me propose quelque chose de nouveau, mais j'aime bien les transition douces, et surtout que je puisse m'intégrer avec l'existant, bref que je puisse faire des appli autour d'une plateforme portable tout en m'intégrant dans les environnements où je les exécute.

                                      La seule chose qui ait changé, c'est uniquement pour apple qui a mis de belles couleurs partout.
                                      Oué enfin Apple a fait plus important je trouve : il a conçu des applications concrêtes, bref, un existant.
                                      • [^] # Re: enlarge your penis

                                        Posté par  . Évalué à 4.

                                        Pour moi le langage c'est une question de goût, un langage ne doit pas être dépendant d'une plateforme, et une plateforme ne doit surtout pas dépendre d'un langage.

                                        Complètement idiot ce que tu dis...
                                        Pour qu'un framework soit efficace, il doit être adapté au langage qui l'utilise et tirer profit de toutes ses particularités.

                                        Je sais MS propose plein de langages pour son .NET. Enfin, des langages qui acceptent .NET à peu près. Par exemple le C++ qui n'a plus droit à l'héritage multiple etc.
                                        Oui, il y a aussi de l'ADA qui tourne après compilation comme du C#, autant développer en C# dans ce cas puisque de toutes façons tu perds tous les avantages liés au langage...

                                        Je crois qu'il faut comprendre qu'un langage ne se limite pas à une syntaxe mais contient également des spécificités à l'exécution. Le framework ne peut pas faire abstraction de ces spécificités, même si MS essaye de nous le faire croire.

                                        Celà revient au même : si je suis obligé de faire table rase de MON existant pour aller vers un autre celà va être très rédibitoire. Je veux bien qu'on me propose quelque chose de nouveau, mais j'aime bien les transition douces, et surtout que je puisse m'intégrer avec l'existant, bref que je puisse faire des appli autour d'une plateforme portable tout en m'intégrant dans les environnements où je les exécute.

                                        Et moi, qui ne connaît que OpenStep, pourquoi t'essaye de m'embrouiller avec tes Qt et Gtk ? moi je veux pas faire table rase de MON existant...

                                        Pour travailler sur GNUstep, tu ne dois pas faire table rase sur tes connaissances. Par contre tu dois apprendre de nouvelles syntaxes (celles de l'Objective-C) et penser tes applications un tout petit peu différemment.

                                        Tes connaissances en développement objet seront nécessaires...
                                        Au fait, je vois que tu as développé sur .NET dans ton cv, ça faisait parti de ton existant ? tu n'as jamais eu à l'apprendre, tu as la science infuse ?
                                        • [^] # Re: enlarge your penis

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

                                          Tu cite ADA sur .NET, mais je te signal qu'il y a également IronPython, qu'il y a également Eiffel (avec héritage multiple), mais aussi du Caml, etc. Pourtant ces langages respecte leur syntaxe et sémantique originale.

                                          Pour ce qui est de l'indépendance du framework vis-à-vis d'un langage, il suffit de prendre l'exemple de GTK qui a été conçu pour être "bindé" facilement et donc utilisable depuis ton langage favori.

                                          Je crois qu'il faut comprendre qu'un langage ne se limite pas à une syntaxe mais contient également des spécificités à l'exécution. Le framework ne peut pas faire abstraction de ces spécificités, même si MS essaye de nous le faire croire.
                                          Les langages ont beaucoup de points communs, et leurs environnements d'exécution aussi. De toute façon il est toujours possible d'ajouter ce qui manque dans le framework et qui est vital au langage (héritage multiple en Eiffel au dessus de .NET par exemple)

                                          Il ne faut pas oublier que tous les langages sont conçu pour tourner sur des architectures de proc au mode de fonctionnement similaire, il est donc tout à fait possible de faire la même concentration au niveau d'une machien virtuelle par exemple.


                                          Et moi, qui ne connaît que OpenStep, pourquoi t'essaye de m'embrouiller avec tes Qt et Gtk ? moi je veux pas faire table rase de MON existant...

                                          Mais justement, que vas-tu devoir faire si tu veux faire une application qui s'intègre dans Windows ou Gnome ?

                                          ---> OpenStep se vente d'être portable mais ne t'encourage pas du tout à t'intégrer dans les autres environnements, tu ne trouves pas celà contradictoire ?

                                          Pour travailler sur GNUstep, tu ne dois pas faire table rase sur tes connaissances.
                                          Mon existant n'est pas limité à mes connaissances mais aussi à tout ce que j'ai codé, et apprendre un nouveau framework complet c'est légèrement rédibitoire comme qui dirait. Le langage ca encore c'est surmontable (et parfois agréable)

                                          Au fait, je vois que tu as développé sur .NET dans ton cv, ça faisait parti de ton existant ?
                                          Justement tiens, puisque tu en parles, ben quand je développe une appli qui cible plusieurs environnements, je peux me baser sur la même plateforme (Mono), utiliser le toolkit graphique et m'intégrer comme je l'entend dans les différents environnements sans toucher au reste de mon appli, et cerise sur le gâteau, je peux même réutiliser mes compétences en GTK quand je codais en C, réutiliser la doc existante, les tutoriaux, réutiliser mes libs écritent en C, etc.
                                          • [^] # Re: enlarge your penis

                                            Posté par  . Évalué à 4.

                                            Tu cite ADA sur .NET, mais je te signal qu'il y a également IronPython, qu'il y a également Eiffel (avec héritage multiple), mais aussi du Caml, etc. Pourtant ces langages respecte leur syntaxe et sémantique originale.
                                            Bon ecoute, arrète de dire que c'est une avancé terrible d'avoir ces langages sur .Net.
                                            -Pour Eiffel, l'implémentation est du pur hack de gros sagouin (bin faute de mieux quoi, fait tenir un langage avec heritage multiple, types ancrés et assertion sur une plateforme qui ne le supporte ...) ISE à juste réaliser cela pour faire un coup de pub pour son langage (Bertrand Meyer à fait des conférences pour Microsoft) mais aucun utilisateur du langage Eifel penserrais à utiliser mono (Eiffel et deja cross-plateforme).
                                            -Pour Caml, ce lanage posséde déja un interpréteur, une VM, un compilo natif et pleins de bibliothèques, et le tout disponible pour plus d'architecture que .Net (ou mono) donc pouvoir le compiler sur .Net n'est absloument pas une avancé!
                                            Pense que l'on pourrait réaliser un compilateur d'a peu prés n'importe quel langage pour qu'il produise du basic par exemple, oui cela n'aurrait aucun interet, un peu comme .Net qui supporte 50 langages différents.

                                            il suffit de prendre l'exemple de GTK qui a été conçu pour être "bindé" facilement et donc utilisable depuis ton langage favori
                                            Bon faut un peu arreter la, les 'binding' ne sont qu'un pis-aller. Ca se comprend trés biens pour des langages comme python mais un véritable langage (dont le but est une compilation native) aurra des plus qui nécessiteron de réécrire les bibliothèque pour utiliser ces + (en eiffel les agents par exemple)

                                            OpenStep se vente d'être portable mais ne t'encourage pas du tout à t'intégrer dans les autres environnements, tu ne trouves pas celà contradictoire ?
                                            Heu non ... je ne croit pas à une ergonomie parfaite et unique. Mais j'aime cette de NeXT mais bon c'est vrai que les frameworks pourrait y travailler dessu (sous formes de fichier de conf peut-etres?). Mais quel framework propose cela?

                                            et apprendre un nouveau framework complet c'est légèrement rédibitoire comme qui dirait. Le langage ca encore c'est surmontable (et parfois agréable)
                                            Donc tu voudrais un seul framework et plusieurs langages qui l'utilise (tiens ca ressemble à .Net ...). Bon c'est que tu n'a riens compris aux differents apports des langages. Si mon langage possède l'héritage multiple, je _veux_ que le framework l'utilise, si mon langage possède les assertions, je _veux _ que mon framework l'utilise, si mon langage et fonctionel pur, je _veux_ que mon framework soit fonctionel pur, si mon langage et // ou distribué, je veux que mon framework en tienne comptes, sinon il n'y a _aucun_ interet à choisir tel ou tel langage (mis a part des notions discutables de syntaxe).

                                            [mono tou ca ...] je peut utiliser le toolkit graphique et m'intégrer comme je l'entend dans les différents environnements sans toucher au reste de mon appli
                                            Heu je fait une application en c# sur mono en utilisant gtk#, elle aurra le look&feel de kde si je l'utilise sous kde, de gnome sous gnome, de cocoa sous macOS, de windows sous windows? Non? ha bin GNUStep c'est pareil.
                                            Par contre quand tu dit que tu t'intègre comme tu l'entend sans toucher au reste de ton applis, tu doit quand même recoder toutes la partie IHM non?
                                            • [^] # Re: enlarge your penis

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

                                              Je sais très bien que Caml ou Eiffel sont déjà portables, qu'ils ont déjà un framework et tout et tout.
                                              Mais tu ne t'ai jamais dis qu'on pouvait avoir besoin d'utiliser quelque chose qui n'est pas disponible dans ton framework ?
                                              A part en C où tu vas tout trouver, tu vas devoir te taper tes bindings à la main ?
                                              SI .NET supporte de nombreux langages ce n'est pas juste à cause de la syntaxe, c'est aussi pour pouvoir utiliser facilement du code existant, justemetn écrit dans ce langage.

                                              Heu non ... je ne croit pas à une ergonomie parfaite et unique. Mais j'aime cette de NeXT mais bon c'est vrai que les frameworks pourrait y travailler dessu (sous formes de fichier de conf peut-etres?). Mais quel framework propose cela?
                                              Aucun que je ne connaisse en tout cas.
                                              C'est bien pour celà que j'ai fortement réagit à cette news :
                                              permet de programmer des applications en quelques heures au lieu de jours
                                              alors que cette plateforme se veut portable. Ce qui m'a fait encore plus sursauter c'est de voir qu'on ne semble pas encourager l'utilisation d'autre toolkit que celui fournit avec GNUStep : bonjour l'encouragement à l'intégration, surtout dans le domaine du dsktop.

                                              Donc tu voudrais un seul framework et plusieurs langages qui l'utilise
                                              Pas forcement, ce que je veux c'est pouvoir réutiliser l'existant et m'y intégrer. Tout les moyens sont bons, mais il ne faut pas refuser l'intégration avec comme excuse la portabilité.

                                              Bon c'est que tu n'a riens compris aux differents apports des langages
                                              Je me rend bien compte que beaucoup de langages ont des spécificités (héritage multiple, ou même esprit même du langage : fonctionnel, impératif, etc.) , mais je constate une chose : la plupart des APIs disponibles sont principalement orientés objet : on vous fournit un ensemble de classes et d'interface (au sens large) pour utiliser nos fonctionnalités, servez-vous en.
                                              Après je suis d'accord que les classes de base des langages doivent évidemment proposer des foncitonnalités propres à chaque langage (d'ailleur souvent ces classes font partie du langage ou de la "base" du langage).
                                              Mais quand il s'agit de réutiliser, et surtout proposer à la réutilisation, il faut utiliser les points communs entre tous les APIs, et c'est là qu'une plateforme comme Mono permet de gagner à mon sens beaucoup plus de temps (suffit de voir le temps mis pour pondre une plateforme productive, vu qu'il s'appui sur un existant éprouvé) que de s'amuser à refaire totalement une plateforme pour un unique langage.
                                              GNUStep est pour moi trop fermé, d'ailleur ça va biend ans la politique actuelle de Apple tiens :) (désolé pour le troll, pas besoin de réagir =) )

                                              Non? ha bin GNUStep c'est pareil.
                                              Sauf que Mono te propose tous les outils pour que tu puisse t'intégrer dans les principaux environnement, c'est dans la philosophie de la plateforme (Qt#, WinForms, GTK#, Cocoa#).

                                              tu doit quand même recoder toutes la partie IHM non?
                                              pas toute, la partie la plus haute oui. Tu peux garder toute la couche de contrôle de l'IHM à mon sens. J'en ai un peu marre de toutes ces promesses à la Java de portabilité totale, promesses reprises par GNUStep sur leur site web, alors qu'à l'arrivé on se retrouve avec des trucs bizzares, les programmeurs clamant faire tourner leurs appli sur toutes les plateformes, et c'est l'utilisateur qui en patie. Je trouve celà en tout cas vraiment dommage pour ce qui est du desktop. Pour ce qui est des appliactions plus spécialisées ou destinées aux informaticiens celà me dérange beaucoup moins.
                                          • [^] # Re: enlarge your penis

                                            Posté par  . Évalué à 2.

                                            les langages ont beaucoup de points communs, et leurs environnements d'exécution aussi. De toute façon il est toujours possible d'ajouter ce qui manque dans le framework et qui est vital au langage (héritage multiple en Eiffel au dessus de .NET par exemple)


                                            Pas d'accord! les caractéristique d'un langage conditionnent ce qu'on peut faire avec et si on s'en sert pour batir un framework, les autres langages wrappés dessus devront s'adapter aux limitations (différences) associées au langage d'implémentation

                                            Les exemples sont nombreux mais en voici un explicite qui fera plaisir au gnustep addicted ici présent puisque c'est l'aveu du propre developpeur du toolkit graphique Fox ecrit en C++.
                                            http://www.fox-toolkit.org/faq.html#CALLBACKS(...)

                                            dixit pour les pressés
                                            "Were FOX written in Objective-C, one could achieve the goal of type-safety as well; C++ clearly limits our choices"
                                            • [^] # Re: enlarge your penis

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

                                              Je pense sincèrement que c'est une mauvaise idée pour un framework que de le destiner à un seul langage en particulier, en tout cas pour un framework spécialisé : on limite d'autant sa réutilisation ! Heuresement que la plupart des APIs techniques qu'utilisent les 3/4 des langages sont écrits en C... (APIs multimédias, réseau, graphique, etc.)

                                              Pour moi tu veux faire un API, tu le fais dans le langage que tu veux, mais l'idéal est tout de même de lui donner une interface "générique" utilisable par le maximum de langage, bref principalement de simple méthodes, et pourquoi pas orienté objet, ce qui correspond à la plupart des langages.

                                              Après il peut être possible de rajouter une couche au dessus pour faciliter l'intégration dans un langage particulier, mais pour moi un framework (autre que le framework qui contient String & Co, les APIs de base d'un langage quoi) n'a pas pour ambition de s'intégrer dans un langage mais de fournir une base sans qu'on est besoin de réinventer la roue dans chaque plateforme.

                                              Enfin si tu préfères toujours réinventer la roue, ne pas favoriser l'interopérabilité des plateformes, et proposer des solutions dispo que pour un seul langage, libre à toi de l'écrire en Objective-C, mais il ne faut pas s'étonner après si personne utilise cette plateforme.
                                              • [^] # Re: enlarge your penis

                                                Posté par  . Évalué à 3.

                                                des APIs techniques qu'utilisent les 3/4 des langages sont écrits en C... (APIs multimédias, réseau, graphique, etc.)

                                                Oui, c'est juste et dis moi comment tu pourras utiliser les nouvelles bibliothèques écrites en C sous Mono ?

                                                Contrairement à mono, l'ObjC est une surcouche du C, donc question intégration environnement, l'ObjC n'est pas si mal puisqu'il n'y a rien à faire pour utiliser tes bibliothèques C.

                                                mais il ne faut pas s'étonner après si personne utilise cette plateforme.

                                                L'intérêt n'est pas de vendre un produit, mais de faire quelquechose d'efficace et dont on a besoin.
                                                Le jour où GNUstep sera parfaitement exploitable, ne t'inquiète pas, les gens l'essayeront et l'odopteront.

                                                Par contre, mono, tout le monde s'y intéresse, mais est-ce pour ses qualités, où plutôt pour "quoi ? .NET sous Linux ?"...

                                                Et pour finir, qu'Apple ait choisi OpenStep, c'est une marque de qualité pour OpenStep. Car même si Apple n'a jamais vendu autant que MS, Apple a toujours vendu des produits de qualité, débuggés et beaux. D'ailleurs, une fois que t'as goûté à Apple, tu ne manges plus que de l'Apple.

                                                Par contre, .NET, on en entend beaucoup parlé, mais plus souvent pour ses bugs que pour ses qualités.

                                                Ensuite concernant la compatibilité, je crois plus en celle de GNUstep avec Cocoa qu'en celle de Mono avec .NET (y'a déjà des classes dépréciés, des classes doublons etc.).

                                                Alors entre Mono et GNUstep, le choix est évident pour moi, c'est GNUstep.
                                                • [^] # Re: enlarge your penis

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

                                                  Oui, c'est juste et dis moi comment tu pourras utiliser les nouvelles bibliothèques écrites en C sous Mono ?
                                                  Parcque la plateforme Mono est une implémentation de .NET, et que .NET a été conçu pour réutiliser facilement l'existant, notamment du code écrit en C.
                                                  C# inclu les notions de pointeurs, de structure, etc., c'est pas pour rien.

                                                  [DllImport("mylib.so")]
                                                  void monprototypedefonction(String param1, truc param2);

                                                  et hop maintenant je peux l'utiliser.
                                                  Autre facilité : le compilateur C++ de Microsoft permet de mixer code managé et code natif, il suffit de faire :
                                                  #include <stdio.h>
                                                  et zou ca marche.

                                                  De plus j'ajouterai qu'en plus des facilités offertes, la philosophie de la plateforme encourage à réutiliser l'existant.
                                                  Enfin Mono propose une interface pour utiliser facilement du code .NET depuis l'extérieur, Mono est alors vu comme n'importe quelle bibliothèque.

                                                  Contrairement à mono, l'ObjC est une surcouche du C, donc question intégration environnement, l'ObjC n'est pas si mal puisqu'il n'y a rien à faire pour utiliser tes bibliothèques C.
                                                  A vrai dire sans connaître ObjC je m'attendais à cette compatbilité, mais j'ai commencé à douté en lisant les commentaires de certains... tu me rassures :)

                                                  Le jour où GNUstep sera parfaitement exploitable,
                                                  Elle n'est pas exploitable ? Pourquoi ?
                                                  L'implémentation d'Apple n'est-elle pas exploitable ?

                                                  C'est bien parcque Apple a choisi cette plateforme pour son OS que je m'y intéresse et que je ne doute pas qu'elle a des qualités. Le problème c'est que cette plateforme se veut portable mais ne semble pas vouloir s'intégrer ailleur que dans un environnement qui lui est dédié, et tant que j'ai pas de mac, ben...

                                                  Ensuite concernant la compatibilité
                                                  Je parlais pas de la compatibilité d'implémentation (celle de Mono a quand même pour objectif de faire tourner une appli Windows sans la recompiler, ce qui marche très bien pour la partie ASP.NET par exemple), mais d'interopérabilité, bref d'intégration avec l'existant.
                                                  • [^] # Re: enlarge your penis

                                                    Posté par  . Évalué à 2.

                                                    Tout d'abord faut comprendre une chose, OpenStep est une spécification.
                                                    Cocoa d'Apple est une implémentation, GNUstep en est une autre.

                                                    Elle n'est pas exploitable ? Pourquoi ?

                                                    Si c'est exploitable mais les versions de l'AppKit (interface graphique), de Gorm et ProjectCenter n'ont pas encore atteint la version 1.0. Donc en entreprise, je vois mal comment l'utiliser.

                                                    L'implémentation d'Apple n'est-elle pas exploitable ?

                                                    Si, l'implémentation d'Apple est parfaitement exploitable.

                                                    Le problème c'est que cette plateforme se veut portable mais ne semble pas vouloir s'intégrer ailleur que dans un environnement qui lui est dédié

                                                    Comme Java, Qt ou Gtk.
                                                    • [^] # Re: enlarge your penis

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

                                                      Comme Java, Qt ou Gtk.
                                                      Ce n'est pas du tout le but affiché par Gtk ou Qt qui sont de simple toolkit graphique, pas une plateforme complète.
                                                      Quand à Java voilà pourquoi je ne l'aime pas :)
                                                      • [^] # Re: enlarge your penis

                                                        Posté par  . Évalué à 2.

                                                        Remplace Gtk par Gnome. Quand a Qt, meme sans Kde ca s'approche vraiment de la plate-plateforme vu le spectre couvert par les API.
                                                        • [^] # Re: enlarge your penis

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

                                                          Ah non du tout. Gnome ou KDE sont des environnements, même s'ils sont très complets, ils ne visent pas une plateforme complète de développement et encore moins la portabilité.
                          • [^] # Re: enlarge your penis

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

                            Je cherche pas des poux à GNUStep, je m'apercois juste que c'est normal que ce projet en soti toujours à ce stade (pas utilisé).

                            Stop the FUD (tm) !

                            Il est utilisé et meme en environnement commercial:
                            o Turbocat WebMail,
                            o eCommStep,
                            o OpenGroupware (qui utilise gnustep-core ou qui devrait l'utiliser bientot).

                            Sans compter que certains developpeurs du projet d'en servent pour leurs boite en interne ou pour leurs clients.

                            On avait meme faillit s'en servir pour le portail boursier Voila, il y a quelques années...

                            Manuel
                      • [^] # Re: enlarge your penis

                        Posté par  . Évalué à 1.

                        Ah bon le langage est limité à la plateforme ? (???)

                        Tu sais un langage reste quand même limité par les API disponibles. La seule API complète qui utilise Objective-C est le framework GNUStep mais il y'a eu dans un passé récent des tentatives de faire des bindings Gtk pour Objective-C. Bref je te conseille de lire ce site :

                        http://www.foldr.org/~michaelw/objective-c/(...)

                        Ca te permettra d'avoir une vision plus précise de ce que permet Objective-C et ses avantages par rapport à d'autres langages. Parce que pour l'instant tu discutes sans vraiment connaître, ce qui donne une discussion où on a clairement l'impression que tu cherches à démontrer que GNUstep c'est ringard mais sans argument.

                        Mais si je ne peux même pas concevoir une application desktop qui s'intègre ailleur que dans un environnement dédié, ben je dis que c'est normal que ce soit au même stade depuis 20 ans.

                        Tu dis toi même que les applis Gtk ne sont pas intégrées dans KDE par exemple. On est typiquement dans un cas où l'application ne s'intègre pas correctement ailleurs que dans un environnement dédié et pourtant c'est utilisé. Il y'a d'autres raisons qui font ce framework est moins utilisé et il n'y a clairement pas que l'integration.
                  • [^] # Re: enlarge your penis

                    Posté par  . Évalué à 1.

                    il n'y a pas d'intégration voilà quoi...
                    C'est a mon avis l'un des principaux problemes de GNUStep actuellement. C'est beau d'avoir un "supair framework", si celui-ci n'est pas capable d'etre integré entierement dans l'environement cible, cela pert de son interet.

                    Tu peux tres bien decider d'utiliser GNUStep base qui te fournira des objets independants de l'IHM (par exemple : gestion des strings, collections, heure, filesystem, ...) et qui te garantie une independance de la plateforme tout en utilisant derriere GTK ou Qt (via un wrapper C tant que gcc n'est pas capable de marier le C++ a l'ObjC) pour l'IHM.
                    L'avantage est une integration parfaite dans l'environnment, mais tu perd un peu de l'interet de GNUStep. A mon avis c'est une tres mauvaise solution.

                    Ou alors tu accepte la contrainte d'avoir un truc horrib^R^R gris ;) qui n'est pas du tout integré, et qui ne fonctionne pas si bien que ca sous windows, et tu croises les doigts pour que le support de windows arrive au bout et que l'IHM Gnustep soit themable. C'est pour ca que je prete beaucoup d'attention au projet de nicolas, Cameleon, car il permettra d'utiliser des skins "approchant" le theme du desktop (un peu comme firefox aujourd'hui).
                    • [^] # Re: enlarge your penis

                      Posté par  . Évalué à 1.

                      il n'y a pas d'intégration voilà quoi...

                      WindowMaker n'existe pas ?

                      Si pour vous l'intégration c'est avoir la même geule que son desktop, je suis désolé mais GNUstep est parfaitement intégré à WindowMaker...
                    • [^] # Re: enlarge your penis

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

                      L'avantage est une integration parfaite dans l'environnment, mais tu perd un peu de l'interet de GNUStep. A mon avis c'est une tres mauvaise solution.

                      Cette solution est pénible, je te l'accorde (celà donne du boulot au programmeur), mais je ne vois pas d'autres solutions pour obtenir une parfaite intégration, critère pour moi relativement vital pour une applicatoin desktop tout public.

                      Le choix des thèmes qui s'intègre ne résoud que le problème d'intégration visuelle, pas d'ergonomie.
                      • [^] # Re: enlarge your penis

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

                        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.
                  • [^] # Re: enlarge your penis

                    Posté par  . Évalué à 2.

                    Il y a des bindings Objective C pour gtk1 mais pas pour gtk2.
              • [^] # Re: enlarge your penis

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

                Donc bref, c quoi qui enlarge mon penis ?

                Généralement, une bonne motivation.

                Sinon, il paraitrait qu'il existe des petites pilules bleues, un genre de poudre verte pour la bite...

                Proverbe Alien : Sauvez la terre ? Mangez des humains !

      • [^] # Oui et Non Re: enlarge your penis

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

        Plus precisement c'est en cours. Et ca marche plutot pas mal entre MacOS X et Unix, avec par exemple GNUMail.app.

        Pour Windows, ca progresse AFAIK.

        Il suffit de suivre les listes de discussion pour voir la progression.


        Manuel
    • [^] # Re: enlarge your penis

      Posté par  . Évalué à 2.

      On peut avoir des arguments ? En quoi cette plateforme, surement superbe, permet-elle de développer plus rapidement une application ? qui de plus s'intègrera dans tous les environnements sur toutes les plateformes ? Parcque bon, celà fait quand meme longtemps que ca se saurait si ce saint graal avait été atteind...

      Perso, je suis développeur Cocoa (donc sous osX) et depuis que j'ai découvert Objective C et ce framework , j'ai beaucoup de mal a aller sur d'autres :)

      Côté arguments... déjà le langage utilisé (objC). Si tu veux avoir plus d'infos dessus, une recherche sur Google t'en donnera beaucoup plus (à quoi bon faire un copier coller ici).
      Et il y a également le framework en lui même qui est bien pensé avec pas mal de bonnes idées (comme les delegate par exemple).
      Je ne détaille pas plus car si tu veux vraiment essayer alors tu iras sur les sites web qui en parlent. Dans le cas contraire, cela serait une perte de temps et d'espace. Pour moi GnuStep tout comme Cocoa sont des bijoux de conception pour les déveleppeurs (surtout comparé à GTK par exemple). Dès que le look sera plus fun, il aura un succés fou :) Regardez, GTK s'est développé alors que pourtant .... (heureusement que la version 2 est sortie ;) )


      PS: à l'équipe de Gnustep, j'espère que tout ce qui touche aux bindings en Cocoa pourra être intégré (et j'imagine que cela doit être du boulot).
  • # article wikipedia à compléter

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

  • # Lien OpenStep

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

    Le lien OpenStep de la dépeche ne devrait il pas être renommé en "Objective C" ?

    OpenStep n'a plus de page officielle ?

    http://fr.wikipedia.org/wiki/OPENSTEP(...)
  • # Hors sujet mais pas tant que ça

    Posté par  . Évalué à 10.

    J'ai l'impression qu'on a deux types de commentaires:
    1. OpenStep, c'est bien mangez-en, vous coderez plus vite, mieux tout ça;
    2. Connais pas mais si c'était mieux, ça se saurait.

    Je ne connais pas OpenStep mais le second type d'argument m'ennerve.

    Il y a maintenant 8 ans, on m'a fait découvrir ocaml.
    J'ai assez vite trouvé que c'était pas mal: un langage qui compile en natif mais
    qui tourne aussi sur une machine virtuelle, c'est bien,ça permet de ne pas
    toujours recompiler. En plus, à l'époque, le code compilé tournait peut-être
    2 fois plus vite que la version natif. Ce langage était (et est toujours) développé
    à l'INRIA par une petite équipe de bourrins.
    À la même époque, on commençait à entredre parler de java: la révolution,
    on a inventé les machines virtuelles, vous pourrez ne compiler qu'une seule
    fois et ça tournera partout. Moi, ça me faisait rire. Surtout que j'ai eu à coder
    en java à cette époque, sur la jvm de SUN (j'étais sur solaris). La révolution
    java, je la trouvai risible. Mais les marcketeux de chez SUN étaient bons et
    SUN avait assez de sous pour que tout le monde crois que java était génial.
    Je ne dis pas que ce langage n'apportait rien mais il était déjà très en retard
    sur beaucoup de points par rapport à certains langages académiques. Vous
    allez dire que je lance un FUD et que dans cette enfilade de messages, on en
    tient un et c'est suffisant. Ce que je voudrai dire, c'est que les personnes
    à qui je parlais d'ocaml me disaient toutes que si ocaml, c'était bien, ça se
    saurait, que les gens l'utiliseraient etc...
    Quelques années plus tard, à la fac, j'ai eu un projet « compilation ». Le
    langage était imposé: ocaml. Il y a eu des haut cris: ocaml, c'est de la
    merde... La prof à tenu bon. En trois mois, toute la promo a appris un
    nouveau langage et a écrit un compilateur pour un sous-langage de
    smalltalk. Et toute la promo était fan d'ocaml. Cette même année, un prof
    a tenu à ce qu'on fasse un projet en C++. Le premier jour, je lui ai dit que
    C++ n'était pas adapté à ce qu'il voulait faire et qu'ocaml serait mieux.
    Il a tenu bon. Trois mois plus tard, aucun projet ne fonctionnait et en deux
    heures, je lui ai codé son truc en ocaml. Il m'a répondu que peut-être mon
    truc fonctionnait mais c'était forcément lent. On a fait la course. Mon truc
    codé en 2 heures en ocaml allait plus vite que le sien codé en C++.

    Dites les gens, le problème de beaucoup de projets est que c'est chaint
    de réfléchir. On veut pondre un truc vite. Alors on ne prend pas le temps
    de réfléchir, on fonce tête baissée et on sort une première version. Et puis
    on se rend compte que c'est largement sous-optimal alors on modifie la
    spécif et on sort une seconde version, puis une troisième...
    En 96, quand je codais en java, le compilo me sortait déjà qu'un certain
    nombre de chose que je faisais étaient « deprecated ». Ils avaient du
    réflichir longtemps avant de les définir pour que si peu de temps après, ce
    soit déjà deprecated.

    Alors, je me répète, je ne connais pas OpenStep mais
    1. Si les spécifs d'OpenStep n'ont pas changée en 10 ans et qu'elles
    permettent de faire des trucs (cf. cocoa), je trouve que ce point seul
    justifie qu'on s'y intéresse;
    2. Affirmer que si c'était bien, ça se saurait et que de toute façon,
    C++, qt, gtk ou n'importe quoi d'autre, c'est fondamentalement mieux,
    c'est d'une connerie et d'une étroitesse d'esprit affolante.

    Frédéric

    P.S. Le fait que je n'ai lu aucun vrai argument contre OpenStep et le
    fait que la spécif reste d'actualité me font penser qu'OpenStep, c'est
    bien mangez-en.
    • [^] # Re: Hors sujet mais pas tant que ça

      Posté par  . Évalué à 4.

      2. Affirmer que si c'était bien, ça se saurait et que de toute façon,
      C++, qt, gtk ou n'importe quoi d'autre, c'est fondamentalement mieux,
      c'est d'une connerie et d'une étroitesse d'esprit affolante.


      Sans compter que c'est grosso-modo l'argument du fan-club des produits Microsoft.

      "Franchement, si Linux c'était vraiment mieux que Windows, y'a longtemps qu'on n'utiliserait plus que ça."

      Chapeau bas, messieurs.
    • [^] # Re: Hors sujet mais pas tant que ça

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

      GTK+ peut également être utilisé avec Ocaml : http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html(...)

      (Il y eut une corrélation de langage pour Objective-C, mais ça n'a pas eut de suite)
    • [^] # Re: Hors sujet mais pas tant que ça

      Posté par  . Évalué à -2.

      > 2. Connais pas mais si c'était mieux, ça se saurait.

      Ça reste généralement vrai même si peut-être ici ce n'est pas le cas.

      Ce qui me gène dans ton argument c'est qui ne s'appuie que sur l'incompétence des autres et les autres ne sont rien moins que les développeurs du logiciel libre qui dans la grande majorité des cas savent adopter de nouvelles solutions et sont relativement insensible aux propos marketing. Java n'est pas un succès délirant dans le logiciel libre. Python est très utilisé, ruby se fait une "place au soleil", etc.

      > 2. Affirmer que si c'était bien, ça se saurait et que de toute façon,
      C++, qt, gtk ou n'importe quoi d'autre, c'est fondamentalement mieux,
      c'est d'une connerie et d'une étroitesse d'esprit affolante.

      Il doit bien y avoir de solides raisons autre que la "paresse" pour que les gens développent gtk+, gnome, KDE, ... alors qu'il y a déjà OpenStep. Nier ce fait, c'est aussi faire preuve "d'une étroitesse d'esprit affolante".
      • [^] # Re: Hors sujet mais pas tant que ça

        Posté par  . Évalué à 4.

        Il doit bien y avoir de solides raisons autre que la "paresse" pour que les gens développent gtk+, gnome, KDE, ... alors qu'il y a déjà OpenStep. Nier ce fait, c'est aussi faire preuve "d'une étroitesse d'esprit affolante".

        Tu aurais une "solide" raison pour justifier le manque d'intérêt de la communauté pour OCaml? C'est pourtant un langage libre, fiable (typage fort et strict et tout), performant (la version compilée n'a pas à rougir devant C++), souple (possibilité de choisir entre du bytecode, de l'interpreté pur ou du natif), interopérable (via le C, notamment), et j'en passe.

        La seule raison que je vois à ce manque d'intérêt, c'est qu'il prône un mode de pensée qui n'est pas beaucoup répandu: le fonctionnel. Sans aller jusqu'à taxer les gens du libre de paresse, il faut bien admettre que quand on n'a pas l'habitude, on a du mal à s'y mettre. Et moi-même, malgré tout l'intérêt que je porte à ce langage, je me tourne de plus en plus vers python.

        C'est, il me semble, un phenomène similaire qui frappe Openstep et ObjectiveC. J'ignore quel est l'aspect qui "dérange" (à mon avis, c'est dû à son approche du paradigme objet très éloignée de la vision C++/Java), mais je pense que c'est plus un "rejet" de la part de la communauté qu'un réel vice de conception dans le langage ou dans l'API.
        • [^] # Re: Hors sujet mais pas tant que ça

          Posté par  . Évalué à 0.

          > Tu aurais une "solide" raison pour justifier le manque d'intérêt de la communauté pour OCaml?

          Non. Et d'ailleur je ne connais pas OCaml.
          Je ne dis pas que OCaml est de la "bouse" car il est peu utilisé. Tu as peut-être raison lorsque tu dis que OCaml est injustement impopulaire et les différents arguments que tu avances sur du _vécu_ sont pertinents et intéressants.

          Je dis simplement que "2. Affirmer que si c'était bien (...) c'est d'une connerie et d'une étroitesse d'esprit affolante" n'est pas la marque d'une personne "large" d'esprit :-)

          > je pense que c'est plus un "rejet" de la part de la communauté qu'un réel vice de conception dans le langage ou dans l'API.

          Mais "voilà"...
          Le problème du chois d'un langage (ou autre) est qu'il est fortement basé sur des considérations qu'on ne peut ramener à sa "conception" ou son API. Il y a tout un tas de contraintes qui influence énormément.

          Au premier abord, le C est nul et se fait explosé par le C++. Dans la pratique, le C reste génial et pas pour des raisons de conceptions évidentes. Le C++ aussi est génial :-) Et OCaml sûrement aussi :-)
          Quoi ? Oui, python aussi :-)

          Je crois que ça suffit maintenant.
        • [^] # Re: Hors sujet mais pas tant que ça

          Posté par  . Évalué à 4.

          J'ignore quel est l'aspect qui "dérange"

          Je ne sais pas non plus, mais il faut dire que l'objective-C est étroitement lié à OpenStep, et du coup n'a pas eu la popularité qu'il méritait.

          Maintenant, il faut dire qu'on parle souvent des avantages de GNUstep, mais on oublie souvent de parler de l'Objective-C.

          Pour moi l'Objective-C a deux gros avantages :

          - il y a très peu de choses qui ont été rajoutées au C. Par exemple, l'holomorphisme est naturel, il n'y a pas besoin de déclarer les méthodes virtuelles etc.

          - les déclarations et appels de méthodes sont beaucoup plus claires que tous les langages classiques, par exemple :
          - on aura en C++, Java, VB... : objet->drawPoint(10, 15, 3, rouge);
          - en ObjC on aura : [objet drawPointWithX: 10 Y: 15 diametre: 3 color: rouge];
          Il n'y a aucune discussion à avoir, l'ObjC est 1000 fois plus claire.
          • [^] # Re: Hors sujet mais pas tant que ça

            Posté par  . Évalué à 0.

             en ObjC on aura : [objet drawPointWithX: 10 Y: 15 diametre: 3 color: rouge];
            Il n'y a aucune discussion à avoir, l'ObjC est 1000 fois plus claire.


            Ben justement je voudrais discuter parce que franchement je vois pas en quoi c'est plus clair
            [objet drawPoint X: 10 Y: 15 diametre: 3 color: rouge]
            ca serait plus clair dans mon pov esprit
            ou objet.DrawPoint(X=10, Y=15, diametre=3, color=rouge) ok

            holomorphisme kezako ? si c'est natutel pour ObjC pas pour moi .
            Je ne connais que le polymorphisme.
            Quant à la différence methodes virtuelles/statique de c++ n'est là que pour génerer du code plus efficace en c++. Beaucoup d'autres langages ne font pas cette différence et toutes les méthodes sont virtuelles. l'holomorphisme c'est encore une autre approche
            Peux tu développer un peu ton argument ?
            • [^] # Re: Hors sujet mais pas tant que ça

              Posté par  . Évalué à 2.

              [objet drawPointWithX: 10 Y: 15 diametre: 3 color: rouge] n'est pas clair pour moi étant donné que je n'ai pas l'habitude de programmer de cette façon, objet->drawPoint(10, 15, 3, rouge) m'étant plus naturel.
              Je comprends cependant pourquoi celà peut paraitre plus clair au yeux de certains.
              C'est un peu comme si la doc de la méthode était dans le code l'appelant. Pas besoin de chercher à quoi correspond le premier paramètre de la méthode, le deuxième, etc..
              On le voit directement ( même si les varibles passées à la méthode permettent de le savoir).
              • [^] # Re: Hors sujet mais pas tant que ça

                Posté par  . Évalué à 0.

                Tu pourrais me traduire l'instruction suivante (syntaxe Eiffel) en syntaxe Ojective C ou SmallTalk ?
                echantillon_courant := centri.nacelles.item (parcours.item (iteration).numero_nacelle).emplacements.item (parcours.item (iteration).numero_emplacement).element
                • [^] # Re: Hors sujet mais pas tant que ça

                  Posté par  . Évalué à 2.

                  echantillon_courant = [[centri nacelles] item: [[[[parcours item: iteration] numero_nacelle] emplacements] item: [[[parcours item: iteration] numero_emplacement] element]]

                  Oui, effectivement, c'est pas claire du coup...

                  Faut dire que j'ai considéré que chaque élément de ton truc était un objet, sinon, la syntaxe . ou -> reste valable pour les structures.

                  Ensuite, ton truc paraît plus claire, mais si tu essayes de comprendre ce qui se passe c'est exactement pareil...

                  Si tu programmes comme un porc, c'est pas l'Objective-C qui va te sauver... Par contre quand tu programmes proprement, l'Objective-C t'apporte beaucoup.

                  Comme dit un peu plus haut, tu as ta doc dans le nom des méthodes.
                  • [^] # Re: Hors sujet mais pas tant que ça

                    Posté par  . Évalué à 0.

                    C'est de l'implémentation. Un bras robotisé fait un traitement sur des échantillons placés dans des nacelles (comportant plusieurs emplacements) portées par le rotor (qui porte bien sûr plusieurs nacelles) d'une centrifugeuse. Le parcours des échantillons se fait selon un ordre (contenu dans l'objet parcours qui contient les numéros de nacelles et les numéros d'emplacements dans les nacelles contenant des échantillons) qui optimise les mouvements du bras. Iteration, c'est le numéro (le "combientième") de l'échantillon à traiter.

                    Le rotor de la centri contient donc des nacelles munies d'emplacements qui peuvent contenir des échantillons. Il y aurait moyen de décomposer un peu plus le traitement, mais je trouve que ça se lit déjà très bien comme ça...
                    • [^] # Re: Hors sujet mais pas tant que ça

                      Posté par  . Évalué à 2.

                      Le rotor de la centri contient donc des nacelles munies d'emplacements qui peuvent contenir des échantillons. Il y aurait moyen de décomposer un peu plus le traitement, mais je trouve que ça se lit déjà très bien comme ça...

                      ... parce que tu sais de quoi ça parle. Si je te sors un compute_values(str, valx, valy, 0) hors contexte, tu risques fort d'avoir du mal à comprendre la logique sous-jacente (en plus c'est un exemple pris au hasard, mais bon).

                      Le fait de nommer les paramêtres, que ce soit façon SmallTalk/ObjC ou façon python, permet d'améliorer grandement la lisibilité du code.

                      En plus, dans le cas d'ObjC, les étiquettes des paramêtres sont pris en compte dans la signature de la fonction. Ca permet une forme de polymorphisme paramêtrique, mais totalement désambiguïsée.
                      • [^] # Re: Hors sujet mais pas tant que ça

                        Posté par  . Évalué à 0.

                        Le fait de nommer les paramêtres, que ce soit façon SmallTalk/ObjC ou façon python, permet d'améliorer grandement la lisibilité du code.

                        Il y a des environnements de dev qui te proposent la liste des paramètres au moment où tu invoques la routine. A contrario de ce que tu dis, le fait de ne pas nommer les paramètres permet d'alléger l'écriture... On ne peut pas tout avoir.
                        • [^] # Re: Hors sujet mais pas tant que ça

                          Posté par  . Évalué à 3.

                          Il y a des environnements de dev qui te proposent la liste des paramètres

                          Oui, je connais, mais quand tu lis du code, tu ne suis pas ta lecture avec le curseur et l'affichage de la liste n'est pas instantanné.

                          Je trouve ce principe simple, intéressant et ne nécessitant pas un éditeur évolué pour comprendre le code.
                          • [^] # Re: Hors sujet mais pas tant que ça

                            Posté par  . Évalué à -1.

                            Je trouve ce principe simple, intéressant et ne nécessitant pas un éditeur évolué pour comprendre le code.

                            Je suis foncièrement d'accord avec toi. Il se trouve juste que j'ai appris la COO avec SmallTalk dont la syntaxe m'a fait souffrir, et que j'ai eu à en connaître d'autres qui me font moins mal. D'accord pour l'éditeur simple, mais si tu es avec un environnment évolué (qui simplifie le travail), dans le cas de certains hop ! un clic droit sur la routine, on ramène le lien sur une sous fenêtre et paf ! on a une image plus ou moins complète de la routine que l'on avait sous les yeux. C'est pas mal non plus.
                            • [^] # Re: Hors sujet mais pas tant que ça

                              Posté par  . Évalué à 2.

                              Si tu lis ton code depuis autre chose que ton éditeur, c'est dommage. Typiquement, tu essaies de comprendre un bout de code depuis le viewcvs d'un projet, t'es bien embêté.

                              Avoir des aides au niveau de l'éditeur est bien entendu une bonne chose, mais (dans ce cas précis) je vois ça un peu comme une rustine, un moyen de combler une défficience du langage.
                              • [^] # Re: Hors sujet mais pas tant que ça

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

                                Quand les développeurs produiront autre chose que du code (doc, schéma) alors peut être qu'on n'aura plus besoin de considérer ces problèmes de langages et de syntaxe.
                                • [^] # Re: Hors sujet mais pas tant que ça

                                  Posté par  . Évalué à 2.

                                  Quand ils ne s'engueuleront plus sur des questions de syntaxes de code, ils se prendront la tête sur des questions de sémantique UML (ou autre norme de modélisation qui prendrait le relai).
                        • [^] # Re: Hors sujet mais pas tant que ça

                          Posté par  . Évalué à 1.

                          oui et qu'en tu peux choisir entre les 2 modes dans le même langage
                          C'est encore mieux

                          Vive Anaconda

                          []<---
                          • [^] # Re: Hors sujet mais pas tant que ça

                            Posté par  . Évalué à 1.

                            ai dérapé

                            je me corrige
                            "oui et quand tu peux choisir entre les 2 modes dans le même langage, c'est encore mieux

                            pour un peu me moinsserais moi même na!


                            Sérieux, en python on peut passer les argument sans les noms
                            ou avec et ca dans le même appel genre

                            objet.drawpoint(15, 50, red=50, blue=100, green=200)
                            pour les premiers l'ordre est important pour les autres non.
                            • [^] # Re: Hors sujet mais pas tant que ça

                              Posté par  . Évalué à 2.

                              Sérieux, en python on peut passer les argument sans les noms
                              ou avec et ca dans le même appel genre...


                              La possibilité n'est pas suffisante, il faut que ce soit obligatoire.
                              On sait très bien que si c'est optionnel, dès que tu seras pressé, tu l'oublira.

                              D'ailleurs, j'ai déjà fait du Python (pour voir ce que c'est) et je n'ai vu nulle part cette syntaxe...
                  • [^] # Re: Hors sujet mais pas tant que ça

                    Posté par  . Évalué à 0.

                    Ca peut s'écrire comme suit :
                    echantillon_courant := centri.nacelles.item (le_bon_numero_de_nacelle).emplacements.item (le_bon_numero_d_emplacement).element
                    Et décomposé comme ça, ça se comprend de suite.
              • [^] # Re: Hors sujet mais pas tant que ça

                Posté par  . Évalué à 3.

                objet->drawPoint(10, 15, 3, rouge) (...) même si les varibles passées à la méthode permettent de le savoir

                10, 15 et 3 te permettent de savoir de quoi il s'agit ?
                • [^] # Re: Hors sujet mais pas tant que ça

                  Posté par  . Évalué à 2.

                  ce qui ne me parait pas clair ce n'est pas le fait que les paramètre soient explicite au contraire
                  ce qui me gène c'est que le peremier paramètre soit lié avec le nom du message drawPointWithX;

                  c'est pourquoi je précisais

                  [objet drawPoint X: 10 Y: 15 diametre: 3 color: rouge]
                  m'apparait plus naturel
  • # Cocoa/Linux

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

    Il y a une appli qui me plait BEAUCOUP.. mais suqui est en cocoa... c'est facile de mettre ca qui se lance sur une debian testing ?
    (je n'y conncais rien en prog, c'est juste pour savoir si ca se fait ou si faut s'ecrimer comme nu diable et refaire la GUI)

    Le logiciel est la :
    http://lynkeos.sourceforge.net/french/index.html(...)

    Si c'est possible et que quelqu'un(e) est intéressé(e)... On est hyper preneur !! ("on" c'est l'équipe de ca : http://www.lin4astro.org(...) )
    • [^] # Re: Cocoa/Linux

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

      En regardant très rapidement les sources de lynkeos, ça semble relativement simple à porter. Le seul truc bien évidemment (on fait pas de miracles malheureusement), c'est que l'on peut oublier le support Quicktime :-) (y'a une implémentation de quicktime sous linux ??)

      M'enfin pour le reste, c'est à dire faire du traitement sur des images, à priori, y'a pas de raison. Je jette un oeil demain, si je peux.
      • [^] # Re: Cocoa/Linux

        Posté par  . Évalué à 3.

        « (y'a une implémentation de quicktime sous linux ??) »

        Quicktime For Linux (sous LGPL):
        http://heroinewarrior.com/quicktime.php3(...)

        Mais apparement ça n'est que pour les videos quicktime non-compressées.
        • [^] # Re: Cocoa/Linux

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

          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!
          • [^] # Re: Cocoa/Linux

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

            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 :-/
            • [^] # Re: Cocoa/Linux

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

              Euh......... je peux peut etre donner quelques idées aux ceusses que ca intéresse...

              1) on a pas besoin du quicktime. moi ce qui compte c'est qu'il me pernne mes 300-500 images. Après, qu'elles soient dans le conteneur Quicktime ou avi... pour l'astro on s'en fiche.
              >: il utilise juste le fait de traiter une serie d'image comme un film

              voila, c'est ca que je voulais dire. aulieu d'enregitrer 500fichiers, on en a qu'un... bof, ca change rien.

              >d'autant que je vois que vaguement a quoi sert le programme :)

              Le programme sert a :
              charger des images, faire des tranformée de fourier dessus pour arrriver a les aligner. Puis additionner ces images, pour en faire 1 belle. et enfin faire des traitements dessus (deconvolution)
              • [^] # Re: Cocoa/Linux

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

                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..)
            • [^] # Re: Cocoa/Linux

              Posté par  . Évalué à 3.

              Je dis peut-être une énorme connerie, mais il n'y aurait pas moyen de faire un NSMovie qui encapsule ffmpeg au lieu de QuickTime (ou mieux, GStreamer, mais bonjour les dépendances).

              Je n'ai aucune idée de ce que fait le NSMovie de GNUstep actuellement, ni de la charge de travail nécessaire pour encapsuler ffmpeg dedans, mais ça fournirait un moyen relativement portable de travailler avec des vidéos.
              • [^] # Re: Cocoa/Linux

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

                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.
                • [^] # Re: Cocoa/Linux

                  Posté par  . Évalué à 2.

                  J'ai regardé la classe NSMovie... elle ne sert pas à grand chose sinon à ouvrir une URL.

                  J'ai l'impression qu'il faut surtout redévelopper NSMovieView qui apparemment récupère le pointeur vers le film de notre NSMovie.
      • [^] # Re: Cocoa/Linux

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

        Normalement, ffmpeg peut décodé du quicktime sorenson sans dll windows ;) Enfin c'est ce qu'il me semble avoir lu sur la ml mplayer y'a au moins 1 an.
  • # Questions sur la portabilité

    Posté par  . Évalué à 2.

    Bonjour,
    Juste pour faire le point sur l'état de l'art, comme dirait mon client : Qu'est-ce qu'il en est de la portabilité?
    Linux<->Apple <-> Windows (surtout)
    Est-ce une question de méthode, pour être portable? Ne pas utiliser certaines méthodes par ex.
    Est-ce qu'on peut envisager d'utiliser XCode pour directement faire du code qui tournera sur linux voire Windows? Ou est-ce difficile?
    Merci d'avance et longue à lisp fortran net data forth l'assembleur gnuStep!
    • [^] # Re: Questions sur la portabilité

      Posté par  . Évalué à 3.

      Si tu fais de l'OpenStep:

      * Apple: aucun probleme. Ca sera meme du natif, et la rigueur tu peux aussi faire tourner GNUStep dessus (c'est de l'unix)
      * Linux => GNUStep: si tu n'as pas programme sur un Mac en utilisant les extensions proprios, pas de probleme
      * Windows: GNUStep compile avec cygwin ou MinGW, mais cygwin et cie ca vaut ce que ca vaut (pas une super integration avec le systeme qu'il y a en-dessous).

      http://www.gnustep.org/information/machines_1.html(...)
      • [^] # Re: Questions sur la portabilité (Windows)

        Posté par  . Évalué à 4.

        Pour Windows, je vais être un peu plus précis (j'ai testé récemment). Ca demande un peu de boulot pour le compiler (via MinGW), pas vraiment à la portée du néophyte. Par contre, si ton but est de packager une application GNUstep spécifique à destination de Windows, ça ne devrait pas poser de problème. Dans l'ensemble, à part quelques bugs agaçants, GNUstep fonctionne de manière similaire à la version Linux.

        Par contre, certaines applications GNUstep (GWorkspace, notament) font certaines assertions sur la plateformes sous-javente (en gros, ils considèrent qu'ils ont affaire à un Unix-like). Résultat, ça ne compile même pas sous Windows. Mais c'est, à mon avis, quelque-chose qu'on retrouve surtout dans des applis très liées au système (ce qui, pour moi, est le cas d'un shell graphique).

        En fait, la grande question de GNUstep sous Win, c'est son utilité. Du fait des problèmes avec GWorkspace, utiliser un bureau GNUstep complet sous Win n'est pas actuellement envisageable. Et déployer une seule application bien spécifique est rendu un peu délicat par le look "détonnant" de GNUstep.

        Cette situation n'est aucunement définitive, et il y a des développeurs soucieux d'améliorer le support de la plateforme Microsoft, et il y a des développeurs (coucou Rio) soucieux d'apporter les thèmes à GNUstep. Mais pour le moment, pour une appli graphique, c'est un peu prématuré.
        • [^] # Re: Questions sur la portabilité (Windows)

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

          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...
  • # Un peu de mémoire...

    Posté par  . Évalué à 5.

    On a tous été confrontés à des gens qui critiquent le Linux sans le connaitre.

    Du genre « Linux c'est de l'UNIX, ça a 30 ans, il faut vivre avec son temps »; « C'est un joujou pour développeur »; « Ca fait pas tourner mes applications »; « c'est pas beau » ( Celle la, c'était il y a longtemps... )

    Franchement, ça me gonfle un peu d'entendre les mêmes arguments ici, contre GNUstep.

Suivre le flux des commentaires

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