Lancement d'un projet officiel d'intégration d'OpenOffice.org à KDE

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
16
déc.
2003
Bureautique
Les gens d'OpenOffice.org viennent d'accepter dans l'incubateur deux projets (Cuckoo et ooo-qt) visant à mieux intègrer leur (notre) suite bureautique à KDE. Cela signifie que si suffisement de gens sont intéressés, le projet deviendra un projet officiel soutenu par OO.org. Un appel à contribution est donc lancé. La nouvelle a été annoncée hier soir sur KDE.news. On apprend là bas que ces deux projets consistent en Cuckoo, un Kpart pour intégrer à KDE une prévisualisation effectuée par OO.org et ooo-qt qui vise entre autres à permettre à OO.org d'utiliser les éléments de thèmes de KDE (comme ceux de Gnome dans la version 2.0).

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.

Aller plus loin

  • # Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE

    Posté par  (site web personnel) . Évalué à 10.

    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  (site web personnel, Mastodon) . Évalué à -3.

      Pierre, vas dormir bondiou ! :)

    • [^] # Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE

      Posté par  (site web personnel) . Évalué à 10.

      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  . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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  . É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

          Posté par  (site web personnel) . É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  . Évalué à 0.

          Leur toolkit n'est pas plus moche que la série des Windows 95 98 et Me...

        • [^] # Re: Lancement d'un projet officiel d'intègration de d'OpenOffice.org à KDE

          Posté par  . É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  (site web personnel) . É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  (site web personnel) . É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

      Posté par  . Évalué à 2.

      Toutefois j'émet un vœu, 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

    Posté par  . Évalué à 8.

    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  (site web personnel) . É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  . Évalué à 10.

        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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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

    Posté par  (site web personnel) . Évalué à 2.

    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  . Évalué à 1.

    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.

  • # Et pourquoi pas à Gnome/GTK ?

    Posté par  . Évalué à 3.

    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  . É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  . É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  (site web personnel) . É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

    Posté par  . Évalué à 7.

    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  . É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  . É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  (site web personnel) . É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 ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.