Gof a écrit 2223 commentaires

KHotKeys

ça se trouve dans KControl, section accessibilité.

KHotKeys permet de faire beaucoup de chose, mais peut paraître assez compliquer à configurer.

Et avec KDE il y a
fish://login@host/path
C'est tres pratique et ça marche assez bien.

Je trouve que c'est même un gros inconvénient du truc.
on ne peut pas mettre une URL précise dans ses bookmark, où la filer à quelqu'un d'autre.

C'est du au fait que les URL contiennent en fait, si j'ai bien compris, un numéro autoincrémenté, qui n'est valable que une seule fois et qui perd sa validité dés que on clic sur un autre lien.

Pire, si on se trompe de lien, et qu'on clic sur le boutton retour du navigateur, les autres liens ne fonctionnent plus.

C'est très dommage car ça pose de gros problèmes d'accessibilités

Il vaut 100 fois mieux utiliser Jabber avec msn messenger (si c'était possible) que d'utiliser le réseau msn avec gaim.

C'est possible (cf mon post plus bas et http://msn2jabber.jabberstudio.org(...) )

De plus, c'est normal qu'il prennent de l'avance puisque c'est eux qui modifie le protocolent en fonction de ce qu'il veulent faire dans leur client. les client MSN tierce ne peuvent faire que suivre ça avec un retard plus ou moins grand.

En théorie, avec Jabber, on peut étendre le protocole. Le problème c'est que comme il existe plein de clients et plein de serveur différent, il y a un processus de standardisation qui peut être assez long.

Je ne connais pas tellement le mécanisme des JEP, mais j'ai l'impression que c'est pas très rapide.

1. Il suffit de mettre la base en plus sur quelques serveurs miroirs performent.
2. oui, certes, mais est-ce un problème ?

Il faudrais aussi trouver un système de signature pour que les pacquages officiels soit signés.

et n'importe quel utilisateur pourait faire ses pacage. Cela permettrais d'avoir une grande quantité de paquet. Mais il faut faire parfois confiance à des inconnus.
Peut-être aurais t il la possibilité d'avoir un système de cotation qui permet de quoter les bon et les mauvais packagers.

Enfin, si tu as déjà envisager la chose, ok. c'était juste pour partager mon idée.

je n'ai pas trouvé de distribution qui gère bien source/binaire

J'utilise actuellement Archlinux et je trouve cette distribution géniale sur ce point.


Juste une idée que j'avais: comment on télécharge les updates avec votre distro ? Un truc qui peut être sympa c'est de baser ça sur le p2p.

C'est quoi comme distribution ?
Quels sont les spécificités ?

Plutot desktop ou plutot server ?
Plutot débutant ou plutot utilisateur confirmé ?
Plutot KDE , Gnome ou indépandent du desktop ? (la question qui troll)
Logiciel dépassé et Obsolete ou en version CVS ?

A quoi ressemble le logo ? (Le plus important)
Vous avez pas un site web ?

Quels sont les particularités par rapport aux autres distros ?
Quels sont les buts poursuivit ?

(Mais YaST reste utilisable en mode texte, on s'entend).

Utilisable c'est un grand mot.
Disons que ça fonctionne en mode texte. mais il faut être mazo, ou avoir de sérieux problème de configuration de la carte graphique pour vouloir s'y essayer.

Si il y en à qui sont attaché au client MSN Messenger (j'ignore pourquoi, mais bon...) je vois 2 solutions:

la première: utiliser MSN Messenger comme client Jabber.
Hé oui, c'est possible. Pour cela, il suffit de faire un faux serveur MSN qui fait passerelle.
Il existe http://msn2jabber.jabberstudio.org/(...)
J'ai jamais testé et j'ai aucune idée si ça fonctione ou pas.


2eme idée: S'il existe des transport Jabber -> MSN . Pourquoi ne pas faire un transport MSN -> Jabber.
Même principe que les transport Jabber. Un "server" qui tourne quelque part et qui est à la fois client MSN et client Jabber.

Techniquement, le "bot" devra inscrire plein de contact auprès de passport.com sous là forme de login%jabber.org@botjabber.com (où botjabber.com est le serveur sur lequel il tourne)
L'inscription nécessite de lire une image. Il suffit de transmettre cette image à l'utilisateur (MSN permet d'envoyer des image et le les afficher directement) qui n'aura plus qu'a recopier les quelques symboles.

Légalement cependant, lorsque on s'inscrit sur passport.net, on est sensé accepter un contrat, qui stipule que on ne peut pas se connecter avec autre chose que MSN Messenger. (cela comprends donc tout les client libre, mais aussi les bot) Et il peuvent se permettre de fermer les compte de ceux qui ne respectant pas ce fameux contrat.

Mais bon, pour que ça marche, il suffit que quelqu'un le fasse. et j'ai pas trop le temps pour ça actuellement.

Le Yast de la 6.1 m'avais aussi donner entière satisfaction.

Mais depuis qu'il sont passé à Yast2 , j'aime moins.
(je préfère les outils de config en mode texte)

Surtout que Yast avait un peu tendance à écraser mes config manuelle (je parle de SuSE 7.1 là)

J'ai beaucoup aimé SuSE quand j'ai commencé. Mais maintenant, je ne suis plus assez débutant pour l' apprécier à sa juste valeur.

Là j'utilise Archlinux et j'aime bien.

Et question subsidiaire, ou puis-je trouver un semblant de docs sur le protocole MSN (pour une implémentation par exemple) ? Merci

Il y a ça ici.
http://www.hypothetic.org/docs/msn/index.php(...)
(C'est pas officiel, c'est du reverse)

Moi même je ne savais pas.
Alors j'ai demandé.

c'est un kioslave.
applications:/

En gros, ça montre le menu K dans Konqueror. Je sais pas trop a quoi ça peux servir.

>> Dbus est basé sur dcop
> C'est complètement faux.


Pas complètement.

C'est même indiqué dans la doc de Dbus:
http://www.freedesktop.org/software/dbus/doc/dbus-tutorial.html(...)

Je cite:

For the within-desktop-session use case, the GNOME and KDE desktops have significant previous experience with different IPC solutions such as CORBA and DCOP. D-BUS is built on that experience and carefully tailored to meet the needs of these desktop projects in particular.

Semantics are similar to the existing DCOP system, allowing KDE to adopt it more easily.

DBus et DCop font exactment la même chose.

DBus est bien là pour remplacer DCop

DCop qui actuellement sert dans la communication entre les applications KDE sera remplacer par DBus, qui permettra la communication entre toute les applications qu'elles soit gtk ou qt.
l'inconvénient de DCop étant qu'il utilise les types de QT

DCop et DBus se ressemblent tellement qu'il devrai être très facile de porter les application utilisant dcop à dbus.
Cela pourait même être fait en théorie sans casser la compatibilité. Mais ça n'en vaux as la peine, considérant que KDE4 arrive bientôt.

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

Ça me rappel ce mail de la mailing liste de kde-core-devel qui m'a fait beaucoup rire:
http://lists.kde.org/?l=kde-core-devel&m=110487003524071(...)

Pour donner un peu le contexte:
Il existe dans la norme de PDF un moyen d'exécuter un script lorsque on clic sur un lien du document PDF (pratique parait il lorsque on veut faire la démonstration d'une application lors d'une présentation)
Certains développeurs sont contre l'ajout de cette fonctionalités dans KPdf car selon eux c'est trop dangereux. Et même si on rajoute des (magnifiques) avertissements tel que celui-là: http://www.dei.unipd.it/~rosenric/temp/after.png(...)

Cela a généré un beau troll.

PS: C'est marrent, si on tape son mot de passe dans un commentaire, Templeet le remplace par des étoiles.
Par exemple, mon mot de passe est *****

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.

Joyeuse année 1905 2005

(Y2K compilant)

Bonne fin d'année alors.

killall -9 artsd est effectivement dans mon top-10

J'avais déjà vu (ici je crois) un moyen de savoir la commande qu'on tapais le plus.

Mais j'ai pas retrouvé, alors j'ai essayé de le faire moi même:

cat ~/.bash_history | sort | uniq -c -w3 | sort -r | head

Et on obtient la liste des commandes qu'on tape le plus (basé sur les 3 premiers caractères tapés.

Chez moi c'est cd.
(Et en root, c'est pacman évidement, vive Archlinux)

Les fils qui ont l'air inutilisés permettent de réduire les bruits causés par les champs électromagnétique générés par les fils utilisés.

Maintenant, si tes cables sont suffisamment courts, ça doit pas être trop grave.

Pire, sous Linux on a une intégration beaucoup plus forte des logiciels. Je peux par exemple parler de bête menu gnome/kde qui n'est pas organisé avec un sous menu par application mais par thème/but. Les thèmes et l'orientation ne sera pas la même suivant les distros, impossible d'avoir une intégration "habituelle" sans faire du spécifique. Windows a choisi de ne pas se préoccuper de ce genre d'intégration, moi j'aimerai qu'on évite de mettre une croix sur ce genre de choses intéressantes sous Linux.

Les menus KDE/Gnome ne sont pas comparables au menu démarrer de MS Windows (Celui où il te faut plusieurs minutes pour trouver l'application que tu cherches dans la longue liste ordonée arbitrairement des noms des éditeurs)

Ce menu devrais être en théorie le même pour chaque distributions car les entrées de ces menu sont depuis peu une spécification de freedesktop.org. Et les applications devrais pouvoir s'intégrer dans ce menu facilement.

Changement de version mineur (x.1.y -> x.2.z), pas de compatibilité binaire, mais compatibilité source.

Si, il y a compatibilité binaire.

Un programme compilé pour KDE 3.0 avec QT 3.0 fonctionnera très bien sous KDE 3.4.
L'inverse n'est pas vrai, car il y a des évolutions.

J'y serais probablement, comme j'y étais les 2 années précédentes

Et vous ?