• # La démo de WebODF

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

    Pour ceux qui veulent voir ce que ça donne dès aujourd'hui, une démo de WebODF est en ligne à cette adresse :

    http://www.webodf.org/demo/ci/webodf-0.4.2-1278-gb5d1fc9/editor/localeditor.html

    Rappel : Comme c'est du web vous pouvez tester ça en un clic. C'est pas du Qt quoi.

    Avis perso : C'est pas parfait et super stable, mais ça fait son travail.

    • [^] # Re: La démo de WebODF

      Posté par  . Évalué à 9. Dernière modification le 24 octobre 2013 à 09:47.

      vous pouvez tester ça en un clic. C'est pas du Qt quoi.

      T'as raison, si c'était du Qt il faudrait au moins deux clics, l'un pour installer l'autre pour lancer le logiciel.

      • [^] # Re: La démo de WebODF

        Posté par  (site web personnel) . Évalué à -1. Dernière modification le 24 octobre 2013 à 09:56.

        Toute la subtilité de ta réponse est dans le «au moins» :-)

        D'ailleurs, aurais-tu un exemple de démo en Qt qui se teste en 2 clics ? Je suis curieux.

        • [^] # Re: La démo de WebODF

          Posté par  . Évalué à 9. Dernière modification le 24 octobre 2013 à 10:10.

          aurais-tu un exemple de démo en Qt qui se teste en 2 clics ? Je suis curieux.

          C'était juste une petite pique parce que je pense que ton argument est fallacieux, aussi je me permets de répondre avec un autre argument fallacieux sur un ton humoristique. Pour répondre à ta question j'installe et je lance mes applications Qt en zéro clics à l'aide d'un clavier.

          Indépendamment de cela, je pense que ton argument n'est pas correct.

          1. Tu n'avais aucune raison de citer Qt. Peut-être que tu voulais critiquer le code natif, mais ce n'est pas ce que tu as fait.
          2. Tu peux parfaitement développer tes applications web en Qt, et même avec qtdjango si tu veux.
          • [^] # Re: La démo de WebODF

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

            Oui bon, t'as gagné pour l'astuce du clavier.

            J'ai cité Qt car c'est en rapport à un fil de commentaire sur un journal précédent ou j'ai eu le malheur de parler de HTML au lieu de Qt.

            • [^] # Re: La démo de WebODF

              Posté par  (site web personnel) . Évalué à 4. Dernière modification le 24 octobre 2013 à 12:02.

              ou j'ai eu le malheur de parler de HTML au lieu de Qt.

              Pour ceux pas au courant, il parlait de HTML pour une application d'analyse de trames réseau, le truc où tu dois dans tous les cas installer le logiciel pour choper les trames réseaux et ui afficher plein de lignes très très rapidement (chiche de faire pareil en HTML5!), alors que la on parle d'un truc qui demande quelques cycles CPU et 1 fps (de l'édition de texte, que c'est grand!)
              sans compter que comme l'a dit JGO, Qt n'a absolument rien à voir avec le sujet ici, c'est jsute une attque gratuite contre ce Qt détesté on ne sait pas trop pourquoi.
              Bref, une belle démonstration sur comment tout mélanger sans essayer de comprendre le hic.

          • [^] # Re: La démo de WebODF

            Posté par  . Évalué à 2.

            avec qtdjango si tu veux.

            Ou mieux avec http://www.treefrogframework.org car c'est quand meme classe de compiler son site web :)

            • [^] # Re: La démo de WebODF

              Posté par  . Évalué à 2. Dernière modification le 25 octobre 2013 à 10:32.

              Merci pour le lien. Au passage, pour illustrer les gains que ce framework Qt peut apporter à une application serveur, je me permets de citer leur image de benchmark (nombre accès à une base de données ; en transactions par seconde) :

              Comparaison de performance treefrogframework. Le code natif réalise 10x plus de transactions par seconde que PHP

              source : http://www.treefrogframework.org/documents/comparison-of-performance

              • [^] # Re: La démo de WebODF

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

                C'est pas aussi simple que ça : https://docs.google.com/spreadsheet/ccc?key=0AlpTorSDNQjbdEpWTURuRE5TaEtNN0FYbXU5Vl92RUE#gid=0

                Ce que je vois, c'est que sur le benchmark forcément très représentatif d'un GET, treefrogframework est effectivement dix fois plus rapide que CakePHP.

                Mais le code PHP pas beau (https://github.com/ichikaway/CakePHP-PerformanceCheckSample/blob/master/php/view.php) est plus rapide que treefrogframework.

                Et l'autre élément qui est donné dans l'article, c'est que CodeIgniter se défend pas mal (seulement 2 fois plus lent que treefrogframework).

                Ensuite, c'est PHP-APC qui est utilisé. Avec Hip-Hop PHP de facebook (qui compile du PHP en C++), ça devrait être encore plus perfomant.

                Et juste une dernière remarque, même si PHP est 10 fois plus lent que ce framework, vu le prix et la difficulté de trouver des développeurs compétents en C++/Qt, par rapport aux développeurs PHP, je pense que la plupart des équipes préfèrent dépenser plus en infrastructure serveur.

                • [^] # Re: La démo de WebODF

                  Posté par  . Évalué à 3.

                  Et juste une dernière remarque, même si PHP est 10 fois plus lent que ce framework, vu le prix et la difficulté de trouver des développeurs compétents en C++/Qt, par rapport aux développeurs PHP, je pense que la plupart des équipes préfèrent dépenser plus en infrastructure serveur.

                  C'est le même raisonnement qui fait qu'on a plein d'applis Java qui se traînent sur des quadricœurs avec 16Go de RAM.
                  Coder en Java c'est "simple". Il y a beaucoup de codeurs Java, et du coup le coût du codeur est bas.
                  C'est pareil pour le PHP.

                  Les 2 langages sont très accessibles, y compris aux codeurs du dimanche, et c'est tout leur problème sur le marché professionnel:
                  Soit tu joues les économies, tu vantes la disponibilité de dév Java/PHP sur le marché, tu recrutes des manches à pas cher, et faut venir pleurer après si le résultats est un peu merdoyant. Soit tu es prêt à payer un vrai bon dév, et après filtrage, tu te rends compte que le ratio dévs PHP/dévs "autres outils web" est subitement bien plus bas.

                • [^] # Re: La démo de WebODF

                  Posté par  . Évalué à 3.

                  je pense que la plupart des équipes préfèrent dépenser plus en infrastructure serveur.

                  En effet, mais ce framework s'adresse surtout à mon avis aux dev C++/Qt qui veulent faire du web dans leurs technos préférées. De plus il est à mon avis idéal pour le faire tourner sur une machine type raspberryPI, beaucoup plus léger en ressources et performant que la stack PHP.
                  Sinon il existe des sites web grand public qui sont en C++, exemple OkCupide : http://www.okcupid.com/about/technology
                  c'est un choix qui n'est pas stupide.

        • [^] # Re: La démo de WebODF

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          Tu prend en compte l'installation de la Webapp sur le serveur ?

          • [^] # Re: La démo de WebODF

            Posté par  . Évalué à 0.

            Non puisque c'est à priori pas lui qui l'a installé.

            • [^] # Re: La démo de WebODF

              Posté par  (site web personnel, Mastodon) . Évalué à 4.

              Certes, mais comparer le nombre d'étapes avant le test d'un logiciel déjà installé, même sur une machine distante, à celui d'un logiciel non installé est fallacieux.

              D'autant plus qu'ici il est question d'un logiciel potentiellement installé par son utilisateur.

              Pour comparer justement il faudrait le faire soit en prenant en compte l'installation des dépendances et des logiciels, soit simplement le lancement des logiciels une fois installés (et encore, on compte le lancement du navigateur Web ou pas ?). Et ce pour un hôte local comme distant.

              • [^] # Re: La démo de WebODF

                Posté par  (site web personnel) . Évalué à -1. Dernière modification le 24 octobre 2013 à 12:35.

                Vous allez trop loin dans le cotés technique. Ici on s'en fiche de l'installation du logiciel. Le but est de tester rapidement et efficacement les fonctionnalités d'un logiciel, pas son processus d'installation.

                Vous voyez la chose d'un point de vue administrateur système alors que c'est l'utilisateur lambda qui est ciblé.

                Donc oui pour l'utilisateur lambda, c'est mieux et plus simple de ne pas avoir à télécharger/exécuter/installer un logiciel en faisant attention à son système d'exploitation, l'architecture de sa machine, les risques de sécurité, etc…

                • [^] # Re: La démo de WebODF

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

                  Vous voyez la chose d'un point de vue administrateur système alors que c'est l'utilisateur lambda qui est ciblé.

                  chiche!
                  Donc l'application native étant installé par l'admin système, c'est un seul clic aussi.
                  Merci.

                  c'est mieux et plus simple de ne pas avoir à télécharger/exécuter/installer un logiciel en faisant attention à son système d'exploitation, l'architecture de sa machine, les risques de sécurité, etc…

                  C'est le boulot de l'administrateur système, pas de l'utilisateur lambda.
                  Bizarre que tu prennes l'admin d'un côté, et pas de l'autre…

                  • [^] # Re: La démo de WebODF

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

                    Bizarre que tu prennes l'admin d'un côté, et pas de l'autre…

                    [ModeSérieuxSansAllusionSexuelle] Donc si on suit ta logique, il faudrait que l'utilisateur lambda appelle son administrateur système pour pouvoir tester un logiciel natif qu'il a trouvé sur le web.

                    Et si c'est lui l'administrateur système de sa machine, il faut donc qu'il fasse de l'administration système, mais cette étape se passe dans une autre dimension pour pas que ça fasse plus compliqué par rapport à un simple clic sur un lien web.

                    Tout ça pour au final se rendre compte que c'est un banal éditeur de texte riche sans véritable intérêt.

                    • [^] # Re: La démo de WebODF

                      Posté par  . Évalué à 3.

                      Tout ça pour au final se rendre compte que c'est un banal éditeur de texte riche sans véritable intérêt.

                      Mais puisqu'on te dit que c'est hyper simple !

                    • [^] # Re: La démo de WebODF

                      Posté par  . Évalué à 3.

                      il faut donc qu'il fasse de l'administration système, mais cette étape se passe dans une autre dimension

                      oui, d'ailleurs je connais des systèmes où cette dimensions s'appelle « root »… et dans cette dimension, les problèmes peuvent surgir vite et être assez conséquent.

              • [^] # Re: La démo de WebODF

                Posté par  . Évalué à 3.

                Certes, mais comparer le nombre d'étapes avant le test d'un logiciel déjà installé, même sur une machine distante, à celui d'un logiciel non installé est fallacieux.

                Ça dépend qui installe le logiciel distant.

                Pour la quasi-totalité des gens, c'est bien plus simple d'utiliser gmail que d'installer son propre SMTP et son MUA en local. Ce qui est le principal problème de la lutte contre le minitel 2.0.

                Après si on considère que owncloud c'est personel et que c'est la même personne qui installe son logiciel dans le Claude ou en local, alors effectivement, ça ne fait que déporter le problème.

                Le FN est un parti d'extrême droite

              • [^] # Re: La démo de WebODF

                Posté par  . Évalué à 2.

                Certes, mais comparer le nombre d'étapes avant le test d'un logiciel déjà installé, même sur une machine distante, à celui d'un logiciel non installé est fallacieux.

                Non ce n'est pas fallacieux. Le problème d'une application native, c'est que tu es obligé de l'installer pour pouvoir l'essayer. La preuve, c'est le nombre de paquets (et de meta-paquets) que j'ai installé juste pour tester et qui trainent sur mon pc car je suis incapable de les lister.

                Dans le cas d'une application en ligne, il me suffit de suivre le lien pour tester l'application.

                Ca n'est donc pas fallacieux, c'est justement une grande force des applications en ligne: c'est hyper simple pour l'utilisateur de l'essayer.

                • [^] # Re: La démo de WebODF

                  Posté par  . Évalué à 3.

                  Le problème d'une application native, c'est que tu es obligé de l'installer pour pouvoir l'essayer.

                  tu ne connais pas 0install ?
                  en un clic tu lances une application native !
                  ca existe depuis des lustres ….

                  http://0install.net/

                  • [^] # Re: La démo de WebODF

                    Posté par  . Évalué à 4.

                    Et c'est utilisé par au moins 30 applications… (sic)
                    Dommage qu'il soit concurrencé par klik, runz et autopackage au moins.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: La démo de WebODF

                Posté par  . Évalué à 3.

                Certes, mais comparer le nombre d'étapes avant le test d'un logiciel déjà installé, même sur une machine distante, à celui d'un logiciel non installé est fallacieux.

                L'un des tests est en O(n+m) avec n le nombre d'action lors de l'installation de la webapp et m le nombre de machines sur le quel on l'utilise, l'autre est en O(j*m) avec j le nombre d'actions pour l'installer et m le nombre de machines sur le quel on l'utilise. D'après toi la quelle de ces 2 fonctions croit le plus rapidement ?

                C'est rigolo parce que cette fois l'argument bateau « ouai mais le natif c'est rapide » ne tiens pas, au contraire la démo mange moins de mémoire que LibO sur ma machine cliente (je ne sais pas pour le serveur, mais comme je crois que c'est entièrement en js).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: La démo de WebODF

                  Posté par  . Évalué à 0.

                  Sauf si tu installes le client sur un partage NFS (ou SMB, selon la techno voulue) et alors ton installation sera également en O(j+m), ou plus propre, le client peut-être distribué sur le dépot de paquets de l'entreprise, l'installation sur les postes clients automatisés avec puppet … bref, ça dépend, tout n'est pas forcément installé à la main.

                  Après, c'est un souci d'infra, mais quand elle est là, on peut l'utiliser facilement.

                  • [^] # Re: La démo de WebODF

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

                    Pour une démo de logiciel disponible sur internet, ça risque d'être compliqué de mettre en place ce genre d'infrastructure.

                  • [^] # Re: La démo de WebODF

                    Posté par  . Évalué à 3.

                    Sauf si […]

                    Avec des si on peut en faire des choses. Par exemple on peut dire que c'est lui qui réalise l'installation sur toutes les machine du monde (c'est dans ses cordes).

                    Mais en vrai les internautes ne font pas parti d'un même réseau d'entreprise administré via un quelconque gestionnaire de parc informatique, ils se paluche leur installation locale ou utilise une installation distante si elle est facile d'accès (via du web donc).

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: La démo de WebODF

          Posté par  . Évalué à 4.

          • [^] # Re: La démo de WebODF

            Posté par  . Évalué à 4.

            on doit même pouvoir en faire un seul

            Perdu, il faut au moins trois clics vu que tu t'es planté en collant le lien. Mais sinon, WAHOU ‼

        • [^] # Re: La démo de WebODF

          Posté par  . Évalué à 2.

          D'ailleurs, aurais-tu un exemple de démo en Qt qui se teste en 2 clics ? Je suis curieux.

          Toute la subtilité est de configurer ton environnement pour qu'il réagisse au double click.
          Moi comme j'ai pris le pli du simple click, je n'ai malheureusement pas ça sous la main…

    • [^] # Re: La démo de WebODF

      Posté par  . Évalué à 2.

      vraiment génial ! Ça manquait vraiment un outil comme ça, et si ça permet de se passer de google docs avec l'édition collaborative, c'est parfait.

      J'ai essayé d'éditer un ods qui était sur mon ordinateur, et si j'ai pu l'ouvrir sans problème, je n'ai pas pu l'éditer, peut-être parce que le fichier n'était pas sur leur serveur. Quel est le statut de la partie tableur ? C'est censé fonctionner aussi bien que pour la partie traitement de texte ? Je n'ai pas pu débuter un tableur vierge depuis la démo.
      C'est surtout le tableur qui m'intéresse, car même si ethercalc est pas mal, ça reste moins pratique qu'un vrai tableur.

      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

  • # Pas de numérotation automatique ?

    Posté par  . Évalué à -6.

    En tout cas je ne l'ai pas trouvée.

    Un traitement de texte sans numérotation automatique = poubelle :(

    BeOS le faisait il y a 20 ans !

    • [^] # Re: Pas de numérotation automatique ?

      Posté par  . Évalué à 4.

      C'est juste la première version bêta…

      Citation du blog mentionné dans le journal :

      Please note that this is only the first version of this great feature. Not every ODT element is supported but we are working on improving this considerably in the future. We will invest significantly in this because we think that this is a very important feature that is useful for people. — Frank Karlitschek

  • # Génial

    Posté par  . Évalué à 6.

    Plus qu'à avoir l'édition à plusieurs en simultané.

    « 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: Génial

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

      Déjà possible : https://togetherjs.com/

      • [^] # Re: Génial

        Posté par  . Évalué à 4.

        En fait, si on lit l'article, on se rend compte qu'il parle de l'édition collaborative dans owncloud.

        « 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: Génial

          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 24 octobre 2013 à 14:07.

          Oui et je dis que c'est déjà possible de l'avoir dans Owncloud avec l'outil de mozilla. C'est moins bien intégré mais ça fonctionne.

          • [^] # Re: Génial

            Posté par  . Évalué à 2.

            C'est tellement moins bien intégré que ça ne marchera pas probablement pas en l'état : l'outil de Mozilla impose d'être sur le même site en même temps, ce qui risque de coincer quand le document aura deux URLs différentes selon l'utilisateur (l'un le verra à sa "vraie" place tandis que l'autre le verra dans Shared, typiquement).

            Bref, oui TogetherJS est très bien, mais ça n'a pas grand chose à voir avec la choucroute.

  • # Mouais

    Posté par  . Évalué à 6.

    Techniquement c'est sympa mais ça n'édite que des documents texte, et j'attends surtout l'édition de classeurs OpenDocument.

    Pour le coup le nom est un peu usurpé : ça devait plutot s'appeler WebODT et « owncloud Text Documents ».

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

Suivre le flux des commentaires

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