La suite bureautique libre LibreOffice vient de sortir en version 4.0 le sept février. Ce changement soudain de numéro de version s'explique par l'évolution de l'interface de programmation applicative (API) induisant des incompatibilités avec d'autres programmes, comme les extensions, qui devront être adaptés.
La suite de cette dépêche s'attachera à préciser lesdites incompatibilités, puis un petit tour des nouveautés sera proposé, agrémenté de captures d’écrans correspondantes.
Sommaire
- Version majeure
- Writer
- Calc
- Impress
- Interface d’apparence
- Filtres d’importation
- Gestion du protocole CMIS
- En vrac
- Le mot de la fin
- Remerciements
Version majeure
Une incompatibilité périodique est nécessaire à une évolution saine. C'est ce qui vient d'arriver chez cette suite bureautique.
En effet, cette version propose une interface de programmation applicative potentiellement non compatible avec les versions antérieures. Ceci aura un impact sur les extensions qui devront éventuellement s’adapter pour pouvoir fonctionner avec LibreOffice. Les développeurs se sont toutefois efforcés de minimiser autant que possible l’impact de ces modifications.
Ainsi, les modules Python ont migré vers la version 3.3, et les modules complémentaires doivent adapter leur code en conséquence pour rester fonctionnels avec cette version et les suivantes.
Une grande partie de l’interface de programmation a été nettoyée, et les parties obsolètes en version 3 ont maintenant été supprimées.
Writer
Commentaires
Le pointage des commentaires de travail a été nettement amélioré, ce qui facilite leur compréhension. Ainsi la flèche peut maintenant être liée à un ensemble de mots surlignés (au lieu d'une seule lettre auparavant), mais cet ensemble est limité à un seul paragraphe pour l’instant.
LibreLogo
LibreOffice dispose dorénavant d’un mécanisme de génération de graphisme vectoriel avec le langage Logo, un outil simple, similaire par certains côtés à ce qu’on peut faire avec Canvas en HTML.
Pour plus d'informations :
http://numbertext.org/logo/posters/logoposter_en.pdf
http://numbertext.org/logo/librelogo.pdf
http://numbertext.org/logo/lok_en.pdf
http://numbertext.org/logo/librelogo_en.pdf
http://sophiegautier.com/blog/index.php/2012/12/04/190-librelogo
http://libreoffice.hu/2012/11/29/logo/
Séparateurs de mots
Les statistiques textuelles sont encore une fois présentes dans la liste des nouveautés. Il est maintenant possible de spécifier des caractères délimitant les mots. Ça peut être utile — par exemple — pour les tirets cadratins délimitant les incises.
Taches d’encre
Les amateurs apprécieront de savoir qu’il est maintenant possible d’importer les notes faites à l’encre numérique au sein de fichier DOCX et RTF.
Mathématiques RTFiennes
La prise en charge du format RTF s’améliore encore en ajoutant la possibilité d’importer ses formules mathématiques correctement. N’hésitez-pas à migrer vos documents RTF maintenant !
Sans style
L’utilisation de LibreOffice repose sur un concept simple qui consiste à donner un style particulier à chaque page. Ceci permet, notamment, de pouvoir modifier un groupe de pages de manière simple et centralisée.
La première page n’échappe pas à cette règle, mais il est maintenant possible de spécifier des en-têtes et des pieds de page différents sans changer de style.
C’est un changement légèrement discutable, et ce serait dommage de perdre l’habitude d’appliquer un style à chaque page (ceci n’implique que l’avis personnel de l’auteur).
Vrac
La prise en charge de documents RTF améliore également l’importation de dessins à la syntaxe ancienne.
Les documents DOCX sont mieux importés ; notamment en ce qui concerne les tables flottantes, les objets OLE à l’intérieur des rectangles ainsi que les marges autour des images noyées dans le texte.
Calc
La norme ODF Open Formula est mieux respectée grâce à l’implémentation d’une fonction ou-exclusif.
Il est maintenant possible de spécifier comment traiter une chaîne de caractères vide dans une formule.
L’exportation des légendes de couleurs ainsi que des histogrammes de données vers un document XLSX se passe bien. Ceci améliore la compatibilité avec Microsoft Office 2010 et suivants.
Impress
Sous Gnu/Linux, le code de GStreamer a été remodelé, et prend maintenant en charge la version 1.0. Le contenu multimédia est ainsi bien mieux géré au sein des diapositives que vous créez.
Les éléments bitmap sont maintenant éditables via un éditeur externe.
Enfin, votre position au sein de la liste de diapositives est maintenant sauvegardée entre chaque session.
Interface d’apparence
Structurer avec style
Les styles (tels que Titre 1, texte, etc.), proposent maintenant un aperçu de l’effet appliqué.
La cohabitation avec Unity est maintenant beaucoup plus sereine, et LibreOffice occupe mieux l'espace en intégrant le menu global.
Rapprochement avec Firefox
Il est maintenant possible d'utiliser les personas de Firefox au sein de la suite bureautique, et ainsi la personnaliser au gré de ses goûts.
Nouveau gestionnaire de modèles
Codage de l’interface en interne
Jusqu’à présent, l’interface de LibreOffice était écrite en dur dans le code, ce qui rendait les changements difficiles et accessibles seulement aux programmeurs chevronnés.
À présent, dans LibreOffice 4.0, les interfaces peuvent être écrites en XML avec Glade dans le format utilisé par GTK. Cela ne veut pas dire que LibreOffice utilise GTK, mais utilise seulement ce format de codage d’interface. LibreOffice utilise toujours son propre toolkit : VCL.
La conversion de l’ancienne interface vers la nouvelle est encore en cours.
Plus d’informations :
https://wiki.documentfoundation.org/Development/WidgetLayout
http://blogs.linux.ie/caolan/2013/01/24/converting-libreoffice-dialogs-to-ui-format-100-conversions-milestone/
Filtres d’importation
Les filtres de fichiers binaires StarOffice (versions 1.0 à 5.0) ne sont maintenant plus fournis.
Les documents Microsoft Publisher sont maintenant importables.
LibreOffice prend maintenant en charge la totalité des fichiers Microsoft Visio !
Gestion du protocole CMIS
Le protocole CMIS est maintenant parfaitement pris en charge, ce qui permet d’accéder aux documents enregistrés sur des gestionnaires de contenus tels qu’Alfresco, Nuxeo, SharePoint…
En vrac
Le nombre de fonctionnalités dépendantes de Java s’amoindrit de plus en plus et l'assistant de création de lettre et de fax est maintenant écrit en Python.
Le moteur d'expressions rationnelles a été changé pour être plus standard et se base sur ICU.
Les greffons « Presenter Console » (qui gère désormais les langues écrites de droite à gauche) ainsi que « PDF Import » font maintenant partie intégrante de LibreOffice.
Le mot de la fin
Le tour des principales nouveautés est maintenant terminé. Si vous souhaitez avoir un aperçu plus complet, n’hésitez pas à consulter la note de version officielle, ou installez cette nouvelle version sur le champ pour l’essayer.
Pour les autres, votre distribution favorite vous l’amènera sur un plateau, en temps voulu.
Enfin, il est bon de rappeler que les entreprises sont conviées à attendre la sortie de la version 4.0.1.
Remerciements
Je tiens à exprimer ma gratitude à toutes les personnes ayant contribué à cette dépêche, c'est-à-dire, par ordre alphabétique, à :
coid, El Titi, francis latouche, jcr83, jerome_misc, NeoX, Nÿco, Xavier Verne, ZeroHeure.
Aller plus loin
- Site officiel (1337 clics)
- Page de téléchargement (562 clics)
- Notes de version (267 clics)
- Note de version détaillée (228 clics)
# Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 10.
Troll : pourquoi ils passent pas à Qt ? LibreOffice est en C++ et multiplateforme, Qt aussi.
Je comprends pas pourquoi ils sont passé de dmake à automake alors que CMake existe et corresponds logiquement bien mieux à leurs besoins.
Très instructif: LibreOffice: the story of cleaning and re-factoring a giant code-base
[^] # Re: Pourquoi VCL et automake ?
Posté par coid . Évalué à 3.
Pour le choix de make, je ne sais pas.
En revanche, la raison pour laquelle LibreOffice n’utilise pas Qt, c’est que le logiciel possède déjà son propre toolkit interne, appelé VCL, et que d’après ce que j’ai ouï dire, impossible de s’en débarrasser d’un claquement de doigts, le code de LibreOffice étant encore un plat de spaghettis, malgré tout le nettoyage fait (il y a encore beaucoup de boulot pour avoir un code clair, semble-t-il).
Par ailleurs, j’ai le sentiment, vu certains choix faits, que les dévs ont un penchant plutôt pour GTK+ et Gnome. :(
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 8.
Mon commentaire faisait écho à ça justement. GTK+ ne brille vraiment pas par son coté multiplateforme et en plus c'est du C alors que Qt est vraiment multiplateforme (s’intègre même parfaitement à GNOME) et en C++.
De plus Qt a une bonne longueur d'avance (au moins 5 ans) sur GTK+. Même Canonical utilise Qt pour son nouvel OS mobile alors que c'est une entreprise fondamentalement pro GNOME et pro GTK+ !
Qt a également la particularité de pouvoir s’intégrer avec d'autres toolkits pour permettre de changer le code d'une appli au fur et à mesure. A l’époque de Qt 3 il y avait Qt Motif Extension pour mélanger du Motif avec du Qt. Il existe la même avec les MFC. On peut même mélanger du Qt et du GTK+ !
Il y a surement moyen de créer un "pont" entre VLC et Qt pour pouvoir réaliser les nouveaux développements en Qt et garder les anciens en VCL.
Oui ça on sait…
[^] # Re: Pourquoi VCL et automake ?
Posté par bibitte . Évalué à 8.
Toi oui, mais le reste du monde pas forcement … (moi je savais pas)
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 10.
C'est écrit dans la news : "LibreOffice utilise toujours son propre toolkit : VCL". On peut supposer que les personnes qui commentent ont lu la news.
[^] # Re: Pourquoi VCL et automake ?
Posté par ariasuni . Évalué à 2.
Moi non plus je ne savais et je me demande d'où sort cette information. Il y a des tas de petits trucs comme ça qui sont intéressant à savoir, et pourtant on ne les trouvent nulle part (surtout que les toolkits c'est limite la première chose qu'on te dit quand on présente un logiciel sous GNU/Linux).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pourquoi VCL et automake ?
Posté par Jean-Baptiste Faure . Évalué à 5.
https://wiki.documentfoundation.org/Development
http://docs.libreoffice.org/
[^] # Re: Pourquoi VCL et automake ?
Posté par david.g . Évalué à 3.
Outre le fait que se soit un très gros chantier que de changer de Toolkit en cours de route, il me semble que pour sa version en ligne, les développeurs LibreOffice, mise beaucoup sur le backend "broadway" de Gtk+.
Leur toolkit utilise Gtk, comme le fait Mozilla avec ses produits sous Linux. Tout n'est pas parfait, mais ça à le mérite de fonctionner, donc pourquoi changer ?
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 6. Dernière modification le 08 février 2013 à 18:25.
Backend HTML5 pour Qt : http://www.youtube.com/watch?v=qDyWjNju1yU
[^] # Re: Pourquoi VCL et automake ?
Posté par Atem18 (site web personnel) . Évalué à -5.
N'importe quoi. Ce qu'il ne faut pas entendre de nos jours. La seule raison pour laquelle Ubuntu à toujours fourni Gnome par défaut, c'est parce que Debian l'a toujours fait ! N'oubliez jamais que Mark est un ancien dev Debian et qu'Ubuntu est son cadeau à la communauté. S'ils ont choisi Qt, c'est parce que c'est un framework alors que Gtk+, non.
[^] # Re: Pourquoi VCL et automake ?
Posté par xcomcmdr . Évalué à 1.
Ils le font toujours. Unity n'est qu'un shell basé sur Compiz. Tout le reste c'est Gnome 3 (voire Gnome 2.32 dans la 11.04 !)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 10.
Je te retourne le compliment. Imaginer qu'une entreprise qui depuis sa création (8 ans) base tout son travaille sur GNOME et GTK+ ne soit pas pro GNOME / GTK+ est d'une stupidité évidente. En fait c'est un complot, ils sont pro wxWidgets…
Ba ouai bien sur Canonical est marié à vie avec Debian.
Si Ubuntu fournit Unity par défaut, c'est parce que Debian l'a toujours fait.
Si Ubuntu fournit des logiciels propriétaires par défaut, c'est parce que Debian l'a toujours fait.
Si Ubuntu fournit Upstart par défaut, c'est parce que Debian l'a toujours fait.
Si Ubuntu sort tous les 6 mois, c'est parce que Debian l'a toujours fait.
Si Ubuntu utilise Bazaar, c'est parce que Debian l'a toujours fait.
Canonical fait ce qui l'arrange, point barre.
Ca veut rien dire, personne ne s'accorde sur la définition de ce qu'est un framework.
Si Canonical a choisit Qt plutôt que GTK+ pour leur OS mobile c'est parce que Qt corresponds mieux aux besoins. Forcement un outil qui a 5 ans d'avance sur l'autre, ça fait réfléchir…
[^] # Re: Pourquoi VCL et automake ?
Posté par Maclag . Évalué à 5.
Je suis en train de faire un effort de mémoire important pour me souvenir de l'époque à laquelle Debian ne fournissait QUE Gnome.
Finalement, grâce à toi, j'ai un sentiment que je n'ai pas eu depuis bien longtemps: celle d'être un p'tit jeune!
[^] # Re: Pourquoi VCL et automake ?
Posté par Taurre . Évalué à -1.
Ah ? Tu as des sources pour confirmer ce que tu avances ?
Et ?
C'est surtout que, comme cela a déjà été dit, GTK+ n'a pas pour vocation d'être un « framework » (comprendre par là : un ensemble d'outils fournissant au programmeur un peu près tous ce dont il a besoin pour créer son application), mais bien une bibliothèque spécialisée dans la création de GUI. Comparer les deux n'a absolument aucun sens, ils n'ont pas du tout la même vocation.
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . Évalué à 9.
Oui, menfin lorsqu'on souhaite écrire un GUI multiplatforme, vient le moment où on se demande si on va opter pour tel ou tel toolkit et les candidats sont peu nombreux, entre autre : GTK, QtGui, wxWidget, Java et .NET (je déconne).
Ca paraît donc relativement pertinent de mettre Qt et GTK dans la balance à ce moment là.
[^] # Re: Pourquoi VCL et automake ?
Posté par Taurre . Évalué à 3. Dernière modification le 11 février 2013 à 11:09.
Il me semblerait plus juste de parler de bibliothèque et non de « toolkit ». M'enfin, nous sommes d'accord sur ce point.
Oui, mais dans ce cas, uniquement du point de vue de la création de GUI.
Parler en termes général comme l'a fait tangui_k est un non sens car c'est omettre l'objectif de GTK+ qui est de fournir une bibliothèque spécialisée dans la création de GUI, sans plus. Pour faire une analogie, cela revient à comparer GTK+ et la SDL en disant que GTK+ à cinq ans d'avance parce qu'il n'est pas possible de créer facilement une GUI avec la SDL. Or, c'est absurde, elles n'ont pas le même objectif.
Sinon, soit dit en passant, je remercie les courageux qui m'ont moinsser sans prendre la peine de répondre.
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 10. Dernière modification le 11 février 2013 à 19:43.
QtGui a exactement le meme objectif que GTK+.
C'est évident que Qt a plusieurs années d'avance sur GTK+, 210 contributeurs pour 3000 commits/an vs 400 contributeurs pour 15780/an
Il y a UN développeur payé pour travailler sur GTK+ et c'est même pas le cas pour la GLib !
Quelques commentaires dans le même article qui s'adresse a la communauté GNOME :
Même Shuttleworth a proposé de re-écrire GNOME en utilisant Qt…
Et malheureusement je n'arrive pas a trouver l'article d'un (ex-?)employée de Nokia qui avait commencé en GTK+ et qui a du a contre coeur se mettre a Qt suite au rachat de Trolltech par Nokia pour finalement adorer cette bibliothèque et "renier" GTK.
Maintenant j'attends les avantages supposés de GTK+ vs Qt…
PS : c'est Tanguy comme dans le film, pas tangui
[^] # Re: Pourquoi VCL et automake ?
Posté par xcomcmdr . Évalué à -7.
Bah non, c'est indiscutable
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 10.
Oui il y a des points qui sont indiscutables. La doc : QPushButton vs gtk_button et l'intégration a l'OS par exemple, tout comme le multiplateforme.
Avantages de GTK+ :
- Le C++ est plus complexe que le C et la syntaxe est "bloated"
- GNOME/GTK+ est l'environnement par défaut des grosses distribs Linux
- GTK+/GNOME est plus jolie par défaut que Qt/KDE
- Les bindings GTK+ sont plus a jour et plus utilise que ceux de Qt
- Pas besoin d'utiliser un preprocesseur (moc)
[^] # Re: Pourquoi VCL et automake ?
Posté par xcomcmdr . Évalué à 0.
Pour l'intégration à l'OS, je viens d'utiliser qbittorrent.
Il utilisait le jeu d'icônes Gnome (WTF ?) alors que j'utilise Faenza… et tout est pourtant bon dans qtconfig.
K3b utilise lui mon jeu d'icônes (grâce à Faenza-KDE… Ça c'est pas fait tout seul ! L'utilisation de Faenza tout court amenait des icônes utilisés de façon totalement aléatoire), mais pas le sélecteur de fichiers de GTK+, ni l'explorateur de fichiers GTK+.
Smplayer, une application QT que j'utilise beaucoup, utilisait là aussi le jeu d'icônes GNOME (dans le sélecteur de fichiers GTK+ O_o ) avant que je ne fasse je ne sais plus quel manipulation en ligne de commande ou avec qtconfig. Et pour le reste il utilise ses propres icônes.
Intégration ? Quelle intégration ?
Quant à GTK, aujourd'hui il y a vala par exemple…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 6.
Bref ca depend de plein de choses. Qt de son cote propose tous les outils (depuis Qt 4.6 - decembre 2009) aux developpeurs pour le faire et ca fonctionne (teste moi meme) :
- Les thèmes d'icones : http://qt-project.org/doc/qt-5.0/qtgui/qicon.html#fromTheme
- Layout des boutons : http://qt-project.org/doc/qt-5.0/qtwidgets/qdialogbuttonbox.html#details
- Positionnement des labels dans un formulaire (oui c'est un detail presque et pourtant…) : http://qt-project.org/doc/qt-5.0/qtwidgets/qformlayout.html#details
Ce sont que quelques fonctionnalites, Qt fourmille de "goodies" pour permettre de s'integrer parfaitement aux guidelines des differents OS.
Un article a ce sujet : http://agateau.com/2011/03/26/common-user-interface-mistakes-in-kde-applications-part-4-being-gnome-friendly/
un autre : http://tkrotoff.blogspot.fr/2010/02/qiconfromtheme-under-windows.html
Pour SMPlayer (et VLC) pour connaitre le code source des 2 projets : aucune integration des icones : code en dur (a moins que ca ai change mais j'en doute).
Pour qBittorent, vue la tete de l'appli je pense que c'est pareil.
Même si tout n'est pas parfait (et c'est pas vraiment la faute de Qt - vive le monde de Linux), que propose GTK+ ?
[^] # Re: Pourquoi VCL et automake ?
Posté par xcomcmdr . Évalué à -8.
Une parfaite intégration, par exemple. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 7.
Un langage non standard qui a est utilise par 4 applications, spécifique a GNOME et qui n'est pas sorti en v1 (API qui peut changer a tout moment) ?
[^] # Re: Pourquoi VCL et automake ?
Posté par xcomcmdr . Évalué à -2.
Énormément de langages vivent très bien sans standard ISO.
Si on devait se fier à la popularité d'un langage pour juger de sa qualité, ben merde alors.
Quant à l'API, eh bien si elle est utilisée par 4 applications, c'est pas grave si elle change. :p
Quant au langage lui-même, il ressemble au C#, et permet de faire une application très rapidement (beaucoup moins de lignes qu'en C). Et puis il y a pas mal d'autres bindings avec d'autres langages pour GTK+, je ne vois pas pourquoi tu fais une fixation sur le C, le nombre de contributeurs (il y a sûrement plus de contributeurs à WPF qu'à QT, pourquoi utiliser GNU/Linux alors ? :p ), etc…
Des chiffres qui sont peut être utiles, mais dans le cas présent c'est surtout du (mauvais) marketing.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Suivant Qt depuis plus d'une dizaine d'années, j'ai surtout vu une équipe de gens très talentueux et à la barre, des personnes qui ont su imposer un très gros niveau de qualité, en particulier au niveau de l'API qui est d'une très grande clarté et cohérence.
La doc est absolument géniale, elle fourmille d'exemples, de cas d'usages, est d'une exhaustivité rare, c'est un vrai bijou.
Je réalise que mon commentaire est dithyrambique mais ce framework m'a vraiment réconcilié avec l'IHM alors que je sortais d'années de développement avec Delphi.
[^] # Re: Pourquoi VCL et automake ?
Posté par Taurre . Évalué à -2. Dernière modification le 11 février 2013 à 21:59.
Désolé, au temps pour moi.
Au contraire, c'est fort discutable comme affirmation puisqu'elle manque cruellement d'arguments. Sans remettre en cause la qualité de la documentation de Qt, je constate que celle de GTK+ fourni, entre autre, la hiérarchie des widgets, une galerie d'exemples et les informations pertinentes sur chaque objets (méthodes, attributs, signaux, etc), bref tout ce qui est nécessaire pour permettre la réalisation de programmes utilisant cette bibliothèque.
En effet, c'est assez regrettable.
Oui, GTK+ aussi hein et par extension toutes les bibliothèques graphiques…
Un non sens je ne pense pas, le paradigme objet peut être appliquer à des langages de programmation ne proposant pas d'outil spécifique à la POO (comme le C). En revanche, cela demande des efforts supplémentaires, c'est certains.
Je te l'accorde.
Il me semble que l'on sort du cadre d'une bibliothèque spécialisée dans la création de GUI. Sinon, concernant QML, GTK+ offre également un langage simplifié (en ce qui la concerne, du XML) afin de décrire simplement une interface (voir le GtkBuilder).
Sans remettre en cause tes statistiques, d'où les tires-tu ?
Parce que bon, c'est gentil de balancer des chiffres, mais il faudrait que l'on puisse savoir a quoi ils correspondent et d'où ils viennent.
Sinon, à supposer que cela représente les contributeurs et commits de GTK+ et les contributeurs et commits de Qt. D'une part, comme je l'ai dit, c'est comparé une bibliothèque et un framework, ce n'est donc pas pertinent (notamment, dans ce cas ci, en terme de volume de code). D'autre part, je ne vois pas ce que tu cherches à démontrer via cette information. Il y a moins de contributeur et de commit du côté de GTK+, et alors ?
Et ? Depuis quand c'est un gage de qualité pour un projet d'avoir des développeurs salariés ?
Hmm… Je vois juste un billet sur lequel une personne donne son avis et plusieurs commentaires allant dans son sens. C'est censé démontrer quelque chose ? Si tu le souhaites je peux faire pareil avec un billet promouvant GNOME.
Pour cela, il faudrait que je connaisse suffisamment Qt et le C++, ce qui n'est pas mon cas. D'un autre côté, mon propos n'a jamais été de dire que GTK+ était mieux ou moins bien que Qt, mais que les comparer de manière générale est absurde, car elles n'ont pas le même objectif.
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 10.
Non ce n'est pas discutable, cf http://linuxfr.org/news/libreoffice-se-met-en-4-0#comment-1430124 et http://linuxfr.org/news/libreoffice-se-met-en-4-0#comment-1430116
Absolument pas ! QML remplace les QPushButton (équivalent de gtk_button) par une syntaxe descriptive en Json.
QML c'est le même principe que XAML par exemple. Le but de QML EST de creer une interface graphique (plus facilement encore qu'auparavant).
Et oui c'est si on veut le meme principe de GtkBuilder, sauf que le format XML de GtkBuilder n'a pas été pense pour être écrit a la main (et ca change tout). Deja a l'epoque de Qt 3 (sortie en 2001) tu pouvais avoir la description de l'interface en XML et charger le XML a la volee avec un editeur graphique (QtDesigner - equivalent de Glade).
Avec QML et sa syntaxe Json tu peux creer des interfaces tres tres facilement.
Je t'ai donne le lien. Avant de choisir une librarie, un framework, whatever; toujours verifier la sante du projet, le nombre de commits, de bugs, de contributeurs…
Stackoverflow fournit egalement des graphs sur la sante d'une communaute, y'a aussi ohloh.net, github et bien sur Google trends mais c'est plus léger comme analyse :)
Fait le !
Et ba lit et interprète mieux alors ! L'auteur est Benjamin Otte, le seul dev qui est paye pour travailler full time sur GTK+.
Le lectorat de son blog s'adresse aux sympathisants GTK/GNOME et les commentaires proviennent logiquement en majorite de son lectorat. Etonnant que son lectorat trouve Qt très bon et que meme certains proposent de virer GTK+ non ? Meme le seul qui défend GTK se fait contredire !
C'est pas "juste un billet" c'est un appel de détresse du principal dev de GTK+ alors que les rats (troll - Canonical) quittent le navire.
Je vois pas pourquoi. Je veux dev une interface graphique, j'ai le choix entre Qt et GTK+. L'objectif de Qt est plus large que GTK+ mais il suffit alors de comparer Qt Gui avec GTK+.
Rien n'empeche de faire un coeur avec C++/STL/Boost ou meme C/Glib et d'utiliser Qt Gui/QML pour la partie graphique.
C'est peut etre ca le problème, expliquer que c'est absurde de comparer 2 bibliothèques graphiques parceque justement on ne l'a jamais fait… Si tu le faisais peut etre que tu trouverais ca moins absurde.
De toute facon JS/HTML/CSS va tout bouffer (Qt, GTK+, WPF, SWING) :)
[^] # Re: Pourquoi VCL et automake ?
Posté par xcomcmdr . Évalué à 4.
Plutôt crever.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi VCL et automake ?
Posté par Taurre . Évalué à -1. Dernière modification le 12 février 2013 à 11:22.
Et tu espères être convaincant en t'appuyant sur tes propres réponses et sur l'avis d'une autre personne ? C'est une blague ?
Ah ? Donc pour toi le HTML ou le XML ne sont pas fait pour être écrit à la main ?
Oui, merci, je l'ai lu. Cependant, l'article de Wikipedia ne donne pas la référence, d'où mon interrogation.
Ok, au temps pour moi, j'ai effectivement parler un peu vite.
Toutefois, je constate que le billet se concentre essentiellement sur GNOME. En effet, ce que Benjamin Otte souligne avant tout, c'est le manque de développeurs à plein temps sur le projet et le manque d'objectif pour GNOME 3. Pour le reste, il ne remet pas en cause la qualité de GTK+. D'ailleurs, pas mal d'utilisateur précise qu'ils sont passé à XFCE, or je te rappel que ce dernier est basé sur GTK+ (pareil pour Unity), de même que la plupart de ses applications (thunar, midori, etc).
Il suffit de demander :
Oui, mais ce n'est pas ce que tu fais, d'où ma remarque.
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 2.
QPushButton vs gtk_button
Objectivement es ce que la doc de Qt est plus fournie et mieux foutue que celle de GTK+, OUI OU NON ?
[^] # Re: Pourquoi VCL et automake ?
Posté par Taurre . Évalué à -4. Dernière modification le 12 février 2013 à 11:55.
Objectivement, si je passe sur la description en partie inutile du côté de Qt (merci, on sait ce qu'est un bouton), les deux fournissent les mêmes types de renseignements. Donc, tout logiquement, ma réponse est : ni l'une, ni l'autre. ;)
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Punaise, soit tu as les paupières fermées, soit tu es d'une sacrée mauvaise foi….
Qt a des défauts, mais sa doc enterre largement celle de GTK…
[^] # Re: Pourquoi VCL et automake ?
Posté par Taurre . Évalué à -3.
On m'a demandé de comparé les deux liens objectivement. Or, dans les deux cas, j'ai les informations nécessaire pour créer et utiliser un bouton. Mon analyse s'arrête là.
[^] # Re: Pourquoi VCL et automake ?
Posté par zebra3 . Évalué à -1.
Explique en quoi, parce que j'ai du mal à voir où. J'avoue que je ne suis pas développeur, mais a-priori les deux fournissent les informations nécessaires…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . Évalué à 9. Dernière modification le 12 février 2013 à 16:37.
Si tu n'es pas développeur, comment arrives-tu à savoir a priori ce qu'il est nécessaire d'aller chercher comme informations ?
Je sais bien que mon affirmation était péremptoire, mais franchement, il faut développer souvent en Qt pour comprendre en quoi cette doc est, à défaut d'être parfaite - aucune doc ne l'est - très bonne.
Elle anticipe de nombreux cas d'usages qui sortent un peu du cadre général d'utilisation des objets Qt, c'est en cela qu'elle cartonne, dans sa réponse à ces situations un peu tendues où l'on utilise un objet de façon peu courante.
En outre, elle n'hésite pas à intégrer des bouts de codes en exemple même dans les documentations de membres des classes en anticipant également les prochaines étapes (ou même transverses) de conception de notre logiciel, typiquement http://doc.qt.digia.com/qt/qmainwindow.html#restoreState
[^] # Re: Pourquoi VCL et automake ?
Posté par zebra3 . Évalué à 0.
Parce que je ne suis pas totalement idiot et que même si je ne suis pas dev, je suis quand même sysadmin et je suis quand même capable d'avoir une petite idée de la manière dont on développe un logiciel, et de ce qu'une doc doit fournir.
C'était bien pour ça que je précisais « a-priori », pour bien dire que je sais lire les docs tout en n'ayant pas l'expérience de quelqu'un de plus spécialisé.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Je réalise que ma phrase était mal formulée, je te présente mes excuses.
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . Évalué à -2.
Oh, la belle 404 !
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . Évalué à 1.
NON
Bah oui, j'ai regardé les deux, la doc de Qt est mignonne (ce qui n'est pas objectif), mais ça me prend plus de temps pour, par exemple, connaître la totalité de la hiérarchie. De quoi hérite QAbstractButton ?
Avec GTK+, on à toute l'info.
D'autres ont dis qu'il y a des exemples partout, je n'en vois aucun sur cette page, pour l'un comme pour l'autre.
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
C'est plus fin que ça avec la doc Qt, dans chaque section (public/protected/private) tu as le nombre de propriétés héritées des classes ancêtres, tu peux donc indirectement voir par exemple pour le QPushButton pour les méthodes publiques que :
21 public functions inherited from QAbstractButton
215 public functions inherited from QWidget
31 public functions inherited from QObject
12 public functions inherited from QPaintDevice
Et tu as les liens directes vers les portions des scopes (public/protected/private) pour les ancêtres.
Après bien sûr, y'a toute une page avec la hiérarchie des objets Qt, mais c'est en vrac et pas pratique à lire.
Vous cherchez vraiment la petite bête.
Le ton de Tanguy est rentre dedans, je comprends que ça irrite, mais franchement, la doc de Qt est vraiment difficilement attaquable.
Encore un exemple : http://qt-project.org/doc/qt-5.0/qtwidgets/qwidget.html
Dès qu'un comportement est un peu particulier, il est décrit en détail, avec des schémas s'il le faut, des justifications sur le pourquoi du comment, etc.
Cette doc m'a de nombreuses fois évité d'aller parcourir les forums/stackoverflow
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . Évalué à 3.
C'est exactement ça. Je n'apprécie pas les dogmes, quels qu'ils soient, et affirmer les choses de cette façon m'agace. Je me fais même parfois un plaisir de contredire des gens en argumentant, alors que je suis d'accord avec eux (je sais, je suis vicieux). Rien que pour casser leur dogme.
J'ai juste repris l'exemple donné, et n'étant utilisateur ni de cute, ni de gétéca, je pense être assez objectif, et donc, au premier coup d'oeil, je trouve les informations qui m'intéressent plus vite dans celle de gtk.
C'est bien ça, être objectif, non?
Je ne dis pas qu'elle est mal foutue, non plus, je dis juste que je ne la trouve pas parfaite. Son concurrent chez gtk à aussi ses défauts, elle est un peu fruste, mais de là à dire de façon catégorique que celle de Qt est la meilleure, il y a un fossé que je n'oserais jamais franchir.
La qualité d'une doc, elle ne se juge pas sur un exemple choisi (ça signifie que tu peux m'en donner autant que tu veux), mais sur l'ensemble de la doc ET du produit documenté. Certains produits n'ont même pas besoin de doc, ils sont leur propre doc, et ça ne rend pas la chose mauvaise pour autant.
Et pour prouver mon assertion sur les exemples, regardes: http://qt-project.org/doc/qt-5.0/qtwidgets/qwidget.html#find
Vu le nom, je devine que ça cherche quelque chose, vu les paramètres, je parie que ça renvoie un widget, concept générique mais qu'ici l'on dois sûrement tous comprendre, correspondant à un numéro d'ID. J'ai pas lue la description, et j'aurai dis la même chose en voyant le prototype dans mon auto-complétion.
Par contre, la doc à un problème, ici: quid de la complexité de cette fonction? "find" => "recherche" => consomme du temps. Alors?
C'est une preuve que cette doc n'est pas exhaustive. GTK a peut-être le même problème, j'en sais rien et je m'en fout, c'est pas le sujet (le sujet, c'est "la doc de qt est-elle irréprochable" pour moi. Dans cette branche de discussion du moins.).
D'ailleurs, si elle était exhaustive, ça ne rendrait pas forcément cette doc meilleure: trop d'informations noie celle que l'on cherche.
Et, vue la taille de la page, ainsi que la quantité de méthodes, je le dis et j'assume: y'a trop d'informations. L'interface de cette classe est trop complexe.
Je pense avoir été plutôt objectif, mais mon post est malgré tout très subjectif, et c'est normal, parce qu'on parle de la vision des choses que les gens ont, et différentes personnes ont une vision des choses différente, c'est normal. Quand cette vision est proche, un projet commun est réalisable, quand ce n'est pas le cas, on tiens une des explications de pourquoi on à autant de choix dans le logiciel libre.
Je pense que c'est une bonne chose, même si parfois (souvent) je m'interroge sur le bien fondé de la constellation de distributions autour de notre noyau préféré, mais je diverge.
Toujours est-il cela explique que moi, comme d'autres, je puisse ne pas aimer Qt, ne pas la considérer comme la librairie ultime. Je me souviens avoir lu un type qui pensais que wxwidgets aurait sa place dans le standard C++, par exemple. J'utilise cette lib pourtant, mais je lui ai répondu que, non, ce n'est pas une bonne idée (pour diverses raisons).
Pas plus qu'intégrer Qt ou Gtk serait une bonne idée, d'ailleurs.
Franchement, Qt, pour moi, c'est presque un langage à part entière, et qmake me conforte dans cette façon de penser, de la même façon que le 1er compilateur C++ générait en fait du code C, le compilateur de Qt, qmake, génère du code C++.
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Moi je le franchis, mais vraiment complètement et sans hésitation.
C'est peut-être parce que je connais les deux, je les pratique, et je prends un plaisir bien plus grand avec la doc Qt, car elle est complète et rigoureuse et m'évite des aller-retour avec des forums et des sites pour trouver de l'info.
Là franchement, y'a des mouches qui devraient mettre un peu de lubrifiant si elles veulent passer une meilleure soirée ; si tu veux une doc qui colle autant au code source de la lib, bin… lis le code source, ça tombe bien, il est libre. D'autre part, un code IHM qui cherche un widget en fonction d'un id n'a pas forcément besoin d'un algo en O(log(n)), savoir si on est dans un parcours intégral des widgets (dans le pire des cas, comme on peut le supposer) ou pas est une info d'un intérêt très relatif.
Sinon, tant que la doc ne collera pas à la ligne prêt au code source, il y aura des gens mécontents qui se serviront de ce prétexte pour avoir toujours raison dans les conversations.
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 0. Dernière modification le 12 février 2013 à 15:41.
Ça explique tout : commenter sur un sujet alors que l'on n'y connait strictement rien et espérer être crédible.
[^] # Re: Pourquoi VCL et automake ?
Posté par Taurre . Évalué à 0. Dernière modification le 12 février 2013 à 17:44.
C'est marrant, puisque tu parles de crédibilité, je te rappel que tu es le seul a n'avoir avancé aucun argument sur le sujet. On a juste eu droit à « c'est indiscutable ». Quel argumentaire flamboyant !
@guid: nous sommes bien d'accord, la documentation de Qt est claire, bien ficelée et pourvue d'exemples et d'explications en abondance. Toutefois, comme freem, je ne suis pas d'avis quelle est meilleure que celle de GTK+ (cela fonctionne aussi dans l'autre sens). En tous les cas, en ce qui me concerne, la documentation de GTK+ m'a été suffisante et précieuse pour réaliser mes projets.
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . Évalué à 2.
Hum… bon, j'en déduis qu'il faut que je dise la liste des libs graphiques que j'ai utilisées en totalité alors?
Je ne parle pas de celles que j'ai regardées en espérant trouver un outil qui me correspondrait mieux.
Pas énorme, je te l'accorde, mais niveau crédibilité, ça me permet juste d'avoir la possibilité de commenter en argumentant, en utilisant mon cerveau et mon vécu, sans trop dénigrer les autres.
Une bonne doc sera aussi accessible à un dev qui n'utilise pas (encore?) la lib, qu'a un dev qui l'utilise. Idem pour les avantages: j'ai vu les docs de C# sur la msdn, et je leur trouve des défauts. Donc je suis pas crédible?
Je vois…
Au passage, je n'ai fait que contrecarrer tes affirmation avec des arguments. Certains m'ont répondu de façon correcte, et ça peut faire avancer mon opinion (et si tu te moque de ça, alors, sois gentil, garde tes commentaires, parce qu'une discussion sers justement aux échanges d'idées, dont le but est logiquement de faire évoluer les opinions des divers participants).
Contrairement à tes "contributions".
[^] # Re: Pourquoi VCL et automake ?
Posté par barmic . Évalué à 3.
Ça sert à quoi ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi VCL et automake ?
Posté par windu.2b . Évalué à 1.
Cette séparation est très utile lorsqu'on fait du polymorphisme.
Soit la classe a, qui propose la fonction
toto(), et la classe B qui hérite de A, alors :[^] # Re: Pourquoi VCL et automake ?
Posté par barmic . Évalué à 5.
Merci je sais ce qu'est le polymorphisme. Je me demande plutôt à quoi ça sert d'avoir le détail du nombre de méthodes héritées.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Pas à grand chose mais ça peut donner une idée générale de la "pilosité" (nombre de membres) des classes ancêtres.
[^] # Re: Pourquoi VCL et automake ?
Posté par BAud (site web personnel) . Évalué à 5.
ah d'accord. Après la granularité, ya la pilosité. Vous bossez avec un microscope électronique pour sodomiser les drosophiles ?
sbon, hein j'ai mon business loto pas loin
~~> [ ]
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Oui, savoir si une classe est "poilue" quoi, c'est de l'argot de programmeur (vois pas le rapport avec le chipotage pour le coup)
[^] # Re: Pourquoi VCL et automake ?
Posté par groumly . Évalué à 3.
Nan, mais vous pouvez aller vous rhabiller avec vos docs:
http://developer.apple.com/library/ios/ipad/#DOCUMENTATION/UIKit/Reference/UIButton_Class/UIButton/UIButton.html
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Je dois avouer que la séparation des propriétés/méthodes en catégories fonctionnelles est très séduisante.
De plus, la présentation est claire, simple, pas trop verbeuse.
Ils sont allé encore plus loin que Qt.
[^] # Re: Pourquoi VCL et automake ?
Posté par groumly . Évalué à 1.
Ouais, ya des trucs relou quand meme, notamment dur de trouver les properties/messages definies sur les super class.
Leur hierarchie est tres peu profonde, donc en pratique, ca va, mais quand tu cherches un truc un peu exotique sur nsresponder, ca peut devenir relou.
On trouve aussi quelques bijoux d'apple speak dedans, a base de "nscache peut ejecter des objets, ou pas, et chercher pas a savoir lesquels (ou pas)".
Les proramming guides notamment sont particulierement bien foutus, et ils ont pas mal de docs approfondies plutot poussees. Bref, ya de tout pour tout le monde, et c'est plutot bien organise.
Niveau qualite d'api, la par contre, ca poutre tout, objc est d'une elegance extreme pour tout ce qui est UI et NextStep avait tellement bien pense le bouzin que les autres sont encore loin derriere - mais on va me traiter de fan boy encore une fois.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . Évalué à -1.
Allez, pour le fun:
Avantages de GTK sur Qt, vus par quelqu'un qui n'utilise ni l'un, ni l'autre, mais utilise C++ en permanence:
Ces 3 points cassent tout ton argumentaire, sauf le nombre de gens payés. Mais, franchement, ce n'est pas une référence pour moi. Je ne crois pas que quelqu'un soit payé pour faire la SDL, et jusqu'a preuve du contraire, il s'agit d'une bonne lib.
Pour l'API C, voici quelques avantages contre le C++ (que je préfère pourtant largement au C):
PS: je considère que qmake c'est de la bidouille.
[^] # Re: Pourquoi VCL et automake ?
Posté par Shuba . Évalué à 9.
Déja c'est pas qmake le préprocesseur de Qt, c'est moc. qmake est un système de build, qui a l'intérêt d'être assez simple pour de petits projets, mais qui n'est pas super drôle à utiliser pour de plus gros projets. Et surtout, il permet d'appeler moc tout seul.
Certainement un très bon point pour GTK+, même si Qt fait pas mal de choses pour garder une ABI la plus stable possible (idiome PIMPL, plus sans doute d'autres astuces que je ne prétends pas connaitre).
Après la popularité de Qt fait qu'il a des bindings dans de très nombreux languages, ce qui réduit le désavantage versus l'API C de GTK+. Cependant il est sûr que sur des langages de niche on trouvera plus souvent GTK+
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 1.
Je viens de le retrouver !!!
http://blog.mardy.it/2012/05/from-g-to-q.html (et la source qui m'a donne le lien : http://blogs.kde.org/2012/06/06/de-icaza-were-dropping-xaml-qmls-human-friendly )
Grosso modo le monsieur a code pendant 10 ans en utilisant GObject et GTK+, après quelques temps d'adaptation difficile, il est devenu un fanboy de Qt.
[^] # Re: Pourquoi VCL et automake ?
Posté par Loïc Ibanez . Évalué à 0.
fltk, fltk, fltk, fltk !
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . Évalué à 1.
http://en.wikipedia.org/wiki/List_of_widget_toolkits#Cross-platform
Histoire de.
J'ai pas compté, mais à vue de nez, je dirais, une 20aine?
Il ne faut pas confondre "candidats pas nombreux" et "nombreux candidats peu connus" ;)
[^] # Re: Pourquoi VCL et automake ?
Posté par djano . Évalué à 2.
C'est certainement vrai aujourd'hui mais ça l'était sans doute beaucoup moins lorsque StarOffice avait été créé en 1984: http://en.wikipedia.org/wiki/Staroffice#History . Qt n'a commencé son existence qu'en 1992 et KDE n'a été lancé qu'en 1996, Donc Gnome et GTK+ on existé seulement après 1996.
Ensuite, le poids de l'historique fait que personne ne s'est vraiment penché sur moderniser certains aspects du code source à cause de l'investissement à réaliser, du risque associé au changement, etc. Et la situation traîne jusqu’à aujourd'hui
[^] # Re: Pourquoi VCL et automake ?
Posté par Frank-N-Furter . Évalué à 9.
Tu as déjà compilé des applis GTK sous OSX, et fait en sorte qu’elles utilisent Quartz et pas X11 pour s’afficher?
Depending on the time of day, the French go either way.
[^] # Re: Pourquoi VCL et automake ?
Posté par jypaigue . Évalué à 5.
Pourquoi gmake et pas automake ?, le problème a été étudié…
Pourquoi pas Qt ? Je pense qu'il faut considérer le rapport quantité de travail / gain. C'est vrai quoi, est-ce que modifier plusieurs millions de lignes de codes pour ajouter une dépendance supplémentaire c'est vraiment une bonne idée ? Et puis pourquoi Qt ? wxWidget est bien aussi…
Bon courage pour montrer que faire un tel changement en vaut la peine…
[^] # Re: Pourquoi VCL et automake ?
Posté par xcomcmdr . Évalué à 8.
Ah non merci! C'est ultra moche sous GNU/Linux !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . Évalué à -1.
Hum… donc, Gtk est ultra moche sous linux, selon toi?
Non, parce que bon, WxWidgets, sous linux, se base sur GTK… En tout cas, je ne connais aucune application utilisant le port pour X11, vu que celui-ci n'est pas complet il me semble, et je n'ai pas non plus vue d'appli utilisant le port motif.
Sûrement parce que Debian utilise le port Gtk, cela dis. Après, si on compile WxWidgets pour utiliser Motif ou X11, on peut pas se plaindre que c'est moche, mais plutôt encenser une lib qui est capable d'utiliser plusieurs toolkits sans piper mot.
Pour rappel, l'esprit de WxWidgets, c'est d'utiliser les composants standards du système, et s'ils n'existent pas, de les implémenter.
Donc, sur windows, ils se basent sur l'api win32, et, comme beaucoup (ref needed, je sais) considèrent que gtk est l'api ""standard"" (à prendre avec beaucoup de pincettes, hein, je veux pas fâcher les utilisateurs de KDE) le port qui me semble le plus utilisé sous linux est celui basé sur Gtk.
Quant aux 5 ans d'avance de Qt… ça doit être pour ça qu'a part pour l'IDE fait exclusivement pour lui, QtCreator, que je n'apprécie d'ailleurs pas du tout, raisons esthétiques:
il est très pénible à intégrer?
Ah, j'imagine que KDevelop aussi dois le supporter correctement.
Ensuite, les 5 ans d'avance, j'aimerai bien voir ça, avec des preuves et une argumentation, parce que je ne considère pas que forcer un utilisateur à utiliser des fonctionnalités non standard, nécessitant une pré-compilation, pour dessiner une simple interface graphique soit être en avance.
D'ailleurs, si c'était 5 ans d'avance, j'aimerai qu'on m'explique, par exemple, pour std::vector est ré-implémenté. Par exemple.
Après… WxWidgets à des défauts, oui, c'est vrai. Mais il faut les citer. Par exemple, la version stable actuelle compile en dur les gestionnaires d'évènement, ce qui oblige à des contournements un peu dégueu pour avoir un truc dynamique. On peut aussi citer l'architecture autour des barres de menu, qui laisse quelques peu à désirer.
Mais voila, il faut au moins argumenter, et, malgré ces points, ça reste un framework important qui vois la portabilité plus dans l'esprit C++, en utilisant ce qui existe, plutôt que dans l'esprit Java, en ré-implémentant tout, comme Qt fait.
[^] # Re: Pourquoi VCL et automake ?
Posté par xcomcmdr . Évalué à 7.
Ben non vu que j'utilise Xfce. La dernière fois que j'ai lancé une application wxwidgets, ça ressemblait à une application Tk/Tcl ou à une application GTK3 sans thème. De quoi vomir sur son écran. Et c'était aussi difficile à utiliser du coup (forcément avec plein de vomis sur l'écran… ;-) ).
Cependant j'viens d'installer et de lancer gtimelapse, et là cela s'intégrait bien à mon environnement (le thème gtk était respecté, on aurait pas pu dire).
Ceci dit je n'aime pas trop me demander à chaque fois que j'installe une application wxwidgets si elle va être moche (cf. utiliser le backend X11 ?) ou non…
Au moins avec Tcl/Tk, ce sera moche à tous les coups, et l'intégration sera inexistante.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . Évalué à 0.
Je veux bien connaître le nom de l'appli moche en question?
Si ça se trouve, tu es juste tombé sur une exception, vu que tous les toolkit permettent de ne pas respecter le thème du système.
Après… des applis utilisant wxwidget, je peux en citer 2-3, et elles respectent toutes le thème: code::blocks (bon, pour être exact, ça c'est amélioré sur cet IDE, à un moment les thèmes sombres étaient… hum… mais je pense que c'est dû au fait qu'ils aient refait la roue pour certaines widgets. La, on sait à qui reviens la faute.), amaya, et filezilla.
Avec aucune de ces applications je n'ai eu de soucis de thème, même si j'admets ne pas passer 30 ans à bidouiller mes thèmes :) (en général, je me contente de celui qui prend le moins de place possible)
D'ailleurs, il faudra que j'installe un outil pour changer le thème gtk sur ma machine, celui par défaut étant trop gourmand en place à mon goût.
Pour tcl/tk, il y a pire je crois: jettes un oeil à xpaint ;) (je ne suis même pas sûr qu'il y ait un toolkit derrière…)
Mais il a au moins l'avantage d'être utilisable par n'importe qui et d'être d'une légèreté à toute épreuve.
PS: il faudra un jour qu'on me dise exactement ce que l'on entend par "intégration". Juste l'apparence graphique?
[^] # Re: Pourquoi VCL et automake ?
Posté par tanguy_k (site web personnel) . Évalué à 6.
http://linuxfr.org/news/libreoffice-se-met-en-4-0#comment-1430091
GTK+ : 210 contributeurs pour 3000 commits/an, Qt : 400 contributeurs pour 15780/an
Il y a UN développeur payé pour travailler sur GTK+ et c'est même pas le cas pour la GLib !
Encore et tjrs le même argument a la con. Oui le préprocesseur c'est chiant, mais ça les slots/signaux apportent tellement ! De plus GTK+ est bourré de macros dans tous les sens bien éloignées de la philosophie du C.
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . Évalué à 2.
Peut-être que si cet argument reviens tout le temps, c'est qu'il est valide?
Oh que oui, c'est chiant, parce que c'est infernal à utiliser avec un IDE qui n'est conçu pour Qt du coup.
Quant à l'intérêt des signaux, je sais pas, pourrais-tu me dire, code comparatif à l'appui, ce que ça apporte?
Après, pour les macros… ouai, je suis d'accord, j'aime pas non plus. Mais de nos jours, on peut faire des choses très propres en C++ sans macros, et sans pour autant imposer un outil de pré-compilation.
Au niveau de la philosophie du C: ref needed.
[^] # Re: Pourquoi VCL et automake ?
Posté par ariasuni . Évalué à 5.
Bah ça évite la maintenance de leur propre toolkits (ne pas réinventer la roue carré toussa), ça leur permet de faire des interfaces en QML exploitant la puissance du processeur graphique (je pense que ça peut être super pratique pour les gros documents pleins d'images, de diagrammes, etc), de pouvoir faire tourner LibreOffice sous Android sans Xorg, ça permet une intégration visuelle plus poussée de LibreOffice dans les environnements (bref le rendre moins moche), de rendre son lancement plus rapide si on a déjà chargé Qt en mémoire (si on utilises VLC et/ou KDE)…
Bon c'est sûr que c'est un sacré boulot, mais je pense qu'à long terme ça en vaut largement la peine. Maintenant si c'est pour se retrouver avec un truc inutilisable pendant plusieurs versions, non (traduction: au moins attendre qu'il ai à peu près fini de faire le ménage). Mais j'ai peu d'espoir, Firefox aussi aurait pu choisir cette voie, mais en fait non.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pourquoi VCL et automake ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Il faut aussi voir si Qt est meilleur VCL, ce qui n'est pas évident vu les widgets complexes qu'on voit dans LibreOffice.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi VCL et automake ?
Posté par Guillaume Denry (site web personnel) . Évalué à 9.
Il faut surtout se demander si on peut les mettre au même niveau, Qt est très générique et VCL a l'air de loin (mais je peux me tromper) d'être une lib métier dédiée à la suite bureautique, VCL offre peut-être des outils qui seraient considérés comme appartenant à une couche au dessus de Qt, bref, est-ce vraiment comparable ? Sans compter que VCL a l'air d'être uniquement dédiée au graphique là où Qt offre beaucoup plus de possibilités.
De toute façon, qui a envie d'évaluer le temps que ça prendrait de convertir la VCL a Qt ? Qui a envie de se demander s'il faudrait utiliser uniquement QtGui ou bien plus de modules pour le coeur de l'application ? C'est très difficile de bouger l'existant, l'inertie a l'air énorme, et je ne vois pas qui trouverait ça trippant de se dire "hé ho, et si je m'amusais à adapter LibreOffice à Qt en ré-écrivant tous les composants métier de l'application avec !"
[^] # Re: Pourquoi VCL et automake ?
Posté par ariasuni . Évalué à 3.
Je ne pense pas que ça soit compliqué de faire ce qu'ils font avec VCL avec Qt, cf. Calligra. Néanmoins je suis d'accord, il est clair, que tout réécrire chez LibreOffice ça serait un immense chantier… Rien que de passer de Qt3 à Qt4 ou de GTK2 à GTK3 est chiant (en tout cas il semblerait), alors passer carrément de VCL à Qt…
Firefox-qt ça existe et c'est hautement instable, la dernière version «stable» publiée est la 14… Donc je vois mal faire ça pour toute une suite bureautique. Même si comme je disais les bénéfices à long terme serait énormes!! (NOTE: de plus les interface sont très faciles à faire en QML il parait)
Enfin bref, tout ça pour dire que ça serait bien, mais que ça ne va probablement pas arriver. Ou en tout cas pas avant plusieurs dizaines d'années.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pourquoi VCL et automake ?
Posté par djano . Évalué à 3.
Je pense surtout qu'ils on d'autres chats a fouetter pour l'instant. On dirait que changer le toolkit graphique n'est absolument pas la priorité. Ils sont déjà en train de changer les classes de chaînes de caractères et la façon de coder l'UI entres autres. Sana compter le reste, ça fait déjà pas mal!
[^] # Re: Pourquoi VCL et automake ?
Posté par vida18 . Évalué à 6.
Je pense aussi que c'est pour éviter de diviser la communauté.
Genre "Nous on continue à développer notre propre toolkit. Si vous voulez du Qt, dans ce cas contribuez à l'amélioration de Calligra."
http://linuxfr.org/news/calligra-2-6
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . Évalué à 0.
Mais plus lent si on ne les utilise pas.
[^] # Re: Pourquoi VCL et automake ?
Posté par ariasuni . Évalué à 1.
Mof, je suis pas sûr que ça ai un grand impact si on retire VCL. Surtout avec Qt5 en fait.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pourquoi VCL et automake ?
Posté par spider-mario . Évalué à 2.
Plus lent que le toolkit perso de LibreOffice ? Pourquoi serait-ce le cas ?
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . Évalué à 0.
Au hasard: Qt est peut-être plus lourd. Vu que je n'arrive pas à trouver la lib utilisée par OOo et LO, je ne peux bien sûr pas confirmer.
Après, je dois dire que les applications Qt installées sur ma machine, il faut que j'aie vraiment besoin d'elles. (Mais cet "argument" de mon usage est bidon, puisque très subjectif.)
[^] # Re: Pourquoi VCL et automake ?
Posté par Sytoka Modon (site web personnel) . Évalué à -3.
Qt est-il piloté par une fondation libre ?
Je pense que lorsqu'on a subit le joue d'Oracle et qu'on arrive enfin à former une communauté libre autour de son projet, qu'on essaye de virer Java dont le pilotage à toujours posé des problèmes, on n'a pas forcément envie de se mettre un autre fils à la patte quel que soit la qualité de l'environnement, notamment si ce n'est pas un aspect critique du projet.
[^] # Re: Pourquoi VCL et automake ?
Posté par claudex . Évalué à 10.
Qt a récemment migré vers un système d'open governance où d'autres personnes que les employés de (Trolltech|Nokia|Digia) ont leur mot à dire. Je ne sais plus si la migration est déjà terminé, mais c'est le but. Le site web en est le reflet car il n'est plus le sous domaine d'un autre mais est bien à part et on retrouve la version commerciale chez Digia.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi VCL et automake ?
Posté par kadalka . Évalué à -4.
automake c'est libre (GNU pour être précis) et ne dépend pas d'autrui.
CMake dépend de quelques personnes…
Sur le plan stratégique [sur le long terme donc] automake est préférable à CMake.
Souvenez vous, ReiserFS s'est arrêté dès que "l'unique developpeur" n'était plus là, malgré sa qualité.
EXT lui continue d'exister et maintenant arrive BTRFS…
C'est du simple bon sense [common sense] :-)
# Édition collaborative
Posté par ParaDoxe . Évalué à 10.
Ils travaillaient pas sur l'édition collaborative de documents en utilisant XMPP?
# code nettoyé ?
Posté par antistress (site web personnel) . Évalué à 4.
A t-on idée du nombre de lignes de code retirées/ajoutées ?
[^] # Re: code nettoyé ?
Posté par paco81 . Évalué à 10.
Donc, nettoyé, peut être… raccourci, on dirait pas =)
[^] # Re: code nettoyé ?
Posté par coid . Évalué à 9. Dernière modification le 08 février 2013 à 18:48.
Le gros nettoyage, c’était surtout avant la 3.6, même si ce n’est pas encore fini. La version 4 amorce à présent la refonte de l’API et du code interne.
http://people.gnome.org/~michael/blog/2012-08-08-libreoffice-3-6-0.html
[^] # Re: code nettoyé ?
Posté par antistress (site web personnel) . Évalué à 3.
merci paco81 & coid
# I See You!!!
Posté par cosmocat . Évalué à 8.
Je sais pas s'il y a un pare-feu dans cette version, mais apparement, ils ont mis une option Big Brother!
[^] # Re: I See You!!!
Posté par Frédéric Perrin (site web personnel) . Évalué à 4.
Oui, il y a pare-feu.
http://workshop.netfilter.org/2010/wiki/images/f/f2/Oowall.odp
[^] # Re: I See You!!!
Posté par steph1978 . Évalué à 3.
C'est très bon.
Par contre il ne montre pas comment on crée les règles de filtrage.
# du style pour les styles
Posté par goom . Évalué à 7.
Ce qui manque le plus à libreoffice ce sont des styles qui en ont. Pour comparer régulièrement avec MS-Office, les styles prédéfinies proposés de ce dernier sont plus nombreux et permettent facilement de faire des mises en page variées (et évidemment comme c'est la suite office la plus répandue tout le monde finit par avoir les mêmes mises en formes :D )
Autrement, le librelogo ça a l'air vraiment sympa, surtout avec des enfants.
[^] # Re: du style pour les styles
Posté par Jean-Baptiste Faure . Évalué à 8.
J'ai l'impression que tu confonds liste des styles prédéfinis (accessible avec le gestionnaire de styles, F11) et la richesse en modèles de documents fournis par défaut.
Pour les styles prédéfinis, l'objectif actuel est plutôt d'en réduire le nombre afin d'en faciliter l'utilisation. On peut déjà masquer ceux qu'on ne veut pas utiliser.
Pour les modèles, chacun peut en produire et les partager sur le dépôt https://templates.libreoffice.org. C'est à la portée de n'importe quel utilisateur averti (qui sait faire un modèle), donc n'hésitez pas à vous lancer, aucune compétence de développeur n'est nécessaire.
La prochaine étape du développement du nouveau gestionnaire de modèles permettra d'accéder directement à un dépôt distant comme celui-là. Pour le moment cette possibilité n'est accessible qu'en activant les fonctions expérimentales.
[^] # Re: du style pour les styles
Posté par goom . Évalué à 5.
Je parle bien des styles prédéfinis et notamment des jeux de styles qu'on peut avoir dans word. Ils sont plus nombreux et plus harmonieux pour une mise en page rapide sans devoir se prendre la tête à définir tous les styles.
[^] # Re: du style pour les styles
Posté par zebra3 . Évalué à 4. Dernière modification le 11 février 2013 à 09:38.
Bof. Ils ont beau être plus beaux (je dirais plutôt « tape à l'œil » m'enfin ce n'est que mon point de vue) de toute façon personne ne s'en sert. Tout le monde utilise le formattage direct qui rend le tout plus laid et moins cohérent.
Pire, il y a encore des gens pour utiliser « Comic Sans MS ».
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: du style pour les styles
Posté par saltimbanque (site web personnel) . Évalué à 3.
Les styles dans Libre Office, voilà ce qui me dérange le plus. Certes mes besoins ne sont pas élevés, je n'utilise même pas de macro dans calc, m'enfin, justement!, le style c'est une fonctionnalité qui vient vite lorsqu'on utilise une suite bureautique!
[^] # Re: du style pour les styles
Posté par Jean-Baptiste Faure . Évalué à 2.
Où est le problème précisément ? Tu peux te créer un modèle par défaut comme tu le souhaites. Et tu peux créer tous les modèles de document que tu veux si ceux qui sont disponibles sur le dépôt LibreOffice ne sont pas à ton goût.
[^] # Re: du style pour les styles
Posté par claudex . Évalué à 6.
Faire un thème c'est bien, mais il faut un peu avoir des compétences en design et c'est long. Je pense que le problème, c'est de ne pas avoir de choix qui plait dans les templates.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: du style pour les styles
Posté par jihele . Évalué à 3.
Je trouve les styles bien plus pratiques à utiliser dans LibreOffice que dans MS Office (dans MS Office, ça relève du parcours du combattant et je ne suis pas surpris que mes collègues ne les utilisent pas).
Dans LibreOffice, la dernière fois que j'ai regardé, je n'ai pas trouvé de façon simple d'exporter/importer un jeu de styles. J'entends pas là une fonction qui permettrait d'exporter l'ensemble des styles (ou un sous-ensemble) et de l'importer dans un document existant.
Ça doit pourtant bien exister. On peut appliquer un modèle à un document existant, non ? On est pas obligé de partir du modèle ? (Attention je mélange allègrement modèle, jeu de styles, etc, mais je pense que vous comprenez l'idée.)
[^] # Re: du style pour les styles
Posté par lolop (site web personnel) . Évalué à 2.
Non, tu lèves bien un manque, la gestion des styles en tant que tel comme entités que l'on puisse manipuler de façon avancée (ou alors je n'ai pas cherché au bon endroit - dans mon LibreOffice 3.5.4.2, ça a peut-être changé avec la version 4).
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: du style pour les styles
Posté par Jean-Baptiste Faure . Évalué à 5.
Sur ta version ça se trouve dans le gestionnaire de modèles. Tu aurais trouvé en posant la question sur la liste d'entraide des utilisateurs de LibreOffice : http://fr.libreoffice.org/assistance/
Pour la version 4 c'est un peu différent : le nouveau gestionnaire de modèles n'est pas encore tout à fait stabilisé.
Sinon pour appliquer un autre modèle à un document existant il y a une extension qui fait ça : http://extensions.libreoffice.org/extension-center/template-changer
[^] # Re: du style pour les styles
Posté par lolop (site web personnel) . Évalué à 2.
Cool.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: du style pour les styles
Posté par dave_null (site web personnel) . Évalué à 0.
Dans Pages d'Apple, les styles sont bien mieux mis en avant, et ça n'a rien à voir à l'utilisation.
[^] # Re: du style pour les styles
Posté par dave_null (site web personnel) . Évalué à 0.
C'était une remarque pour dire que la remarque «libreoffice fait mieux que ms office» n'est pas très utile sachant que c'est deux logiciels mauvais pour les styles, avec comme élément comparatif le logiciel d'apple.
[^] # Re: du style pour les styles
Posté par Jean-Baptiste Faure . Évalué à 3.
Est-ce que tu as une fois au moins posé une question sur la liste d'entraide utilisateurs pour apprendre à te servir des styles dans LibreOffice ?
C'est un peu léger, je trouve, de porter des jugements définitifs de cette façon.
Puisque apparemment tu as des idées sur la question, je t'invite à venir proposer sur la liste discuss-fr des améliorations de la gestion des styles dans LibreOffice. Merci pour ta contribution.
[^] # Re: du style pour les styles
Posté par saltimbanque (site web personnel) . Évalué à 2.
D'accord et pas d'accord : faire un retour argumenté et contributif, mille fois oui, tout en gardant en tête que ce n'est pas forcément évident, qu'on en a pas forcément les compétences - on ne s'invente pas ergonome. Essayer, oui, pourquoi pas.
Quant à la liste d'entraide, je ne doute pas que ce soit une communauté magique, mais le problème n'est-il pas que les styles dans LO sont difficiles d'accès, peu "découvrables"? Je n'ai pas forcément envie de créer deux mille templates, juste d'avoir une dizaine de trucs prédéfinis à portée de main.
J'avais lu un tuto ou deux, et en tout cas à l'époque, ce qui commençait par "appuyer sur F11" m'avait dépanné mais en laissant en goût amer - du genre "trop d'efforts pour ce que je veux".
Le manque n'est pas forcément la logique LO qui serait cassée. Par exemple, j'ai vu que cette version apporte une prévisualisation, plus que bienvenue, qui résout déjà une partie du problème. Il s'agit plus de travail à faire, d'améliorations connues et déjà désirées par des développeurs, que de bugs ignorés.
[^] # Re: du style pour les styles
Posté par BAud (site web personnel) . Évalué à 3.
En gros, faire revenir le sélecteur de styles, ce qui serait une bonne idée àmha (c'était la killer feature de OOo). Enterrée par les utilisateurs au travers de nombreux rapports de bugs :/ (malheureusement /o).
En même temps, tout le monde ne connaissait pas SGML à l'époque, il faut croire (et pourtant, malgré quelques limites, c'était en avance, pas pour la lettre à mamie, mais surtout sur la doc' technique…).
[^] # Re: du style pour les styles
Posté par Jean-Baptiste Faure . Évalué à 3.
Qu'est-ce que tu appelles le "sélecteur de styles" si ce n'est pas le styliste (Style et Formatage / F11) ?
[^] # Re: du style pour les styles
Posté par dave_null (site web personnel) . Évalué à 1.
Je me sers des styles de LibreOffice, que je préfère pour ses formats et son cotés libre.
Je retiens l'invitation pour participer aux discussions sur les styles, et quand je pense que je viendrais discuter à l'occasion, de manière plus constructive.
# Firewall.
Posté par Gof (site web personnel) . Évalué à -3.
Est-ce que LibreOffice possède un pare-feu ?
[^] # Re: Firewall.
Posté par ariasuni . Évalué à 2.
Oui, on l'a conservé lors du passage à LibreOffice. En revanche je n'ai pas eu le temps de me renseigner si le pare-feu gérait l'IPv6.
Bon, je retourne potasser l'HADOPI 3.
Cordialement,
Christine Albanel, ministre de l'inculture.
Écrit en Bépo selon l’orthographe de 1990
# RTF
Posté par O'neam Anne . Évalué à -4.
RTF comme dans Read The Formula ?
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
# Version conseillée aux entreprises
Posté par Jean-Baptiste Faure . Évalué à 10.
Contrairement à ce qui est indiqué à la fin de la dépêche, il n'est pas conseillé aux entreprises d'attendre la 4.1.
Ce que j'ai indiqué sur le site francophone c'est d'attendre, pour une utilisation en production, une prochaine mise à jour corrective, c'est à dire la 4.0.1 mais plutôt la 4.0.2 qui devrait être publiée dans 2 mois (https://wiki.documentfoundation.org/ReleasePlan#4.0_release).
La version 4.1 (précisément la 4.1.0) est prévue pour dans 6 mois (semaine 30).
JBF
[^] # Re: Version conseillée aux entreprises
Posté par patrick_g (site web personnel) . Évalué à 5.
Tu as raison, j'ai corrigé la news.
# icône / logo ??
Posté par mike.simonson . Évalué à 5.
Sans vouloir faire mon inculte, quelle est le dernier logo dans la liste ?
C'est pour les extensions ?
Impossible de trouver ce logo sur le site de LibreOffice ou pas évident en tout cas.
[^] # Re: icône / logo ??
Posté par j (site web personnel) . Évalué à 3.
C'est pour les extensions ?
Il me parait plus probable que ce soit une allusion à l'éditeur de macros.
# Superbe logiciel mais mauvaise "Impress"ion.
Posté par BD . Évalué à 3.
Dans ce bel édifice qu'est devenu LibreOffice, le module Impress reste loin derrière la concurrence dans la gestion du multimédia. Quel que soit le système, il est nécessaire d'installer des codecs pour lire une vidéo, et la gestion LibreOffice de ce type de média est des plus étrange : il faut en programmer l'arrêt pour que la vidéo ne se lance pas automatiquement en même temps que la diapositive, et si on programme son démarrage, il ne faut pas cliquer sur l'image qui la représente mais à côté pour la lancer.
Cette logique me rappelle celle du bouton démarrer de Windows qui servait à l'arrêter…
I have a dream : un module impress qui permettrait de piloter des extraits audio et vidéo au 10ème de seconde près, qui laisserait le présentateur libre de démarrer et arrêter son média quand bon lui semble et d'en reprendre la lecture sans recharger la diapo, peut-être avec une intégration d'un plug-in genre VLC ? Bref un module Impress qui permette à l'utilisateur d'illustrer avec la plus grande souplesse son propos par du son, des images animées pour donner du sens à son intervention avec autre chose que des tableaux de chiffres, des textes ou des images fixes.
Certes la critique est facile est l'art est difficile : je tiens à redire mon admiration pour le travail accompli, mais cette fonctionnalité que je suggère ferait bien des heureux dans le monde de l'éducation, où l'on doit apprendre aux élèves à donner du sens à l'univers audio-visuel qui fait leur quotidien. On ne peut cependant pas leur demander d'investir dans des logiciels coûteux, fermés et souvent incompatibles avec ceux qu'ils trouvent dans leurs établissements.
# 1ère mise à jour corrective publiée
Posté par Jean-Baptiste Faure . Évalué à 1.
Bonjour,
LibreOffice 4.0.1, première mise à jour corrective de la branche 4.0, a été publiée aujourd'hui : http://nabble.documentfoundation.org/The-Document-Foundation-annonce-LibreOffice-4-0-1-tp4041941.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.