Articles précédents : Articles
- [118] Migration de DLFP effectuée
- [54] Soutenez le Logiciel Libre et payez moins d'impôts
- [18] L'état australien de Canberra décide de privilégier les logiciels libres
- [52] De la fin de vie chez Redhat
- [156] Looking Glass - Desktop 3D
- [10] Le Micral N au Musée des Arts et Métiers, le 10 décembre.
- [15] Portrait de Stallman dans <i>Le Monde</i>
- [23] SCO se fait soi-disant attaquer par un DDoS
- [104] Microsoft attaque un revendeur français de Lindows pour contrefaçon de marque
- [79] La longue marche vers le hardware libre
Liens connexes
- La nouvelle sur KDE.news (792 hits)
- Cuckoo (913 hits)
- "OpenOffice.org Qt port" (888 hits)
- Des infos interessantes sur une ML du projet (424 hits)
Dépêche modérée par
Articles : Lancement d'un projet officiel d'intégration d'OpenOffice.org à KDE
Posté par Brice Arnould ( un_brice ) (page perso, ). Modéré le 15 décembre 2003.
![[en]](../../../images/en.png)
La nouvelle sur KDE.news (792 hits)-
Cuckoo (913 hits)
-
"OpenOffice.org Qt port" (888 hits)
-
Des infos interessantes sur une ML du projet (424 hits)
> Lire la dépêche (54 commentaires, moyenne: 3).
Si Cuckoo existait déjà, ooo-qt semble le premier projet d'envergure de ce style. Ce n'est en effet pas juste une tentative pour rapprocher le look d'OO.org de celui de KDE (ce qui se fera quand même dans un premier temps), mais plutôt d'utiliser de plus en plus les fonctions natives de Qt/KDE, et à terme de dissocier dans le code d'OpenOffice le code d'interface, ce qui permettra de proposer beaucoup plus facilement différentes interfaces réellement natives (boites de dialogues, d'ouverture de fichiers). Il semble donc que finalement ce remaniement de OO.org ait aussi des avantages pour ceux qui préfèrent Gnome. Notons d'ailleurs que les hacks à la '#ifdef kde' semblent exclus.
Les questions qui se posent maintenant portent sur l'avenir de Koffice, la suite native de KDE. L'avis de ceux de KDE.news semble être "OOo is now, koffice is the future" ("OpenOffice.org est le présent, Koffice le futur").
Il faut en effet reconnaître qu'OO.org est la suite libre la plus complète du moment, son principal défaut étant sa mauvaise idée d'avoir réinventé la roue. Ce projet visant à mieux l'intègrer aux unix semble donc une excellente chose... c'est pourquoi je me permet de rappeller qu'il a besoin de notre aide.
Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
C'est vraiment une très bonne nouvelle, on peut même dire une suite de très bonnes nouvelles. Celle qui me plait le plus est la séparation entre l'interface graphique et le reste des logiciels. Cette modularité très cartésienne est dans la suite logique de l'évolution du logiciel libre et elle est un gage d'évolutivité d'OpenOffice.org.
Qiue de chemin parcouru depuis StarOffice 5.2 : Disparition du bureau, du gestionnaire d'impression, fontes lissées, export direct en pdf, XML docbook .... Ce ne sont pas des détails !
Toutefois j'émet un vœu, celui de voir un logiciel moins lourd et plus vite lancé.
-
[+] [^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Fabien Penso (Jabber id, page perso, ) le 16/12/2003 à 00:18. (lien). Évalué à -3.Pierre, vas dormir bondiou ! :)
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Philippe Fremy (page perso, ) le 16/12/2003 à 00:35. (lien). Évalué à 11.Cette seperation ne sera effective que dans OpenOffice 2, ou ils utiliseront un langage generique (VCL il me semble) qui sera implemente dans l'un ou l'autre toolkit.
<<
Cette modularité très cartésienne est dans la suite logique de l'évolution du logiciel libre et elle est un gage d'évolutivité d'OpenOffice.org.
>>
Certe, mais elle est un poids tres lourd au niveau technique. Toute fonctionnalite doit etre codee dans un premier temps au niveau de l'abstraction (la partie document du modele document/vue), puis au niveau graphique pour le rendu, donc dans ce cas en VCL, puis transposee via VCL dans un GUI natif (Qt, KDE, Windows, ...). Dans le cas ou une fonctionnalite manque a VCL, elle doit etre recree dans chacun des ports.
Tout ce processus est extremement lourd a maintenir et a developper. KOffice, a l'oppose, en s'appuyant a fond sur des technologies choisies et directes, fait un bien meilleur boulot. Si on compare le nombre d'annees hommes investies sur chacun des projets, KOffice doit representer le 1/10 de OpenOffice.
Quand on songe que StarOffice etait une boite allemande, on se demande vraiment pourquoi ils n'ont pas choisi Qt des le depart. Ils ont du commencer leur truc avant 1993. C'est dommage quand meme parce que avec Qt, il se serait epargnes bien du boulot.-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par PenPen () le 16/12/2003 à 01:29. (lien). Évalué à 6.C'est vrai que tout développer en Qt a la base serait pas mal, leur toolkit à eu est quand même assez (aheeeem) peu attrayant niveau design mais bon en même temps pour le port win32 comment ils vont faire?
Payer des licences a trolltech? Non trop cher...
Réimplanter tout le code utilisant Qt en utilsant l'api propre a chaque plateforme (pas tojuors aussi complète) et maintenir plusieurs openoffice, probablement pas synchrone les uns avec les autres de part les difficultés propres a chaque port?-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Mathieu Malaterre (page perso, ) le 16/12/2003 à 03:39. (lien). Évalué à 6.Pourquoi il utilise pas wxWindows (http://wxwindows.org(...)) pour developper ce genre de soft ? Quelqu'un a un avis ? Est-ce que ca ralenti vraiment de passer par ce genre de couche d'abstraction ?
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Philippe Fremy (page perso, ) le 16/12/2003 à 07:31. (lien). Évalué à 3.Ca marcherait aussi. Le probleme, c'est que c'est trop tard, OpenOffice est deja la.
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par sparky () le 16/12/2003 à 16:34. (lien). Évalué à 0.Un peu dommage de ne pas avoir plus utiliser wxWindows (GPL et LGPL pour les librairies), Qt n'est que partiellement libre et seulement depuis 98 par le KDE Free Qt Foundation.
Peut-être faudrait faire un window manager avec wxWindows pour améliorer sa visibilité ?-
[+] [^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Piksou () le 16/12/2003 à 17:56. (lien). Évalué à -1.WxWindows est rendu par GTK sous X11
or un win manager ça sert pas à grand chose sous w32 ou MacOS X donc en gros, ça reviendrait à faire un wondows manager qui tuiliserait WxWin le quel utiliserait GTK dans 100% des cas
on peut simplifier la chiane en passant à GTK diretc et... tu as réinventé Gnome et xfce ;-)
Wx est conçu pour des applications portables comme OOo (il pourrait aussi servir à une app comme Mozilla si il n'y avait pas XUL ou à un logiciel d'IM), mais pour un windows manager l'intérêt me paraît limité-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par sparky () le 16/12/2003 à 18:25. (lien). Évalué à 1.Ah ? Tu n'es donc pas au courant de la multitude des WM qui existent, style java, l'autre en python , pourquoi pas Wx alors ???
Et puis GTK n'est pas GNOME: Gnome se base sur Gtk, xfce aussi, wxGtk aussi... C'est une couche en plus mais est-ce si grave ???
A la base, Gtk ne servait qu'à Gimp donc qu'à des applications pas à un WM complet.
Selon certains, sous Windows, la partie graphique est un sous système qui pourrait être remplacé, je n'ai pas testé, à mon avis personne n'a essayé (si?).
Je persiste à dire que c'est dommage que wxWindows (qui est sous GPL) ne soit pas plus utilisé.
Pouvez continuer à moinsser, je m'en tape, vraiment con ce système de vote.-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Piksou () le 16/12/2003 à 20:20. (lien). Évalué à 0.je ne dis pas que ça n'existe pas, ya plein de trucs qui existent dans le libre (et pas tjs utiles...)
je dis juste qu'utiliser WxWindows pour un wm n'est pas adapté car il est pensé pour la portabilité, ce qui n'a pas d'intérêt dans ce cas précis: cela revient en effet en gros à utiliser GTK. Il existe plein d'autres cas d'applications ou Wx est potentiellement très utile mais dans ce cas, bof.
Non, GTK n'est pas Gnome, bien sur, mais fonder un wm sur Wx revenant en gros à utiliser GTK mais en intercalant une "couche" inutile, il existe une foule de wm déja basés sur GTK comme Gnome ou xfce, donc je ne vois pas ou est l'originalité.
"A la base, Gtk ne servait qu'à Gimp donc qu'à des applications pas à un WM complet." => le rapport ? c'est déja ce que tu proposes en suggérant d'employer Wx@X11
et pour finir: je suis d'accord que Wx mériterait une plus grande place et je en cherche pas la bagarre: stop ta parano :-/
-
-
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Erwan (page perso, ) le 17/12/2003 à 03:04. (lien). Évalué à 1.Quand on developpe un projet gros comme OpenOffice.org, on evite de s'ajouter trop de dependances. Surtout on evite les dependances de petits projets.
Regarde un peu le temps qu'il a fallu a wxWindows pour passer de Gtk+ a Gtk+2. Tu imagines Sun dire a ses clients: "Ben l'allemand qui fait ca tout seul dans son garage a pas eu le temps de porter wxGtk ces derniers mois, faut attendre...". Ou encore faire le portage eux-meme sans savoir si ca va plaire a l'auteur ou pas, finir en fork...
Bref, des fois il vaut mieux reinventer la roue que s'emmerder avec des dependances pas pratiques.-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
-
-
-
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Philippe Fremy (page perso, ) le 16/12/2003 à 07:31. (lien). Évalué à 4.Le prix des licences Qt est tout a fait abordable dans une entreprise, compte tenu de la qualtie du toolkit. Perso, j'ai vu une licence a 1500$ passer dans une start-up ou les gens n'etait pas payes.
Sinon, il y a PyQt, nettement moins cher puisque pour 500$, on a toutes les plateformes accessibles.-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Aurelien Gateau (page perso, ) le 16/12/2003 à 08:37. (lien). Évalué à 2.Sinon, il y a PyQt, nettement moins cher puisque pour 500$, on a toutes les plateformes accessibles.
Si tu utilises PyQt, il me semble qu'il faut payer la licence Qt en plus.-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Philippe Fremy (page perso, ) le 16/12/2003 à 10:50. (lien). Évalué à 2.Oui, j'ai manque de precision. En fait, c'est BlackAdder, de TheKompnay, qui coute 500$ . Il vient avec PyQt . C'est ce que j'utilise au boulot et ca marche nickel linux/windows. J'ai pas encore lance BlackAdder mais ca doit surement etre bien :-)
Sinon, le PyQt vendu par riverbank-computing est en effet complementaire d'une licence Qt, ce qui le rend tres onereux.
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Croconux () le 16/12/2003 à 12:40. (lien). Évalué à 1.Il y a un truc que je ne pige pas : Si tu codes en Python, tu ne link rien. Tu ne distribues que les scripts Python qui n'incluent aucun code de Trolltech.
Pourquoi faut-il payer une license dans ce cas?-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Aurelien Gateau (page perso, ) le 16/12/2003 à 12:49. (lien). Évalué à 2.Il me semble que la contrainte n'est pas technique, mais contractuelle. A partir du moment où tu conçois une appli Qt proprio tu dois payer, que ce soit en C++ ou en Python.
A mon avis, quand Trolltech a écrit son système de double licence ils n'ont pas envisagé le cas des langages de scripts, d'où un certain flou...
-
-
-
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Nectroom () le 16/12/2003 à 17:30. (lien). Évalué à 1.c'est vrai qu' une version GPL pour win32 de l'API 3.x est vraimant un grand manque :(
Des projets sont en cour pour sa réecrire de A à Z sous GPL en se basant sur le travail deja fait pour la 2.x mais bon c'est loin d'être fini
et surtout les devel se font presque tous engage par des boites pour faire du QT et on acces aux sources win écrites par TrollTech ce qui
les oblige a arreter de contribuer au projet :(
Car pour le reste Qt c'est vraimant exellent :)
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Guillaume Laurent (page perso, ) le 17/12/2003 à 10:26. (lien). Évalué à 1.> Payer des licences a trolltech? Non trop cher...
Exercice amusant : regarde le cout d'une license Qt, puis regarde le cout mensuel d'un ingénieur.
Sur le budget de développement d'un projet comme Star Office, le prix d'une license Qt c'est presque une erreur d'arrondi.
-
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Matthieu Moy (page perso, ) le 16/12/2003 à 06:26. (lien). Évalué à 8.Il y a déjà une couche d'abstraction dans OOo. Je crois bien qu'elle s'appelle VCL justement. Le truc, c'est que pour l'instant, elle redessine tout pixel par pixel pour avoir le même résultat au pixel près sous toutes les plateformes.
=> Ca s'intègre bien dans win9X/NT4 parce que c'en est une pâle copie, et donc, ça ne s'intègre pas du tout visuellement dans tout le reste.
Il y a quelque temps, ils songeaitent à passer à une autre librairie portable genre wxWindows ou Qt, mais visiblement, wxWindows est un peu léger (en tous cas, ca serait la première fois que ça serait utilisé sur un projet aussi gros), la licence de Qt pour Windows ne convient pas, ... Je ne sais pas quelle décision a été prise exactement, mais en tous cas, ils vont vraissemblablement s'y mettre. L'avantage, c'est que le boulot fait sur leur couche d'abstraction pourra être réutilisée par d'autres.-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Aurelien Gateau (page perso, ) le 16/12/2003 à 12:46. (lien). Évalué à 1.Parce qu'il n'est pas possible de créer des custom widgets ?
(En tout cas c'était le cas il y a un an)-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Nap () le 16/12/2003 à 12:57. (lien). Évalué à 1.je n'ai jamais dépassé le stade du XUL et du mini-browser, mais :
http://xulplanet.mozdev.org/tutorials/xultu/introxbl.html(...)
XUL has a sister language, XBL (eXtensible Bindings Language). This language is used for declaring the behavior of XUL widgets.
c'est peut-etre ça dont tu parles, je ne sais pas-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Aurelien Gateau (page perso, ) le 16/12/2003 à 14:13. (lien). Évalué à 1.XBL te permet de faire de la composition de widgets et de définir les événements qui y sont associés. Dans mon cas je devais coder un widget pour afficher une image et permettre de scroller/zoomer dessus. Je n'ai pas trouvé comment faire, ni en Javascript, ni en C++. En fait la solution (ultra-bourrin) a été d'écrire un plugin Mozilla, avec un mime-type bidon.
-
-
-
-
-
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Ed GhZaaark () le 16/12/2003 à 13:21. (lien). Évalué à 2.Toutefois j'émet un vu, celui de voir un logiciel moins lourd et plus vite lancé
le lancement n'est pas top en effet, mais aujourd'hui je met 12secondes à ouvrir un Oowriter, alors qu'il m'en fallit 30 avec les version antérieurs.. même configuration.
Quand à sa lourdeur, je ne la sens pas du tout personnellement, j'en fais un usage raisonable ceci dit, je ne fais pas d'office tous les jours.
OpenOffice est vraiment sur un très bon rail.
+
Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Ils devraient faire comme Mozilla Firebird: avoir un toolkit avec des themes tellement bien fait qu'on peut faire appel a un autre toolkit pour dessiner les controles.
=> le theme base sur le toolkit d'Aqua devient le theme par defaut sous MacOSX de Firebird:
http://mozillazine.org/talkback.html?article=3945(...)
(et ce theme a ete ecrit sans modifier le code de Firebird, bien sur)
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par spell (page perso, ) le 16/12/2003 à 08:51. (lien). Évalué à 2.>Ils devraient faire comme Mozilla Firebird: avoir un toolkit avec des themes tellement bien fait qu'on peut faire appel a un autre toolkit pour dessiner les controles.
Oula! J'ai pas tout compris là. Y'a quelqu'un qui peux expliquer ?
Qu'est ce que tu appelles "dessiner des contrôles?"-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par tene (page perso, ) le 16/12/2003 à 10:37. (lien). Évalué à 18.Une fenêtre, aussi bien sous windows que sous linux est composé d'une série d'élément (bouton, check box, label, etc...) généralement appelé "controle". Ces controles ont une représentation graphique, ils ont donc été dessinés à l'écran. Sous windows et xfree cette opération se passe relativement souvent (sous osx un peu moins souvent me semble-t-il): aucun des deux ne garde réellement en mémoire l'image complète de la fenêtre, et donc lorsqu'elle devient apparente (passage en avant plan, maximisation, etc...), les controles sont redessinés. Cela veut donc dire: les controles sont dessinés, et ce asse souvent.
Niveau implémentation, il y'a en général quelques par une fonctione DessineMoiMonBouton, qui est appelé pour dessiner chaque bouton (et une pour chaque checkbox, et une pour caque... controle imaginable dans le toolkit). Le problème de cette approche est que le bouton n'a qu'une représentation possible, celle pensée par le toolkit au départ. On s'est alors décidé à faire des thèmes (skin, visual style, ...). Dans ce cas la fonctions DessineMoiMonBouton ne dessine plus diretement, mais à le choix:
- charge une image précisée par le thème et l'afficher (et donc un thème est une série d'image ainsi que quelques paramètres genre la taille de police, et la façon d'afficher les images). C'est l'approche des visual style de Windows XP entre autre.
- exécuter un bout de code contenu dans le thème. C'est beaucoup plus puissant puisque tu n'es pas limité à ce que peuvent donner les images.
Cette dernière approche est celle de mozilla (une des approches possible plutôt), un thème implémente donc une fonction "DessineMoiMonBouton" et dans la cas du thème macosx le thème cette fonction se contente d'appeler ... un autre thème! (Note: c'est vrai pour firebird sous win et sous gnome, ainsi que je suppose un paquet d'autre).
Le schéma passe donc de:
Mozilla -> Toolkit -> Thème
à
Mozilla -> Toolkit -> Thème -> Autre toolkit
Là où ça devient vraiment marrant c'est que cet auter toolkit peut lui même permettre les thèmes, tu auras alors:
Mozilla -> Toolkit -> Thème -> Autre toolkit -> Thème de l'autre toolkit.
Le "Toolkit" étant évidemment l'abus de langage utilisé pour désigner le "truc" qui est responsable de l'affichage et de la gestion des controles dans les fenêtres. Sous linux il en existe plusieurs, les plus connus sont GTK (utilisé par gnome) et Qt (utilisé par KDE). Sous Windows il n'en existe réellement qu'un seul, celui inclus dans windows qui ne porte pas de nom commercial spécifique à ma connaissance (on le désigne comme une partie de Win32).
En bref: il semblerait que le toolkit de mozilla soit suffisemment bien foutu que pour offrir portabilité, stabilité et une relative rapidité... dommage que ce ne soit pas plus simple à programmer...
Mes 0.02 euros.-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par spell (page perso, ) le 16/12/2003 à 13:55. (lien). Évalué à 2.>Mes 0.02 euros.
non, non ca vaut plus que ca.
Merci beaucoup pour ces explications très claires.
-
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Erwan (page perso, ) le 16/12/2003 à 10:38. (lien). Évalué à 7.Eh bien les controles, ce sont les boutons, les ascenseurs et les cases a cocher entre autres. Dans Motif on a appelait ca les widgets, je sais pas si ca se dit encore.
Certains toolkits, comme Gtk et Qt sous X11, dessinent eux-memes les controles. Ca veut dire que quand Gtk veut dessiner un bouton, il se debrouille tout seul pixel par pixel. Heureusement les themes sont passes par la, on a separe la presentation du reste et c'est le theme qui explique comment se dessine un bouton.
Sous Qt/Win et Gtk/Win, quand par exemple Qt veut un bouton il demande a l'API de Windows "s'il-te-plait, dessine-moi un bouton". Et comme ca, c'est homogene avec le reste.
Avec Mozilla, c'est aussi le theme qui s'occupe de dessiner les controles, comme pour Qt et Gtk donc. Par contre, la ou c'est fort (mais peut-etre que finalement cette separation existe aussi chez Qt et Gtk) c'est que le theme peut faire appel a une API pour dessiner les controles. Donc sans toucher au code de Mozilla, rien qu'en ecrivant un theme on peut se coller sur l'apparence du systeme du dessous. C'est ainsi que c'est homogene avec l'environement sous Windows, X/Gtk et sous MacOSX.-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Philippe Fremy (page perso, ) le 16/12/2003 à 11:00. (lien). Évalué à 3.> Par contre, la ou c'est fort (mais peut-etre que finalement cette
> separation existe aussi chez Qt et Gtk) c'est que le theme peut faire
> appel a une API pour dessiner les controles.
De fait, c'est aussi comme ca que fait Qt. Sous Windows XP et sous MacOs/X et il me semble sous KDE, Qt utilise l'API native de l'OS pour dessiner les controles (si tu choisis le theme qu'il faut) et tu obtiens une application parfaitement homogene a ton environnement.
Pour voir a quoi ce ressemble d'un point de vue dev:
http://doc.trolltech.com/3.2/qstyle.html(...)
Gtk a un mecanisme similaire, mais n'utilise l'API native sur MacOs/X ou sous Windows. Rien au niveau technique ne s'y oppose, il faut juste que qq'un le fasse mais cela ne semble pas des plateforme prioritaires pour les developpeurs de Gtk.
Et dans les prochaines news hot, qq'un est en train de bosser sur un theme Gtk qui en fait utiliserait le theme courant KDE. Ca permettrait aux applications Gtk de s'integrer proprement dans KDE.-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Erwan (page perso, ) le 16/12/2003 à 12:37. (lien). Évalué à 3.De fait, c'est aussi comme ca que fait Qt. Sous Windows XP et sous MacOs/X et il me semble sous KDE, Qt utilise l'API native de l'OS pour dessiner les controles
Ca je le sais, qu'il utilise l'API native sous Windows et MacOSX. Ce que je ne sais pas c'est si c'est du cote du theme que c'est code ou si c'est dans le source des portages win et mac.
Gtk a un mecanisme similaire, mais n'utilise l'API native sur MacOs/X ou sous Windows.
Sisi.
http://gtk-wimp.sourceforge.net/screenshots/gfx/gimp-winxp.png(...)
Et dans les prochaines news hot, qq'un est en train de bosser sur un theme Gtk qui en fait utiliserait le theme courant KDE. Ca permettrait aux applications Gtk de s'integrer proprement dans KDE.
Ca, c'est une bonne idee. J'espere que Qt est aussi bien pense et qu'on pourra faire l'inverse.
-
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Guillaume Laurent (page perso, ) le 17/12/2003 à 10:31. (lien). Évalué à 1.Dans Motif on a appelait ca les widgets, je sais pas si ca se dit encore.
Ça se dit encore :-).
Certains toolkits, comme Gtk et Qt sous X11, dessinent eux-memes les controles.
Toutes les toolkits X11 dessinent elles-mêmes les contrôles, parce que X11 n'a simplement pas la notion de "controle", donc ce sont les toolkits qui implémentent ce concept.
-
-
Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
et quand une version integrée a gnome? parceque kde personne s'en sert :)
-
[+] [^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par kolter (page perso, ) le 16/12/2003 à 07:31. (lien). Évalué à -2.toi t'es très fort....
<<
et quand une version integrée a gnome? parceque kde personne s'en sert :)
>>
mais gnome non plus.......
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par oliv () le 16/12/2003 à 09:27. (lien). Évalué à 5.Un truc comme ça?
http://people.redhat.com/dcbw/(...)
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Christophe Merlet (page perso, ) le 16/12/2003 à 09:28. (lien). Évalué à 9.> et quand une version integrée a gnome?
Ben, ça fait longtemps que ça existe !!! ça s'appelle le Native Widget Framework (NWF)
voir le lien pour plein de joli captures d'écrans
http://people.redhat.com/dcbw/(...)
Ha oui, autre chose, ce sera intégré pour OpenOffice 1.1.2 vers mars/avril 2004.
Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Bon plan. L'idéal serait de tout basculer sous QT/KDE, ca doit etre faisable facilement
puisque OO doit etre codé en C++. Je suis sur que la taille du code serait divisé par 3 ou 4.
En utilisant OO, je me suis toujours demandé comment ils avaient fait pour que ce soit
aussi lent meme sur des bécanes rapides.
-
[+] [^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par xsnipe () le 16/12/2003 à 08:01. (lien). Évalué à -1.C'est bizarre j'avais l'impression que c'était plutôt du Java, me trompe-je ??
--
Debian ... gentoo moi ça et vite :)-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par gnumdk (page perso, ) le 16/12/2003 à 08:54. (lien). Évalué à 1.Non, OpenOffice peut utiliser java pour certaines fonctionnalités, mais il est codé en C++
--
Agogo
-
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par kesako () le 16/12/2003 à 08:52. (lien). Évalué à 5.Comme c'est dit plus haut, parce qu'ils redessinent tout pixel par pixel afin que l'aspect soit le meme quelque soit la plateforme.
C'etait la seulle solution envisageable il y a 5ans .-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par spell (page perso, ) le 16/12/2003 à 14:10. (lien). Évalué à 3.Je suis pas expert, mais wxWindows existait déjà il y a 5 ans.
Je me souviens avoir eu des cours à l'iut du Havre et c'était en 97.
Donc il y avait au moins cette solution, maintenant les developpeurs
de starOffice connaissaient peut-être pas ou trouvaient que c'était pas
adapté.-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par Sebastien Tanguy (page perso, ) le 16/12/2003 à 21:45. (lien). Évalué à 1.> Je me souviens avoir eu des cours à l'iut du Havre et c'était en 97.
Tout pareil, je confirme.
-
-
[^]Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE
Posté par max () le 16/12/2003 à 20:05. (lien). Évalué à 3.> ils redessinent tout pixel par pixel
C'est pas pour ça que c'est plus lent. OpenOffice c'est un logiciel avec plein de fonctions. C'est simplement pas optimisé comme il faudrait. Le problème, c'est qu'optimiser et rester portable ça représente beaucoup de boulot. MS Office c'est un peu plus rapide car ça ne fonctionne que sous Windows.
-
Et pourquoi pas à Gnome/GTK ?
Je ne suis pas certain d'avoir tout compris, mais si on sépare clairement la partie traitement de la partie graphique. Les briques de OOo 2 peuvent s'interfacer avec n'importe quoi ?
-
[^]Re: Et pourquoi pas à Gnome/GTK ?
Posté par tene (page perso, ) le 16/12/2003 à 10:40. (lien). Évalué à 3.C'est la belle théorie... mais je crains que la pratique ne soit pas si rose, surtout pour ce genre d'application énormément orienté vers l'UI.
-
[^]Re: Et pourquoi pas à Gnome/GTK ?
Posté par Jllc () le 16/12/2003 à 16:53. (lien). Évalué à 1.Y'a une question que je me pose (surtout après les explications un peu plus haut sur le fonctionnement des toolkits/thèmes). Au niveau de l'application, y'a t-il de grosses différences selon le toolkit GTK/Qt/Win32 ..., rendant difficile le port sur un autre OS ?
A ma connaissance, on retrouve toujours les mêmes widgets (boutons, menu, listes, conteneurs ...) fonctionnant toujours sur le même principe. Pour organiser l'interface, on imbrique les conteneurs, les mêmes widgets ont toujours les mêmes propriétés (label dans un bouton ..). Après, selon le toolkit utilisé, c'est plus ou moins rapide, plus ou moins gourmand en mémoire, plus ou moins joli ...
La réponse semble oui puisque chaque projet multi-plateforme (Mozilla, OpenOffice) refait sa propre moulinette, mais je ne comprends pas pouquoi.-
[^]Re: Et pourquoi pas à Gnome/GTK ?
Posté par bad sheep (page perso, ) le 16/12/2003 à 17:17. (lien). Évalué à 3.La gestion des évènements en particulier est très différente d'un environnement à l'autre. Pour simplifier, les applications graphiques utilisent une boucle d'évènements «quand l'application ne fait rien», c'est à dire 90% du temps. Cette boucle dirige les évènements vers les contrôles notamment (par exemple, un menu qui change d'apparence quand la souris passe dessus...).
Cette boucle est différente pour chacun des toolkits, c'est le premier problème.
Le second, c'est que les toolkits n'ont pas toujours les même «widgets» (contrôles graphiques) et si ils les ont, n'ont pas toujours le même comportement.
-
-
Re: Lancement d'un projet officiel d'intégration d'OpenOffice.org à KDE
Il me semble qu'une des meilleurs idées consiste en effet, comme l'a suggéré un autre contributeur, à utiliser WxWindows pour la réalisation de l'interface graphique.
Cela offre me semble-t-il d'énormes avantages sur tous les autres modes envisagés :
1- compatibilité immédiate avec les principaux systèmes d'exploitation : Linux, Unix, Windows, MacOS, ...
Le tout en mode natif s'il-vous-plaît.
2- support en un seul coup des principaux environnments graphiques natifs :
* X11, KDE, Gnome : pour Unix et Linux
* Win32 : pour windows
* etc ...
Là encore en mode natif.
3- existence d'interfaces simples de programmation pour les newbies qui souhaiteraint personaliser des choses via par exemple WxPython
4- non dépendance ou limitation à tel ou tel outil de dévelopement tel que QT qui n'est pas disponible gratuitement sur tous les environnements. Ce qui constitue à mon avis une entorse ENORME à la philisophie du OpenSource.
QT sous windows par exemple pose souci, or beaucoup d'utilisateurs commenceront probablement par utiliser OpenOffice sous windows quoi qu'on en dise.
De plus il ne sera pas plus difficile de faire un port vers WxWindows que vers QT, avec les inconvénients de QT en moins. Donc l'argument qui consiste à pousser l'intégration avec QT .....
Cependant même si dans les détails il peut y avoir discussion, cette initiative d'intégration de OpenOffice dans les environnements graphiques existants me semble très bien d'un point de vue général.
-
[^]Re: Lancement d'un projet officiel d'intégration d'OpenOffice.org à KDE
Posté par grmbl (page perso, ) le 16/12/2003 à 09:47. (lien). Évalué à 1.Bin si l'impossible WxQt avait existé, je suis sûr qu'ils l'auraient choisi !
-
[^]Re: Lancement d'un projet officiel d'intégration d'OpenOffice.org à KDE
Posté par Lionel Fournigault () le 16/12/2003 à 09:49. (lien). Évalué à 4.Oui effectivement, sauf que dans le cas QT/KDE il ya déjà des widgets de haut niveau bien au dessus de QT plus une architecture très bien pensée mais qui est liée à QT. De plus il faut que au final le desktop et toutes les applies soient homogènes au niveau look-and-feel. C'est de mon point de vue très important, sinon ça fait bricolo.
-
[^]Qt pour du developpement libre ?
Posté par Pothin Alain (page perso, ) le 17/12/2003 à 14:42. (lien). Évalué à 1.Je suis developpeur java et je suis interessé de faire des développements en C++ sous KDE. Donc utiliser les api Qt directement ou indirectement. Je trouve ce framework à première vue intéressant.
A priori, si on developpe par exemple un Kpart sous GPL pas besoin de payer une licence à trolltech. Mais si on le fait closed source en sein d'une entreprise, faut-il payer la licence ?
et plus généralement pensez vous qu'utiliser Qt pour du développement GPL en C++ soit contre nature à l'esprit du libre ? il y a t-il une alternative ?
-
Cette page a été générée par Templeet en 0.2176s (dont 0.0576 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.