(j'ai l'impression que tu me prends pour un c...;-)
C'est _toi_ qui le dit (on reproche souvent aux autres de faire ce qu'on leur fait ;oP).
Tu m'expliques que c'est un principe de base de KDE, super, ça ne solutionne pas le problème de définir des contrats entre ces composants permettant à la fois d'être souple, tout en restant implémentable. C'est un problème récurrent en IT depuis ... le tout début. Pratiquement: au plus ton contrat est précis et poussé, au plus il sera spécifique et limite le type d'échange possible.[...]
On est d'accord : c'est le problème des composants. Si on code tout dans une seule application, on est sûr (modulo les bogues et erreurs de conception) que tous les modules vont pouvoir discuter correctement. Et, si on décide de rendre les modules plus autonomes (jusqu'à en faire des applications autonomes), soit on est obligé d'avoir des contrats complexes bien spécifiés, soit on se limite dans les interactions entre les parties du document (p.ex. un sous-document prendra seulement un rectangle).
De plus, on parle ici de composants koffice, donc de composants spécifiques dont les contrats peuvent être déterminés, on ne parle pas d'un modèle générique ou d'intégrer n'importe quoi n'importe où n'importe comment.
L'objectif est de fournir des composants qui, p.ex., évitent à Konqueror d'avoir à lancer kword+kivio pour obtenir un aperçu d'un document composite. Ces composants permettront aussi à d'autres applications d'intégrer des sous-documents koffice d'une façon plus profonde (p.ex. intégrer un kcalc éditable dans Scribus).
Quand je parle de versionning, je ne parle pas de versionning de document, mais de composant, comment t'assurer que tu instancies bien la bonne version de ta classe? [...]
(Encore fallait-il dire que tu parlais de version de code et pas de document...)
Tu récupères le composant qui promet la bonne version du contrat. C'est tout.
En plus, KDE est un environnement total : tous les composants sont livrés par le même fabricant. Il y a peu de chances qu'ils ne soient pas correctement associés. Si tu n'est pas KDE.org et que tu construits une application qui utilise ces composants, tu es exactement dans le même cas que lorsque tu utilises le sélecteur de fichiers : s'il est bogué ou si l'API a changé, ben ton application ne fonctionne plus. Comme ton application a plus d'interactions avec KDE, elle en dépend d'autant plus. C'est évident mais ce n'est pas la peine d'en exagérer les problèmes.
Ça apporte un plus : plus d'interactions possibles.
Ça apporte un moins : plus d'intrication, de dépendance.
Personne n'est, non plus, obligé de s'en servir. C'est un choix à faire en pesant les pours et les contres.
Voilà, ça veut pas dire que c'est une mauvaise idée, que c'est nul, que c'est pas bien, et surement pas que je ferais mieux, plutôt que je suis curieux de voir comment seront [adresser abordés, pris en compte, réglés ?] ces différents problèmes, qui sont bien réel[s] (si tu veux des exemples de ma vie de tous les jours, c'est quand tu veux ;).
Je ne nie pas les questions (qui ne sont pas des problèmes mais des choix à faire), j'ai juste essayé de répondre à tes remarques (qu'on pourrait qualifier de peu argumentées).
Bref, tout comme KDE4, je suis intéress[anté], et curieux de voir ce que ça va donner!
[^] # Re: intérêt
Posté par Sylvain Sauvage . En réponse au journal Un regard sur KOffice 2.0. Évalué à 2.
C'est _toi_ qui le dit (on reproche souvent aux autres de faire ce qu'on leur fait ;oP).
On est d'accord : c'est le problème des composants. Si on code tout dans une seule application, on est sûr (modulo les bogues et erreurs de conception) que tous les modules vont pouvoir discuter correctement. Et, si on décide de rendre les modules plus autonomes (jusqu'à en faire des applications autonomes), soit on est obligé d'avoir des contrats complexes bien spécifiés, soit on se limite dans les interactions entre les parties du document (p.ex. un sous-document prendra seulement un rectangle).
De plus, on parle ici de composants koffice, donc de composants spécifiques dont les contrats peuvent être déterminés, on ne parle pas d'un modèle générique ou d'intégrer n'importe quoi n'importe où n'importe comment.
L'objectif est de fournir des composants qui, p.ex., évitent à Konqueror d'avoir à lancer kword+kivio pour obtenir un aperçu d'un document composite. Ces composants permettront aussi à d'autres applications d'intégrer des sous-documents koffice d'une façon plus profonde (p.ex. intégrer un kcalc éditable dans Scribus).
(Encore fallait-il dire que tu parlais de version de code et pas de document...)
Tu récupères le composant qui promet la bonne version du contrat. C'est tout.
En plus, KDE est un environnement total : tous les composants sont livrés par le même fabricant. Il y a peu de chances qu'ils ne soient pas correctement associés. Si tu n'est pas KDE.org et que tu construits une application qui utilise ces composants, tu es exactement dans le même cas que lorsque tu utilises le sélecteur de fichiers : s'il est bogué ou si l'API a changé, ben ton application ne fonctionne plus. Comme ton application a plus d'interactions avec KDE, elle en dépend d'autant plus. C'est évident mais ce n'est pas la peine d'en exagérer les problèmes.
Ça apporte un plus : plus d'interactions possibles.
Ça apporte un moins : plus d'intrication, de dépendance.
Personne n'est, non plus, obligé de s'en servir. C'est un choix à faire en pesant les pours et les contres.
Je ne nie pas les questions (qui ne sont pas des problèmes mais des choix à faire), j'ai juste essayé de répondre à tes remarques (qu'on pourrait qualifier de peu argumentées).
Itou.