Bonjour Le Mercredi 20 Avril 2005 19:08, LE LOUARNE Serge a �crit�: > Pierre D. a �crit : > >C'est un avantage de KOffice et Gnome-office : ils sont rapides > >� charger, c'est fascinant ! R�sultat si on veut modifier quelque chose de > >KOffice on peut rapidement le tester. > Ils utilisent ce qui est d�j� charg� au lancement de KDE : l'aspect > gestion des fen�tre, �change des messages entre elles, etc... . Pour > OOo, ce n'est pas le cas. On retrouve d'ailleurs cela dasn MSO Ne serait-il pas possible de se d�charger au maximum de ce genre de t�ches ? Gestion des fen�tres => laisser le toolkit s'en charger (Qt, Gtk ou les libs win32) Echange de messages entre elles => pareil (Qt le fait divinement ;)
Et que veux tu dire par "on retrouve cela dans MSO" ? MSO ne marche que sur win32 et donc ils ont pas � s'emmerder avec le multi plateformes ! > >Pourquoi OOo ne peut il pas consid�rer l'utilisation d'outils de plus haut > >niveau afin de se d�charger de certaines t�ches lourdes (dont > > l'abstraction du syst�me) ? Ou exploser OOo en plusieurs projets > > distincts ? > >Et plus haut niveau != Java > Le java marche bien quand il est seul et que l'on utilise une version > r�cente. Des classes remonte � Java 1.1... Antique ! > En outre (et je peste assez contre ca) il n'y pas vraiment de > standardisation dans les variables d'environnement utilis�e par Java et > surtout par les diff�rends programmes (librairies comprises). > Maintenant, je ne suis pas s�r que C++ puisse passer pour �tre de plus > niveau que Java. Apr�s tout, le C++ s'adresse au processeur, alors que > Java vise une VM, ce qui permet entre autre de g�rer le GC et de > s'abstraire de l'allocation de m�moire qui semble �tre parfois > hasardeuse en C++ (Bon, je ne pratique pas ou si peu ...). Nous n'utilisons pas le m�me C++ :p Je fais en C++ autant d'allocations m�moire qu'en Java ! (Sauf quand je dois int�grer dans mon code C++ des acc�s � une librairie en C, chose que je s�pare au maximum du code de mon appli pour �viter l'odieux malloc ;) > >�a aussi �a repousse des gens : certains n'aiment pas java parce qu'il n'y > > a pas d'impl�mentation libre de Java disponible. Je les comprend, leur > > point de vue se d�fend ! Et pousser Java dans OOo, c'est laisser de c�t� > > un potentiel assez gros. > Oui, ca se d�fend. Mais dans ce cas pourquoi ne pas en dire autant de > Xul, qui implique de passer par Mozilla (Tant que le runtime XulRunner > ne sera pas sorti, en tout cas ...), ou de la pr�sence de Python > (j'avoue que je ne sais pas � quoi il sert dans OOo) ? Mozilla et XUL sont particuliers... XUL fournit quelque chose de nouveau, c'�tait ""r�volutionnaire"" lors de la sortie de mozilla ! Et XUL a un potentiel �norme, qui sera pouss� avec xulrunner (et pourquoi pas pouvoir utiliser python avec une interface XUL, ce qui serait le r�ve...) Python pourrait dans OOo servir � r�aliser des macros complexes tout en b�n�ficiant de toutes les librairies python disponibles : il me semble que le basic d'OOo ne permet pas par exemple de parser du XML, alors que python le permet rapidement et facilement. > Pour moi, le vrai probl�me est cette multiplicit� de langages qui > obllige � des ponts entres librairies/executables. Cela � sans doute une > origine historique. Tu parlait de QT sous windows, il me semble que la > version gratuite (et opensource, je crois) de QT pour Windows est toute > r�cente ... Petite erreur : toute r�cente => pour bient�t !!! QT 4 sera en GPL sous windows... Mais GPL, et pas LGPL.. Et �a �a g�ne OOo : ben oui, Sun ne pourrait plus reprendre le code d'OpenOffice pour en faire StarOffice : StarOffice aurait � �tre libre. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
