si Yzis fait ses preuves les gens auront la volonté de refaire leur ptit script en Lua si c'est nécessaire ;)
mais a nouveau, si des gens font le script pour traduire les fichiers Vim, tres bien, je prends !
Mais moi je ne le ferai pas ;) (ou alors faudrait vraiment que je m'ennuie sévère ;)
Je pense qu'on a des choses bien plus intéressantes à développer dans Yzis.
d'autant plus que 90% des scripts de Vim sont utilisés par 1% des utilisateurs de Vim, ce qui fait qu'on ira bien plus vite de réécrire les 10% "vraiment" utilisés à la main ;)
sinon traduire les 10 lignes du .vimrc des gens, franchement l'utilisateur peut le faire ;) (à un moment ou un autre l'utilisateur devra s'habituer à la conf d'Yzis de toute facon, la conf 'de base' est un bon moyen pour s'y habituer en douceur).
Le 'tout-auto-a-la-mode-windows-que-je-fais-plein-de-choses-partout-sans-te-le-dire', je trouve pas que ca soit une excellente idée ;)
Enfin, nous aurons normalement les options de base visibles via une jolie interface graphique "click-click" pour les vrais débutants, bien plus simple que le .vimrc ;)
(voire toutes les options peut-etre si on arrive à définir une méthode d'organisation et d'affichage propre et claire dans une GUI ce qui n'est pas forcément évident quand on a x centaines d'options)
ce qui nous a plu avant tout c'est la facilité d'integration en C ainsi que la simplicité du langage lui-meme.
et enfin c'est tres leger tout en etant tres rapide.
apres savoir si c'est "mieux" que Python ou Perl, je pense que c'est une simple question de gouts et de couleurs ;), et surtout l'usage qu'en font les utilisateurs.
a priori Lua est et restera le langage de 'base'
neanmoins lorsqu'on aura finit la premiere version stable (a priori synchro avec KDE4 si tout va bien), on pourra envisager de rajouter les interfaces vers d'autres langages de scripts.
(je ne veux pas le faire avant pour pas que les developpeurs principaux se prennent trop la tete avec des choses qui me paraissent a l'heure actuelle 'gadget' ;)
Lua est un langage vraiment sympa et tres leger, facilement améliorable et dont l'integration en C est sympa.
concernant le module de compatibilité, Philippe a commencé un script Lua pour convertir les scripts vim en lua, c'est pas chose facile (conversion de regexps, des 0 qui veulent pas dire 'false' em Lua ...), donc on aura besoin d'aide pour faire ca.
de meme, ca ne me parait pas 'indispensable' comme fonctionnalité ;)
Sinon si vous avez besoin d'un script particulier, ca ne coute rien de poster un mail sur nos listes ou sur le site. Un volontaire pour s'entrainer a Lua passera peut-etre par la :)
et a defaut, ca nous aidera a voir quelles interfaces sont nécessaires entre le script et la librairie pour faire que ca soit plus simple a scripter.
au niveau Qt4, ca correspond a 95% a ce que j'esperais, a savoir des interfaces beaucoup plus claires, une separation en plusieurs librairies (ce qui fait que nyzis n'a plus besoin de charger une lib de 10Mo pour demarrer, le lancement est instantanné maintenant), et des perfs vraiment améliorées globalement comparées a qt3.
les 5% qui restent concernent QPrinter, mais je suis trop exigeant envers Qt ;) (j'aurais voulu que ca soit dans QtCore et pas dans QtGui ;o)
ca fait pas bcp de debug ca
c'est pas normal :)
il devrait au moins detecter la connexion client->server sur le port TCP 554 et t'afficher quel client tu utilises (cf ma reponse a phh).
par contre il faut p-e une regle iptables du genre :
iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
(pour autoriser vraiment le conntrack)
Mik
Chez moi dans le debug ca donne qq chose du genre :
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: conntrackinfo = 2
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: IP_CT_DIR_REPLY
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: conntrackinfo = 2
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: IP_CT_DIR_REPLY
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help_out: found a setup message
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: rtsp_parse_transport: tran='Transport: RTP/AVP;unicast;client_port=33440-33441^M
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: rtsp_parse_transport: lo port found : 33440
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help_out: udp transport found, ports=(1,33440,33441)
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help_out: Changing expectation mask to handle multiple ports
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help_out: expect_related 212.27.38.253:0-82.233.104.105:33440
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: NAT rtsp help_out
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: hdr: len=9, CSeq: 2^M
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: hdr: len=52, Transport: RTP/AVP;unicast;client_port=33440-33441^M
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: hdr: Transport
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: rtsp_mangle_tran: stunaddr=82.233.104.105 (auto)
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: rtsp_mangle_tran: using ports 33440-33441
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: rep: len=52, Transport: RTP/AVP;unicast;client_port=33440-33441^M
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: hdr: len=59, User-Agent: MPlayer (LIVE555 Streaming Media v2005.10.05)^M
Feb 21 09:46:27 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: IP_CT_DIR_REPLY
Feb 21 09:46:27 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: IP_CT_DIR_REPLY
Feb 21 09:46:27 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: expected: newsrcip=212.27.38.253, newdstip=10.0.0.2, newip=10.0.0.2
(la derniere ligne indique que le conntrack marche normalement ;)
ce bug la, j'ai fait un patch sur leur bug tracker.
yet_another int->long ...
moi ca marchote plutot pas mal en ligne de commande (mieux que tous les autres lecteurs flashs 'libres' que j'ai pu voir), mais pour le plugin le chemin va etre long a priori ...
y a sans doute plein de bugs 64 bits encore ... faut nettoyer un peu ...
a mon humble avis, il faudrait que les gens de chez Kolab comprennent un jour que openpkg est horrible (tant conceptuellement que techniquement) et que ca ne vaut _VRAIMENT_ pas une bonne documentation avec un .tar.bz2.
ca leur ferait gagner du temps, et nous (utilisateurs) aussi.
ca permettrait que les distribs integrent ca "nativement" et donc (parce qu'y a une logique la-dessous) d'augmenter le nombre d'utilisateurs finaux (ce qui ne leur serait pas inutile si vous voulez mon avis, ne serait-ce que pour avoir des rapports de bugs sur le logiciel lui-meme plutot que sur leur installateur nullard ....).
bref, _jamais_ je n'installerai un openpkg sur un de mes serveurs, moi je veux utiliser les paquets standards de ma distribution preferee ( ou au pire pouvoir faire moi-meme ces paquets sans y passer 6 mois) pour pouvoir avoir :
1- les options que je veux avec ma distrib,
2 - les mises a jour de securite (parce que les mises a jour de secu chez openpkg j'ai un gros doute)
3 - 0 problemes de compatibilite
bref, ils se compliquent la vie avec un truc que personne n'a envie d'utiliser... et a mon avis ca en freine plus d'un a installer kolab qui pourtant en ont tres envie (moi par exemple mais j'en connais d'autre).
en fait, je suis de plus en plus decu par 'kdepim'.
J'ai vraiment le sentiment que de developper kolab (pour certaines entreprises donc ;) est plus important que d'avoir un client mail qui puisse avoir un 'uptime' superieur a 12h sans utiliser 90% de la RAM (ou sans planter...) ...
je n'ai qu'un espoir : que quelqu'un qui ait du temps se jette dedans pour nous refaire un kmail digne de ce nom pour KDE4 en repartant "from scratch" ....
L'integration de kmail dans kontact n'est d'ailleurs qu'une pile de "hacks" pour faire marcher le truc, je trouve tout ca bien 'decevant'
Mik, franchement depite par le chemin que suit kdepim ...
c'est ici : http://websvn.kde.org/home/kde/branches/work/kde4/
le boulot a commence mais non, kdelibs ne compile pas entierement ;)
DCOP a ete porte et devrait meme etre compat avec le DCOP de kde3.x.
Reste a faire des tests reels pour voir ce que ca donne.
kdecore, on a presque fini, encore quelques portages a faire. Peut-etre ce soir, si j'ai le temps j'essaierai de tout finir (y a des subtilites a travailler tout de meme, et je ne parle que de "faire compiler" la bete ...) (de la a ce qu'on puisse lancer une KApplication, y aura sans doute encore un pas ;)
kdeui, alors la c'est pas pour demain, plein de changements a faire ;)
kio, devrait a priori pas etre trop complique d'apres ce que j'ai pu en voir...
le reste de kdelibs devrait suivre sans trop de problemes normalement
Maksim a deja porte kdefx ainsi qu'un style de base pour les fenetres, il va attaquer keramik il me semble.
Thiago s'est occupe de la couche reseau qu'il avait prepare depuis un moment.
apres il faudra voir pour kdebase ou y aura un boulot enorme egalement.
une fois qu'on aura tout ca, qu'on aura bien compris toutes les subtilites, y a moyen que ca aille un peu plus vite pour le reste des applis.
bref, pour voir demarrer un kde4 (encore faudrait-il en avoir envie hein parce que pour le moment ... ;), il faudra compter plusieurs semaines ;)
c'est cause par le syntax highlighting qui calcule toutes les lignes du fichier pendant le chargement.
je dois pouvoir corriger ca dans la journee, c'est trivial ;)
Cheers,
Mik
PS: pour tester , sudo mv $KDEDIR/share/yzis/syntax $KDEDIR/share/yzis/syntax.old, puis yzis ./configure (1Mo), moins d'une seconde pour le chargement chez moi.
l'interface core<->GUI utilise tres peu Qt, justement pour simplifier l'integration avec d'autres toolkits,
et en cas de probleme, on est toujours pret a faire les modifs necessaires pour permettre une integration plus facile ...
il faut juste des volontaires qui connaissent gtk(2)(+) :)
Yzis , c'est :
1 - une librairie 'core' basee sur Qt et Lua (pour le moment)
pour l'instant Qt3 mais avec Qt4 on devrait avoir un 'qt4 non-GUI' qui normalement sera une petite librairie (plus legere que le Qt actuel quoi)
2 - une appli 'kyzis' qui utilise la librairie precedente et les librairies KDE pour faire un composant et une jolie appli KDE
3 - une appli 'nyzis' qui utilise ncurses 5 pour avoir un 'yzis' en mode console
vu que libyzis utilise Qt, on a ainsi directement des choses comme l'unicode, les listes, les keycodes etc. Ca nous evite de reecrire 90% du code de Vim en gros et de nous concentrer sur les choses importantes (== les fonctionnalites ;)
a terme, on espere avoir un 'gyzis' qui utilisera gtk(+?) pour faire une jolie interface GTK/Gnome a yzis. L'ideal etant d'en faire d'abord un composant bonobo. La librairie 'core' fournit des interfaces generiques et independantes de KDE permettant ainsi de coder differentes GUIs au-dessus.
Nos objectifs sont donc :
1 - une librairie principale ou on fait tout le truc d'edition de texte dependante uniquement (et le moins possible) de Qt
2 - greffer des GUIs qui utilisent la librairie, apres c'est aux devels des GUIs de decider s'ils font ou non des composants reutilisables. kyzis fournit un kpart/ktexteditor pour pouvoir etre greffe dans kdevelop/quanta/etc...
donc s'il y a des volontaires pour une bonobofication de yzis, y a pas de probleme, suffit de coder et de nous contacter ;)
bien entendu, toutes les GUIs doivent 'linker' avec Qt vu que le composant de base c'est quand meme Qt, mais ca n'empeche nullement de faire une appli Gtk...
concernant Qt, on n'utilise qu'une tres faible partie de Qt dans le 'core', principalement les QStrings, QFile ... Que des trucs tres basiques. On attend donc impatiemment Qt4 :)
sinon peut meme avoir un yzis fait en motif, wxwindows, X ? , ...., tout ce qu'il faut c'est des volontaires pour les faire ;)
des qu'un connaisseur bonobo voudra bien rejoindre l'equipe alors oui sans doute ;)
on a peut-etre quelqu'un qui va s'en occuper mais c'est pas encore fait, mais on est encore dans les debuts d'yzis. L'avenir nous le dira.
[^] # Re: Des bugs dans Vim ?
Posté par Mickael Marchand . En réponse à la dépêche Chasse aux bugs ouverte pour Vim 7.0. Évalué à 1.
;)
Mik. qui lui, curieusement, avait bien compris la phrase quand meme :))
[^] # Re: Yzis, c'est le futur
Posté par Mickael Marchand . En réponse à la dépêche Chasse aux bugs ouverte pour Vim 7.0. Évalué à 2.
mais a nouveau, si des gens font le script pour traduire les fichiers Vim, tres bien, je prends !
Mais moi je ne le ferai pas ;) (ou alors faudrait vraiment que je m'ennuie sévère ;)
Je pense qu'on a des choses bien plus intéressantes à développer dans Yzis.
d'autant plus que 90% des scripts de Vim sont utilisés par 1% des utilisateurs de Vim, ce qui fait qu'on ira bien plus vite de réécrire les 10% "vraiment" utilisés à la main ;)
sinon traduire les 10 lignes du .vimrc des gens, franchement l'utilisateur peut le faire ;) (à un moment ou un autre l'utilisateur devra s'habituer à la conf d'Yzis de toute facon, la conf 'de base' est un bon moyen pour s'y habituer en douceur).
Le 'tout-auto-a-la-mode-windows-que-je-fais-plein-de-choses-partout-sans-te-le-dire', je trouve pas que ca soit une excellente idée ;)
Enfin, nous aurons normalement les options de base visibles via une jolie interface graphique "click-click" pour les vrais débutants, bien plus simple que le .vimrc ;)
(voire toutes les options peut-etre si on arrive à définir une méthode d'organisation et d'affichage propre et claire dans une GUI ce qui n'est pas forcément évident quand on a x centaines d'options)
Mik
[^] # Re: Yzis, c'est le futur
Posté par Mickael Marchand . En réponse à la dépêche Chasse aux bugs ouverte pour Vim 7.0. Évalué à 2.
et enfin c'est tres leger tout en etant tres rapide.
apres savoir si c'est "mieux" que Python ou Perl, je pense que c'est une simple question de gouts et de couleurs ;), et surtout l'usage qu'en font les utilisateurs.
Mik
[^] # Re: Yzis, c'est le futur
Posté par Mickael Marchand . En réponse à la dépêche Chasse aux bugs ouverte pour Vim 7.0. Évalué à 4.
neanmoins lorsqu'on aura finit la premiere version stable (a priori synchro avec KDE4 si tout va bien), on pourra envisager de rajouter les interfaces vers d'autres langages de scripts.
(je ne veux pas le faire avant pour pas que les developpeurs principaux se prennent trop la tete avec des choses qui me paraissent a l'heure actuelle 'gadget' ;)
Lua est un langage vraiment sympa et tres leger, facilement améliorable et dont l'integration en C est sympa.
concernant le module de compatibilité, Philippe a commencé un script Lua pour convertir les scripts vim en lua, c'est pas chose facile (conversion de regexps, des 0 qui veulent pas dire 'false' em Lua ...), donc on aura besoin d'aide pour faire ca.
de meme, ca ne me parait pas 'indispensable' comme fonctionnalité ;)
Sinon si vous avez besoin d'un script particulier, ca ne coute rien de poster un mail sur nos listes ou sur le site. Un volontaire pour s'entrainer a Lua passera peut-etre par la :)
et a defaut, ca nous aidera a voir quelles interfaces sont nécessaires entre le script et la librairie pour faire que ca soit plus simple a scripter.
au niveau Qt4, ca correspond a 95% a ce que j'esperais, a savoir des interfaces beaucoup plus claires, une separation en plusieurs librairies (ce qui fait que nyzis n'a plus besoin de charger une lib de 10Mo pour demarrer, le lancement est instantanné maintenant), et des perfs vraiment améliorées globalement comparées a qt3.
les 5% qui restent concernent QPrinter, mais je suis trop exigeant envers Qt ;) (j'aurais voulu que ca soit dans QtCore et pas dans QtGui ;o)
Mik
[^] # Re: Voila
Posté par Mickael Marchand . En réponse au message besoin de testeurs pour patch conntrack+RTSP+2.6.15. Évalué à 2.
c'etait un pbl de noyau qui n'avait rien a voir avec le RTSP en particulier :)
merci a toi :)
Mik
[^] # Re: Voila
Posté par Mickael Marchand . En réponse au message besoin de testeurs pour patch conntrack+RTSP+2.6.15. Évalué à 0.
/me hides
Mik
[^] # Re: Voila
Posté par Mickael Marchand . En réponse au message besoin de testeurs pour patch conntrack+RTSP+2.6.15. Évalué à 1.
c'est pas normal :)
il devrait au moins detecter la connexion client->server sur le port TCP 554 et t'afficher quel client tu utilises (cf ma reponse a phh).
Mik
[^] # Re: Voila
Posté par Mickael Marchand . En réponse au message besoin de testeurs pour patch conntrack+RTSP+2.6.15. Évalué à 2.
normalement y a aucun param a passer.
par contre il faut p-e une regle iptables du genre :
iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
(pour autoriser vraiment le conntrack)
Mik
Chez moi dans le debug ca donne qq chose du genre :
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: conntrackinfo = 2
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: IP_CT_DIR_REPLY
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: conntrackinfo = 2
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: IP_CT_DIR_REPLY
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help_out: found a setup message
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: rtsp_parse_transport: tran='Transport: RTP/AVP;unicast;client_port=33440-33441^M
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: rtsp_parse_transport: lo port found : 33440
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help_out: udp transport found, ports=(1,33440,33441)
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help_out: Changing expectation mask to handle multiple ports
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help_out: expect_related 212.27.38.253:0-82.233.104.105:33440
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: NAT rtsp help_out
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: hdr: len=9, CSeq: 2^M
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: hdr: len=52, Transport: RTP/AVP;unicast;client_port=33440-33441^M
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: hdr: Transport
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: rtsp_mangle_tran: stunaddr=82.233.104.105 (auto)
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: rtsp_mangle_tran: using ports 33440-33441
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: rep: len=52, Transport: RTP/AVP;unicast;client_port=33440-33441^M
Feb 21 09:46:25 localhost kernel: net/ipv4/netfilter/ip_nat_rtsp.c: help_out: hdr: len=59, User-Agent: MPlayer (LIVE555 Streaming Media v2005.10.05)^M
Feb 21 09:46:27 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: IP_CT_DIR_REPLY
Feb 21 09:46:27 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: help: IP_CT_DIR_REPLY
Feb 21 09:46:27 localhost kernel: net/ipv4/netfilter/ip_conntrack_rtsp.c: expected: newsrcip=212.27.38.253, newdstip=10.0.0.2, newip=10.0.0.2
(la derniere ligne indique que le conntrack marche normalement ;)
[^] # Re: Instructions CVS incorrectes
Posté par Mickael Marchand . En réponse à la dépêche Gnash, le lecteur Flash libre. Évalué à 2.
yet_another int->long ...
moi ca marchote plutot pas mal en ligne de commande (mieux que tous les autres lecteurs flashs 'libres' que j'ai pu voir), mais pour le plugin le chemin va etre long a priori ...
y a sans doute plein de bugs 64 bits encore ... faut nettoyer un peu ...
[^] # Re: packaging
Posté par Mickael Marchand . En réponse à la dépêche Nouvelle version de Kolab Groupware. Évalué à -3.
et 4 comptes IMAP ?
perso, j'essaye meme plus . c'est pire a chaque fois ...
Mik
# packaging
Posté par Mickael Marchand . En réponse à la dépêche Nouvelle version de Kolab Groupware. Évalué à 2.
ca leur ferait gagner du temps, et nous (utilisateurs) aussi.
ca permettrait que les distribs integrent ca "nativement" et donc (parce qu'y a une logique la-dessous) d'augmenter le nombre d'utilisateurs finaux (ce qui ne leur serait pas inutile si vous voulez mon avis, ne serait-ce que pour avoir des rapports de bugs sur le logiciel lui-meme plutot que sur leur installateur nullard ....).
bref, _jamais_ je n'installerai un openpkg sur un de mes serveurs, moi je veux utiliser les paquets standards de ma distribution preferee ( ou au pire pouvoir faire moi-meme ces paquets sans y passer 6 mois) pour pouvoir avoir :
1- les options que je veux avec ma distrib,
2 - les mises a jour de securite (parce que les mises a jour de secu chez openpkg j'ai un gros doute)
3 - 0 problemes de compatibilite
bref, ils se compliquent la vie avec un truc que personne n'a envie d'utiliser... et a mon avis ca en freine plus d'un a installer kolab qui pourtant en ont tres envie (moi par exemple mais j'en connais d'autre).
en fait, je suis de plus en plus decu par 'kdepim'.
J'ai vraiment le sentiment que de developper kolab (pour certaines entreprises donc ;) est plus important que d'avoir un client mail qui puisse avoir un 'uptime' superieur a 12h sans utiliser 90% de la RAM (ou sans planter...) ...
je n'ai qu'un espoir : que quelqu'un qui ait du temps se jette dedans pour nous refaire un kmail digne de ce nom pour KDE4 en repartant "from scratch" ....
L'integration de kmail dans kontact n'est d'ailleurs qu'une pile de "hacks" pour faire marcher le truc, je trouve tout ca bien 'decevant'
Mik, franchement depite par le chemin que suit kdepim ...
# Mise a jour ...
Posté par Mickael Marchand . En réponse à la dépêche KDE doit-il abandonner KHTML pour Webcore ?. Évalué à 3.
http://www.kdedevelopers.org/node/view/1046
la cooperation n'a pas encore totalement disparue apparemment
Mik
[^] # Re: KDE 4
Posté par Mickael Marchand . En réponse à la dépêche Le basculement de KDE vers Subversion est terminé. Évalué à 2.
(vieille URL qui trainait dans mon konqui)
Mik
[^] # Re: KDE 4
Posté par Mickael Marchand . En réponse à la dépêche Le basculement de KDE vers Subversion est terminé. Évalué à 10.
le boulot a commence mais non, kdelibs ne compile pas entierement ;)
DCOP a ete porte et devrait meme etre compat avec le DCOP de kde3.x.
Reste a faire des tests reels pour voir ce que ca donne.
kdecore, on a presque fini, encore quelques portages a faire. Peut-etre ce soir, si j'ai le temps j'essaierai de tout finir (y a des subtilites a travailler tout de meme, et je ne parle que de "faire compiler" la bete ...) (de la a ce qu'on puisse lancer une KApplication, y aura sans doute encore un pas ;)
kdeui, alors la c'est pas pour demain, plein de changements a faire ;)
kio, devrait a priori pas etre trop complique d'apres ce que j'ai pu en voir...
le reste de kdelibs devrait suivre sans trop de problemes normalement
Maksim a deja porte kdefx ainsi qu'un style de base pour les fenetres, il va attaquer keramik il me semble.
Thiago s'est occupe de la couche reseau qu'il avait prepare depuis un moment.
apres il faudra voir pour kdebase ou y aura un boulot enorme egalement.
une fois qu'on aura tout ca, qu'on aura bien compris toutes les subtilites, y a moyen que ca aille un peu plus vite pour le reste des applis.
bref, pour voir demarrer un kde4 (encore faudrait-il en avoir envie hein parce que pour le moment ... ;), il faudra compter plusieurs semaines ;)
Mik
# KDE 4 en octobre 2005 ...
Posté par Mickael Marchand . En réponse à la dépêche Ubuntu Hoary Hedgehog (5.04) est sortie. Évalué à 6.
ca parait totalement surrealiste hein
(le portage a meme pas encore commence...)
sachant que en plus KDE 3.5 est prevu...
Mik
[^] # Re: sugestion
Posté par Mickael Marchand . En réponse à la dépêche Yzis M3 est arrivé. Évalué à 1.
bande passante :
c'est en cours (le serveur est pas pinguable)
pour les impatients :
http://yzis.org.free.fr/shots/ pour les screenshots ;)
retour du serveur ce soir vers ~17h normalement
Mik
[^] # Re: sugestion
Posté par Mickael Marchand . En réponse à la dépêche Yzis M3 est arrivé. Évalué à 1.
Mik
[^] # Re: sugestion
Posté par Mickael Marchand . En réponse à la dépêche Yzis M3 est arrivé. Évalué à 1.
Mik
[^] # Re: Hum, hum
Posté par Mickael Marchand . En réponse à la dépêche Yzis sort sa deuxième version. Évalué à 2.
je dois pouvoir corriger ca dans la journee, c'est trivial ;)
Cheers,
Mik
PS: pour tester , sudo mv $KDEDIR/share/yzis/syntax $KDEDIR/share/yzis/syntax.old, puis yzis ./configure (1Mo), moins d'une seconde pour le chargement chez moi.
[^] # Re: Y a plus qu'à...
Posté par Mickael Marchand . En réponse à la dépêche Yzis sort sa deuxième version. Évalué à 1.
mais c'est justement parce qu'on peut rien en faire que c'est nul.
alors que kyzis ....
ben vous verrez bien ;)
Cheers,
Mik
[^] # Re: Y a plus qu'à...
Posté par Mickael Marchand . En réponse à la dépêche Yzis sort sa deuxième version. Évalué à 5.
l'interface core<->GUI utilise tres peu Qt, justement pour simplifier l'integration avec d'autres toolkits,
et en cas de probleme, on est toujours pret a faire les modifs necessaires pour permettre une integration plus facile ...
il faut juste des volontaires qui connaissent gtk(2)(+) :)
Mik
[^] # Re: Une question
Posté par Mickael Marchand . En réponse à la dépêche Yzis sort sa deuxième version. Évalué à 4.
mais on essaye de garder les memes noms pour les options.
pour M4 on essayera de faire un systeme de compatibilite avec vim, pour lire et essayer de comprendre les .vimrc etc ...
Cheers,
Mik
[^] # Re: Intégrer Vim dans Gnome..
Posté par Mickael Marchand . En réponse à la dépêche Vim 6.3 dans les bacs.. Évalué à 4.
Yzis , c'est :
1 - une librairie 'core' basee sur Qt et Lua (pour le moment)
pour l'instant Qt3 mais avec Qt4 on devrait avoir un 'qt4 non-GUI' qui normalement sera une petite librairie (plus legere que le Qt actuel quoi)
2 - une appli 'kyzis' qui utilise la librairie precedente et les librairies KDE pour faire un composant et une jolie appli KDE
3 - une appli 'nyzis' qui utilise ncurses 5 pour avoir un 'yzis' en mode console
vu que libyzis utilise Qt, on a ainsi directement des choses comme l'unicode, les listes, les keycodes etc. Ca nous evite de reecrire 90% du code de Vim en gros et de nous concentrer sur les choses importantes (== les fonctionnalites ;)
a terme, on espere avoir un 'gyzis' qui utilisera gtk(+?) pour faire une jolie interface GTK/Gnome a yzis. L'ideal etant d'en faire d'abord un composant bonobo. La librairie 'core' fournit des interfaces generiques et independantes de KDE permettant ainsi de coder differentes GUIs au-dessus.
Nos objectifs sont donc :
1 - une librairie principale ou on fait tout le truc d'edition de texte dependante uniquement (et le moins possible) de Qt
2 - greffer des GUIs qui utilisent la librairie, apres c'est aux devels des GUIs de decider s'ils font ou non des composants reutilisables. kyzis fournit un kpart/ktexteditor pour pouvoir etre greffe dans kdevelop/quanta/etc...
donc s'il y a des volontaires pour une bonobofication de yzis, y a pas de probleme, suffit de coder et de nous contacter ;)
bien entendu, toutes les GUIs doivent 'linker' avec Qt vu que le composant de base c'est quand meme Qt, mais ca n'empeche nullement de faire une appli Gtk...
concernant Qt, on n'utilise qu'une tres faible partie de Qt dans le 'core', principalement les QStrings, QFile ... Que des trucs tres basiques. On attend donc impatiemment Qt4 :)
sinon peut meme avoir un yzis fait en motif, wxwindows, X ? , ...., tout ce qu'il faut c'est des volontaires pour les faire ;)
Mik
[^] # Re: Yzis
Posté par Mickael Marchand . En réponse à la dépêche Vim 6.3 dans les bacs.. Évalué à 1.
j'ai repare le ftp
de toute facon mieux vaut utiliser les snapshots, ca a bien change depuis M1 ;)
Mik
[^] # Re: Vim 7
Posté par Mickael Marchand . En réponse à la dépêche Vim 6.3 dans les bacs.. Évalué à 2.
on a peut-etre quelqu'un qui va s'en occuper mais c'est pas encore fait, mais on est encore dans les debuts d'yzis. L'avenir nous le dira.
En tout cas, techniquement, yzis a ete fait pour.
Mik