TImaniac a écrit 6423 commentaires

Erf. Il y a plusieurs degrés de "liberté" dans un logiciel. La licence, même avec sa table des 4 vérités façon GPL n'est qu'une partie de ces libertés. Encore faut-il la faciliter. Pour moi un projet qui n'a par exemple aucune documentation perd beaucoup de son ouverture. Idem pour un projet dont les développeurs sont "fermés". Ben pour moi il en est de même de l'architecture des logiciels. Evidemment KDE et Kat resteront des logiciels "libres" au sens "GNU"/OSI du terme, mais Kat restera enfermé dans KDE. C'est une autre forme de dépendance.

Même si je suis conscient que KDE et Gnome ont des conceptions très différentes du desktop ils partagent cependant de nombreuses valeurs communes, le plus souvent d'un point de vue architecture ou techniques : les 2 sont indépendant du noyau sous-jacent, les 2 aiment à séparer bibliothèques techniques et applications utilisateurs, ce qui est un critère de qualité évident et minimum de toutes solutions informatiques bien conçues.

Après j'essai de démontrer que toute la valeur ajoutée de softs comme Beagle et Kat réside ENTIEREMENT en dehors de toutes considérations liées à l'interface et son environnement (Gnome ou KDE). Il est donc parfaitement stupide d'enfermer un tel projet dans un environnement de bureau, alors que les technologies sous-jacentes pourraient être partageables et réutilisable en dehors de tous contexte graphique.

On peut par exemple imaginer faire tourner un tel service sur un serveur de fichier et proposer les fonctionnalités d'indexation à travers un serveur web.

Incorporer Kat dans KDE et rendre le premier dépendant du second est un choix complètement idéologique, trollesque, mais n'est d'aucune manière un choix pertinent de conception,à moins que tu arrives à me montrer le contraire, autrement que par la "force" des propos. Moi j'ai agrémenter mon argumentation d'un exemple : Beagle, non pas LA solution, mais l'exemple d'architecture qu'il représente (et pourtant Beagle n'a pas inventé l'eau chaude en matière d'architecture).

À te lire on dirait presque une critique.
Oui c'est une critique, en ce sens que KDE compte bien intégrer ce projet. On n'a plus le droit d'émettre une critique ?

Comme indiqué plus haut, les trolleurs empêcheront Beagle d'être intégré à Gnome ou KDE, mais KDE a pour moi fait le mauvais choix, en tout cas un choix qui ne va pas dans l'esprit du libre : leur appli ne sera pas réutilisable dans Gnome. Et Gnome n'a pas d'équivalent ! (Beagle étant trollogène ne compte pas).
Il aurait été tellement plus simple d'avoir une base commune, pour une fois, dans la techno qui vous fait plaisir, mais conçu avec une architecture intelligente; la même que Beagle (et tant d'autres applications).
Mais non, chez KDE on aime bien montrer que c'est nous qu'avons la plus grosse, et hop on fait comme Microsoft : on enferme l'utilisateur et ses logiciels sous le prétexte "d'intégration", et au final on préfère se targuer de prendre position dans un troll et en jouant à la surenchère de features (hypothétiques au passage) plutôt que de penser au principal : l'architecture du soft.
Clap clap clap. On croirait entendre des décaïdeurs.

Oui je suis aigri, mais je trouve déjà tellement dommage d'avoir autant d'effort duppliqués bêtement entre Gnome et KDE là où y'a pas besoin, que le projet Kat a tendance à m'énerver.
Ne prenez pas ce journal pour la gloire de Mono ou Beagle, mais comme un exemple de ce que Kat devrait suivre.

Houlà, mais je comprends tout à fait cette controverse, mais lisez ma phrase en entier : ce que je trouve dommage, c'est que Kat soit dépendant de KDE (ou Qt), et donc pas du tout réutilisable dans Gnome.
Ce que j'aime dans Beagle c'est justement son architecture, son modèle client/daemon, qui a toujours fait la force des unix/linux. Que Kat réinvente la roue ne me dérange pas en soit, Beagle le fait également, mais Kat le fait de manière à ce que ca ne soit pas réutilisable directement, et c'est bien celà que je trouve dommage.

Continuez à troller sur les technos si ca vous amuses, Mono a beau être controversé, Qt l'a été pendant de nombreuses années sans que ca dérange KDE, et au final la plupart des distributions intègrent mono, sauf bien entendu font exception les Red Hat/Fedora qui a fait le choix du troll Java/Mono.

Je trouve ca con de s'arrêter à ce genre de détails, quand un détail à mon sens plus important (ici l'enfermemant d'un soft dans un environnement). Ce qui aurait été bien c'est qu'ils partagent au moins les mêmes bases d'indexation, que freedestkop normalise tout ca.

C'est justement là où je voulais en (re)venir : Kat réinvente la roue (puisque Beagle commence a devenir mature et utilisable) et semble avoir pour seule raison de vivre, le fait d'être dans un futur proche intégré à KDE alors que Beagle "apparaissait" comme une solution pour Gnome.

Pour se justifier un peu plus, Kat voit "grand" et envisage la notion de "contexte", mais plutôt que de rajouter des super jantes aux roues existentes et en faire profiter tout le monde en participant à Beagle, ils se dirigent vers une solution dépendante de KDE et donc inutilisable en dehors.

C'est dommage, surtout que c'est un domaine où le gros du travail n'est pas fait au niveau de l'ergonomie (donc indépendament de KDE ou Gnome) mais à un niveau beaucoup plus bas. D'autant plus dommage qu'il aurait été bien d'avoir un seul daemon d'indexation qui tourne sur la machine, qui partage la même base d'indexation.

AbiWord utilisant l'artillerie Gnome, je suppose que le chargement est beaucoup plus rapide dans cet environnement. Sous Windows, il doit se retrouver à égalité avec OOo, chacun ayant le même désavantage : à savoir charger en mémoire tout le framework graphique.

Lis le premier commentaire, et suit le lien qui est dedans, y'a la réponse à ta première question, et en partie à ta 2ème question.

News par ici :
http://linuxfr.org/2005/10/04/19674.html(...)

Ca paraissait trop gros aussi, Microsoft n'est pas assez fou pour laisser une marge aussi visible (6 fois plus) entre une migration vers Linux et une upgrade Win->Win. Sinon y'a longtemp que de nombreuses entreprises auraient switcher si c'était aussi évident :)

Fallait se bouger le cul à la pointe du cotentin, là c'était la totale, et c'est autrement plus impressionnant : ombre qui approche, cris des mouettesn, nuit soudaine, vent froid avec finalement comme seul bruit des vagues contre les falaises...

Maintenant que tu connais la définition de ce mot vital, passe à l'étape suivante de ton apprentissage de geek (je te laisse trouver le sens de ce mot) :
utiliser un moteur de recherche.
- Va à l'adresse http://www.google.fr(...)
- dans la boite, tapes le texte : lol
- coche la case "pages francophones"
- lance la recherche
Miracle ! Cliques sur le premier lien
@+ pour de nouvelles aventures !

Y'a Eclipse qui tourne bien avec GCJ et qui est un bon exemple de bonne grosse appli stressante pour la VM :)
Sinon ca sert à rien de faire la guguerre CLassPath/Mono, le 2ème proposant une passerelle entre les 2 : on peut utiliser les ClassPath depuis Mono, et utiliser les libs Mono depuis Java. Le plus rigolo c'est qu'on peut compiler du code en natif sans passer par gcj mais en utilisant IKVM puis mono qui fait la compilation en natif depuis un baille (les technos .NET étant conçu pour cette opération).

C'est sûr :)
Mais bon rien ne t'empêche d'utiliser les autres méthodes. Perso quand je dois le faire à la main, je me fais bêtement 2 classes "MachinReader" et "MachinWriter" qui sont capable de serialiser/deserialiser tout le graphe d'objet métier. Ensuite j'en ai autant que j'ai de support visés, et je touche jamais au modèle métier.

Ben pas comme ca :)
Y'a pleins de solutions.
Dans tous les cas t'as une classe métier, appelons la : Metier.
Il faut qu'elle soit parfaitement indépendante de toutes bibliothèques techniques, qu'elle soit graphique ou accès au FS.
Ensuite tu peux :
- faire une classe MetierSerialisable qui hérite de Metier et qui se trouve dans la couche de persistance : problème, il faut passer par une FabriqueAbstraite pour garantir que ce sont bien tes objets de persistance qui sont construits, bref ca t'oblige à modifier ta couche métier.

- injecter la méthode Serialize à l'aide d'un outil de tissage d'aspect (programmation par aspect).

- utiliser une classe séparée (genre XMLSerializer) qui sérialise tous tes types métiers et qui parcours ta structure.

- utiliser une classe séparée qui sérialise automatiquement par Reflection.

- utiliser une lib de mapping qui fera tout le boulot pour toi. Elles utilisent généralement une des techniques au dessus.

L'idée est dans tous les cas de pouvoir modifier/changer de moyen de persistance sans jamais toucher au modèle métier.

et avec .Net, vous risquez de pondre un truc qui dépend... de Windows
Suffit de d'installer Mono sous Windows et de développer avec l'IDE SharpDevelop, qui propose l'intégration avec Mono.

En C++ je peux te pondre du code qui sera dépendant que de Windows ou que de Linux de la même façon :) (voir encore plus simplement)

e.g les algorithmes, la gestion des fichiers, la base de donnees ect...)
Ah non :)
La gestion des fichiers, la base de données, ca c'est dans la couche de persistance, pas dans la couche métier malheureux :)

Le problème qui va se poser à mon niveau pour le C# est que le temps imparti risque de nous faire regretter ce choix au final
Effectivement, c'est toujours mieux quand il y en a au moins 1 de compétent... Cela dit à 1 ou 2 mots clés prêt tu peux coder comme en Java, avec exactement la même syntaxe sans exploiter toutes les possibilités... Pour avoir eu l'occasion d'apprendre le C# à 2 reprises au reste de l'équipe lors de projets universitaire, ca c'est toujours très bien passé, et rapidement.
Le plus simple c'est d'essayer : sous Windows, installe SharpDevelop, et essai de dessiner une interface.

Qu'entend-tu par couche métier ?
Couche de l'application qui contient le coeur de l'application, tu y trouves les objets qui représente le domaine, typiquement dans une application de commerce en ligne tu y trouveras les classes Client, Produit, Vente, Reduction, etc.
Cette couche est parfaitement indépendante de l'interface graphique, mais elle fait tout le boulot.

oué c'est pas top top dans le rapport, ca passe à peu prêt sous Acrobat reader seulement :-/
Je viens de metttre la version HTML en ligne, beaucoup plus friendly :
http://pascalfresnay.free.fr/projet/synthlab/(...)

TIens même M$ s'y mets :
http://www.start.com/pdc/(...)

Quand a Mono, il faudra d'abord qu'on trouve rien qu'une seule application élaborée et fiable, utilisée fréquemment qui fonctionne avec Mono pour qu'on puisse présenter cela comme une option.
iFolder ? http://www.ifolder.com/(...) (ok ok c'est Novell)
GMovil ? http://www.aspl.es/gmovil/us/index.html(...) (Ok ok on l'utilise pas tous les jours, mais c'est quand même un test grandeur nature)
Virtuoso ? http://virtuoso.openlinksw.com/(...) (idem, c'est pas tous les jours, mais c'est une application "professsionnelle")

GOOOOoooog... ok un premier lien :
http://membres.lycos.fr/interaction/Architecture/Pac/pac1.html(...)

C'est un modèle, il faut penser à l'adapter à ses besoins, à ses outils, etc.
Perso je n'aime pas trop le principe consistant à toujours passer par la couche de contrôle, notamment lors de communications entre 2 présentations ou 2 abstractions, pour la simple et bonne raison que les abstractions constituent souvent le modèle métier, et fonctionne donc de manière autonomne, et que les objets de présentation on besoin de communiquer pour "s'emboiter" comme l'impose tous les toolkit graphiques.

Tu peux consulter le rapport de notre projet pour avoir un aperçu de mon "mod" de PAC, notamment adapté à la plateforme .NET et à l'indépendance vis-à-vis du toolkit graphique.

Franchement, argumente parce que là je vois pas l'intérêt !
Ben si je l'ai dis : ajouter une ligne à ton CV.

si tu ne connais pas le C++, ça me semble une bonne chose de l'apprendre
Tout à fait d'accord, mais un projet court aux objectifs éducatifs nombreux n'est pour moi pas le bon contexte, faut de temps, à moins d'y consacré la totalité du projet, ce qui n'a absolument aucun intérêt pédagogique.
Pour ce qui est des difficultés, que tu le veuilles ou non tu vas les rencontrer, à commencer par la gestion de la mémoire, la notion de pointeur, de référence, l'utilisation de Qt apportant également son lot de difficultés pour le débutant en C++.

Et puis le plus gros pb du C++ c'est que très peu de gens savent vraiment l'utiliser !
Justement, son apprentissage ne s'improvise pas dans le cadre d'un projet àlavavite, mais s'étudie lors d'un cours et s'approfondit lors de TP encadré.

Comme l'a constaté un prof de fac en parlant des projets de fin d'année : "ca fait 10 ans qu'on faisait les TP en C++, il n'y avait quasiment aucun projet de fini, ca fait 2 ans qu'on les fait en Java et ils arrivent quasiment tous à terme."

En gros, vous avez placé la priorité sur l'interface dependant de logiciels propriétaire et torché la version 100 % libre à l'arrache, au feeling.
Pas du tout.
Nous avons fait un soft qui s'intègre dans l'environnement qui était à notre disposition pour développer/utiliser notre application.
Qt utilise des bibliothèques de Windows de la même manière lorsqu'elle tourne sous Windows. En tant que fervant défenseur des logiciels libre j'avais comme objectif de montrer l'intérêt de l'approche, et j'ai pensé depuis le début à concevoir l'application de manière à coder l'interface en GTK, ce qui s'est révélé être une formalité, validant les choix de conception.
C'est pas du tout du "feeling" et fait à l'arrache comme tu dis. C'est encore la meilleure méthode que j'ai trouvé pour proposer une intégration suffisante dans des environnements très différents comme Windows et Gnome.

Or Mono, c'est loin d'être considéré comme très fiable, pour le moment, si je ne m'abuse.
C'est tellement pas fiable que c'est supporté commercialement :
http://www.mono-project.com/Kickstart(...)
Et ca commence à être utilisé par un certain nombre d'entreprises :
http://www.mono-project.com/Software#Commercial_Applications(...)

Et puis le fait est que pour notre application cheznouscamarche (TM).

Donc en gros, on a une interface qui dépend de Mono torchée en une soirée à coté d'une interface bien préparée qui fonctionne sur WinForms/.Net ?
Il n'y a aucune dépendance envers Mono, la seule dépendance est envers WinForms ou GTK#, ce dernier tourne sous Windows sans Mono si ca t'amuse. Voir aucune dépendance, il est facile d'utiliser la partie métier sans aucune interface graphique.

Je me répête, franchement, un amateur de libre aura toutes les raisons de favoriser Qt.
Un amateur de libre a la première liberté d'utiliser la technologie qu'il souhaite, et je le repèterai jamais autant, ajouter une dépendance envers une bibliothèque graphique est un mauvais choix de conception. Qt n'est que partiellement intégré à Windows et ne présente donc pas une solution idéal pour ses utilisateurs. Il est donc vital de pouvoir facilement utiliser un autre toolkit si les besoins des utilisateurs s'en fait sentir.

Pour moi enfermer une application en utilisant Qt à tous les niveaux (des threads à l'IHM), c'est "fermer" un logiciel à un certain nombre d'utilisateur et de développeurs.

On peut aussi apprendre un nouveau langage dans certains cas, ce qui apportera un + sur le CV, mais que dans certains cas :
- C# connu ? Apprendre Java.
- Java connu ? Apprendre C#.
- C++ connu ? Moins évident d'apprendre Java ou C#
- Java ou C# ? Quasiment impossible de passer à C++ sans perdre de vue les autres objectifs du projet.

Point 2 et 4 testés sur des projets de quelques mois dans le cadre universitaire (pas à temps plein)

Ben nous on avait utilisé ce modèle en développant uniquement l'interface WinForms/.NET dans un premier temps. J'ai codé la version GTK sous Linux en une soirée, tout le gros du code étant réutilisable, notamment la couche Contrôle.

Faire un filtrage sur le contenu n'est pas impossible du tout, seulement cela demande bien trop de ressources pour être fait en temps réel. C'est tout simplement le principe du filtrage du spam.
Me semble que c'est ce que font les logiciels côté client justement... La charge est répartie sur toutes les machines.
J'ai jamais essayé, je suppose que l'affichage d'une page est plus long.