djano a écrit 1147 commentaires

Ah ben justement c'est marrant: http://linuxfr.org/news/nouveau-site-communautaire-de-la-forge-libre-tuleap

En libre et qui gere les exigences (a quel point? Je ne sais pas!) de manière un peu intégrée (forge, bugtracker, etc.), je connais Tuleap: http://www.enalean.com/?q=fr/tuleap#gestion-exigences

Par contre, je n'ai pas joue avec alors je ne sais pas du tout ce qu'il vaut.

Je suis vraiment bluffe par les photos incluant l’élévation du terrain, c'est vraiment magnifique.
Du coup, c'est ballot, mais ça fait très moche lorsque les bâtiments sont uniquement représentes par des textures toutes plates… :-/
Ce n'est pas le cas de Paris et des grandes villes, mais est ce que les villages et les villes de campagne resteront toutes plates?

On en veut toujours plus!

Je vois. Merci pour ta reponse.

Ne serait-il pas possible d'avoir un "Adapter" des anciennes APIs vers les nouvelles APIs?
Ca permettrait de conserver la compatibilite avec les anciens plugins.
Je suppose que si c'etait si facile, ils l'auraient deja fait. C'est dommage pour les plugins actuels! :(

Par contre je vois qu'ils font une implementation OpenCL ce qui est bon pour les perfs :)

Par curiosite, peux-tu detailler le probleme que cela pose s'il te plait?

paramèyres

=> paramètres

Et un de plus!

Ca sent le sapin pour GTK+…

Gnome va-t-il finir pas passer lui aussi sur Qt?

Je ne comprend pas bien ton besoin: est ce que c'est n'est pas le role d'un annuaire LDAP?
OpenDJ, OpenLDAP, voire meme AD (beurk) puisque vous semblez l'utiliser.

Je suppose que j'ai loupe quelque chose…

Il me semblait surtout que la pricipale difference etait que les pilotes libres partagent du code entre materiel de differents marques (AMD, NVidia ou Intel) grace a des frameworks existant exclusivement sous Linux tels que TTM (ou GEM? je ne sais plus).

Alors que les pilotes proprietaires sont destines a s'executer sur Windows, Linux et tous les OS qu'ils veulent alors ils ne peuvent pas vraiment utiliser des frameworks specifiques a un seul systeme.

Oui, oui, c'est bien ce que je voulais dire :)

Alors je suis oblige de crier ou de faire une emphase ce qui ne correspond pas a la typographie usuelle. :-/

Ce n'est pas le besoin d'évolution que je pense que tu sous-estimes, mais la difficulté de faire évoluer LibreOffice tout court (à cause du code, des concepts utilisés, etc).

Je ne crois pas que je le sous-estime non.

Reecrire une base de code depuis zero est la pire erreur qui peut etre faite.

Que je trouve absurde quand elle est énoncée comme une vérité absolue.

Je pense et je maintiens que c'est une grosse erreur dans 95-99% des cas de repartir de zero pour TOUT le projet.
[apparte: quelqu'un sait-il comment souligner du texte en markdown?]

Tu penses reellement que LibreOffice aurait ete plus vite en repartant de zero? (C'est une vraie question)
Et est ce que les developpeurs auraient suivi?
Est ce que cela aurait attire les contributeurs sachant que les projets libres concurrents sont plethores? (Apache OpenOffice, Caligra, Gnome Office)

Merci pour ta reponse detaillee, ca fait beaucoup plus plaisir a lire!!

l'inertie du code l'emporte sur la migration vers une nouvelle librairie

Tout le monde a bien conscience que c'est compliqué de changer, que ça prends des années.
Qt permettrait de le faire par étapes en se mélangeant au code historique.
Ça c'est déjà fait pour les MFC, Motif et Java AWT/Swing.

Je ne connaissais pas ces pages, c'est interessant. Je croyais que Qt Jambi est mort, mais c'est seulement le support commercial. Il semble qu'il soit maintenu par la communaute.

Je pensais que tu parlais d'ajouter une nouvelle implementation de la VCL pour Qt. Cela aurait ete un peu redondant avec l'implementation GTK sur la plateforme GNU/Linux, d'ou le fait que personne ne se bouscule pour la realiser.
Je pensais qu'alors il faudrait avoir une implementation Qt complete de la VCL avant de pouvoir l'utiliser, ce qui retarde d'autant le moment ou tu peux l'utiliser.

D'ailleurs, le code existe pour une implementation Qt de la VCL (patches welcome):
http://ubuntu.5.x6.nabble.com/LibreOffice-welcomes-Qt-devs-was-ubuntu-devel-Digest-Vol-96-Issue-24-td4988545.html

quel serait l’intérêt pour eux de le faire ?

Utiliser un toolkit comme Qt permet d'externaliser beaucoup de code à des gens dont c'est le métier, qui ont le temps, les compétences et les ressources pour le faire beaucoup mieux que toi.

J'avoue que je ne connais pas parfaitement Qt puisque je fais essentiellement du Java. Mais je commence a voir ou tu veux en venir: Qt pourrait etre utilise non seulement en tant que lib graphique, mais plus que cela: types de bases tels que String, filesystem, reseau, audio, etc.

Quelqu'un a deja propose Qt, mais rien ne semble bouger:

• https://wiki.documentfoundation.org/Development/Crazy_Ideas#Replace_all_interface_code_with_an_interface_using_the_Qt_widgets
• http://ask.libreoffice.org/en/question/22528/changing-lo-code-to-use-qt/
• http://lwn.net/Articles/434802/ (peut etre plus interessant)

Ceci dit, je n'ai pas trouve de position des developpeurs principaux. J'ai juste trouve l'email de Bjoern Michaelsen (ci-dessus) qui est un contributeur tres regulier.

Et les arguments du type "une nouvelle librairie que tu ne connais pas" et "tu ne maîtrises pas l'évolution" tiennent plus de NIH qu'autre chose.

Je parlais surtout de WxWidget. Si je travaillais sur LibreOffice, je ne pense pas que je me baserais dessus. Pour Qt, cela me semblerait tout a fait faisable, surtout vu la maniere dont le perimetre de Qt a augmente, et aussi depuis qu'il a ete separe en plusieurs librairies independantes.

Temps de développement important pour ajouter/améliorer des fonctionnalités à LO : exemple de rapidité de développement avec Qt : http://www.youtube.com/watch?v=_6_F6Kpjd-Q, je doute que ça soit aussi rapide et facile avec VCL…

Oui, mais je pense que Glade leur permet de facilement concevoir des propositions d'interfaces. Je viens de voir que Qt a Qt designer dans le meme registre.

En revanche on est bien d'accord que la priorité est de nettoyer le code avant de pouvoir faire un changement de cette importance. Mais apparemment remplacer VCL pour Qt n'est clairement pas à l'ordre du jour :-/

Oui, je pense que c'est un enorme pas dans la bonne direction que ce changement d'attitude vis-a-vis du code legacy.
Je reconnais que tes arguments sont tout a fait pertinents, et j'ai bien bien peur qu'un portage vers Qt ne soit pas dans le radar actuellement.

Pour le reste, je ne crois pas que tu comprennes la difficulte et l'enormite de la tache.

Et peut-être que tu ne comprends pas la difficulté et l'énormité de la tâche qui consiste à faire évoluer LibreOffice suffisamment pour qu'il soit au niveau de la concurrence :) ?

Je dois dire que je n'ai pas compris ta blague ni ce qui te fais penser que je sous estime le besoin d'evolution?

(hum, une remarque en passant pour les moinsseurs : je participe au développement de LibreOffice - mais bon, restez avec vos certitudes : puisque Joel Spolsky le dit c'est que c'est vrai il faut toujours conserver le code existant et ne jamais repartir de zéro)

Evolution n'est pas revolution.
Tu as mal compris mon propos ou celui de Joel Spolsky.
Reecrire une base de code depuis zero est la pire erreur qui peut etre faite.
Je suis au contraire fan de faire evoluer (meme a grande vitesse, quitte a creer quelques bugs au passage) une base de code existante tout en etant capable de livrer une nouvelle version a tout moment.

Je suis donc tout a fait content de l'evolution actuelle de LibreOffice, et je dois meme dire que cela m'a attire puisque j'ai soumis quelques patches (acceptes!!) pour supprimer la class UniString.

 

Merci a toi pour tes contributions :)

VCL n'est qu'une couche d'abstraction vers les les libs qraphiques des OS

Tout comme wxWidgets, AWT, SWT et dans une moindre mesure GTK+, Qt, SWING…
Ta négation "n'est qu'une […]" sous entends que c'est facile alors que ça ne l'est absolument pas.

WxWidget n'existe que (!) depuis 1992, alors que StarOffice a debute en 1985.
Je pense que VCL a existe bien avant WxWidget.
Ensuite, une fois que les VCL ont ete partout, l'inertie du code l'emporte sur la migration vers une nouvelle librairie fournit par un tiers que tu ne connais pas et dont tu ne maitrise pas l'evolution.
Le cout de changer de librairie devait etre bien superieur au cout de maintenir l'existant.

Tu m'as l'air bien motive, vas-y, lance toi

Remarque récurrente pour éviter de répondre à toute critique.

Repondre a quelle critique? Si c'est pour ecouter des yakafokon, je ne vois pas l'interet.
Tu proposes un plan pour le faire (avec €€€€) ou tu espere que les gens de LibreOffice vont le faire pour te faire plaisir?
Encore une fois, ce n'est pas du tout leur priorite. Si tu ne le comprends pas je ne peux rien pour toi.
D'ailleurs quel serait l'interet pour eux de le faire?

Pour toi la réécriture complète du moteur de Calc ce n'est pas majeur ?

Non. Niveau utilisateur, ca change rien. Ca marche pareil qu'avant, (ou pas, mais on s'ee fout, un bug doit etre corrige, que ca soit par un nouveau moteur ou pas)

Sauf si ca permet de corriger de nombreux bugs dans le futur et d'accelerer l'ajout de nouvelles fonctionnalites.

Le backend expérimental Firebird SQL de Base à la place de l'immonde HSQLDB ce n'est pas majeur ?

Non plus, l'utilisateur s'en bat les roubignoles.

Qui es tu pour parler au nom de tous les utilisateurs?
Pour autant que je sache tu n'es qu'un unique utilisateur.

Peut etre que tu ne fais que des petits tableurs alors tu t'en moque, mais ceux qui ont des gros tableurs doivent y voir un interet eux.
L'utilisateur n'en a rien a foutre d'amelioration

Pour rappel: ceci est une suite bureautique destinee aux utilisateurs finaux.
Tout ce qui est derriere l'interface et un detail sans importance.

Si tu n'en a rien a foutre, pourquoi lire et commenter les changelogs techniques?
Ne le fais pas, tout le monde t'en remerciera.

J'ai bien lu mais bon ca fait plusieurs annees de nettoyage pour arriver a un truc qui marche mal sur les bureaux KDE et qui stagne sur toutes les fonctionnalites. Vu le temps pris pour le nettoyage je me demande si il n'aurait pas mieux valu abandonner le code et repartir d'un truc propre?

Ha ha ha!
Abandonner une base de code sur laquelle il y a eu des dizaines (centaines) de millions d'investissement pour repartir de zero?
Lit ceci: http://www.joelonsoftware.com/articles/fog0000000069.html

Pour le reste, je ne crois pas que tu comprennes la difficulte et l'enormite de la tache.

Pourquoi conserver le vieux toolkits qui s'integre mal partout et fait bien sentir son age. Pourquoi ne pas passer sur le seul toolkit reellement multiplateforme Qt?

Ils attendent ta contribution…

Precedemment on parlait du "'dénigrement' du code qui a été modifié", et bien je parle ici du denigrement du projet LibreOffice.

C'est ri-pou !

C'est triste ton avis sur LibreOffice et ton attitude non constructive.
Si tu n'es pas content et que tu n'as pas le temps, passe ton chemin et utilise Calligra ou Gnome Office.

Parce que convertir toute la suite à Qt est un travail de titan ?

Plus que maintenir un toolkit entier (VCL) sur 3 plateformes ?

VCL n'est qu'une couche d'abstraction vers les les libs qraphiques des OS pour ce que j'en avais vu.

Du code Qt peut très bien vivre avec du code fait avec autre chose. Le travail peut se faire au fur et a mesure.

Oui mais la vie est une question de priorite, et pour l'instant les priorites sont ailleurs.
De plus il semble que personne de suffisamment motive ne se soit lance.
Tu m'as l'air bien motive, vas-y, lance toi, je ne pense pas qu'ils te diront non.

D'ailleurs tout ce travail engage sur la base de code permet de faciliter et accelerer ce genre de contributions.

J'ai lu la version anglaise et je n'ai pas senti ce denigrement dont tu parles.

On peut dire que le code a vieilli ou bien qu'il etait lourd sans pour autant jeter le bebe avec l'eau du bain.
Parfois le code est ecrit salement des le debut, le developeur le sait lui meme, mais des contraintes externes font qu'il ne puisse pas faire mieux dans le temps imparti.

Oui le code a fait le boulot pendant quelques annees, c'est toujours le cas du code legacy, mais on peut et doit pouvoir le critiquer objectivement et surtout l'ameliorer. C'est la vie de tous projet logiciel.
Contrairement a ce que tu dis, voir une telle activite de nettoyage me donne envie de contribuer car je sais que tout est fait pour rendre le travail sur cette base de code beaucoup plus agreable en supprimant/reecrivant les parties problematiques. Cela me semble tres sain.

Le "monstre" ici, c'est pour "enorme". La tache a ete tres longue car ces classes etaient utilisees partout.
L'utilisation du mo "moisi" dans la traduction est beaucoup trop fort a mon gout et ne traduit pas les mots/le ton de l'auteur original.

Je vais passer ma journee a jouer au lieu de travailler (un peu).
Bon, on me dit que puisque c'est vendredi, c'est permis ^_^

Merci! ;)

Je pense que tu reponds au mauvais commentaire?

Je signalais un faute d'orthographe.

L'ABI C++ n'est pas standardisee et notamment le name mangling.
L'ABI generee par g++ a egalement changee au cours du temps et des versions.

Les vrais nouveautés (comme ou ) apparaîtront dans doute avec C++17.

=> …sans doute…