MacOS X et GNUstep : un bel avenir

Posté par  . Modéré par Brice Favre.
Étiquettes : aucune
0
16
sept.
2002
GNUstep
L'excellent article de Delmar Watkins, sur l'avenir commun souhaitable de Linux (avec GNUstep) et Macintosh (avec OS X) a été traduit par le CLX.



Si vous avez raté la première news sur LinuxFR, ou que vous souhaîtez faire passer l'article à des collègues réfractaires à l'Anglais, c'est le moment ;-)



NdM : Je rajoute en lien deux screenshots pour vous faire une idée des looks de GNUstep.

Aller plus loin

  • # Le titre !

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

    Le titre me choque un peu :
    Comment Linux deviendra l'interface graphique utilisateur Ultime
    Il semble ravaler Linux au rang de faire valoir pour une interface graphique, ce qui peut être dommageable. Il me semble que qque chose comme suit aurait été plus opportun :
    Comment Linux deviendra l'environnement utilisateur Ultime.
    D'autres petites divergences gâchent un peu la traduction ...
    • [^] # Re: Le titre !

      Posté par  . Évalué à 4.

      Si tu as la moindre remarque sur la traduction:

      mailto:clx@gaia.anet.fr
    • [^] # Re: Le titre !

      Posté par  . Évalué à 10.

      Linux, c'est pas un noyau plutot qu'une interface graphique?
    • [^] # Re: Le titre !

      Posté par  . Évalué à 4.

      Corrigé.
      Pour les imperfections de traduction, tu as des exemples ?
      • [^] # Re: Le titre !

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

        Merci d'avoir corrige, alors que je considerais cette remarque comme un peu anecdotique. J'aurais du attendre qu'il y ait d'autres posts avant, pour minorer son importance...
        En fait, je ne suis pas un grand litteraire, loin de la, mais en relisant la traduction en diagonale, j'ai eu l'oeil accroche a 2 ou 3 endroits :
        - le titre, donc
        - il manque la seconde partie du paragraphe intitule "Windows Shadows", c'est dommage
        - le paragraphe sur Java et Sun me semble un peu violent : j'adoucirais en ecrivant plutot "[...] les decisions ecervellees de Sun qui l'on rendu lent, penible et [...]"
        - l'absence du paragraphe suivant (qui encense Cocoa) est-elle volontaire ?
        Quoi qu'il en soit, merci pour le boulot fait, que je n'aurais pas eu le courage de faire moi meme ...
    • [^] # Re: Le titre !

      Posté par  . Évalué à 10.

      GNUstep n'est pas une interface graphique mais une plateforme a part entiere.
      C'est une surcouche de Linux (mais pas que de lui) qui permet d'avoir un environnement "complet" fortement inspire de NextStep/OpenStep

      Fred
      • [^] # Re: Le titre !

        Posté par  . Évalué à 1.

        C'est l'auteur qui parle... mais j'ai tenté d'adoucir dans le notes... je vais ajouter une NDT.
  • # le futur de gnustep ?

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

    Précisions qu'il ne s'agit pas de la futur interface de gnustep, simplement d'un thème.
    • [^] # Re: le futur de gnustep ?

      Posté par  . Évalué à 10.

      Comment est-ce que les icônes sont gérées dans GNUstep ? c'est l'appli qui les amène, ou alors est-ce que c'est GNUstep qui les propose ? Parce que dans le second cas, ce serait sympa de pouvoir changer d'ensemble d'icônes. Un peu comme les iconsets de windowmaker.
      • [^] # Re: le futur de gnustep ?

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

        Certaines icones de bases sont fournies par GNUstep (par exemples celles utilisées pour GWorkspace), mais sinon les icones sont inclues dans chaque appli (difficile de faire autrement).
        • [^] # Re: le futur de gnustep ?

          Posté par  . Évalué à 10.

          A preciser que comme tout composant specifique a l'application ses icones sont stockees dans le bundle (directory specifique a l'app) de cette meme appli et sont donc aisement exportables
          • [^] # Re: le futur de gnustep ?

            Posté par  . Évalué à 10.

            enfin je pense quand même que dans un souci d'homogénéité, un "dépôt" d'icônes serait assez pratique. De même que sous windows, on a toujours "fichier", "édition" & co, les applications GNUstep doivent avoir énormément d'icônes en commun, et je pensais que le meilleur moyen de mettre en commun aurait été de laisser GNUstep proposer les icônes aux applications, l'appli faisant une demande du genre :"je voudrais l'icône maison" etc... En plus, par la suite, il est plus facile de changer les icônes de manière globale.

            Dans le cas présent, les icônes sont exportables par l'appli, mais que faire quand on a pas l'appli en question installée et qu'on aimerait profiter de ses icônes ?

            Ou peut-être que la gestion des icônes sort des attributions de GNUstep ?
            J'ai quand même l'impression qu'il y a un réel besoin.
            • [^] # Re: le futur de gnustep ?

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

              Ben en fait le principe que tu propose est déjà celui appliqué : les icones qui peuvent être mises en commun le sont...
              Quand je disais "difficile de faire autrement" c'est qu'en plus des icones "standard" une application peut très bien avoir besoin d'icones spécifiques. Donc là difficile quand même d'intégrer les icones de tout le monde dans GNUstep...
  • # Ouimais.

    Posté par  . Évalué à 10.

    Le gros probleme de MacOSX, c'est que ce n'est pas libre.

    Donc, quel que soit ses "avantages" techniques ou autres, ca reste de la meme trempe que Winmachin.

    C'est sur que ca fait plus rebelle de dire qu'on utilise MacOSX, qu'on est un rebelle parcequ'on n'uilise pas Win.

    Mais bon, la pub pour leur nouvelle lampe, c'est quand meme, entre autre:
    "Utilisez Word, Excel, Powerpoint1".

    De beaux rebeles, je vous dit.
    • [^] # Exactement!

      Posté par  . Évalué à 10.

      Tu veux MacOSX sous GNUstep? Tu t'installes NetBSD avec GNU Step, comme celà, tu as le même OS sous-jacent, mais c'est tout libre!
      Evitons de donner de l'argent et du crédit à ces rois de l'architecture fermée, propriétaire et nombriliste.

      Cordialement,
      • [^] # Re: Exactement!

        Posté par  . Évalué à -3.

        MacOS X est basé sur FreeBSD.
        • [^] # Re: Exactement!

          Posté par  . Évalué à 1.

          A vérifier, mais il me semble qu'ils ont piqué des bouts de FreeBSD et d'autres de NetBSD.
          • [^] # Re: Exactement!

            Posté par  . Évalué à 10.

            Quand je disais basé sur FreeBSD, je parlais du kernel :
            Mac OS X is largely based on one of the most popular and stable open source UNIX variants: FreeBSD. FreeBSD has a long history on the Web [...]
            Source:
            http://developer.apple.com/internet/macosx/intro.html(...)

            Ou sur : http://www.macdevcenter.com/pub/a/mac/2002/06/28/data_visualization(...) on peut lire :
            The Mac OS X kernel, Darwin, is a Mach kernel based on FreeBSD.

            Ou l'interview de Jordan Hubbard, le fondateur de FreeBSD, qui travaille sur Darwin chez Apple...
            http://kerneltrap.org/node.php?id=278(...)

            Autre exemple :
            http://developer.apple.com/darwin/history.html(...) voir section Darwin's Root, pour le kernel Mach :
            FreeBSD, the primary reference platform for Darwin's BSD kernel development.
            Là effectivement il est fait référence à NetBSD :
            NetBSD, the upstream source for a significant portion of Darwin's user-space commands and tools.
            Les outils niveau utilisateur viennent de NetBSD, c'est tout simplement du à la portabilité légendaire et bien réelle de cet OS. Ca évite de se casser le cul à chercher ou ça coince pour compiler sur le G4 !
            Bien entendu, Free/Net/OpenBSD ont des morceaux de kernel communs, mais l'OS de référence est bien FreeBSD.
        • [^] # Re: Exactement!

          Posté par  . Évalué à 10.

          Il est surtout basé sur Darwin, qui implémente un micro-noyau MACH, mais je pense que la comparaison s'arrête là...

          A vérifier sur la chrono unix (je sais plus où elle est, mais http://www.google.fr/search?q=chronologie+unix(...) devrait répondre ;-)
          • [^] # Re: Exactement!

            Posté par  . Évalué à 6.

            Desole pour toi mais MacOSX s'appuie sur Darwin qui s'appuie sur NetBSD ... donc le post precedent est correct


            Quand a a'appuyer sur Mach cela n'empeche pas de faire tout le reste sur la base de NetBSD (libraries, hierarchie de base des directory POSIX, ... )

            fred
            • [^] # Re: Exactement!

              Posté par  . Évalué à -2.

              Désolé pour toi aussi tu as tout faux, Mach est bien basé sur FreeBSD, n'importe qui avec un peu de culture en informatique te le confirmera !
              • [^] # Re: Exactement!

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

                > Désolé pour toi aussi tu as tout faux, Mach est bien basé sur FreeBSD,
                > n'importe qui avec un peu de culture en informatique te le confirmera !

                Mach basé sur FreeBSD ? C'est quoi cette blague ? Darwin sur FreeBSD, ok, mais Mach sur FreeBSD ? Et MkLinux, alors, c'est un Linux qui tournait sur un FreeBSD, en fait ?
                Mondieumondieumondieu, qu'est-ce qu'il faut pas entendre ...
                :-)


                seb.
          • [^] # Re: Exactement!

            Posté par  . Évalué à 2.

            Sinon pour la page est elle sur le site perso de Eric Levenez : http://www.levenez.com/(...)
        • [^] # Re: Exactement!

          Posté par  . Évalué à 3.

          Possible. J'ai entendu des bruits contradictoires là dessus et en regardant un peu l'arborescence de Mac OS X dans un terminal, j'ai eu l'impression que ça ressemblait plus à NetBSD. Mais vu que je ne suis un expert ni de l'un ni de l'autre, j'ai pu me tromper.
          Celà dit, ca ne change rien à mon propos. :-)

          Cordialement,
        • [^] # Re: Exactement!

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

          Sur Mach, le noyau des BSD, et non pas une distrib de BSD/Mach (c'est vrai, on devrais dire ça, comme on dit GNU/Linux ;p)
    • [^] # Re: Ouimais.

      Posté par  . Évalué à -1.

      oui c pas libre et alors ou est le probléme ? faut dire vu la qualité et le niveau t'intégration de macosx avec les autres appli ca peux forcement pas etre libre ....
  • # simply gnustep

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

    Simply GNUstep a plus l'air de s'orienter vers une distrib particulière de linux, intégrant correctement GNUstep... cela permet de montrer simplement à certains cet environnement (bien que pour le moment Simply GNUstep n'utilise pas toujours les dernières versions des applications).

    Par contre, LinuxSTEP (http://www.linuxstep.org(...)) me paraît, à terme, plus intéressant. Ils ont beaucoup plus de boulot à faire, mais leur idée est de faire un OS basé sur GNUstep et le kernel linux.

    Je pense que cette approche a peut être plus de chance d'obtenir un OS plus accessible pour le grand public (entre autre, hièrarchie FS plus simple, etc).
    • [^] # Re: simply gnustep

      Posté par  . Évalué à 6.

      Euh... c'est quoi un truc qui met des applications autour d'un noyau linux ? Une distrib, non ? J'ai du mal à saisir la différence de philo entre Simply et LinuxStep...
      • [^] # Re: simply gnustep

        Posté par  . Évalué à 9.

        Un distrib classique se doit de respecter quelques prerogatifs propres a tous systémes Unix/Posix, genre ce foutoir qu'est /usr .
        Le principe de LinuxSTEP c'est de faire du GNUstep par dessus un noyau linux, pas de faire du GNU/linux classique dessus, ca fermerait donc a cette distrib tous les packages classiques, mais lui permetrait de créer un systéme beaucoup plus addapté au desktop.

        GNUstep est un framework, faut pas l'oublier.

        Bon apres l'idée est bonne mais ca risque de demander pas mal de travail. Les applications GNustep sont pas legions, l'Objective-C fait peure a bon nombre de developpeur C et C++ qui se demande pourquoi apprendre un nouveau language meconnue, pour developper sur GNUstep qui pour le moment fait trés vieilliot niveau interface ( tous gris, avec des barre et des icones assez moches, y a du boulot la aussi a fournir parce qu'est pas trés convivial par rapport a MAC OSX ou QT/GTK ).
        • [^] # Re: simply gnustep

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

          Eh faut arrêter l'assimilation (convivialité == jouli thème)

          Je préfère de très loin avoir des interfaces cohérentes et bien pensées mais avec le look -- peu attrayant il est vrai -- de {NeXT,Open,GNU}Step, que des trucs à la windoze mais avec un monceau de thèmes...

          Monceau duquel on ne peut tirer le plus souvent qu'1 ou 2 thèmes à la fois complets et pas trop chargés, ce qui revient à la solution 1, mais après des heures de recherche...
          • [^] # Re: simply gnustep

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

            C'est sur, mais il faut bien voir que le théme GnuStep était génial sur un moniteur N&B (les premiers Next étaient N&B) car les couleurs contrastes bien et ne sont pas trop fatiguante, en couleur, c'est trés "tristounet" et un peu "gerbatif".
            Alors certes l'interface est lisible, mais pas agréable visuellement, sans avoir pleins de gadget à la con, ça serait bien d'avoir un théme plus adapté à un écran couleur.
            De même sur l'exemple de GnuStep déguisé en Aqua, les bords de fenêtres restent bien Noir, ça rend l'interface moins consistante, ce qui n'est pas le but recherché.
            J'ai adoré les machines Next à leur sortie, je les utilisais à la fac.
            Mais il y a toujours un truc que je trouve imbittable, c'est le gestionnaire de fichier, qui pour moi, n'est pas trés pratique. Il y a trop d'infos affichés et on ne peut pas faire l'économie d'en ouvrir un deuxième si on veut comparer plusieurs répertoires.

            Non sérieux, je sais bien que Gnustep est cohérent, bien pensé, etc...
            Mais un peu plus de couleurs et moins de gris (je ne parle pas de graphismes et d'animations à la con) ça ne ferait pas de mal, et donner nous un gestionaire de fichier qui soit moins lourd à utiliser.
            • [^] # Re: simply gnustep

              Posté par  . Évalué à 3.

              > De même sur l'exemple de GnuStep déguisé en Aqua, les bords de fenêtres restent bien Noir, ça rend l'interface moins consistante, ce qui n'est pas le but recherché. Juste pour info, les bords de fenetre ne sont pas geres par le moteur de theme (qui n'est pas termine, ca explique pourquoi les tables ne sont pas encore themees, etc) mais par le gestionnaire de fenetre, il aurait fallu mettre un theme aqua pour windowmaker.
  • # Unix, bureaux et MacOS X

    Posté par  . Évalué à 7.

    Il y a un édito passé sur Freshmeat sur le futur des bureaux Linux et MacOS X, en réponse à un article de Tim O'Reilly, et qui n'a pas le même avis sur l'avenir des bureaux Unix.

    http://freshmeat.net/articles/view/557/(...)
    • [^] # Re: Unix, bureaux et MacOS X

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

      Je viens de lire cet article, c'est grosso modo un troll bien poilu, avec bien peu d'arguments. Exemples :

      "gcc/gdb/fortune ne sont pas livrés avec MOSX ! c'est donc pas un UNIX!" ==> gcc et gdb sont sur le developer disc, ce qui semble quand même très normal.

      "alors que quand même, citez moi une distrib linux qui ne livre pas gcc !" ==> si on choisit une install NON développeur, la plupart des distribs n'installent pas gcc, ce qui là encore est logique.

      "Y'a pas X11 ! c'est donc pas un UNIX" ==> depuis quand il faut X pour être un Unix ? de plus, XDarwin existe, et fait tourner sans problèmes les applis X11...

      et ça continue sur cette lancée, comme quoi apple c'est le mal, etc. Certains points sont valables
      (rappel que l'intérêt majeur de linux, c'est qu'il est libre), mais le reste de l'article suffit à déconsidérer les rares arguments potables.

      D'autant que ces arguments n'empêchent pas pour autant une éventuelle progression de MOSX sur le desktop...

      Bref article à la poubelle... et c'est dommage, car il y a quand même pas mal de choses à critiquer sur Apple et ses positions. Mais bon, honnêtement, leurs produits sont quand même bien près de ce que l'on aimerait avoir sous linux.
      • [^] # Re: Unix, bureaux et MacOS X

        Posté par  . Évalué à 5.

        Y'a néanmoins des arguments valables :

        Apparement, dans MacOS X, les fichiers de conf ne sont pas dans /etc mais dans des fichiers binaires (ceci dit, ça semble être en projet pour certains environnement "libres").

        Ensuite, les arguments de Tim O'Reilly de type "ça marche", "ça ne suce pas des ours", n'en sont pas non plus, et ce n'est pas un tort de le signaler...
        • [^] # Re: Unix, bureaux et MacOS X

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

          >(ceci dit, ça semble être en projet pour certains environnement "libres").

          Si tu penses a E17, ça sera pas le cas avant quelques temps :)
          • [^] # Re: Unix, bureaux et MacOS X

            Posté par  . Évalué à 2.

            oui, enfin, dans E17, il s'agira quand même d'un système de BD très bien documenté (pour le moment pas trop, Use the Source Luke).
            Donc, n'importe qui sera à même de coder une appli pou aller écrire dedans... et comme c'est pas très courant de scripter la config des environnements de bureaux (si c'est nécessaire, genre pour un environnement d'entreprise homogène, il suffit de copier les bases, je ne vois pas d'autres applications... mais mon imagination à des limites, forcément :) ).

            Enfin, qu'est ce qui empêchera de faire un DB::enlightenment, hein, je vous le demande ?
            et de remplir la base à partir d'un fichier texte ?

            Je ne sais pas ce qu'il en est de MacOS X, mais en tout cas, je ne me fait pas de soucis pour enlightenment (même si j'aime bien utiliser vim comme outil de conf, car vim est, lui, vraiemnt user-friendly, c'est bien connu).

            Bon, fin du troll, vous pouvez reprendre une activité normale :)
        • [^] # Re: Unix, bureaux et MacOS X

          Posté par  . Évalué à 2.

          macosx stocke les user , les groups etc ... non pas dans des fichiers binaires mais dans "NetInfo" c'est une sorte de mini annuaire ldap local. plein de softs le supportent en vrac postfix et samba
  • # Apple, la pomme qui voulait cacher la foret.

    Posté par  . Évalué à 10.

    Delmar Watkins se fout ouvertemant de notre gueule avec cette article, si on le decortique correctemant c'est ni plus ni moin, amis developpeur linux arrettaient de developpeur pour KDE et Gnome, et tournez vous vers GNUstep ainci vous pourez venir developper sur un systéme MAC demain.

    Il nous amuse et titille la corde sensible, en nous parlent de GNUstep, d'opensource et de framework multi-platforme sur le model de next. Mais qui imagine serieusemant que GNUstep pourra ratraper le retrard accumulé depuis quelque temps dans le domaine des environnemant graphique ? On compte plusieur clients de mails qui tourne sous GNOME, alors qu'il n'y a qu'un sous GNUstep et c'est encore l'un des seul applications stable dans la petite dizaine d'applies propres a GNUstep. Delmar ne fait pas la promotion de la framework next ou assimilé, mais simplemant de MAC OSX, si ils veuelent ramenter les developpeur du monde du LL avec GNUstep ils feraient bien de commencer par donner quelque lignes de codes et des developpeur pour redonner un peut d'energie a GNUstep qui fait pale figure face a GNOME/KDE, qui on surment le default par moment de singaient windows, mais qui n'ont pour le moment pas les porblémes d'Apple avec la compatibilité unix.
    • [^] # Re: Apple, la pomme qui voulait cacher la foret.

      Posté par  . Évalué à 10.

      > qui imagine que GNUstep pourra ratraper le retrard accumulé depuis quelque temps

      J'ai testé GNUstep il y a 12 - 18 mois et j'ai été très, très déçu (surtout par rapport à tout le "bruit" fait autour). Très déçu car j'avais une nextcube (ya très longtemps et N/B) et que GNOME (connait pas KDE...) était bien meilleur (Et je parle pas du look qui est la cadette de mes préoccupations).

      > GNOME/KDE, qui on surment le default par moment de singaient windows

      Singer windows est un défaut ?

      Se forcer a prendre des distances avec de bonnes solutions est une bonne idée ?

      L'interface graphique Windows a des défauts, mais aussi de fortes qualités. La copier n'est pas forcément une erreur.

      PS: j'ai compris que "singer windows" n'est pas un gros défaut pour toi. C'était juste pour dire que pour moi avoir des trucs qui ressemble à windows ne me pause pas problème (fausse pour
      - cliqué sur démarrer pour arrêter
      - le bouton annuler dans la fenêtre de login
      - c: d: ...
      - leur séparateur de répertoire à la con '\'
      - l' absence de message d'erreur claire en phase de boot.
      - Installer le driver avant d'installer le périphérique.
      - Les trous de sécurité
      - Les anti-virus
      - Ses fenêtres modales.
      - Ses nombreuses fenêtre non-redimensionnable.
      - Sa capacité à rendre perplexe le plus pointu des administrateurs réseau.
      - Sa capacité a générer des conflits entre cartes PCI ?!?.
      - Son obsession à lire A: alors que je n'ai pas de lecteur de disquette.
      - etc... )

      Y a encore plein de choses à ne pas copier...
      • [^] # Re: Apple, la pomme qui voulait cacher la foret.

        Posté par  . Évalué à 10.

        Tu parles d'énormités la :)

        La Consistance d'un desktop ne vient pas que de la :

        la différence entre MOSX/OpenStep (et je l'espère
        GNUstep) et le monde Windows / KDE / Gnome
        c'est :

        1- on sait immédiatement comment doit se comporter une appli (meme si on la lance depuis la premiere fois) cela implique par exemple :

        - Des racourcis clavier commun pour toute les actions
        - des menus toujours a la meme place (ex. sous macOSX Preference c dans Nom_de_lappli -> Preferences)
        - des panneaux semblables (alert,couleur fonts..)
        - un comportement similaire a la souris (un simple clic selectionne, un double ouvre par ex.)
        - enlever toutes les choses inutiles (bloat)
        - conserver une coherence de l'interface pour toutes les applications
        - ne pas avoir plus de 3 sous menus ...
        - ne pas avoir 3 rangés d'onglets....
        - ne pas avoir une représentation de la toolbar
        vertical lorsqu'il faut la configurer alors qu'elle est naturellement vertical .....

        J'en passe et des meilleurs.

        Il m'a fallu un jour pour comprendre comment fonctionné l'interface Mac OSX et maintenant des qe j'installe une application jai tout de suite mes repères.
        C'est loin d'être le cas pour Windows/KDE ou Gnome


        C'est aussi une affaire de gout :

        OpenStep est construit dans l'esprit de faire d'applis qui font bien une chose et qui communique bien ensemble : comme sous Unix

        alors que le monde Windows c'est une appli intégré qui fait énormément de choses (au détriment de la lisibilité et de parfois des incohérence au niveau de l'ergonomie)

        GNUstep tire (devrait tirer) sa guideline de
        OpenStep/NeXStep :
        - http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=(...)

        et de son descendant naturel MacOSX :
        http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuideli(...)


        A user interface must meet the needs of both novice and experienced users:

        * For the novice or infrequent user, it must be simple and easy both to learn and to remember. It shouldn't require any relearning after an extended absence from the computer.

        * For the more experienced user, it must be fast and efficient. Nothing in the user interface should get in the way or divert the user's attention from the task at hand.


        nextuiguide


        Et ne me dite pas que vous vous n'etes jamais dit sous Windows ou Gnome (malgré vos 2 ans d'utilisation) "bon comment on fait ca déjà ?"
        ou
        "ou sont les preferences de cette nouvelle appli
        ?"

        (désolé pour la longueur)
    • [^] # Re: Apple, la pomme qui voulait cacher la foret.

      Posté par  . Évalué à 8.

      On compte plusieur clients de mails qui tourne sous GNOME, alors qu'il n'y a qu'un sous GNUstep

      je pense que c'est plus un problème pour Gnome que pour GNUstep. Côté Gnome, c'est plus une inutile dispersion de compétence qu'une force : tout le monde a les mêmes besoins en ce qui concerne un logiciel de courrier électronique.

      Mais qui imagine serieusemant que GNUstep pourra ratraper le retrard accumulé depuis quelque temps dans le domaine des environnemant graphique ?

      Ca ne paraît pas impossible vu que GNUstep n'est pas handicapé par le choix foireux de faire de l'objet en pur C. Et ne me parlez pas des bindings C++, python et perl qui sont utilisées dans des applis clientes, mais sûrement pas dans le "noyau" Gnome. Pourquoi s'emmerder à faire de l'objet en C quand il y a tant de bon langage objet qui facilite la tâche. GNUstep a choisi Objective C (peu répandu, certes, mais facilement abordable), c'est un vrai langage objet, et qui tient largement la route. C est une malédiction pour Gnome.

      De plus, GNUstep ne part pas de zéro, il implémente OpenStep, un truc étudié et éprouvé, et ça aussi c'est du temps de gagné.
      Le projet Gnome a attendu des lustres par exemple avant de pondre Bonobo.

      Quand à la soi-disante stratégie Apple de rameuter les développeurs GNUstep, c'est de l'extrapolation facile. Il ne s'agira pas de rameuter, mais de profiter de l'API commune de GNUstep et Cocoa pour avoir des applis portables entre ces deux frameworks. Il ne s'agit pas de développer pour GNUstep pour ensuite se tourner vers Cocoa, mais pour les deux à la fois. Si les applis en question sont libres, je ne vois pas de problèmes à ce que les plateformes supportées soient plus nombreuses.

      On pourrait aussi dire que, à terme, GNUstep et ses applis sont la possibilité pour les utilisateurs de MacOS X de retrouver un environnement identique mais libre (et donc, en pratique, gratuit), ce qui n'est pas très bon pour Apple. GNUstep peut ainsi représenter une menace, et pas une opportunité, pour Apple. Question de point de vue.
      • [^] # Re: Apple, la pomme qui voulait cacher la foret.

        Posté par  . Évalué à 3.

        je pense que c'est plus un problème pour Gnome que pour GNUstep. Côté Gnome, c'est plus une inutile dispersion de compétence qu'une force : tout le monde a les mêmes besoins en ce qui concerne un logiciel de courrier électronique.

        Les Forks, les projets multiples et autres sont une des specialitées des logiciel libre, ce n'est surment pas tres productifs mais c'est la preuve que beaucoup de developpeur et d'idée tourne autour d'un projet.
        De plus les besoins, sont loin d'étre les méme pour tous méme en ce qui concerne un logiciel de mail, certains recherche la simplicitée, d'autre des clients avec des fonctions assez complexe de filtrage et de reponces automatique etc etc ...
        C'était juste un exemple pour montrer qu'il n'y a pas a ma connaissance beaucoup de projets qui sont basés sur GNUstep, alors que celui-ci est mature.
        GNUstep tous le monde nous parle de Next et de son concepte revolutionnaire, mais rarement de GNUstep méme qui est assez décevent.

        GNUstep a choisi Objective C (peu répandu, certes, mais facilement abordable), c'est un vrai langage objet, et qui tient largement la route. C est une malédiction pour Gnome.

        Hum, le choix du C dans GNOME n'est pas qu'un pure hasard, oui c'est handicapent, et surment le projet GNOME aurait largemant beneficier d'un language objet, mais il a été choisie pour deux principale raisons, la large majoritée des developpeur GNU/Linux/*BSD code en C, La volonté de se demarqué du projet KDE et du C++. GNOME est née de la contestation de KDE/Qt pour les histoire de licence qu'on sait, c'est assez béte et je pence que personne n'y a vraiment gagnier mais c'est comme cela. Quand au language Object, qui est en effet un critére assez décisif, KDE a un enorme aventage sur GNUstep le C++ est surment bien plus complexe que l'Objective C, mais il est connue enseignié, et la literature sur ce language ne manque pas ce qui n'est pas le cas de l'Obj. C.

        Si les applis en question sont libres, je ne vois pas de problèmes à ce que les plateformes supportées soient plus nombreuses.

        Mois non plus je vois pas de problèmes a ce que les plateformes soit plus nombreuses, mais que Apple nous montre l'exemple pourquoi developper pour du GNUsetup, alors qu'un programme en Gt ou GTK+ touchera plus d'utilisateur et plus de plateforme ?
        Pour prendre un exemple concret, qui s'intressé a XUL de Mozilla, sans Mozilla, a GTK+ sans The Gimp, GNUstep est surment une bonne plateforme et l'Objective C un language tous a fait addapté a cette environnemant, mais pour le moment GNUstep ne donne pas franchemant envie develloper pour, si demain Apple fait tourner Quicktime ou je ne sais quel de ses applications uniquent sur GNUstep et les choses pourrait changés.

        On pourrait aussi dire que, à terme, GNUstep et ses applis sont la possibilité pour les utilisateurs de MacOS X de retrouver un environnement identique mais libre (et donc, en pratique, gratuit), ce qui n'est pas très bon pour Apple. GNUstep peut ainsi représenter une menace, et pas une opportunité, pour Apple. Question de point de vue.

        En tous cas pas dans un futur proche, parce que pour ce que j'en ais vue les utilisateurs de GNUstep utilise plus les fonctions de windowsmaker que GNUstep, tu peux les mettre derriére BlackBox/FluxBox ou autre ils sont pas depaysés, il utilise un menu deroulant pour lancer des applies qui se passe trés bien de GNUstep. Apple ne se mouillie vraiment pas avec GNUstep, ils font la promotion de leurs technologies par l'intermediaire de GNUstep, qui ne risque pas de leurs faire de l'ombre de sitot, contrairemant a XUL de Mozilla, NET, et les autres frameworks, dans le communiqué ils se génent pas pour enfoncer JAVA par exemple, Apple a basé son bizznes sur la difference, le pire qui puisse leur arriver c'est que les utilisateurs d'appel retrouve les méme applis la méme conseption d'interface aillieur que chez Apple et les preuvent s ne manque pas ( par exemple la chasse au skinner qui reprenait de trop pret l'interface Aqua a sont lancemant, le passage a vide avec adobe quand cesi on dessidait de ne faire qu'une seule et méme interface pour leurs produti quelque soit l'OS etc etc ... ).

        GNUstep peut ainsi représenter une menace

        Pour le moment GNUstep n'est pas plus une menace pourqui que ce soit que n'importe quel windowsmanager, sa framework péine a decoller et tous dans ce projet se fait vieillisant, Apple le sait et l'exploite c'est justemant ce que je leur reproche.
        • [^] # Re: Apple, la pomme qui voulait cacher la foret.

          Posté par  . Évalué à 3.

          > Hum, le choix du C dans GNOME.

          > la large majoritée des developpeur GNU/Linux/*BSD code en C

          Juste.

          > La volonté de se demarqué du projet KDE et du C++

          Non.
          C'était pour avoir des "languages bindings". En effet, C++ est un excelent language mais incompatible avec de nombreux language. Et il a toujours été question d'avoir un "wrapper" C++ pour GNOME/GTK !
          Ceci permet à Gnome (et/ou) Gtk d'être programmable en C, C++, Perl, Python, Php, Scheme, Guile, Java, Objective C (et oui :-) ), C#, etc...

          http://erik.bagfors.nu/gnome/languages.html(...)
          Tout n'est pas parfait ...

          Cette possibilité est beaucoup moins visible avec QT où les bindings sont beaucoup moins nombreux.
          • [^] # Demande de confirmation ici

            Posté par  . Évalué à 4.

            Bon, je ne suis pas un expert et je vais probablement me bruler mais... autant que je me souviennes des derniers changelogs de KDE, il y a des bindings pour pratiquement tous les langages dont tu parles : C, Python, Php, Java, etc.
            En fait le package de kdebindings donnent les infos suivantes :

            dcopc (DCOP bindings for C), dcopjava (DCOP
            kdebindings: bindings for JAVA), dcopperl (DCOP bindings for Perl), dcoppython
            kdebindings: (DCOP bindings for Python), kalyptus (C, Objective-C and Java bindings
            kdebindings: generator), kdec (KDE bindings for C), kdejava (KDE bindings for Java
            kdebindings: JNI to use Qt/KDE classes with Java), kdeobjc (KDE bindings for
            kdebindings: Objective-C), qtc (Qt bindings for C), qtjava (Qt bindings for Java
            kdebindings: JNI to use Qt/KDE classes with Java), qtobjc (Qt bindings for
            kdebindings: Objective-C), xparts (allows you to embed non-KDE apps as a KPart


            Bref, apparemment, ce que QT ne fournit pas en natif, KDE l'a apporté.
            Donc l'argument ne me semble pas très convaincant.

            Cordialement,
        • [^] # Re: Apple, la pomme qui voulait cacher la foret.

          Posté par  . Évalué à 2.

          De plus les besoins, sont loin d'étre les méme pour tous méme en ce qui concerne un logiciel de mail, certains recherche la simplicitée, d'autre des clients avec des fonctions assez complexe de filtrage et de reponces automatique etc etc ...

          Est-ce que ces besoins sont incompatibles ? je ne crois pas. Une bonne application, c'est comme un bon langage. Comme dit Larry Wall : "ça doit rendre les tâches simples faciles, sans rendre les tâches complexes impossibles." Et puis des fonctions de filtrage et de réponse automatique, c'est pas ce qu'il y a de plus complexe. Mais c'est vrai que tout le monde ne s'en sert pas, ce qui prouve que les besoins diffèrent. Mais les besoins de base sont les mêmes. Il est facile de mettre les fonctionnalités en place pour ces tâches, tout en rajoutant des fonctionnalités pour des tâches plus complexes, sans que celle-ci fasse obstacle à l'accomplissement des tâches simples. De plus, si les besoins d'un utilisateur augmentent, ça ne forcera pas l'utilisateur à changer de lecteur de mail. Un tout cas, pour les lecteurs de courrier électronique, un logiciel doit répondre à tous les besoins. Peut-être que pour d'autres types de logiciels, il peut être pratique d'avoir diverses solutions.

          ...deux principale raisons, la large majoritée des developpeur GNU/Linux/*BSD code en C, La volonté de se demarqué du projet KDE et du C++

          Je comprends mais je n'approuve pas. La deuxième raison tient de la réaction infantile ("on va dire qu'on triche"), la première est fondée, mais à mon avis, c'est un faible avantage comparaît à l'inconvenance de C pour la programmation objet.

          le C++ est surment bien plus complexe que l'Objective C, mais il est connue enseignié, et la literature sur ce language ne manque pas ce qui n'est pas le cas de l'Obj. C.

          Tu vas encore hurlé, mais il ya bcp d'excellentes documentations Objective C sur le site developpeur Apple. Mais c'est vrai qu'il est moins enseigné que C++.
          Mais en connaissant le C et la COO, on peut facilement apprendre objective C en moins d'une semaine. Avec de la volonté, le projet GNUstep est donc très accessible.

          Pour prendre un exemple concret, qui s'intressé a XUL de Mozilla, sans Mozilla, a GTK+ sans The Gimp

          Oui c'est vrai que GNUstep n'a pas de vitrine alléchante, quoique GNUmail.app soit un excellent lecteur de mail. Ca manque de "marketing" et c'est peut-être ce qui lui fait défaut.

          L'exemple de Quicktime est assez mal choisi puisque c'est un des logiciels apple qui ne suit pas du tout les "guidelines" IHM Apple. Et je ne crois pas qu'il utilise Cocoa, car ça rendrait difficile son portage sous windows.

          Enfin on a compris que GNUstep manquaient d'une application star qui ramèneraient des développeurs et des utilisateurs.

          tous dans ce projet se fait vieillisant, Apple le sait et l'exploite c'est justemant ce que je leur reproche.

          se fait vieillissant... bof, le développement est quand même assez actif, le modèle n'est pas obsolète. Le seul truc qui puisse faire vieux, c'est le thème step morose.

          Enfin j'ai mieux compris ce que tu voulais dire au début. Mais ça suppose que le projet GNUstep n'aboutit pas, ce qui n'est pas fondé, et que Apple a une stratégie pour ramener les développeurs Linux sur Mac, ce qui est une extrapolation de l'article. Si GNustep ne ramène pas de monde selon toi, Apple en ramèneras alors encore moins à mon avis.
          • [^] # Re: Apple, la pomme qui voulait cacher la foret.

            Posté par  . Évalué à 2.

            A propos d'apllication phare, qui se souvient de Lotus IMPROV ? c'était un tableur excellent, qui a été porté sous Windows, et - vraiment - sortait des sentiers battus. Depuis, les fonctionnalités phares (ce qui s'apelle maintenant tableaux croisés) ont été portés sur d'autres tableurs renomés, mais c'était quand même un excellent logiciel, 100% NeXT. Peut-être OpenStep ? [réponse au mail précédent] Ce n'est pas parce qu'il y a plus de developeurs sous KDE/Gnome que c'est mieux. Sinon, pourquoi utiliser linux ? Il y a plus de dévelopeurs sous Windows ! Enfin, pour les % de parts de marché, KDE+Gnome, ça représente 2% OK. MacOS X + GNUStep, ça en fait 6. Du simple au triple. Le choix marketting est vite fait.
            • [^] # Re: Apple, la pomme qui voulait cacher la foret.

              Posté par  . Évalué à 2.

              1) MAC OSX n'utilise pas GNUstep 2) http://gnustep.orange-concept.com/information/faq_1.html#SEC1 Section 1 de la FAQ de GNUstep, GNUstep n'est pas compatible avec Cocoa, parce que Cocoa est proprio. Le portages de applis OPENstep n'est pas complet etc etc ... Si apple veut promouvoir le libre, qui tourne aussi sur ses machines il ferait bien de commencer par arranger ca il me semble non ? GNUstep c'est une part infime des desktop, méme en considerant que les simple utilisateurs de Windows maker sont des utilisateurs GNUstep. GNUstep n'est pas compatible avec les lib et les systémes Apple contrairement a ce qu'ils essaient de faire croire uniquement pour promouvoir leurs technologie qui bien entendut n'est pas libre, ni méme ouverte.
              • [^] # Re: Apple, la pomme qui voulait cacher la foret.

                Posté par  . Évalué à 1.

                Section 1 de la FAQ de GNUstep, GNUstep n'est pas compatible avec Cocoa, parce que Cocoa est proprio. C'est largement exagéré. Les objets distribués et les formats d'archivage de données sont incompatibles, et le deuxième problème peut se résoudre en implémentant un format "maison". Pour le reste, c'est de l'implémentation simple des specs OpenStep. GNUstep c'est une part infime des desktop, méme en considerant que les simple utilisateurs de Windows maker sont des utilisateurs GNUstep. 1- on dit Windowmaker 2- en disant ça, tu n'as rien dit. Tout est relatif. GNUstep n'est pas compatible avec les lib et les systémes Apple contrairement a ce qu'ils essaient de faire croire uniquement pour promouvoir leurs technologie qui bien entendut n'est pas libre, ni méme ouverte. comme je l'ai dit ce n'est vrai qu'en partie en ce qui concerne la compatibilité. oh tiens !! les spécifications openstep : http://www.gnustep.org/resources/OpenStepSpec/OpenStepSpec.html incroyable !!!! encore plus incroyable : open veut dire ouvert !!! évidemment je parle des specs, pas de technologies Apple. Mais le fait est que les spécifications d'OpenStep, et donc de Cocoa en grande partie, sont librement accessibles. Les fautes d'orthographes sus-cité sont déposés auprès de leurs propriétaires respectifs. Aucune responsabilité n'est engagé sur la lisibilité du message ou les éventuelles dommages qu'il peut engendrer. Beretta Vexée ça c'est marrant au début, mais franchement, niveau orthorgraphe, ça devient du manque de respect et tu perds en crédibilité.
              • [^] # Re: Apple, la pomme qui voulait cacher la foret.

                Posté par  . Évalué à 2.

                >GNUstep n'est pas compatible avec les lib et les systémes Apple contrairement a ce qu'ils essaient de faire croire uniquement pour promouvoir leurs technologie qui bien entendut n'est pas libre, ni méme ouverte. C'est faux et les portages qui sont en cours te le prouveront. Voici les principales différences (actuellement) entre Cocoa et GNUstep : - Pas de ObjC++ (devrait être intégré a la branche officiel de gcc) : permettrait d'avoir Chimera (le GaleonStep) - Pas de Cabon (environnment Classic) - Pas de ToolBar (en cours de developpement chez GNUstep) - Pas de Drawers (qui n'est pas ergonomic mais qui sera implémenté aussi pour certain portage) - pas d'extention propiétaire (QuicktimeView par ex.) - le .nib (l'interface crée avec Interface Builder) est propriétaire. il faut avoir MOSX/IB d'un coté et Gorm(le clone de IB) de l'autre le reste passe sans probleme majeur
      • [^] # Re: Apple, la pomme qui voulait cacher la foret.

        Posté par  . Évalué à 1.

        Ben mo, je suis bien content qu'il y ai eu dispersion. Heureusement que j'ai pu trouver autre chose qu'evolution. J'ai pas besoin d'un truc qui me donne la meteo, les cours de la bourse, qui lise les news ... et en plus qui lise le courrier, mais qui se charge en 1min. Heureusement que j'ai trouvé balsa, cronos, pour enfin arriver à sylpheed.
  • # Un bureau classique ?

    Posté par  . Évalué à 6.

    les posters aubade sont inclus dans la prochaine version de Gworkspace.app ?
  • # un peu toujours la même chose

    Posté par  . Évalué à 3.

    1) ohhh mac os c'est beau, c'est cher c'est proprio
    2) mais dis donc, même si je t'ai précédemment pas vraiment aidé, tu sais que tu pourrais me filer un max d'application gratos (libre je m'en fous, mais gratos en fait) pour mon mac os,
    3) comment ça je te prend pour un con,
    4) comment ça, ça se voit comme le nez au milieu de la figure ?

Suivre le flux des commentaires

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