Vu sur OSNews, c'est ici :
http://dot.kde.org/1149518002/
En gros, tous les documents créés avec un logiciel de la suite KOffice pourront être intégrés dans un autre document tel quel, et tous pourront être retravaillés de la même façon (rotation, redimensionnement ...), mais aussi édités depuis le document dans lequel ils sont insérés.
Journal Un regard sur KOffice 2.0
8
juin
2006
# intérêt
Posté par nojhan (site web personnel, Mastodon) . Évalué à 6.
Perso, j'ai beaucoup de mal à gérer des documents qui sont dans d'autres documents qui sont dans d'autres documents qui sont... l'interface change tout le temps, se superpose dans tout les sens ou est limitée à un tout petit cadre.
Bref, qu'est-ce que ça apporte vraiment par rapport à une gestion simple par fichiers/applications séparées ?
[^] # Re: intérêt
Posté par Oook . Évalué à 3.
Après, je suis bien d'accord sur les problèmes d'interfaces. Cela depend cependant des interfaces en jeu (Ragtime fait ça très bien d'après mes souvenirs)
[^] # Re: intérêt
Posté par gnumdk (site web personnel) . Évalué à 7.
Inserer du tableur dans un traitement de texte, koffice 1.x sait tres bien le faire.
Ici, l'interet est d'avoir acces aux "objets" des programmes koffice depuis n'importe quel logiciel. Genre Faire un diagrame dans kword ne lancera plus un composant kivio(comme c'est le cas aujourd'hui) mais inserera directement l'objet kivio dans le document. Ca sera donc plus propre, plus rapide et plus simple...
Si j'ai bien tout compris c'est ca mais je suis moi non plus pas trop sur.
[^] # Re: intérêt
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
Colin a effectivement un peu raccourci le contenu de la news, mais qui n'est pas forcément non plus évidente puisque ce n'est qu'un aperçu technologique de Koffice 2. On en saura donc plus dans quelques temps ...
[^] # Re: intérêt
Posté par Colin Pitrat (site web personnel) . Évalué à 2.
[^] # Re: intérêt
Posté par tene . Évalué à 3.
Quelques questions me viennent en tête:
- Est-ce que cela ne revient pas à chercher un dénominateur commun entre toute les appli?
- Comment gérer le versionning?
- Comment retomber sur ses pates si un de ces objets est buggé?
Ca m'a pas l'air simple tout ça ;)
[^] # Re: intérêt
Posté par Sylvain Sauvage . Évalué à 0.
Non. C'est un des principes de base de KDE qui est ici utilisé : avoir des composants que les applications peuvent utiliser.
L'exemple typique était le composant pour afficher du html : n'importe quelle application KDE qui veut afficher du html ne va pas se retaper un moteur de rendu html ni utiliser/intégrer tout konqueror, elle va se contenter d'utiliser le composant KDE de rendu de html.
À partir de maintenant, on aura d'autres exemples réels que le html.
Parce que les éléphants de mer ?
Un document reste un document. Qu'il intègre un sous-document n'est pas nouveau et ne change rien à sa gestion logique. C'est juste qu'au lieu de lancer une autre application pour manipuler ce sous-document, ce sera plus intégré aussi au niveau du code (et donc de l'interface).
Ça se passe de la même façon (mais avec un peu plus d'interactions) que lorsqu'on utilise le composant « sélecteur de fichier » : comment fait-on s'il est bogué ? On débogue ou on contourne en ne s'en servant pas.
De toute façon, comme ces nouveaux composants vont aussi être utilisés par les applications correspondantes, cela voudrait dire que les applications aussi seront boguées : éditer un graphique dans kword ou dans kivio, ce sera pareil.
[^] # Re: intérêt
Posté par tene . Évalué à 5.
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. Arrives-tu a imaginer des documents s'intégrant dans d'autre autre que des image, du texte et des tableaux? j'ai du mal.
Ton exemple d'HTML est intéressant, c'est justement quelque chose de très difficile à intégrer sur un document papier, prend par exemple les hyperliens, comment doivent-ils se comporter dans un document KWord? ouvrir le lien dans une nouvelle fenêtre? rester dans la même? que dire d'un composant HTML dans un shape, au forme bizaroide? ça doit suivre les contours? la mise à l'échelle ça fait un zoom graphique ou ça ne change que la taille du texte? etc... J'ai un peu l'impression de lire "on vous donne des Shape, théoriquement on peut tout faire dans un shape, donc on vous fournit une techno super révolutionnaire qui permet de tout faire!".
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? celle de KWord 1.1 et pas celle de KWord 1.2 qui n'est pas totalement compatible? Pense au problème de la gestion de paquet, imagine que tu pourrais avoir encore pire... Imagine aussi le cas d'une application intégrant deux composants... mais utilisant des versions différente d'une certaine libraire, out-of-process, c'est possible, in-process... ouais en fait théoriquement ça l'est ;)
Enfin la gestion d'erreur est problématique, si ton composant est in-process et plante, ton appli peut (et va en fait, surtout en natif) crasher avec. Imagines que je t'envoie un document et qu'il fasse planter ton traitement de texte, tu penserais quoi? qu'il te suffit de ne pas l'utiliser? Pourtant, je te garantis, "chez moi ça marche"©®. L'avantage de faire du out-of-process, est que l'os te garantit plus ou moins bien l'intégrité de ta mémoire, réimplémenter cela de façon efficace est légèrement plus complexe in-process (voir impossible). Imagine pire: un copier coller dans ton document "design à pondre pour hier version totalement presque final" qui fasse planter l'appli, pas de bol, la sauvegarde automatique est passée par là... pourquoi tu crois que c'tait une mauvaise idée de permettre l'utilisation d'ActiveX depuis ms-word? :p
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 ces différents problèmes, qui sont bien réel (si tu veux des exemples de ma vie de tous les jours, c'est quand tu veux ;). Bref, tout comme KDE4, je suis intéressant, et curieux de voir ce que ça va donner!
[^] # Re: intérêt
Posté par Thomas Douillard . Évalué à 4.
Tu pas surtout un peu prétentieux ;) Et puis se comparer avec un logiciel, aussi libre soit-il ...
[^] # Re: intérêt
Posté par Sylvain Sauvage . É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.
[^] # Re: intérêt
Posté par Gof (site web personnel) . Évalué à 1.
> 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.
Sauf que KDE est un logiciel libre.
Si tu trouve un bug tu peux le reporter et discutter avec les développeurs.
Si les développeurs ne vont pas assez vite à ton goût, tu peux le corriger toi même.
Il faudrais que tu définisse qui "est KDE.org"
[^] # Re: intérêt
Posté par Sylvain Sauvage . Évalué à 2.
Comme il était question de « versionning », il est évident que l'ensemble des applications et des bibliothèques qui font partie de la même release ont été contruites et testées pour fonctionner ensemble : pas de problème de version à ce niveau.
Le problème de version envisagé par tene ne peut donc se produire que lorsque l'on est en dehors de ce KDE.org. Et, dans ce cas, on est dans le même cas qu'il s'agisse d'un objet de base ou d'un composant complexe : s'il est bogué, ben on a trois solutions :
- attendre qu'il soit débogué ;
- déboguer soi-même ;
- ne pas s'en servir ;
si son API a changé, on peut :
- modifier son application en conséquence ;
- ou pleurer dans son coin.
J'ai simplement dit « ben ton application ne fonctionne plus » car, tant que « tu » n'as rien fait (déboguage ou modification de ton application), c'est toujours le cas.
Je voulais surtout montrer à tene qu'en ce qui concerne les bogues et le « versionning », il n'y a pas de différence entre une qlist, un qfiledialog et ces nouveaux composants.
[^] # Re: intérêt
Posté par Ymage . Évalué à 1.
Avec le succès que l'on connaît...
Rien qu'en songeant à la compatibilité des tableaux Excel, PowerPoint et Word, j'en ai le frisson ...
Sans parler des copier/coller d'un objet de l'un à l'autre ...
Si vous n'aimez pas ce commentaire c'est qu'il est ironique.
[^] # Re: intérêt
Posté par Colin Pitrat (site web personnel) . Évalué à 3.
De plus, la grosse nouveauté c'est que la réutilisation de code sera beaucoup plus importante entre les différentes parties de KOffice, avec tous les effets bénéfiques que l'on connait.
[^] # Re: intérêt
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
Oui, depuis... pfiouu... longtemps (genre plus de 10 ans). À l'origine de cette possibilité, c'etait la technologie OLE (l'ancètre du COM/DCOM).. c'est dire si ça date ;-)
[^] # Re: intérêt
Posté par un_brice (site web personnel) . Évalué à 2.
Du reste, inclure un document Koffice dans un autre est, et à toujours été, possible, apparemment là c'est la manière dont ça l'est qui change...
[^] # Re: intérêt
Posté par pasBill pasGates . Évalué à -1.
Tu peux inclure un document FrameMaker dans KOffice ? Eh oui, meme probleme...
[^] # Re: intérêt
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Ceci dit, à l'époque, ça marchait tellement mal que j'avais pris l'habitude de copier -> collage spécial -> coller et temps qu'image parce que sinon, tu pouvais être sur qu'il te foirait la mise en page à la prochaine modif. Je ne sais pas si ça a progressé depuis, il paraît que oui.
[^] # Re: intérêt
Posté par qdm . Évalué à 2.
# Liens
Posté par tzeentch00 . Évalué à 3.
http://www.osnews.com/comment.php?news_id=14836
pour ceux qui veulent suivre le fil de discussion ;)
[^] # Re: Liens
Posté par Colin Pitrat (site web personnel) . Évalué à 6.
tu voulais dire osnews.com j'imagine ;)
# fonctionnalité qui tue : virer le save
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Plus de fonction "save", le projet en cours était "persitant" mais cela implique de gérer très proprement les versions et le undo.
J'aimerais bien avoir ça :)
"La première sécurité est la liberté"
[^] # Re: fonctionnalité qui tue : virer le save
Posté par kd . Évalué à 4.
Pour comprendre, il faudrait au moins savoir qu'un programme tourne en mémoire vive, que le document que tu modifies est en mémoire vive, que le vrai document est dans un fichier, et que ce fichier est sur une mémoire non volatile. Il faut donc expliquer que la mémoire vive est volatile, il faut expliquer ce qu'est un fichier, ce qu'est le disque dur. Pfiouuuu... ça fait beaucoup de choses :)
[^] # Re: fonctionnalité qui tue : virer le save
Posté par TImaniac (site web personnel) . Évalué à 3.
Après il pourra peut être découvrir qu'il peut annuler une action, auquel cas il commencera à décrouvrir l'intérêt d'un ordinateur par rapport à des modifs physiques :)
[^] # Re: fonctionnalité qui tue : virer le save
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Cela peut aussi être problèmatique avec les crash d'applications qui sont contourné par des sauvegardes automatiques qu'il faut ensuite récupéré ce qui n'est pas forcément évident et propre.
Je préfaire un vrai undo, une vrai gestion de version et des documents persistent.
"La première sécurité est la liberté"
# Tiens, OpenDoc reviens
Posté par lolop (site web personnel) . Évalué à 2.
C'était une techno Apple/IBM/Novell de documents contenant des composants (conteneur générique, et des éditeurs de parties), mais basée sur CORBA à l'époque, avec un MacOS pas trop à l'aise.
Une des technos de plus qu'Apple a lancé... et qui au final a fait perdre du temps aux développeurs. Bon, depuis les errements de MacOS ils se sont rattrapés avec la version X.
Pour les anglophones
http://en.wikipedia.org/wiki/OpenDoc
Le côté négatif (ça n'a pas marché)
http://www.aventure-apple.com/flops/opendoc.html
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.