RMS encourage la collaboration entre Gnome et KDE

Posté par  (site web personnel) . Modéré par Amaury.
Étiquettes :
0
19
fév.
2002
KDE
Richard Stallman, maintenant que Qt est bel et bien soumis à une licence libre, encourage la collaboration entre GNOME et KDE. En particulier, il donne l'exemple des thèmes (il souhaite une unification des thèmes) et attend d'autres suggestions.

Si la collaboration GNOME - KDE se fait plus ou moins (collaboration plus large que les simples thèmes), alors effectivement, les fonctionnalités d'interopérabilité entre les deux logiciels pourraient pousser le LSB à intégrer les desktops dans ses propres spécifications. Ce serait donc grand pas en avant et impact en dehors du desktop seul.

Par exemple : Comme RPM est le système de packaging du LSB, alors on peut également proposer une fonctionnalité d'intégration par défaut dans les menus KDE-GNOME de chaque application directement dans le format RPM (ndm : huh ?).

Aller plus loin

  • # La fin d'un des plus beaux nids a trolls ?

    Posté par  . Évalué à -10.

    Kdnome Roul41z3 Gde su><><><><>< !?!?!?

    snif, la fin d'une epoque...

    [-1jesors]

  • # Vers l'unification et l'au-delà !!!

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

    <troll> Pour une fois que RMS dit pas de conneries</troll>

    C'est vrai qu'une unfication des menus serait super utile. Certaines distrib le font déjà mais au pris de parsing et de mises à jour bouffeuses de ressources à chaque install d'un soft.
    Le tout est de trouver un format commun.
    Le mieux est AMA celui de la gestion par répertoire et fichier par item du menu avec dedans les type mimes et extensions des fichiers supportés pa l'applis.
    Le tout pourrait être stocké dans .menu et tout WM pourrait en profiter.

    Quant pense les KDE/GNOME développeurs ?

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Vers l'unification et l'au-delà !!!

      Posté par  . Évalué à 10.

      Une des distributions qui le fait (je ne donnerais pas le nom pour ne pas attirer un troll qui trainerai dans les parages, mais sachez que son nom commence un un D), laisse le soin de mettre ce qui va bien pour la gestion des menus aux mainteneurs des paquets.

      C'est d'ailleurs un paquet qui s'appelle menu (étonnant, non) qui fait ça, avec quelques scripts a lancer après l'installation et après la suppression de logiciels.

      • [^] # Elle a pas le monopole

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

        Une autre distribution commencant par M fait de même (elle a copié sur D).

        Mais ce qui est dommage, c'est les scripts lancé après l'install d'un soft : c'est lourd dingue et ça duplique tout inutilement :(
        Il faudrait que les WM/DE gèrent eux-mêmes un format commun.

        Le problèmes c'est que le format doit être extensible par chacun sans géner l'autre

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Vers l'unification et l'au-delà !!!

        Posté par  . Évalué à 8.

        Ouais c'est peut-être bien pour les types qui font des packages, mais pour l'utilisateur c'est vraiment à chier ce système...
        Mais heureusement, il y a le clip :)

        D'ailleurs, il aurait pu demander une coopération gnustep/gnome AVANT!
        GNUstep, sa pu le paté ou quoi?

    • [^] # Re: Vers l'unification et l'au-delà !!!

      Posté par  . Évalué à 10.

      Au moins ils sont d'accord sur le format des .desktop, c'est un debut. En meme temps ils y definissent des extensions en X-Whatever ...

      C'est pas gagne non plus. Peut-etre que si quelqu'un se lance a definir une DTD bien logique pour la plupart des choses standards. Et encore ...

    • [^] # Re: Vers l'unification et l'au-delà !!!

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

      Pourquoi une arbo de fichiers ?
      Et pourquoi pas plutôt du XML avec la bonne DTD ? ça déchire pas tout, ça ?

      • [^] # Tout dans un fichier = beurk :(=

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

        Le XML c'est bien mais tout dans un fichier c'est chiant pour modifier à la mano.

        Et puis un fichier par appli c'est plus simple pour mettre ça dans un package (.deb, .rpm, .other ,...) et ça permet d'éviter d'inclure la gestion des menus dans le système de package comme proposé.

        Et puis j'ai pas envie de ravoir un système à la windows où quand on se plante dans la base de registre, tout plante :(

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Tout dans un fichier = beurk :(=

          Posté par  . Évalué à 4.

          Toi qui a l'air de connaître le système de menus sous D...
          tu connais un programme *simple* pour configurer soi-même ses menus? comment ça se passe?

          (man menu j'ai pas eu le courage, y'a ptet un truc plus simple sur lequel je suis pas tombé)

          • [^] # Tu vas être déçu ...

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

            ... drakmenu ?

            Et oui, je connais le principe des menus de D. et M. mais je connais surtout M. ;)

            L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: Tout dans un fichier = beurk :(=

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

          Et puis j'ai pas envie de ravoir un système à la windows où quand on se plante dans la base de registre, tout plante :(
          Exactement ! Il faut suivre l'exemple de gconf, qui place toutes les informations dans des petits fichiers d'une arborescence pas trop mal foutue.

          • [^] # Re: Tout dans un fichier = beurk :(=

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

            et qui met 10 secondes à charger le moindre petit menu, super!

            • [^] # Re: Tout dans un fichier = beurk :(=

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

              Je n'ai pas dit qu'il fallait utiliser gconf, puisque ce n'est absolument pas nécessaire (gconf sert à mettre à jour en temps réel les paramètres y compris si $HOME sert sur plusieurs machines à la fois). Mais on peut se baser sur ses principes, qui permettent de bâtir un système robuste.

              • [^] # Re: Tout dans un fichier = beurk :(=

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

                Mais, est-ce que la lenteur de gnome n'est pas due à ce mode de fonctionnement ?

                • [^] # Re: Tout dans un fichier = beurk :(=

                  Posté par  . Évalué à -2.

                  fait attention, quelqu'un a piraté ta signature à l'insu de ton plein gré... Parceque c'est pas possible d'associer les deux mots ;-)

                  pas constructif => -1

                • [^] # Re: Tout dans un fichier = beurk :(=

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

                  La lenteur de Gnome ? À part nautilus, je ne vois pas bien ce qui est lent dans Gnome (même si bien sûr ça ne vaut pas Window Maker (dont la version 0.80.0 est OUT !)).

                  Au passage, on peut difficilement accuser gconf pour ladite lenteur, car nautilus l'utilise effectivement, mais galeon aussi (et galeon, niveau vitesse, c'est plus qu'honnête), ainsi que ggv (pareil, il va presque aussi vite que gv, avec des bugs en moins et des fonctions en plus).

                  • [^] # Re: Tout dans un fichier = beurk :(=

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

                    Ce n'est pas galeon qui gère le bureau et les menus du panel. Là où je note une lenteur, c'est lors de l'accès au menu principal par exemple et je me demandais si cette lenteur n'était pas due à ce mode de configuration en arborescence de répertoire (indépendamment de gconf). Mode que je trouve par ailleurs très pratique (c'est comme dans windows).
                    Un autre truc qui me turlupine c'est pourquoi ça doit être gmc ou pire nautilus qui gère le bureau et pas un programme spécifique et optimisé pour ça. Et puisqu'on y est, pourquoi pas un programme indépendant de gnome, kde et WM ?

          • [^] # Re: Tout dans un fichier = beurk :(=

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

            > place toutes les informations dans des petits fichiers d'une arborescence pas trop mal foutue.

            J'ai une bonne nouvelle pour vous: c'est exactement ce que fait KDE avec ses .dekstop.

    • [^] # Re: Vers l'unification et l'au-delà !!!

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

      "<troll> Pour une fois que RMS dit pas de conneries</troll>"

      Et que l'on a pourtant tous intérêt à faire ce qu'il dit...
      RMS roulaize !

      • [^] # Re: Vers l'unification et l'au-delà !!!

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

        C'est claire que là, je suis complètement d'accord avec lui. Quelle perte d'énergie ces deux projets en parallèles ! En revanche, l'exemple qu'il donne ne me paraît pas des plus pertinent. Je trouve qu'il y a des choses plus importantes à mettre en commun.
        Par exemple un moteur d'affichage HTML ou un moteur d'indexation de documentation. Ceci dit, ils ont commencé il y a un petit moment déjà avec des bibliothèques pour la gestion du son il me semble.

        • [^] # Re: Vers l'unification et l'au-delà !!!

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

          KDE et Gnome ont tous deux la possiblite d'utiliser Gecko, de mozilla.

          Mais KDE prefere en general khtml, son propre moteur. Gnome a aussi le sien, gtkhtml, qui est base sur khtml.

          Mais il faut voir que c'est pratiquement impossible de reutiliser un composant ecrit en C/Gtk en C++/Qt et vice versa. En revanche, le portage est en general trivial.

          Cela dit, theoriquement, bonobo et xpart peuvent s'utiliser reciproquement, avec un peu de boulot mais pas beaucoup. Il faut cependant voir que ca n'interesse personne. Les gars de KDE bossent sur KDE et les gars de Gnome sur Gnome.

          • [^] # Re: Vers l'unification et l'au-delà !!!

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

            Ouais, c'est à gecko que je pensais aussi. C'est un peu dommage d'avoir 36 moteur d'affichage HTML plus ou moins aboutit sur sa machine au lieu d'en avoir un seul qui soit excellent mais bon, si tu dis que ce n'est pas possible...;

  • # Commentaire du modérateur ?

    Posté par  . Évalué à 10.

    (ndm : huh ?).

    Armaury t'es sur que c'est constructif ca ?
    lancez un troll dans le texte de la news c'est chaud quand même =)

    zou -1 parce qu'il faut pas dire du mal des moderos

    • [^] # Re: Commentaire du modérateur ?

      Posté par  . Évalué à 10.

      Non ça veut dire que je comprends pas ce qu'il veut dire... Je suis pas très intelligent comme gars, hein. D'où le "huh ?", pour qu'on m'explique ce qu'il veut dire avec son " Par exemple : Comme RPM est le système de packaging du LSB, alors on peut également proposer une fonctionnalité d'intégration par défaut dans les menus KDE-GNOME de chaque application directement dans le format RPM".

      Voooala...

      • [^] # Re: Commentaire du modérateur ?

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

        JAMAIS LES RPMs PASSERONT PAR MOI
        troll ou ça ?
        -1

      • [^] # Re: Commentaire du modérateur ?

        Posté par  . Évalué à 2.

        rahh =) ok !
        utilise le terme linuxfr-ien alors : (ndm: gni?)
        A quand le petit lexique pour moderos ? ;)
        toujours -1 car toujours dénué d'intérêt

      • [^] # Re: Commentaire du modérateur ?

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

        Hum, tout d'abord, merci d'avori remanié mon ti texte... les toutes petites modifs que tu y as apporté me semblent éclaircir tout ça... ;-)

        Secundo :
        huh ?

        Ben voilà, imaginons qu'ils (KNODE) réussissent à faire un système de menu unifié...
        RPM peut très bien intégrer la (alors nouvelle) fonctionnalité d'intégration directe dans le menu KNODE...
        ...et hop la "consistence" - qui fait tant défaut au desktop Linux/BSD - s'en rapproche à grands pas !

        hum ?

      • [^] # Re: Commentaire du modérateur ?

        Posté par  . Évalué à 8.

        Non ça veut dire que je comprends pas ce qu'il veut dire...

        Et je te comprends...

        Je ne vois pas le rapport entre l'intégration de l'info de menu dans les packages LSB et cette intéropérabilité Gnome/KDE : cette information pourrait déja etre présente, charge à l'installeur de faire l'intégration dans les bureaux présents sur le système. Si Gnome et KDE utilisent le meme format, tant mieux, ça fait moins de boulot, mais ils ne sont pas les seuls bureaux. Un installeur de packages LSB se devrait de placer le menu dans le(s) bureau(x) présents utilisant cette fonctionnalité, meme si ce n'est ni Gnome ni KDE. Des distribs le font déja avec leur format de package.

        Bref, tout ça est peut-etre favorable à l'intégration des menus dans les packages LSB, mais ce n'est amha en aucun cas indispensable, et la spec LSB pourrait déja contenir une telle fonctionnalité dans l'actuel des choses.

  • # pipo complet

    Posté par  . Évalué à 7.

    Les architectures de KDE et gnome n'ont rien a voir
    C'est un doux reve que de penser à une intéropérabilité
    (mis a part les themes (quelle blague)).
    Cela dit c'est bien essaye de la part de RMS de se
    raccrocher aux branches après avoir tant decrié le projet KDE
    et maintenant que gnome est quasi à l'agonie depuis 2 ans.

    • [^] # Exemple mal choisit

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

      RMS a choisit le pire exemple :
      Les thèmes.

      C'est AMA ce qui est le plus difficile à partager entre les deux car les thèmes KDE se compilent (cf Liquid) et ceux de GNOME supportent le SVG ('fin je crois mais pour KDE c'est pour bientôt).
      Bref, interropérabilité => refonte des moteurs de thèmes pour éviter la compilation => limitation des capacités nouvelles des thèmes (adieu liquid) ...

      C'est impossible et franchement ça n'a pas d'intérêt. A quand la compatibilité XP ?

      Bref, pour les menus OK mais pour le reste bof bof :(

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Exemple mal choisit

        Posté par  . Évalué à 10.

        Un certain nombre de thèmes KDE sont des thèmes pixmap, comme beaucoup de GTK.

        Les vrais thèmes propres et légers se compilent que ce soit avec KDE ou GTK.

        Un problème encore embêtant au sein même de KDE, c'est que Qt ne supporte pas les thèmes si l'application ne les supporte pas. C'est réglé avec KDE3 et Qt3 mais Qt2 et KDE2x ont ce problème (non-uniformitée de l'apparence des applis KDE avec des applis Qt tout court).

        Un truc plus important que les menus auquel personne ne pense mais qui déroute pas mal les nouveaux : les raccourcis claviers ne sont pas encore vraiment uniformisés (en plus ça relance des jihad à chaque fois qu'ils en parlent).

        • [^] # racourcis clavier

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

          j'ai une copie des raccourcis windows. C'est très proche.

          Tiens, z'avez essayé LAlt+LShift+Ver.Num. ?
          sous X ça me fait penser à shift+Ver.num.

          ben sinon, pourquoi Alt+f4 marche sur les stations X HP ?

          Je suis d'accord, les thèmes, c'est le plus mauvais exemple, mais pour les menus, pourquoi on ne ferait pas un répertoire .menu/ avec les racourcis?
          On le voit sous zin, macos, osx,... c'est dynamique et ça marche super-bien

          le xml aussi c'est une super-idée.

          Ceci dit, pour un bon Jihad, je conseille ceci (recette de Mourrier, dessinateur de «Troll de Troy»): une barbe d'une semaine, balancer un gros sac dans une file d'attente ou une réunion en criant "Allah Akbar". Effet garanti.

          Blackbox ro><or

        • [^] # Re: Exemple mal choisit

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

          Pourquoi ne pas étendre les thèmes aux raccourcis claviers ? Comme ça tout le monde serait content. Un thème word.kbd, un thème emacs.kbd, un thème linuxfr.kbd... Enfin moi je dis ça je suis pas développeur hein.

      • [^] # Re: Exemple mal choisit

        Posté par  . Évalué à 10.

        Sans vouloir lancer/rentrer dans un troll, sous Gtk aussi les thèmes peuvent se "compiler", puisque le theme engine peut faire appel à des .so externes.

        Maintenant c'est très limite niveau sécurité comme manip, il est donc préférable d'avoir un moteur suffisament puissant pour éviter d'avoir à inclure du code dans les thèmes eux-mêmes (et favoriser ainsi l'intégration du thème dans un environement mixte, par exemple lors d'un /home monté en NFS sur des machines d'architectures différentes, un utilisateur doit avoir une version du thème par archi, ce qui n'est pas très pratique).

        • [^] # J'ai pas dis le contraire ...

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

          ... j'ai juste donné des exemples que je connais :)

          L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Hors sujet mais quand même ...

        Posté par  . Évalué à 2.

        d'ailleurs pour les svg, aujourd'hui on a quels outils pour en créer sous linux ?

        j'ai bien essayé amaya m'enfin c'est pas encore au top, et SaVaGe Animator il est un petit peu jeune.
        Yapakekchose de plus mature ?

    • [^] # Vous avez dis pipo complet ?

      Posté par  . Évalué à 10.

      Les architectures de KDE et gnome n'ont rien a voir
      Et alors ? Ce n'est pas ca qui peux empecher d'utiliser les mêmes fichiers de conf (voir les fichiers desktop), éventuellement utiliser une interface de configuration commune => Par exemple, lorsqu'on coche le theme aqua ET que l'on coche "Appliquer sur tous les wm", on obtient, ... ben ... le theme quel que soit le bureau utilisé (wm, gnome, kde). Mon rève;/. Ceci n'est qu'un exemple, pê pas très intelligent ni pertinent, mais qui prouve, je pense, qu'on peut faire des choses de ce côté là.

      Un dernier exemple, énormement de travail peut être fait entre KOffice/GnomeOffice/OpenOffice/Abiword/...* Par exemple :
      o un format de fichier interne commun;
      o un système de filtre commun => un filtre crée pour une suite fonctionnera pour une autre;
      o ...
      Et si ce n'était pas un rève (D'ailleurs c +/- en cours d'étude) ?
      * Je ne sais jamais si c'est OO ou Abiword qui est dans GnomeOffice.

    • [^] # Doux rêve

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

      Je pense que le doux rêve, c'est d'arriver à unifier les deux communautés qui se sont formées autour de chacun de ses environnements. D'ailleurs, tu en es un parfait exemple en disant que RMS veut profiter de KDE pour remettre Gnome à niveau.
      On dirait une vieille guerre qui avait sévi au début des années 90 entre Amiga et Atari. Résultat : les deux ont disparu.

      • [^] # Re: Doux rêve

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

        On dirait une vieille guerre qui avait sévi au début des années 90 entre Amiga et Atari. Résultat : les deux ont disparu.
        A l'époque c'était des entreprises qui contrôlaient atari et amiga, et ces dernières étaient assez peu influencées par leur clients.

        Je ne pense pas que cette situation soit comparable à celle qui sévit dans le logiciel libre, où ce ne sont pas les intérêts commerciaux qui dirigent la barque mais les utilisateurs. Il y a de la place pour tous, KDE ou GNOME, sinon y'a longtemps qu'il n'y aurait plus qu'un seul éditeur, ed, si les LL suivaient les mêmes lois que le marché.

        • [^] # Même les users

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

          Il n'y avait pas qu'entre les sociétés que c'était la guerre. Les utilisateurs étaient tout aussi véhéments. Ceci dit, c'est effectivement le marché qui a détruit ces deux bécanes.

  • # Mon troll de la journée

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

    C'est tout à fait vrai. Actuellement:
    - KDE est moche mais bien foutu
    - Gnome est beau mais mal foutu

    Ils ont donc tout intérêt à collaborer, comme ça on aura un truc moche et mal foutu, et tout le monde pourra passer à Window Maker (d'ailleurs le 0.80 est *shpaf*)

    oui oui bon, -1

  • # rpm système de packaging du lsb ???

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

    euh capte pas cet exemple.
    M'enfin pour avoir des menus compatibles, il n'y a pas de pb. au moins chez mdk, on utilise le package "menu" crée chez debian, pour uniformiser les entrées dans les menus -> pas de dépendances du format de package! les prg se trouvent au meme endroit dans les menus gnome, kde ou autre.

  • # On peut mieux faire.

    Posté par  . Évalué à 10.

    Les menus, les thèmes, c'est bien mais je crois qu'il faudrait pousser le concept plus loin.

    Par exemple, il y a un jeu que j'aime bien et qui est décliné version gnome et kde, j'aimerais retrouver les scores quelque soit la version utilisé.

    Cela devrait être pareil pour toutes les appli qui font plus ou moins la même chose.

    Avoir un carnet d'adresses commun.

    Avoir une interface commune pour la messagerie. ainsi que l'on utilise kmail, sylpheed ou autre, on se retrouve avec les anciens messages.

    XML pourrait être d'un grand secours pour ce type de chose.
    Voilà, voila.
    PS: Je ne sais pas si j'ai été très clair mais bon.

    • [^] # Re: On peut mieux faire.

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

      Pour les mails c'est déjà possible. Tous les logiciels qui sont capables d'utiliser le format standard (mh ?) peuvent travailler sur les mêmes boîtes aux lettres. Par contre pour ce qui est du carnet d'adresse, des bookmarks ou autres c'est pas une mauvaise idée.

    • [^] # Résumé du post précédent :)

      Posté par  . Évalué à 9.

      En résume : tous les fichiers de conf + les fichiers contenant les données des utilisateurs.

    • [^] # Re: On peut mieux faire.

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

      Tout d'abord, je voudrais faire une remarque.
      Dans ton commentaire, ce qui me déplait c'est l'inclusion de XML :)
      <TROLL>Je pense que c'est un langage à la mode tout comme Java l'était en son temps (qui a trouvé son public maintenant) et donc il faut pas inclure le XML à toutes les sauces.</TROLL>

      Mais concernant ton idée, pour la messagerie, créer un format de message commun puisque c'est bien de cela que l'on parle. Je suis tout à fait pour, voire on peut faire mieux en laissant choisir l'utilisateur, le programme n'ayant plus qu'à naviguer au travers des librairies.

      Les avantages seraient multiples, tout d'abord, le développement d'un bon type de format serait moindre puisqu'un seul groupe de projet (enfin autant qu'il y a de projets) travailleraient à l'élaboration d'une librairie, et sinon bien entendu avantage certain pour l'utilisateur :)

      Mais as-t'on réellement besoin de pouvoir naviguer dans tous les clients mails ? Exporter c'est sur, mais est réellement nécessaire de pouvoir en changer comme de chemise ? :)

  • # MIME types et raccourcis clavier

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

    zeu veux doubleucliquer sur mon nicone de mon fichier... quand zeu change de bureau, le même nicone n'est pas associé à la même napplication...

    Un autre exemple d'unification possible !...


    Et pis les raccourcis claviers aussi !

    Mozilla a fait un bel inventaire multiplateforme des raccourcis clavier (...mais on peut toujours pas envoyer de mails avec CTRL+ENTER)
    http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html(...)
    http://www.mozilla.org/mailnews/specs/misc/Accelerators.html(...)

    • [^] # Commentaire supprimé

      Posté par  . Évalué à -3.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # Gnome, Kde ...

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

    Aucun interet de voir ces deux projets s unifier .... ça ressemble plus à une parade commerciale, qu'a une prioritée technique.

    Je pense que Kde et Gnome doivent continuer à se développer dans leurs voies, c est ce qui fait la force de ces projets.

    @+
    Code34

    • [^] # Relis la news !!!

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

      On a pas dis unification mais interopérabilité.

      C'est très très différent

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Gnome, Kde ...

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

      non, c'est ce qui fait leur faiblesse.

  • # Et WindowMaker dans tout ça ?

    Posté par  . Évalué à 10.

    Si je suis bien le propos, KDE et Gnome vont devenir LE standard de fait...
    Les auteurs de WindowMaker, desktop éminemant respectable et respecté n'ont ils rien à dire ?

    Et pour Sawfish ? On les fait taire ?
    Comment unifier sans l'avis des auteurs des WM qui enrichissent Gnome ?

    Ça va encore pas être simple ...

    • [^] # Je voudrais qu'on m'explique...

      Posté par  . Évalué à 10.

      Bon Kde et Gnome, y'a pas de problème, ce sont tous les deux des environnements graphiques possèdant chacun leurs spécificités, leurs forces, leurs beautés...

      Mais voila, si j'ai bien tout compris ( et c'est la qu'il faut qu'on m'explique), ce ne sont pas de window manager???

      En fait, il est bien possible d'utiliser n'importe quel wm dessus, non???

      Et WindowMaker, il fait bien partit d'un projet plus global qui s'appelle GnuStep, qui lui est un environement?

      J'ai raison, docteur? Ou alors il faut que je révise ma copie?

      En gros, existe -t-il d'autres environnements graphiques viables à KDE/Gnome?

      Et puis, sont-ils tous les deux véritablements indispensables?
      Nan, je vous jure c'est une vrai question qui attent de vrai réponse, ca m'intéresse de connaitre votre avis!

      • [^] # Re: Je voudrais qu'on m'explique...

        Posté par  . Évalué à 3.

        Mais voila, si j'ai bien tout compris ( et c'est la qu'il faut qu'on m'explique), ce ne sont pas des window manager???

        Oui.

        En fait, il est bien possible d'utiliser n'importe quel wm dessus, non???

        J'opine. À noter que KDE est souvent avec kwin et gnome avec sawfish (à moins que cela ait changé).

        Et WindowMaker, il fait bien partite d'un projet plus global qui s'appelle GnuStep, qui lui est un environnement?

        Tendancieux. WindowMaker n'est pas une appli GNUstep. Mais il a un look *step.

        GNUStep est un environnement ... ouais. J'ai l'impression que ça tient plus du framework que de l'environnement (pour l'instant) mais je laisse le soin à d'autres de préciser ce point.

        En gros, existe-t'il d'autres environnements graphiques viables à KDE/Gnome?

        CDE ?
        Et puis, sont-ils tous les deux véritablements indispensables?

        C'est un autre débat. Les deux fournissent yet another couche d'abstraction au système (dans une certaine mesure), avec la facilité de programmation et le léger coût en performance que cela implique.

    • [^] # Re: Et WindowMaker dans tout ça ?

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

      Bah déjà c'est des standards, ils sont réellement utilisés par une grande partie des utilisateurs. Il est vrai qu'on peut leur accorder le fait que ce n'est pas qu'un wm, mais une suite de logiciels.

      Sinon je ne vois vraiment pas le pb d'unifier les .desktop, ce n'est pas ca qui changera le monde pour les autres distribs qui peuvent l'intégrer ou non. En tout cas, dans ce cas précis, je ne pense que les utilisateurs en profiteront (si cela aboutit)

      Reste ensuite à voir la suite ...

  • # mais, mais, c'est dangeureux !

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

    Avec toutes ces réunifications, ils vont finir par écraser une fois de plus MFC42.DLL à chaque installation d'un nouveau truc-machin...

    --
    Ok, -1, et [jesors]

  • # Pour ceux qui comme d'hab parlent beaucoup et ne suivent rien

    Posté par  . Évalué à 7.

    extrait de gnotice:

    http://news.gnome.org/gnome-news/1002599178/index_html(...)

    "We're also hoping to do some interoperability hacking on the 7th with the KDE team."

    A noter que cette news a été postée sur kde.org mais apparament pas publiée (cf les messages).

  • # Diversité et/ou unification ?

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

    Il est très bon d'avoir deux projets distincts. Si l'un d'eux fait fausse route, l'autre continue. On m'a toujours dit qu'il ne fallait pas mettre tous ses oeufs dans le même panier !
    La diversité est une richesse, elle permet à plus d'innovations de s'exprimer. L'unification, c'est l'efficacité, la force, tous dans le même sens, tous pour la pensée unique...
    Nous avons la chance de pouvoir choisir entre deux modèles de haut de gamme, il faut bien qu'ils soient un peu différents ?

    Cependant, il faut éviter la dispersion quand elle n'est pas ou plus nécessaire.
    Entre le presse papier, les menus, les raccourcis, les fichiers de conf, et nombreuses API telles que dictionnaires, correcteurs... il y a beaucoup de travail à faire pour faire converger ce qui peut raisonnablement être unifié.
    Actuellement, tout le monde utilise GNU qui tend même à supplanter POSIX. Nul ne pense à faire un fork de GNU ce serait certainement inutile.
    De la même façon, les applis graphiques peuvent partager de nombreuses caractéristiques et éviter les dispersions lorsqu'elles ne sont plus utiles.

    Ce qui est amusant, c'est que RMS n'utilise ni Gnome, ni KDE sur son PC ! Devinez ce qu'il utilise ? Emacs pour tout faire. Et il s'en sert bien le bougre ;-) Il traite en moyenne 150 mails par jour.

    Proposition

    Les développeurs GNOME, KDE et les autres sont conviés à venir débattre de ce sujet à Bordeaux, du 9 au 13 juillet

    Si ils font du bon travail, ils pourront assister à un grand feu d'artifice qui clôturera LSM / RMLL :-).
    Je prie tous les contributeurs qui lisent ces lignes de convaincre tous les autres.
    Le site LSM 2002 vient d'ouvrir : http://lsm.abul.org(...)

    Merci d'avance.

  • # wmx est mieux

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

    M'en fous, wmx, c'est beaucoup mieux.

Suivre le flux des commentaires

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