Journal Eolie, le petit frère de Lollypop

Posté par (page perso) . Licence CC by-sa
58
30
mai
2017

Bonjour à tous,

pour ceux qui me connaissent, je suis l'auteur de Lollypop, un lecteur audio pour GNOME. Ce dernier depuis plusieurs mois ne reçoit que des corrections de bug et des ajouts de fonctionnalités quand je trouve les demandes pertinentes, mais de mon point de vue, il est «terminé».

Du coup, je me faisais chier dans le train alors j'ai commencé à bosser sur une autre application: Eolie
Il s'agit d'un navigateur web pour GNOME avec les fonctionnalités de base d'un navigateur web plus:
- Support de la synchronisation avec Firefox Sync
- Support du téléchargement des vidéos en cours de lecture
- Mode "privé" par "onglets" et non par fenêtre
- Mode lecture

Voilà, j'en avais marre de Firefox et son manque d'intégration, Epiphany ne répond pas vraiment à mon besoin et je suis une merde en C (donc dur de contribuer). J'ai démarré Eolie il y'a 4 mois, python + GTK + WebKit sont vraiment efficaces.

https://www.gnomelibre.fr/2017/04/developpement-dun-nouveau-navigateur-web-eolie/
https://www.youtube.com/watch?v=pWHLbaqKOUQ

  • # Merci beacoup pour ce navigateur web de ouf !

    Posté par (page perso) . Évalué à 2.

    Merci beaucoup pour ce navigateur web.

    C’est impressionnant la vitesse à laquelle tu l’as pondu. Chapeau bas !

    Oui, c’est du Python, possible que j’y contribue, si j’en vois le besoin.

    Il est un peu moins stable que Firefox et consomme plus de ressources avec beaucoup d’onglets.

    Un de mes manques est l’ajout de mes extensions Firefox, mais ça viendra avec les Webextensions.

    Sinon, oui, son intégration à GNOME et top !

    La raison pour laquelle j’utilise pas GNOME Web/Epiphany et dû au fait qu’il est extrêmement consommateur de ressources CPU.
    Je pense que c’est lié au HiDPI. Ça n’est pas le cas d’Eolie :)

    • [^] # Re: Merci beacoup pour ce navigateur web de ouf !

      Posté par (page perso) . Évalué à 3.

      Ça n’est pas le cas d’Eolie :)
      C'est plutôt surprenant, je ne vois pas comment Eolie pourrait être moins consommateur de ressource que Epiphany… Ce devrait être identique.

      Il est un peu moins stable que Firefox et consomme plus de ressources avec beaucoup d’onglets.

      Tu parles de ressources CPU? J'avoue que j'ai tendance à rarement dépasser les 10 onglets donc je ne sais pas. Après, il est sur que JavaScriptCore est loin d'être le meilleur moteur js.

      • [^] # Re: Merci beacoup pour ce navigateur web de ouf !

        Posté par (page perso) . Évalué à 2.

        Tu parles de ressources CPU? J'avoue que j'ai tendance à rarement dépasser les 10 onglets donc je ne sais pas. Après, il est sur que JavaScriptCore est loin d'être le meilleur moteur js.

        Oui, je parle de ressources CPU. J’ai ressenti des ralentissements avec trois voir quatre onglets.
        Je viens de réessayer avec une dizaine d’onglets et ça va finalement.
        J’ai un souvenir d’avoir eu des ralentissements.

  • # unixporn

    Posté par (page perso) . Évalué à -3.

    Si tu veux mon avis, je pense que l’image présentée sur la page d’accueil, avec reddit.com/r/unixporn, est une mauvaise idée. En tout cas je serais pas étonné si la vue de « Unixporn » en très gros, au milieu de l’écran, quand on va sur ton site web en révulse quelques-uns.

    Parce que, pour rappel, « porn » ça désigne des représentations très graphiques et concrètes d’actes sexuels. Ça n’est pas un suffixe qui veut dire « qui est agréable à voir ». Ça serait d’ailleurs bien que les différentes communautés sur reddit s’en rendent compte. Foodporn, unixporn, etc… Le jour où quelqu’un voudra faire un subreddit avec des photos d’enfants mignons, ils vont l’appeler /r/childporn ?

    • [^] # Re: unixporn

      Posté par . Évalué à 6.

      Parce que, pour rappel, « porn » ça désigne des représentations très graphiques et concrètes d’actes sexuels. Ça n’est pas un suffixe qui veut dire « qui est agréable à voir ». Ça serait d’ailleurs bien que les différentes communautés sur reddit s’en rendent compte. Foodporn, unixporn, etc… Le jour où quelqu’un voudra faire un subreddit avec des photos d’enfants mignons, ils vont l’appeler /r/childporn ?

      Ce n'est pas du tout lié ni limité à reddit. C'est tout simplement tombé dans le language commun dans les pays anglo-saxons et l'utilisation de porn en tant que suffixe est maintenant décorrélé de la signification et connotation sexuelle du mot seul. Alors certe parler de childporn serait très maladroit mais je pense que tout le monde en est conscient.

      Je dis ça et je ne suis pas très fan de cet usage mais bon c'est l'évolution du language, tu ne peux pas y faire grand chose.

      • [^] # Re: unixporn

        Posté par (page perso) . Évalué à 3.

        décorrélé de la signification et connotation sexuelle du mot seul.

        Non non, dans biduleporn, on garde bien la notion de débauche (de bidules, de nourriture, de câbles…).

        • [^] # Re: unixporn

          Posté par . Évalué à 4.

          Ça tombe bien l'usage du mot débauche a lui aussi évolué à travers les siècles pour ne plus avoir une connotation exclusivement sexuelle.

          Personne ne se masturbe en consultant /r/earthporn. Enfin si il y'en a sûrement 1 ou 2 qui ont ce genre de délire parce qu'il y'a toujours quelqu'un pour avoir des idées plus tordues que les autres mais là on peut pas lutter.

          • [^] # Re: unixporn

            Posté par (page perso) . Évalué à 2.

            Ce que je voulais dire c'est que l'utilisation du suffixe porn est à titre humoristique, il ne s'agit pas vraiment d'une évolution du sens.

            • [^] # Re: unixporn

              Posté par . Évalué à 2.

              Je crois que c'est devenu tellement répandu au point que c'est utilisé à l'oral (pas juste pour la blague !) et en Français ou dans pleins d'autres pays et donc il y'a clairement un glissement dans la signification du mot quand il est utilisé comme suffixe puisque ça concerne des trucs à des années lumières de toute sens sexuel.

    • [^] # Re: unixporn

      Posté par (page perso) . Évalué à 3.

      Le site web a été monté à l'arrache et j'ai juste récupérer une capture d'écran que j'avais posté sur UnixPorn il y'a quelques mois ;) J'attends que les gens qui gèrent le site de Lollypop s'occupent un peu de celui d'Eolie.

    • [^] # Re: unixporn

      Posté par . Évalué à 4. Dernière modification le 30/05/17 à 19:14.

      Parce que, pour rappel, « porn » ça désigne des représentations très graphiques et concrètes d’actes sexuels.

      Il me semble que "porn" est simplement le diminutif de "pornography" qui a le même sens en anglais que le mot français « pornographie ». Or si j’ouvre un dictionnaire que lis-je :

      pornographie
      nom féminin
      Présence de détails obscènes dans certaines œuvres littéraires ou artistiques ; publication, spectacle, photo, etc., obscènes.

      puis :

      obscène
      adjectif
      (latin obscenus, de mauvais augure)
      Qui blesse ouvertement la pudeur, surtout par des représentations d'ordre sexuel ou scatologique : Des propos obscènes.

      Donc principalement lié au sexe (ou au caca) mais pas toujours…

      Bon, ça n’explique pas cette mode des "porntrucs"… c’était juste pour ramener ma fraise une fois de plus :)

      • [^] # Re: unixporn

        Posté par (page perso) . Évalué à 5. Dernière modification le 31/05/17 à 00:41.

        Bon, ça n’explique pas cette mode des "porntrucs"…

        humour… décalé… esprit canal… 'cule un mouton ;-) les guignols l'ont aussi fait dans leur style parfois trash, pourtant à une heure de grande écoute (bon, ça c'était avant les événements :/).

        bon, en outre, je comprends que tout le monde ne comprend pas l'autocollant de la quadrature du net « we make data porn », ce pour quoi je l'ai collé sous mon pc et non sur le devant (surtout quand je me trouve avec mon pc en milieu professionnel), mais bon ça ne me gêne pas trop de le montrer à des gens qui comprennent (déjà que beaucoup trouvent fantaisistes d'avoir un pc couvert d'autocollants prônant le libre ainsi que facebook alors que c'est le logo de Fedora /o\).

        le raisonnement non orthodoxe est peu compréhensible de ceux n'ayant qu'un humour au 1er degré au quotidien et ne s'étant jamais posé la question de situations WTF quotidiennes

        • [^] # Re: unixporn

          Posté par . Évalué à 1.

          tout le monde ne comprend pas l'autocollant de la quadrature du net « we make data porn »

          Je le comprends simplement comme dire qu’une chose est aussi, sinon plus, importante que le sexe pour certaines personnes. Le food porn pour les « gourmets », le data porn pour les… dataphiles…, etc…

          C’est un moyen d’élargir la portée sémantique de « pornographie », donc de dilué l’impact même du mot sur les esprits, je comprends que ça puisse choquer ceux qui ont souffert de la pornographie (dans le sens plus restreint de l’industrie du X…) de près ou de loin.

          ce pour quoi je l'ai collé sous mon pc et non sur le devant (surtout quand je me trouve avec mon pc en milieu professionnel), mais bon ça ne me gêne pas trop de le montrer

          Est-ce que ces auto-collant t’on déjà permis d’initier des discussions sur le libre, ou plus largement des discussions diverses ?

          déjà que beaucoup trouvent fantaisistes d'avoir un pc couvert d'autocollants prônant le libre ainsi que facebook alors que c'est le logo de Fedora

          On t’as déjà fait remarquer que facebook et la quadrature du net pouvaient être… opposable ? trollé, à cause de ces auto-collants ?

          • [^] # Re: unixporn

            Posté par (page perso) . Évalué à 4.

            je comprends que ça puisse choquer ceux qui ont souffert de la pornographie

            rho la la… /o\
            je crois que d'autres choses les ont atteint bien plus, mais bon je n'aime pas trop en parler (ce pour quoi, regarder la série Esprits criminels me dérange, vu qu'elle met en évidence une trame de pensée perverse, biaisée, pseudo-scientifique, principalement basée sur l'affect, bref)

            Est-ce que ces auto-collant t’on déjà permis d’initier des discussions sur le libre, ou plus largement des discussions diverses ?

            Cela m'a permis de reconnaître ceux qui connaissent le libre en milieu professionnel (et n'osent pas le promouvoir autant).
            Quelque part je fais du librepr0n :-)
            Cela m'a permis de donner des idées à ceux qui veulent appliquer une directive d'entreprise du « libre first » (ou l'inversement de la preuve : avant c'était le proprio ya un éditeur solide, la preuve les achats l'ont mis au catalogue ; maintenant c'est ya du proprio, je dois justifier pourquoi une solution libre avec un bon intégrateur ne répondrait pas au besoin). Choquer ou montrer son camp ouvertement, ce n'est pas entrer dans un camp de nudistes hein, c'est simplement indiquer une préférence mais avec la notion d'accompagner et d'essayer de comprendre que ce n'est pas le choix de tout le monde. Au quotidien, j'indique que je ne suis pas un expert des solutions de Microsoft (moi j'ai plutôt les problèmes) et j'indique que si quelqu'un a un problème avec Microsoft, qu'il me l'indique, je l'ai sans doute déjà eu et j'ai le contournement (c'est chaque mois au moins…)

            On t'a trollé, à cause de ces auto-collants ?

            oui au PSL par exemple, surtout sur les projets que je ne connaissais que de nom /o\ et dont je n'ai pas l'utilité à titre personnel, même si utilisé en entreprise comme jenkins qui a une palanquée de logos mais aucun qui me convainc de l'afficher, sérieux, un majordome ?! moui je vois l'idée, mais non (heureusement il y a moins de javaistes à PSL que dans mon boulot). Personne ne m'a fait remarquer que je n'avais pas d'auto-collant python, pourtant il y a beaucoup de pythonnistes à PSL, bon leur logo est pourrite aussite :D

            Quand je suis passé chez google pour la solution d'API management qu'ils ont racheté, mon pc n'est pas sorti du lot non plus, en milieu familier, c'est un truc « acceptable » et accepté. Si plus de monde le faisait, ça m'arrangerait, histoire d'éviter de passer pour un hurluberlu :-) Rien que 2-3 autocollants pour cacher la marque du portable qui ne me rémunère pas pour être homme-pancarte de leur marque (mon tarif est relativement faible : pour 200 € / mois je veux bien ne pas mettre d'autocollant sur une de leur marque de mon portable, celle en dessous ; pour les autres, le tarif est négociable, surtout pour del, dy, lenoro… pas acre en revanche)

  • # Release rapide

    Posté par . Évalué à 4.

    Hello,
    Tout d'abord encore merci pour lollypop, je vais tester eolie, ça a l'air très bien.
    Je suis interpellé par ta productivité. Je traîne un peu sur les news relatives à gnome, etc, et je ne vois aucune commune mesure entre le rythme rapide avec lequel tu développes lollypop et eolie, et la lenteur avec laquelle le projet Gnome avance epiphany ou gnome music malgré le soutien de sponsors et, on l'imagine, une grande communauté de bénévoles.
    Est ce lié au cycle de release, tous les 6 mois, qui aurait une influence sur les contributeurs, ou autre chose?

    • [^] # Re: Release rapide

      Posté par (page perso) . Évalué à 6.

      Pour Music, c'est lié au manque de devs à temps plein.

      Pour Epiphany, je pense que c'est surtout lié au language utilisé, à savoir du C. Franchement, c'est à mon avis une perte de temps.

      • [^] # Re: Release rapide

        Posté par (page perso) . Évalué à 5.

        Est-ce que tu as discuté avec le projet GNOME pour éventuellement remplacer ceux d'origines par les tiens ?

        Je ne crois pas qu'il y ait un dogme pour conserver impérativement Epiphany ou Musique tels quels, la possibilité de repartir à partir de ton travail pourrait être une option.

        • [^] # Re: Release rapide

          Posté par (page perso) . Évalué à 5.

          Je ne veux pas particulièrement voir Epiphany et Music disparaitre, et je place mes applications comme des alternatives, pas des concurrents.

          Par exemple, Music se veut simple sans configuration, ce n'est pas le cas de Lollypop qui essaye de garder une interface la plus sobre possible tout en offrant beaucoup de fonctionnalités.

          • [^] # Re: Release rapide

            Posté par (page perso) . Évalué à 5.

            Je ne veux pas particulièrement voir Epiphany et Music disparaitre, et je place mes applications comme des alternatives, pas des concurrents.

            C'est ton choix, cependant je trouve que ton travail pourrait bénéficier d'une plus large diffusion et améliorer l'offre de base de GNOME encore.

            Par exemple, Music se veut simple sans configuration, ce n'est pas le cas de Lollypop qui essaye de garder une interface la plus sobre possible tout en offrant beaucoup de fonctionnalités.

            Mais est-ce que Music est simple parce que c'est un choix justifié ou parce qu'ils manquent de ressources / d'idées ou autres encore pour aller plus loin ?

            Tes applications respectent plutôt bien l'ergonomie GNOME, le fait qu'ils soient plus complets que ceux de bases ne signifient pas qu'ils n'y ont pas leur place, au contraire même.

            De toute façon, tu es libre de faire ce que tu veux. ;-)

            • [^] # Re: Release rapide

              Posté par (page perso) . Évalué à 4.

              C'est un peu comme Juk and Amarok sous KDE, celui par defaut simple et l'alternative bien plus complète…

              Bon Amarok est un projet complétement mort, j'espère que ce n'est pas de mauvaise augure :)

              • [^] # Re: Release rapide

                Posté par (page perso) . Évalué à 2.

                Bon Amarok est un projet complètement mort

                j'ai marché dedans, heureusement que https://www.openhub.net/p/amarok m'a confirmé que c'était effectivement un trait d'humour ;-) (dernier commit il y a un mois), même si cela tend vers l'encéphalogramme plat à regarder https://www.openhub.net/p/amarok/commits/summary (le prix d'être complet et intégré tant à KDE qu'à Gnome d'ailleurs : c'est un lecteur que je préfère à rhythmbox dont l'orthographe me désarçonne à chaque fois que je le lance o_O)

                Pour lollypop, cela reste àmha un projet en devenir même si sympathique : il n'est pas empaqueté pour Mageia ?! Faut se magner, la 6 est dans les starting-blocks :-)
                Et en plus, si tu es sympa, les admins de LinuxFr.org te permettront d'actualiser ton pseudo en gnumdv^Wgnumga ou gnudeb selon ta préférence (gnudev au besoin, si tes velléités vont vers la distribution passéiste Devuan, mais je ne voudrais pas lancer de troll).

                • [^] # Re: Release rapide

                  Posté par (page perso) . Évalué à 4.

                  Non, les commits automatiques du script de traduction ça ne compte pas :p

                • [^] # Re: Release rapide

                  Posté par (page perso) . Évalué à 4.

                  Ben, Lollypop est dans Fedora donc ça doit être assez simple pour un packageur Mandra^WMandri^WMageia de bosser dessus.

      • [^] # Re: Release rapide

        Posté par . Évalué à -1.

        Je pense que le choix du C est également un gage de perf et de compatibilité avec les libs sous-jacente qui sont en C. Il faut pas oublier que GTK, GNOME sont avant tout des projets en C.

    • [^] # Re: Release rapide

      Posté par . Évalué à 3.

      Pareil, je me joins à mes co-moules pour te remercier, depuis ta première annonce de Lollypop sur LinuxFR, cette application est devenue de-facto mon lecteur de musique par défaut.

    • [^] # Re: Release rapide

      Posté par (page perso) . Évalué à 4.

      Je suis interpellé par ta productivité. Je traîne un peu sur les news relatives à gnome, etc, et je ne vois aucune commune mesure entre le rythme rapide avec lequel tu développes lollypop et eolie, et la lenteur avec laquelle le projet Gnome avance

      Il y a pas mal de nouvelles applications GNOME écrites en C qui se sont développées rapidement : gnome-software, gnome-builder, gnome-photos, recipes et peut-être quelques autres.

      Pour Epiphany, les développeurs s'occupent aussi de WebKitGTK+, donc bon… De manière générale les développeurs GNOME s'occupent aussi des librairies, pas seulement des applications.

      Je suis un dev GNOME et je préfère le langage C pour plusieurs raisons:
      - le compilateur vérifie plein de trucs à la compilation, tandis qu'en Python on découvre certains problèmes au runtime (par exemple une faute de frappe dans le nom d'une fonction).
      - je peux écrire des librairies, documentées avec gtk-doc et les annotations GObject Introspection, comme ça la librairie est utilisable dans plein de langages (dont Python).

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

  • # Firefox Sync

    Posté par . Évalué à 2.

    Bonjour et félicitations.

    Concernant Firefox Sync, as-tu utilisé un client Python existant ou tu as écrit le tien ? J'ai cherché il y a plusieurs mois à écrire un outil CLI pour accéder à Firefox Sync mais la doc était assez pauvre et pas du tout à jour …

  • # En train...

    Posté par . Évalué à -8.

    Hello, et bravo.
    Un navigateur web, c'est déjà un gros programme. Si tu t'ennuies encore en train, ça vaudrait le coup que tu te perfectionnes en C et que tu programmes Eolie dans ce langage.

    • [^] # Re: En train...

      Posté par (page perso) . Évalué à 10.

      Pourquoi faire? Mettre 2 ans pour faire ce que j'ai fait en 4 mois?

    • [^] # Re: En train...

      Posté par (page perso) . Évalué à 7.

      Franchement, je ne vois aucun, mais alors aucun, intérêt de faire du C pour développer une interface graphique (et pourtant, j'en ai bouffé du C dans ma jeunesse).

      Ou alors va falloir m'expliquer là…

      C'est pas parce que Gnome est en C qu'il faut tout faire en C (d'ailleurs il y a de fortes chances que Gnome n'aurait pas été en C si le projet démarrait avec les technos d'aujourd'hui). On a aujourd'hui des langages bien plus efficace en terme de productivité, en terme de sécurité et de stabilité, avec lesquels donc on a moins à penser aux risques de buffer overflow, à la gestion de pointeurs, de leaks mémoire etc.

      Le C, ça reste valable pour tout ce qui est programmation système très bas niveau. Et encore, avec des langages comme Rust, ça se discute de mon point de vue, si on veut un truc un minimum robuste sans décupler les temps de dev et de formation (parce que faire un truc potable en C nécessite quand même pas mal d’expérience pour pas tomber dans tous les pièges amenant à des trous de sécu, fuites mémoire et j'en passe).

      Mais pour faire de la programmation dans les couches hautes, en particulier les interfaces, non. Faut arrêter là. À part quelques cas très spécifiques (par ex, faire une interface pour une machine embarquée très peu performante), je ne vois pas ce qu'apporterait un langage comme C. C'est comme si on demandait de creuser un trou avec un baton alors que depuis quelques temps on a inventé la pelle pour ça (et maitrisé la fabrication de l'acier), voir même les pelleteuses.

      • [^] # Re: En train...

        Posté par (page perso) . Évalué à 3.

        Python se traine une sale réputation quand on parle grosse application graphique.

        Pourtant,le développement de Lollypop m'a montré qu'on pouvait faire des interfaces fluides affichant des milliers d'éléments à partir du moment où l'on ne fait pas ça: while items, put item

        Sans thread, ça fige l'UI.
        Même dans un thread, ça va flooder le toolkit graphique et donc l'application va devenir lente.

        La bonne pratique, c'est récupérer les données dans un thread et après laisser la boucle principale du toolkit faire le boulot élément par élément:

        def add_item(self, items):
        if items:
        item = items.pop(0)
        self.add(item)
        GLib.idle_add(self.add_item, items)

        • [^] # Re: En train...

          Posté par . Évalué à 0.

          Je n'ai rien contre Python, et j'ignorais même cette "sale réputation". Mais comme c'est un langage interprété, nécessairement, à tache égale, il sera plus lent et consommera plus de ressources machine.
          C'est juste mon avis, mais je pense qu'il n'est jamais très bon de compter sur la puissance des machines pour avoir des programmes rapides, et donc dans la mesure du possible, dès qu'on commence à avoir du gros code, choisir du compilé.
          Python est un langage facile d'accès et est donc désormais le langage préféré d'apprentissage. Mais comme il est également très riche et complet et qu'il existe une foultitude de librairies (on peut absolument tout faire avec), ceux qui ont débuté en Python restent en Python, y compris pour des très gros projets, ce qui peut impacter les performances des machines.

          Pourquoi faire? Mettre 2 ans pour faire ce que j'ai fait en 4 mois?

          Je pense que la différence de délai n'est pas due aux langages, mais au fait que tu touches en Python.

          Le C n'est pas si compliqué ni si laborieux à programmer. C'est même un langage assez simple dans sa syntaxe. La facilité de développement est plutôt lié à la disponibilité des librairies.
          Par exemple, programmer un Arduino en C est très simple car les librairies pilotant les modules sont toujours disponibles et bien conçues. Les concepteurs de l'Arduino on même ajouté des fonctions et types de base qui simplifient encore plus la stdlib.
          Pour le Raspberry, c'est plus compliqué. Les concepteurs ont choisi Python pour faire découvrir la programmation aux utilisateurs de leur machines, et donc la plupart des librairies pilotant les modules électroniques dédiés au Raspberry ont été développées en Python. Donc là, effectivement, c'est galère de programmer en C.

          • [^] # Re: En train...

            Posté par (page perso) . Évalué à 5.

            C'est juste mon avis, mais je pense qu'il n'est jamais très bon de compter sur la puissance des machines pour avoir des programmes rapides, et donc dans la mesure du possible, dès qu'on commence à avoir du gros code, choisir du compilé.
            Python est un langage facile d'accès et est donc désormais le langage préféré d'apprentissage. Mais comme il est également très riche et complet et qu'il existe une foultitude de librairies (on peut absolument tout faire avec), ceux qui ont débuté en Python restent en Python, y compris pour des très gros projets, ce qui peut impacter les performances des machines.

            Tu mélanges plusieurs choses. Et il est tout à fait possible d'utiliser des bibliothèques C en Python (c'est d'ailleurs le cas de pas mal de bibliothèque disponible). Ce qui fait que la partie en Python ne n'est pas la partie CPU bound, donc ce n'est pas un problème. Si on prends l'exemple du navigateur Web, ce qui est consommateur en ressource, c'est le moteur de rendu et le moteur JS. Dans le cas qui nous intéresse, ils sont en C++. Donc ce n'est pas Python qui va limiter les ressource. Même une partie de l'interface graphique est en C (via les bindings GTK). Ici, le Python ne fait que la "glue" entre les différents composants (même si c'est bien sûr un peux plus que ça).

            Le C n'est pas si compliqué ni si laborieux à programmer

            Pour une interface graphique, en travaillant proprement (et donc éviter les erreurs mémoires et autres joyeusetés du C), si.

            Par exemple, programmer un Arduino en C

            Rien à voir avec une interface graphique donc. On n'est même pas sur du multitâche… En plus, parler de gros projet et coder sur Arduino…

            Pour le Raspberry, c'est plus compliqué. Les concepteurs ont choisi Python pour faire découvrir la programmation aux utilisateurs de leur machines,

            Je ne vois pas ce que tu veux dire, Raspberry, c'est juste une plateforme matérielle. Après, il y a différents OS dessus et c'est du C classique pour communiquer avec l'OS. Comme tu le ferrais avec un PC classique.

            « 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: En train...

              Posté par . Évalué à 1.

              Dans le cas qui nous intéresse, ils sont en C++. Donc ce n'est pas Python qui va limiter les ressource. Même une partie de l'interface graphique est en C (via les bindings GTK). Ici, le Python ne fait que la "glue" entre les différents composants.

              OK.

              Le C n'est pas si compliqué ni si laborieux à programmer

              Pour une interface graphique, en travaillant proprement (et donc éviter les erreurs mémoires et autres joyeusetés du C), si.

              C'est vrai que la performance de l'exécutable nécessite une certaine discipline.

              Rien à voir avec une interface graphique donc. On n'est même pas sur du multitâche… En plus, parler de gros projet et coder sur Arduino…

              C'est juste un exemple pour expliquer qu'avec des librairies bien fichues, c'est facile de coder en C.

              Je ne vois pas ce que tu veux dire, Raspberry, c'est juste une plateforme matérielle. Après, il y a différents OS dessus et c'est du C classique pour communiquer avec l'OS. Comme tu le ferrais avec un PC classique.

              Autre exemple opposé au précédent. L'Arduino et le Raspberry Pi sont tout deux utilisés pour faire de l'informatique physique, c'est à dire communiquer avec des modules électroniques : capteurs, actionneurs, afficheurs, horloges,…
              Pour les premiers les librairies sont en C, tandis que pour le second, elles sont essentiellement en python.

              • [^] # Re: En train...

                Posté par (page perso) . Évalué à 3.

                C'est vrai que la performance de l'exécutable nécessite une certaine discipline.

                Que ce soit en C ou en Python.

                C'est juste un exemple pour expliquer qu'avec des librairies bien fichues, c'est facile de coder en C.

                Mais c'est un exemple qui n'a rien à voir. Sinon, je te sors Pythran et je te dis qu'on peut avoir de très bonnes performances avec du Python.

                Pour les premiers les librairies sont en C, tandis que pour le second, elles sont essentiellement en python.

                Je ne vois toujours pas ce que tu veux dire. On peut (et on fait) très bien du GPIO sur Raspberry pi en C.

                « 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: En train...

                  Posté par . Évalué à 2.

                  Il a raison de dire que sur RPi, l'écosystème se fédère autour de Python. Les shields / extensions existants fournissent souvent des librairies en python, et rien d'autre.

                  Après, il est possible d'aller porter ça en C, évidemment.

          • [^] # Re: En train...

            Posté par . Évalué à 2.

            En fait ceux qui font du Python vont souvent te dire que le temps qui est le plus cher c'est celui du programmeur (pas celui de la machine). Or en Python tu es généralement plus productif qu'en C (le contraire est quand même très difficile à soutenir).

            Mais bien sur c'est toujours un compromis, et si ton programme est déployé sur des milliers de machines et en permanence ça vaut sûrement le coup de l'optimiser (ou au moins c'est défendable).

  • # Plantage

    Posté par . Évalué à 2.

    Sympa ce petit navigateur, très original la manière de présenter les onglets. Joli travail :)

    J'ai juste un petit soucis quand je vais dans les préférences, Eolie plante avec le message suivant:

    Application::init(): No module named 'requests_hawk'
    Traceback (most recent call last):
      File "/usr/lib/python3.6/site-packages/eolie/helper_passwords.py", line 349, in __on_secret_search
        callback(None, None, *args)
    TypeError: __on_get_sync() missing 1 required positional argument: 'uri'
    
    During handling of the above exception, another exception occurred:
    
    Traceback (most recent call last):
      File "/usr/lib/python3.6/site-packages/eolie/helper_passwords.py", line 354, in __on_secret_search
        callback(None, None, *args)
    TypeError: __on_get_sync() missing 1 required positional argument: 'uri'
    GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Argument invalide.  Aborting. 
    

    Le module request_hawk est introuvable en paquet sous Archlinux, c'est peut-être la cause?

    • [^] # Re: Plantage

      Posté par (page perso) . Évalué à 3.

      Non, tu utilises la version de dev donc forcément :)

      Mais ca doit être corrigé ;)

    • [^] # Re: Plantage

      Posté par (page perso) . Évalué à 3.

      D'ailleurs tu peux utiliser pip3 pour installer pyfxa et le module requests_hawk

      • [^] # Re: Plantage

        Posté par . Évalué à 1.

        Je vais essayer ça merci bien :)

  • # Look & Feel

    Posté par . Évalué à 2.

    J’aime beaucoup le look&feel de l’application. Je ne l’ai pas encore testé (je suis au boulot), mais j’adore le côté épuré. Si ça pouvait être compatible avec le système d’extension de Firefox (il me semble que c’est le but des web extensions), pour les addons tels que les correcteurs de grammaires, vimfx, … ce serait fantastique. Je garde quand même quelque réserve quant aux perfs pour mon usage perso, j’ai très rarement moins de 40 onglets ouvert (mais non actifs, donc FF les décharges).

    bépo powered

Suivre le flux des commentaires

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