Journal J'aime KDE !!!

Posté par  .
Étiquettes : aucune
0
5
jan.
2005
Bonjour cher journal,
Désolé pour l'appel au troll, mais aujourd'hui KDE m'a permis de passer pour un gars bien auprès d'une copine :)
Pour ceux qui ne connaissent/utilisent pas kdepim, il faut savoir que dans kde il y a une gestion du carnet d'adresses centralisé qui permet à toutes les applications kde de s'en servir. Ça permet notamment de lier des gens connus dans kopete à une entrée du carnet d'adresses, de synchroniser leurs infos (comme la date d'anniversaire) qu'ils donnent sur jabber (par exemple) dans son carnet d'adresses, d'afficher les prochains anniversaires dans kontact ou kickpim...
Justement LA fonction qui m'a permis de passer pour un gars bien s'est celle qui vous rappelle les anniversaires, ce qui est très pratique pour ceux qui ne savent pas le jour qu'on est ni les dates d'anniversaires (comme moi ;))
La liste des tâches dans kontact m'est devenue précieuse pour éviter d'oublier de faire des trucs.

PS: il y a sûrement un carnet d'adresses dans gnome, mais là c'était juste pour mettre en avant qu'on peut dire tout ce qu'on veut sur KDE du genre que c'est lourd, mais y'a de + en + une intégration profonde entre les applications KDE, & ça c'est bien pratique !!! Vivement une intégration avec des applications non kde (oui j'ai le droit de rêver, mais avec les normalisations de freedesktop, peut-être qu'un jour...)

PS2: no troll, please :) si vous n'êtes pas d'accord, oubliez mon journal :)

PS3: oui je m'enflamme pour très peu :) mais je voulais partager ma joie ;o)

  • # kabc roxor!

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

    Grace à Kabc, toutes les applis Kde ayant a faire à des contacts(kmail, kopete, konversation, konqueror, ...) partagent leurs données. Et c'est tres pratique, genre je dois envoyer un fichier a quelqu'un, ben au lieu de passer par kopete, je vais dans konqueror et je fais click droit sur le fichier -> copier vers -> nom du contact. C'est autrement plus pratique que de passer par la boite de selection de fichier de Kde(aussi puissante soit elle).

    • [^] # Et Gnome alors ? <no troll>

      Posté par  . Évalué à 3.

      J'avais entendu parler il y a quelque temps de la mise en place d'un système similaire sur Gnome. Ce devait être (de mémoire) un serveur LDAP qui serait accessible par Evolution au départ et que toutes les applications Gnome pourraient consulter.

      Vivement une intégration avec des applications non kde (oui j'ai le droit de rêver, mais avec les normalisations de freedesktop, peut-être qu'un jour...)

      LDAP pourrait d'ailleurs être la solution que tu recherche afin de faire communiquer les carnets d'adresse entre Gnome et KDE car indépendant de toutes plateformes logiciels (je veux dire gtk/qt) et fonctionnant en réseau. Accessoirement, c'est un protocole standardisé (RFC 1777).

      • [^] # Re: Et VCard / Ical / CAP ...

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

        mouifff...

        mais ldap nécessite un serveur et est relativement lourd à implémenter / configurer...

        ou alors il faut un "ldaplite" un peu comme on peut désormais utiliser un "sqlite" ou un "standalone mysql" par exemple.

        pour la communication de carnet d'adresse, mais aussi d'agendas ou de tasklists, il y a normalement CAP (Calendar Access Protocol) au niveau protocolaire ( http://www.imc.org/ietf-calendar/index.html(...) ) et le format utilisé : ical, vcal, vcard. ( http://www.faqs.org/rfcs/rfc2426.html(...) )

        Bref, les applications ont les protocoles et formats ouverts et standards d'échange et de stockage, reste à les faire réellement communiquer entre elles.

  • # Intégrations des applications de messagerie instentaées et freedesktop.

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

    Contrairement à l'intégration statique entre Gaim et Evolution, L'intégration entre Kopete et KMail est réalisée a partir d'une interface DCOP générique baptisée KIMProxy.
    http://developer.kde.org/documentation/library/cvs-api/interfaces/h(...)

    Même si, à ma connaissance, seul KMail, Kopete et Konversation utilise cette interface actuellement, cela signifie que n'importe quelle application peut demander ou signaler l' états de « contacts »

    En théorie, il serait donc possible d'écrire un plugin pour Gaim qui l'intégrerais à KMail. Le seul problème est que KIMProxy utilise DCop qui est une technologie KDE, et emploi les id de libkabc (en gros de KAdressBook) pour identifier les contacts.

    Mais les développeurs de Gaim veulent faire pareil ([troll]toujours à la traine[/troll]), avec leur projet Galago ( http://galago.sf.net(...) ) dont ils compte en faire une spécification de freedesktop.
    Seulement le projet est loin d'être fini (surtout que le développeur n'as plus trop le temps de travailler dessus ces jours ci) et utilise DBus, qui n'est pas encore supporté par KDE.
    De plus, ce que je n'aime pas dans Galago, c'est que ça nécessite un démon qui tourne en arrière plan.

    Voici l'état tel qu'il est maintenant.

    Avec KDE4 qui supportera plus que probablement DBus, L'intégration entre les applications KDE et Gnome (et autres) sera normalement plus aisé.
    Reste à voir laquelle des deux approche sera adoptée.

    Note que un pont entre KIMProxy et Galago est parfaitement possible.

    • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

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

      http://galago.sourceforge.net/specs/notification/index.php(...)

      Ah, je l'avais deja lu cette spec, bien avant que le truc s'appelle galago :)

      Ben coté, Kde, les devels sont vraiment pas chaud pour ce truc, c'est sous featuré, ca ne correspond pas à leurs besoins et de plus beaucoup trouve cette spec completement moisi(genre le fait que cette derniere s'occupe de la mise en forme).

    • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

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

      >Même si, à ma connaissance, seul KMail, Kopete et Konversation utilise cette >interface actuellement

      Tu as oublié konqueror qui utilise ca aussi :) D'ailleurs je te remercie pour cette présentation de kimproxy, je m'etais arreter sur kabc pensant que c'etait cette lib qui faisait tout :)

    • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

      Posté par  . Évalué à 1.

      j'ai lu que Qt 4 aurait un support de DBus.
      Que va devenir Dcop ? perso je trouves que ça serait bien que dcop disparaisse pour faire place à dbus, mais quelqu'un as t'il des infos dessus ?
      Y'a t'il des choses que sait faire dcop & pas dbus ? est-ce que dbus est au moins aussi performant que dcop ?

      • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

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

        Dbus est basé sur dcop donc en principe il offre la meme chose.

        Par contre, j'avais lu un thread super interessant sur une mailing list kde à propos de la migration vers Dbus et des problemes que cela va occasionner mais j'arrive pas à la retrouver :( Si quelqu'un a un lien...

        Sinon, le seul truc qui me plait moyennement dans dbus, c'est le coté service systeme. Parce que si l'utilisateur enleve dbus au démarrage du systeme(via drakconf par ex), normalement , Kde et Gnome ne devrait plus fonctionner. Donc bon, de ce point de vu la, ca m'inquiete un peu... Je vois tres biens le contenu des forums dans quelques années : "Mon gnome marche plus!", "Kde cassé" :)

        Sinon, pour ceux qui vont se la ramener en me disant que gnome utilise deja dbus et que enlever le service n'empeche pas à gnome de fonctionner, je leur répondrais une seule chose: "Preuve que gnome n'utilise pas Dbus"(a part un outils en fait).

        • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

          Posté par  . Évalué à 1.

          http://cvs-digest.org/index.php?issue=oct82004(...)

        • [^] # DCOP vs DBUS

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

          L'inconvénient majeur de DCop est qu'il ne défini pas lui même les types de base, mais réutilise celui du langage utilisé par les applications.
          Dans le cas de KDE, c'est du C++ avec QT, et donc il y a plein de type QT partout (QString, ....) ce qui fait que ça rends les communication avec les applications GTK et autres plus difficile.

          Pour remédier à ça, DBUS à donc été construit sur base de DCop
          La principale différence étant que les types sont bien défini dans les spécifications.

          Mais, alors que DCOP est stable, et utilisé depuis plusieurs années avec succes, DBUS n'en est pas encore à sa version 1.0 et il existe relativement peu d'application l'utilisant réellement qui peuvent prouver sa stabilité et son efficacité.

          j'avais lu un thread super interessant sur une mailing list kde à propos de la migration vers Dbus et des problemes que cela va occasionner


          Tu veux parler de celui-là ?
          http://lists.kde.org/?l=kde-core-devel&m=109646893512881&w=(...)

        • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

          Posté par  . Évalué à 1.

          > Sinon, pour ceux qui vont se la ramener en me disant que gnome utilise deja dbus et que enlever le service n'empeche pas à gnome de fonctionner, je leur répondrais une seule chose: "Preuve que gnome n'utilise pas Dbus"(a part un outils en fait).

          Pour Gnome, actuellement, Dbus est pour les messages systèmes et pratiquement rien d'autre. Donc, vires Dbus et nautilus ne voit pas qu'une clées a été ajouté, G-V-M ne voit pas les volumes, cups ne dit où en est l'impression etc.
          Dbus est utilisé là où il est utile et adapté. Il n'est pas utisé à tous propos. Je trouve amusant que chez KDE, DBus est vu comme un concurrent/remplaçant de tout et n'importe quoi. Une façon de dramatiser les choses...

          > a part un outils en fait

          nautilus
          cups
          desktop-printing
          gnome-volume-manager
          nautilus-cd-burner

          • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

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

            Ben c'est toi qui n'a rien compris à ce qu'offre un systeme d'ipc pour un desktop. Pour l'instant Dbus n'est utilisé par gnome que pour les notifications systeme, mais j'espere bien qu'il vont vraiment intégrer dbus dans toutes les applications gnome afin de leur permettre d'etre piloter, de communiquer entre elle comme le fait dcop dans Kde actuellement. C'est ce qui manque a Gnome actuellement.

            Le seul probleme, c'est que comme pour Kde, ca risque de cassé la compatibilité et donc imposer un nouveau numéro de version. Donc, peu de chance de voir dbus bien intégré à gnome d'ici gnome 3.0 (attention, ce n'est qu'un sentiment et si un devel gnome pouvait donner son avis... Teuf? Dans le coin?).

            http://lists.kde.org/?l=kde-core-devel&m=109646893512881&w=(...) (merci Gof)

            Va voir la si tu veux plus d'info sur ce que peut offrir dbus pour le communication interapplication qui est aussi importante a mon avis que le communication system/desktop.

            • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

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

              Ca risque de casser la compatibilité et donc imposer un nouveau numéro de version.

              Non. Ça risque pas de casser quoi que ce soit vu que c'est quelque chose de nouveau, qui ne remplace rien d'existant.

            • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

              Posté par  . Évalué à 0.

              > mais j'espere bien qu'il vont vraiment intégrer dbus dans toutes les applications gnome afin de leur permettre d'etre piloter, de communiquer entre elle comme le fait dcop dans Kde actuellement. C'est ce qui manque a Gnome actuellement.

              Déjà fait et depuis longtemps. De plus Dbus est plus bas niveau que Dcop et n'a aucun connaissance/contrainte sur ce qui est communiqué.

              Je connais pas ipc mais tu ne connais pas Dbus ni Dcop.

              > Le seul probleme, c'est que comme pour Kde, ca risque de cassé la compatibilité et donc imposer un nouveau numéro de version. Donc, peu de chance de voir dbus bien intégré à gnome d'ici gnome 3.0

              Et ?
              Pourquoi faut-il utiliser Dbus à la place de bonobo ou corba ? Dbus ne fait pas la même chose. Dbus fait un "truc" que bonobo ne fait pas et vice versa.

              > Va voir la si tu veux plus d'info sur ce que peut offrir dbus pour le communication interapplication qui est aussi importante a mon avis que le communication system/desktop.

              Je connais Dbus, merci.
              Mais il y a déjà des technos sous Gnome et il n'y a pas le feu pour les remplacer.

              > http://lists.kde.org/?l=kde-core-devel&m=109646893512881&w=(...)
              Technically DBUS provides roughly the same capabilities as DCOP. This is not
              suprising given that DBUS is modelled after DCOP.

              Dbus a été fait _après_ Dcop. Il n'est pas dit que Dbus est basé sur Dcop. Sinon tu vas dire que IIS est basé sur Apache...

              a) communication between KDE applications and the underlying operating system
              b) communication between KDE and non-KDE applications.

              a) => c'est le cadre d'utilisation de Gnome
              b) => Dbus n'impose pas de format/protocole. C'est un moyen de communication. Pour l'intéropérabilité, c'est l'affaire de FreeDesktop.

              Dbus est bas niveau.
              Ce n'est pas parce que Gnome et KDE utilise Unix qu'il sont compatible. Ce n'est pas parcequ'ils utiliseront Dbus qu'ils seront compatibles. PostgreSQL et apache utilise IPC et s'ils sont utilisable ensemble. Ce n'est pas grace à IPC. Tu comprends la nuance ?

        • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

          Posté par  . Évalué à 0.

          > Dbus est basé sur dcop

          ?????
          Tu es sûr ?

          > en principe il offre la meme chose.

          Ah bon...
          C'est une bonne nouvelle pour KDE.

    • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

      Posté par  . Évalué à 0.

      > Contrairement à l'intégration statique entre Gaim et Evolution

      Connait pas Gaim.

      Evolution n'est pas "statique". Il utilise les composants bonobo (comme les applets). Principalement :
      - Evolution_Addressbook
      - Evolution_Calendar
      - Evolution_Mail
      - Evolution_Shell

      Pour "rigoler", fais :
      $ mv /usr/lib/bonobo/servers/GNOME_Evolution_Calendar* /tmp

      Puis lances Evolution et vois la différence.

      • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

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

        Toi tu fais expres de pas comprendre :)

        Le monsieur disait que actuellement, l'intégration entre gaim et evolution est static, au sens qu'elle est spécifique à ces deux logiciels et qu'elle n'utilise pas une API utilisable par n'importe qui. Enfin je pense :) Je savais meme pas que gaim et evolution savaient se parler :)

        • [^] # Re: Intégrations des applications de messagerie instentaées et freedeskt

          Posté par  . Évalué à 0.

          J'ignore pour gaim, mais evolution utilise le mécanisme "standard" bonobo. Et l'applet "date" de gnome utilise le composant calendard d'évolution s'il le trouve.

          > Je savais meme pas que gaim et evolution savaient se parler :)

          Je répète, je ne connais pas gaim. Mais si gaim veut utiliser les composants Evolution, il peut le faire. S'il ne le fait pas, c'est ses oignons et c'est comme ça.

  • # Et en sens inverse ?

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

    Le jour où cette même copine tombera sur tes images de luc, soigneusement renommées travail.rtf, mais dont Konqueror affiche les vignettes quand même, tu viendras moins faire le malin !!! :-)

    • [^] # Re: Et en sens inverse ?

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

      Ah, mon bon monsieur, linux est déjà là depuis très longtemps pour répondre à ce genre de problématique :

      chmod o-rwx,g-rwx /home/* et le tour est joué ;)

    • [^] # Re: Et en sens inverse ?

      Posté par  . Évalué à 2.

      Pour des raisons de perf, Nautilus utilise maintenant l'extension et pas le magic number pour connaitre le type de fichier lors d'un parcours de repertoire. Par contre quand tu essaye de l'ouvrir, le magic est verifie.

      Tu peux tester en copiant une image en doc.rtf et tu verras une icone RTF plutot qu'une vignette.

      Est ce que konqueror ne fonctionne pas de la meme maniere ? Auquel cas pas de probleme pour ton "document" travail.rtf !

      • [^] # Re: Et en sens inverse ?

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

        Ha bon ? Ha mince, alors.
        Dommage, d'ailleurs. J'aimais bien cette indépendance par rapport aux extensions. Ça donnait un comportement plus intelligent du système, je trouve. Plus proche du Mac que de Windows, quoi. Les extensions, c'est pratique pour l'½il humain, mais ça devient assez vite le bordel. Voire des nids à virus si qq'un à la mauvaise des les rendre invisibles (cf. les .jpg.exe de Win).

        • [^] # Re: Et en sens inverse ?

          Posté par  . Évalué à 1.

          C'est pour ca que Nautilus effectue une verif du magic avant execution/ouverture pour savoir si c'est en accord avec l'extension. Cela permet d'eviter les problemes...

    • [^] # Re: Et en sens inverse ?

      Posté par  . Évalué à 2.

      le linuxien prudent stocke ce genre d'informations sous un autre compte et sur un autre support ;)

Suivre le flux des commentaires

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