Philippe F a écrit 2214 commentaires

A mon avis, il faut plutot appeler layout_principal->activate() dans ton slot pour forcer le recalcul des tailles des differents widgets.

Permets-moi de preciser concernant les versions windows :

- la version en libre telechargement reservee a un usage non commercial est la version 2.3, une vielle version en effet.

- si tu achetes le livre recent "programming with Qt", tu obtiens la toute derniere version de Qt sous Windows, avec une licence pour usage non commercial egalement.

- tu peux facilement obtenir une version de demonstration valable pour deux moi si tu fais la demande comme precise sur leur site web.

Dans aucun de ces trucs la tu n'as les sources. Si tu achetes Qt (1500$), tu as les sources mais pas sous GPL.

C'est vrai qu'on est quand meme sur linuxfr, faudrait pas qu'on commence a discuter de facon conviviale avec des arguments peses mesures, parce que sinon, personne ne saurait plus quoi dire.

Le filtre bayesien fonctionne en reconnaissant l'occurence de certains mots. Dans le cas d'un mail avec une image seule, il va probablement conclure qu'il n'y a pas assez de mot pour se faire une bonne opinion, et classer le mail comme neutre.

Un filtre bayesien n'a pas de notion global du mail, donc il n'est pas capable de reconnaitre un mail avec une seule image en tant que tel.

Donc en effet, ce genre de mail a tendance a passer assez bien. Cela dit, si on desactive l'affichage des liens externes dans les mails html (et c'est hautement recommande, pas seulement pour le spam mais aussi pour eviter un tracage du mail (une requete http a chaque fois qu'un quidam affiche le mail, sympa!) ), le spam devient relativement inoffensif.

Pour contrer ce genre de spam, il va falloir imaginer de nouveaux trucs.

C'est marrant que tu cites vim comme projet innovant. Il le fut en son temps mais mainetenant, vim est exactement l'inverse d'un projet innovant: un bon editeur qui ne bougera plus beaucoup.

Si tu veux chercher de l'innovation cote vi, va plutot voir yzis: www.yzis.org

- integration dans des framework de composants graphiques
- separation entre gui et moteur vi
- code structure et oriente objet (il faut voir les sources de vim - en C pre-ansi - pour comprendre l'interet de celui-la)
- utilisation d'un langage de script existant (lua) au lieu d'un truc fait maison
- integration dans Kate, KDevelop, Quanta

Et bien plus a venir bientot

Mais si, allez voir kexi :

http://www.kexi-project.org/screenshots.html(...)

Si tu scannes de cartes de tarot, tu as un probleme de copyright, a moins d'etre sur que les images sont dans le domaine public.

Le mieux serait de demander a un bon graphiste de nous refaire des cartes de tarot, avec un theme pengouin.

Je l'ai pas vu dans tools->options ...

Ah, il faut trifouiler un fichier texte planque dans un coin obscur, ecrit dans un langage abscond. Je comprend mieux. Dire que naivement, je pensais que Firefox etait un navigateur grand public :-)

Depuis mon post, il y a eu une reponse intelligente.

Sinon oui, le ton tres defensif du posteur initial montre bien qu'il s'est deja fait rembarre et est donc mefiant. Voici un utilisateur qui a eu maille a partir avec des developpeurs ou d'autres utilisateurs. Qui penserait que le logiciel libre est un monde paisible...

Sinon, pour ce qui est du choix entre fonctionnalites graphiques ou fonctionnalites de fond, il faut voir que ce ne sont pas les memes personnes qui contribuent a la correction des fuites memoires et au l'amelioration des themes. Donc quand l'apparence s'ameliore, ce n'est pas moins de temps passe sur les fuites memoires, c'est simplement un autre developpeur qui a passe du temps.

Je pense que ceci s'applique pour mozilla aussi:
http://kdemyths.urbanlizard.com/viewMyth.php?mythID=51(...)

Je me souviens aussi de la fois ou j'ai clique naivement sur une photo recemment telechargee de l'appareil photo numerique d'un copain. Quelle erreur dramatique:
- firebird (a l'epoque) s'etait enregistre pour tous les formats d'images supportes
- l'image etait un mechant png tres haute resolution
- firebird m'a bloque ma machine pendant 10 minutes avant de planter miserablement

Reponse des developpeurs: ben oui, mais il ne faut pas cliquer sur de telles images ! Ben oui, en fait c'est de ma faute, j'ai pas le droit d'avoir des images aussi grosses. Dans ce cas precis, si firebird est incapable de gerer des grosses images, il devrait le dire plutot que de bloquer la machine pendant 10 minutes avec une image qui lui fait repasser sa vie devant lui.

J'ai trouve, c'est dans la meme extension que celle citee plus haut. Vous pouvez pas imaginer a quel point je me sens mieux.

Moi je n'ai pas vu cette attitude-la chez lui. J'ai vu qq'un qui signale un probleme grave, preuve a l'appui, et qui visiblement s'est deja fait rembarre un certain nombre de fois comme vous venez de le faire une fois de plus.

Ca entretient le climat qu'il interdit de critiquer un logiciel libre. Pour un produit aussi repandu et aussi supporte qui firefox, une telle fuite memoire est un probleme tres tres grave et plutot que de taper le messager, je trouve qu'il serai bon ton de s'inquieter.

Sinon on peut toujours rajouter un panneau sur www.mozilla.org disant "l'execution de ce logiciel est recommande pour des machines avec au moins 300 Mo de RAM en raison des importantes fuites memoires".

Ce qui m'agace particulierement, c'est que je suis sur que vous serez les premiers a raler pour une petite boulette d'un logiciel proprietaire mais que vous laissez passer ce probleme comme si ce n'etait pas important.

<< Bien sur qu'il y a des problemes, et personne ne parle ici de faire l'autruche, bien au contraire >>

Ah oui ? Et bien pour ma part, quand qq'un signale un probleme et qu'on ne s'attache a repondre que sur le ton et sur la personne qui le signale, je trouve que vous mettez nettement le probleme de cote.

Aujourd'hui, utiliser du logiciel libre sous windows demande d'avoir une machine plus puissante que pour utiliser du logiciel proprio (OpenOffice, Firefox, Thunderbird) sous windows. Pourtant, dieu sait a quel point les gens de l'open source et de free software ralent sur les besoins en memoire de windows. Mais des qu'il s'agit de balayer devant sa porte, il y a beaucoup moins de monde.

Juste pour anecdote, la fonctionnalite la plus appreciee de KDE 3.2 est la reduction de son occupation memoire (car contrairement a ce qu'en disent ses detracteurs, KDE est de moins en moins gourmand a chaque release) et l'amelioration de la rapidite de lancement de KDE et des applis KDE.

<< Il y aura toujours des fuites mémoires, malheureusement. >>

Ah ouai ? Qu'est ce qui te fait dire ca ? Si tu programmes proprement (avec des strategies d'allocation memoire, des pointeurs geres) et que tu fais tourner ton programme sous valgrind regulierement, je ne vois pas pourquoi il devrait toujours y avoir des fuites memoires. Il y a des langages ou des libs qui facilitent aussi grandement la gestion de la memoire.

Je trouve ca un rien defaitiste comme attitude et surtout pessimiste. C'est comme si tu disais << on sera toujours mauvais, on ne saura jamais programmer donc arrete de te plaindre >>.

> Tu serais surpris par l'étendu de la bêtise parmis les utilisateurs...

Moi ce qui ne me surprend malheureusement plus, c'est l'etroitesse d'esprit de certains developpeurs. Ils fonctionnent avec un scenario d'utilisation unique et souvent pas simple, et refusent de faire quoi que ce soit pour permettre a des gens utilisant les choses differemmant d'etre a l'aise.

Je trouve quand meme que l'attitude a ete ici tres reprobatrice. Comme si on n'avait pas le droit de trouver un defaut a un logiciel libre et de protester.

Une fuite memoire de cette taille, c'est un probleme tres serieux et je partage l'inquietude de la personne qui l'a signale: si plusieurs versions continuent a avoir le meme probleme sans que rien ne soit fait pour le corriger, on est en droit de se demander si les developpeurs considerent ca comme un probleme mineur ou pas.

La consommation memoire et le temps de chargement de mozilla sont aussi des preoccupations importantes je trouve. Pourtant, je l'utilise sous windows ou il parait qu'il est plus rapide que sous linux. Moi ce que je vois, c'est que ma machine le sent tout de suite si je lance thunderbird et/ou firefox. Ca prend du temps a se charger, ca prend de la memoire, etc.

Les champs d'ameliorations possibles de firefox ne manquent pas mais ce point semble quand meme avoir ete laisse de cote.

C'est possible avec une extension, mais il ne me semble pas qu'elle aie ete portee sour firefox 0.9 . Je l'utilisais sur la 0.7 .

Dans la serie des autres trucs chiants, je n'ai pas trouve comment faire en sorte que le middle-click ouvrent un tab _en arriere plan_. Pour mon utilisation personelle, c'est une regression absolument insupportable parce que je n'ouvre les tabs que en arriere-plan.

Yeps.

Historiquement dans le logiciel libre, on a vu des projets qui se sont scindes en un projet stable qui n'evolue plus et un projet dynamique, moins stable, qui evolue plus vite (gcc vs egcs par exemple, ou emacs vs Xemacs, ). De ce que j'en ai vu, le projet qui evolue prend a terme au moins 50% des utilisateurs, voire dans certains cas enterre l'autre projet.

> D'après les commentaires précédents, intégrer Vim dans KDE est très compliqué.

On s'est mal compris sur la signification du mot integrer.

Avoir vim pour editer ses mails dans KDE, c'est possible depuis longtemp (mikmak avait fait un patch dans ce sens). Avoir vim en style KDE, pareil, c'est possible depuis longtemp. Ca revient juste a lancer un editeur au bon moment, il n'y a pas de contraintes particulieres.

Mainenant, si on veut integrer vim dans KDevelop ou dans Kate, on doit avoir:
- la possibilite d'afficher plusieurs fenetres independantes sur le meme texte
- la possiblite de gerer plusieurs fenetres independantes avec du texte different
- la notion de focus: ce n'est pas toujours l'editeur qui controle ce qui se passe
- la notion boucle d'evenement separee: l'editeur n'etant pas le maitre, il doit se laisser controler par l'application qui l'embarque.

Ces 4 points sont _impossibles_ a realiser avec vim, et ce independamment de KDE ou de Gnome.

Pour l'instant, les gens qui parlent d'integration dans Gnome / bonobo de vim parlent en fait de modifier l'application cible pour qu'elle puisse appeler explicitement le composant vim (type le patch evolution).

Pour KDE, on a un niveau d'abstraciton qui a ma connaissance n'est pas present dans Gnome: KDE definit un composant editeur generique, avec des notions de documents, vue, curseur, undo, ... Rentrer vim la-dedans implique de s'adapter a ces contraintes. Le resultat, c'est que n'importe quelle application KDE pourra utiliser vim, sans meme le savoir. L'utilisateur aura juste a declarer le kpart vim comme son kpart editeur prefere. Ca va beaucoup plus loin que patcher evolution. Notamment, les applications comme quanta ou kdevelop n'ont meme pas besoin d'etre patchee.

Voila pourquoi on peut avoir l'impression que l'integration de vim dans KDE est plus difficile que dans Gnome. C'est simplement qu'on va plus loin.

Les 4 points cites sont les plus bloquants pour utiliser vim en tant que composant graphique. Bien sur, je ne vous surprend pas en vous disant que yzis n'a pas ces limitations.

Et ta connerie, elle est comment ?

> Vim, et les applications KDE ont des «philosophies» radicalement opposées

Oui et non. KDE, c'est ce qu'on en fait. Il y a avant-tout une grosse pression sur la facilite d'utilisation, mais il y a aussi une grosse communaute de hackers sur KDE, ce qui fait que KDE convient aussi a un hacker de fond. Il n'y a qu'a voir les possiblites de konqueror ou de dcop pour s'en convaincre.

> Les fonctionnalités que tu attend de kvim, ça ne serait pas plutôt le rôle de kwrite de te les offrir ?

De kvim, j'attend un editeur gvim avec les icones et les menus KDE. Ca, ca va on l'a fait mais ca n'a pas ete sans quelques bidouilles. Apres, l'etape importante, c'est l'integration d'un composant editeur compatible vi dans KDE. Tu serais surpris du nombre de personnes qui sont interessees par ce truc. Les demandes les plus fortes pour ce genre d'integration sont pour KDevelop et Quanta+: des logiciels de developpeurs a qui un vim ne fait pas peur. Avoir un bon Kate avec vi pour la partie editeur etait aussi un de mes reves. Malheureusement, la structure de vim ne le permet pas.

Pour en revenir a la question, pour faire un composant vi pour KDE, il parait naturel de se tourner vers le meilleur editeur vi qui soit, a savoir vim. Malheureusement, en raison d'une part de l'architecture de vim un peu trop orientee C, d'autre part de l'entetement de l'auteur a refuser tout patch, il n'est pas possible de faire de vim un composant editeur KDE proprement. Je dis ca bien que vous puissiez utiliser kvim aujourd'hui dans kdevelop mais a un prix en developpement que vous ne pouvez pas imaginer. Il y a par exemple une chance sur 5 que kvim se lance en dehors de la fenetre de kdevelop.

> Sinon, tu a fait une sacrée sélection dans les demandes de fonctionnalités

J'ai pris les fonctionnalites qui etaient significatives par rapport a ce que je demandais. Les trois fonctionnalites citees sont des fonctionnalites que nous avons demandees a Bram en exposant notre point de vue pendant une longue discussion pour aboutir au final au rejet de notre proposition. A cause de cela, et presque contre notre gre, nous avons demarre un projet d'editeur compatible vim concurrent: yzis.

Je trouve ca ironique qu'apres nous avoir envoye bouler, il figure parmi les fonctionnalites les plus demandees precisement les fonctionnalites que Bram a refuse qu'on ajoute.

Pour finir sur Yzis, je citerai la phrase de Mickael (un des initiateurs du projet): "il faut deux ans pour que Bram integre un patch de notre part dans vim. En deux ans, on a le temps de redevelopper un editeur".

Yzis presente un certains nombre d'avantages indeniables sur vim, meme s'il est encore tres jeune:
- un langage de script reconnu et massivement diffuse: lua (v5.0)
- un support de la coloration syntaxique beaucoup plus puissant et plus simple a ecrire, base en particulier sur des fichiers xml et partage avec l'editeur kate/kwrite
- une abstraction frontend / moteur vi qui permet de reutiliser le moteur yzis dans plein de circonstances
- une utilisation massive de bibliotheques deja existantes de debuggees plutot que l'utilisation de truc faits maison.

Vous allez dire que je suis mechant mais je me marre en lisant ca:

104 points: support embedding of Vim in another GUI program

Apres plus de trois ans de bataille avec le code de vim, et un certain nombre de discussion avec Bram, il est apparu que le GUI graphique ne faisait pas partie des priorites de Bram, ni meme de son champ de comprehension. Apparamment, c'est pourtant la priorite des utilisateurs. Pire, il est apparu que Bram ne comprenait pas vraiment les besoins d'un bon GUI graphique et surtout n'envisageait pas de changer une ligne de code de vim pour supporter quoi que ce soit dans ce sens. A cause de cela, kvim est bourre de hacks qui permettent vaguement de lancer kvim sans prendre 100% de cpu si il est de bonne humeur. Vous pleureriez si vous saviez comment on arrive a faire un composant vim pour KDE a partir de ca.

La derniere fois qu'on lui a demande de separer vim en un moteur vim et un gui vim pour faciliter l'integration graphique, il a dit qu'il ne toucherait pas a ces parties la et que vim resterait tel qu'il est, un editeur oriente terminal. Les changements seraient de toute maniere trop profond pour pouvoir etre realises. Je me demande si il a juste change d'avis et ne realise pas l'ampleur de la tache maintenant, ou si il s'est juste foutu de notre gueule a l'epoque.

A mon avis, vous pouvez toujours rever mais vous n'etes pas pret d'avoir un bon gui pour vim. Par bon gui, j'entends un truc qui ne soit pas equivalent a xterm + vim mais plutot un gui incrustable dans kdevelop, quanta ou kmail.

74 points : add IDE features (debugger integration, shell window)

Dites-moi, il a bien change Bram. Pareil, quand on lui a dit que separer vim en un moteur et un frontend permettrait d'integrer vim dans un IDE style KDevelop, il a dit que c'etait ce qu'il voulait (bien qu'il n'accepte aucun patch allant dans cette direction) et que vim ne devait pas devenir un IDE en soi.

62 points: support multiple top-level windows for one running Vim

La aussi, ca me fait marrer. Parmi toutes les directions qu'il ne voulait pas prendre, celle-ci semble quand meme la plus facile a ajouter au code.

Bah, vim c'est depasse. Mainenant il y a yzis (http://www.yzis.org(...) )

Pour ce qui est de l'integration des nouvelles fonctionnalites, j'espere que Bram se comportera mieux que par le passe mais je n'y crois pas. Il ne lui a fallu << que >> deux ans pour integrer les patch de kvim dans vim. Des que tu lui demandes de changer une ligne de code, il faut compter entre 1 et 12 mois de discussions et negociations. Alors pour une nouvelle fonctionnalite, j'ose pas imaginer.

<< Si vous travaillez sur un projet libre peu connu et ayant besoin de ressources, venez inscrire ce projet à l'adresse au bas de cette annonce. Les inscriptions sont ouvertes durant tout le mois de Juin 2004. >>

Ca existe les projets libres connus et n'ayant pas besoin de resources ? Meme des projets majeurs comme KDE ou le noyau linux ont besoin de ressources alors pour les autres, j'imagine pas...

Tu as rentre 300 operations a la main dans une meme categorie, et tu veux changer de categorie 200 operations parmis ces 300. Sous vi, je te fais ca en 20 secondes. Sous grisbi, je pense qu'il faut une option filtre + une option multi-selection d'operation pour faire ca facilement.

Autre cas que j'ai eu: je veux annuler un rapprochement parce que je l'ai mal utilise. J'ai pas vu comment faire depuis grisbi. Et idem, le faire a la souris sur 400 operations, je le sens pas trop. Alors meme que ca prend 10s sous vi.

J'avais pas trouve a cette epoque l'option de redimensionnement des colonnes et j'ai renonce pour d'autres raisons.

Pour ce qui de la syntaxe du fichier xml, par exemple j'ai note que le nombre d'operations est ecrit dans le fichier alors meme que c'est un nombre qui pourrait etre calcule a la lecture du fichier. Du coup, si je rajoute une operation ou que j'en enleve une, ca craque.

Je pense qu'il y a possibilite de faire un fichier xml un tout petit moins interdependant, qui permettrait plus facilement de laisser la place a des modifs manuelles. Cela dit, en utilisant grisbi un peu plus, j'ai decouvert qu'il etait possible de faire ce que je voulais faire (changer toute une serie d'item de categorie) directement via grisbi (en effacant la categorie).

Pour ce qui est des filtres, je pense que ca peut etre sympa a inclure dans l'affichage des operations et que c'est plus facile a aprehender qu'un etat.

Un bon exemple de filtre est le filtre d'affichage des mails de Thunderbird. Il est facile a mettre en place et pas complique a utiliser.

Si un utilisateur peut en trois clics dire "affiche-moi toutes les depenses de plus de 1000 euro" parce qu'il sait qu'il veut modifier qqch dans ces depenses, c'est un atout.

Ah oui, une fonctionnalite pas trop difficile et fondamentale qui m'a
manque: la recherche d'operations.

Le mode d'emploi est tres bien fait, en francais, avec meme quelques references linguistiques.

Un probleme que j'ai avec mes comptes, c'est que je change souvent d'avis. Je decide de re-categoriser certains trucs differamment, de separer certaines depenses, de faire un virement compte a compte au lieu de marquer une depense et un revenu, etc.

C'est pour ca que j'ai eu des besoins de modifier le fichier xml. A mon avis, ce genre de problematique (les gens qui changent de methode de classement) est a prendre en compte car je ne suis certainement pas le seul.

A priori, l'utilisateur novice va commencer par utiliser les fonctionnalites de base de l'outil, puis, au fur a mesure qu'il se familiarise, modifier la facon dont il rentre ses operations pour tirer plus partie des possibliites du logiciel. Il sera donc amener a changer la facon dont il fonctionne.

Pour ce qui est du probleme du bugotron, je re-essaierai et vous tiendrait au courant. En tout cas, j'apprecie la reactivite sur linuxfr :-)

Moi j'aime bien le projet et j'utilise notamment sous windows pour gerer les comptes d'une PME (ben oui, parfois on fait au plus simple)

J'ai trouve que dans les details quand meme, il y avait des choses desagreables. Par exemple pour la version 0.4, il plantait toutes les minutes, au point que j'ai renonce a l'utiliser.

J'ai eu beau lutter, impossible de me logger sur leur systeme de gestion de bug, ce qui ne fait jamais une bonne impression.

Des petits trucs desagreable, comme le fait que les tailles des colonnes sont fixes et non redimensionnables, ou bien que les sommes ecrites ne soient pas alignees, donnant une impression de desordre.

Mais quand meme, en acceptant les limitations, c'est plutot sympatiques. Des trucs que j'aimerai voir dans le futur:
- une simplification de la syntaxe du fichier xml, pour pouvoir eventuellement le modifier a la main et eviter qu'il plante aussi souvent
- le selection d'operations pour pouvoir modifier un seul critere facilement (typiquement la categorie)
- des filtres dans l'affichage des operations
- le redimensionnement des colonnes
- dans les etats, la possibilite d'afficher mes depenses par categories.

J'espere que le projet evoluera vers qqch de bien.