D'abord merci de faire passer des nouvelles sur Kdenlive…
Et j'ai quelques réactions :)
Tout d'abord, je trouve injuste de dire que ça s'est empiré depuis 2013, que ce soit en stabilité ou en performances.
Nous avons basculé sur l'affichage OpenGL dès la branche Qt4, quand est apparue l'intégration de Movit (effets calculés sur le GPU) qui était très prometteuse et requérait ce changement. Malheureusement l'intégration GPU / Multithreading est compliquée (pour MLT, mais pas que), toujours instable depuis 5 ans, et nous avons donc dû désactiver cette option car trop d'utilisateurs se cassaient les dents là dessus. Nous cherchons toujours des contributeurs maîtrisant ces domaines : ce n'est pas vraiment à la portée du premier bricoleur venu (comme moi :-P)
Hormis les effets, l'affichage via OpenGL a visiblement causé des ralentissements chez certains utilisateurs, minoritaires et malheureusement sans qu'on trouve jamais l'explication. En tout cas chez les développeurs, les testeurs réguliers et d'après le bug tracker, rien n'a justifié un retour en arrière, qui serait compliqué maintenant. Moi-même j'ai un vieux i5 (3ème génération ?) avec 4Go de RAM, GPU Intel intégré : ça roule toujours !
Le passage à Qt5 en 2015 (indispensable car Qt4 en fin de vie) a engendré des régressions et instabilités, gommées au bout d'environ un an alors que le distributions opéraient la transition.
Un autre facteur qui a engendré des ralentissements est l'activation de la transparence sur les pistes par défaut (une requête d'un célèbre graphiste sur ce site je crois !). Dans certains cas (tailles de clips), la moteur s'est mis à appliquer des compositions continuellement. Ca a été corrigé progressivement… Par dessus le marché, nous sommes passés à des compositions plus fines (RGB vs YUV), ce qui implique des conversions qui ont un coût (surtout qu'on ne le fait toujours pas sur le GPU :-( )
De 2016 à 2019, presque tous les efforts étaient sur la réécriture sortie cette année (19.04) : depuis le début, la gestion du montage avait grossi dans quelques énormes classes, avec des imbrications indémêlables, au point que le debug et les évolutions étaient un affreux casse-tête. En repartant sur des modèles (avec tests) + vues (en qml), JB a reconstruit des bases propres, qui font que depuis on ne reçoit presque plus de rapport de crash sur cette partie, les petits bugs sont vite repérés et corrigé, et plein de nouvelles fonctions sont ajoutées pour permettre aux monteurs réguliers d'être plus rapides.
Il y avait encore quelques surcharges mémoires (avec les miniatures audio & vidéo), corrigées dans la 19.12, qui de l'avis de nombreux testeurs est plus réactive que jamais (Qt4 compris).
Concernant les effets disparus : comme MLT propose tous les plugins qu'il trouve, on se retrouvait avec une liste d'effets effrayante pour beaucoup, et la plupart mal gérés. Nous avons délégué la tâche de trier ces effets à nos utilisateurs (lors de plusieurs "cafés", nos discussions mensuelles sur IRC). Ils les ont testés un par un, et éliminé tous ceux qui étaient redondants ou qu'ils n'arrivaient pas à faire marcher. Ils ont aussi proposé une présélection des effets les plus attendus ; on affiche ceux-ci par défaut tout en laissant les liste plus étoffées dans les différentes catégories. Ce point est toujours en discussion !
Retour sur le point GPU : l'intégration de Movit (traitement d'image) est toujours aussi bugguée donc désactivée (l'option est même cachée), je crois que jouer ce jeu risque pour l'instant de vous exposer à quelques frustrations. Mais l'auteur de MLT l'a annoncé comme son chantier de 2020, espérons que ça change bientôt ! Après, certains ont suggéré que la technologie employée (GLSL) n'était peut-être pas très pertinente aujourd'hui, d'autres pistes pourraient être explorées.
Par contre, on constate souvent en profilant ce qui se passe pendant l'export que l'encodage (H264/5, VP8/9) reste la plupart du temps un contributeur majeur.
MLT peut tout à fait utiliser le GPU pour ça, rien à voir avec le traitement (c'est FFmpeg/libavcodec qui fait tout).
Des profils d'export via VAAPI (Intel, AMD) ou NVENC (Nvidia) sont disponibles à télécharger dans le magasin KDE ou même directement depuis le dialogue de rendu. Il faudrait les tester un peu mieux et les intégrer dans les releases…
Pour cela il faut que FFmpeg soit compilé avec les bonnes options, la plupart des distributions récentes proposent au moins VAAPI ; pour NVidia il faut voir, là peut-être qu'il faut chercher dans des dépôts tiers ou recompiler.
Ouf, ça en fait des choses à raconter !
Et dire que des nouveautés se préparent encore pour 2020…
Je vois l'intérêt d'en débattre : c'est à dire discuter de manière ouverte, en étant à l'écoute des besoins de l'autre, en exprimant clairement ses propres besoins, sans se poser en victime ni se moquer de l'autre.
Je les soutiens.
Elles écrivent des bios sur des inconnues… qui justement resteront inconnues tant qu'on ne les fera pas connaître, ça me semble logique.
Elles n'effacent pas l'encyclopédie, elles la complètent sur des sujets où elles pensent pouvoir apporter, c'est tout à fait le but de Wikipedia.
Tracim progresse vraiment à une vitesse impressionnante.
Le partage public est bien pratique, et l'édition collaborative (CODE) va vraiment débloquer les choses pour que je puisse le proposer dans les cercles où j'évolue… Par contre niveau auto-hébergement ça doit commencer à devenir compliqué ?!
Je ne manquerais pas de suggérer l'option payante pour vous soutenir :)
Les fondeurs font des efforts depuis longtemps pour se rendre plus indépendants des éditeurs de CAO, en se basant sur des PDK a décliner automatiquement vers divers outils. Même l'industrie CAO essaye de mettre en place des formats "standards" je crois (genre UPF).
Par ailleurs, Tim Edwards travaille pour efabless (pendant des décennies il faisait ça sur son boulot de prof+consultant je crois), c'est son job de fournir cet environnement fonctionnel. La c'est la démo que tout est prêt.
efabless semble dépendre de Xfab comme unique fonderie, ils ont probablement des accords pour avoir accès aux DK et autres corelibs (a moins qu'il n'utilise des DK & corelibs "génériques", non optimisées, comme ils le proposent dans les bouquins)…
C'est gagnant-gagnant ? La CAO devient accessible, et Xfab enrichit son catalogue d'IPs compatibles…
mais cette libéra(lisa)tion ne va-t-elle pas aussi vers une "uberisation" de la conception ?
quelques "artisans" utilisant Kdenlive :
- Purism : avec toutes les explications sur la démarche et les outils !
- Gunga (Brésil)
- ma chérie
- et plein de contributions dans la rubrique "vitrine" du site Kdenlive
Depuis 2012, plusieurs monteurs indépendants ont choisi Kdenlive comme outil de montage principal, et ont sorti des longs métrages : un en salles je crois, sur la POC21, mais assez confidentiel, et de nombreux en DVD/BlueRay (documentaires, captations de spectacles commercialisées).
Mais aussi de nombreux formats courts, diffusés sur des TV locales, en France (Rhône-Alpes, Bretagne) mais aussi au Brésil, en Estonie ; des lives sur des gros festivals…
En Inde et au Pakistan, 2 chaînes TV font (pré?-)monter leurs journalistes sous Kdenlive, mais ce ne sont pas vraiment des pros de la discipline et c'est probablement retravaillé derrière.
En 2015, Kdenlive a travaillé comme d'autres projets KDE à clarifier sa vision et ses missions (article sur l'ancien site… aux oubliettes :( ) ; résultat, il vise une utilisation pro (pour les petites structures c'est sûr, pas les gros studios).
Cette clarification a amené d'autres professionnels à s'investir dans le projet, justement pour informer les développeurs sur ce qu'il leur manque en priorité, ce qui les aiderait à améliorer l'efficacité du logiciel…
Ça commence juste à porter ses fruits, et les derniers retours sont très positifs !
Concernant MLT, c'est sûr que l'architecture est vieillotte et comporte de graves goulots d'étranglement concernant la performance (rendu multi-coeurs et sur puce graphique), des discussions sont en cours pour lui donner un bon coup de jeune, quitte à en faire un nouveau projet ?
Mais c'est aussi à la base un outil professionnel, qui a rapporté de l'argent à son auteur en prestation chez des diffuseurs.
Et un ASIC permet aussi de d'intégrer des fonctions analogiques, des périphériques et interfaces spécifiques (USB, lien RF ou NFC, contrôle de moteur…)
Un jour en marge de mon boulot j'ai cherché à faire l'inverse de websockify (bridge TCP vers WebSocket), cet outil étant en python je suis d'abord parti de ce code… et je ne m'en suis pas sorti, car pour éviter les dépendances il recode le protocole, mais juste ce qu'il lui faut.
Alors j'ai cherché dans d'autres implémentations, j'ai même essayé du perl !
Et puis j'ai dégaîné Qt, auquel je suis un peu plus habitué, et en 15 lignes j'avais mon outil qui marche, et il tourne depuis plusieurs années maintenant.
Issu de la communauté KDE, si je cherche quelque chose qui n'est pas encore dans Qt & KF5, je fais un tour sur inqlude et normalement ça s'intègre bien.
Et comme gestionnaire de paquet, "fatalement" je suis passé à Craft, et même si j'ai dû participer à pas mal d'empaquetage je suis bien content !
Pas mal de membres de la communauté KDE ont opté pour les Slimbooks, car la boîte avait demandé les specs voulues avant de sortir un modèle avec le logo KDE sérigraphié ; elle est sponsors de divers événements, offre du matos en cadeau (exemple : concours de fond d'écran en cours)…
Ton RPi sera sur les genoux avec Firefox/Chrome avant même de venir parler de bureau. Sauf évidemment si tu ne vous ne consultez que le site de RMS mais du coup, pourquoi installer KDE?
Il me semble que pas mal de gens surfent sur le web avec des configs similaires (quelques coeurs ARM à environ 1.5GHz, entre 2 et 4Go de RAM) : les tablettes et téléphones. Et Firefox et Chrome s'en sortent, surtout avec un bloqueur de pub.
L'effort se justifie sur les Single Board Computers (Pine64 etc), ChromeBooks, voire des téléphones (Librem5 etc) et tablettes pour Plasma Mobile: ils ne disposent pas de slot pour des barrettes de RAM, et quand tu n'as que 2 ou 4Go de soudés, tu es content que le système te laisse de la place pour quelques applis.
Désolé, mais quand je vois ça encore ressassé ça m'agace. Plasma tourne de manière fluide sur des cartes ARM même sans driver GPU propre.
Les effets à la enlightenment 16 ne sont plus activés par défaut depuis des années (bien sûr tout est configurable).
Note : KDE est une communauté, qui travaille sur le bureau Plasma, mais aussi Krita, digiKam, Kdenlive, WikiToLearn, Atelier…
Un personne "lambda" qui veut éditer du S37 n'aura peut-être pas peur du python (la réciproque n'étant pas vraie : quelqu'un qui veut éditer du python face au S37… ?)
Pour un programme compilé (pas PyQt alors), il est aussi possible de "linker" Qt en statique, et alors s'opère le grand ménage dans les fonctions…
On peut arriver à des résultats très compacts (exemple en embarqué: 7Mo non compressé).
Il me semble que la guerre des brevets se concentre plus sur les interfaces mobiles de nos jours, et dans la communauté OIN je ne retrouve pas nos chers amis de chez Apple, Samsung etc !
Hello,
Je n'y connais pas grand chose, mais dans le domaine des cadriciels web en C/C++, j'ai vu passer parfois des articles sur Cutelyst. Ça se base sur un Qt minimal (runtime pas bien lourd), c'est rapide, et assez élégant.
Et puis il y en a forcément en Rust & Go.
Enfin, bravo pour ton travail et merci pour l'info.
Carrément !
Prendre la main sur la doc pour la rendre plus claire :
par exemple les instructions que nous avions écrites pour compiler Kdenlive commençaient à sentir le moisi (instructions pour ubuntu 15.04…), petit à petit les contributeurs qui voulaient s'y mettre les ont mises à jour en posant des questions sur la mailing list ou IRC (et pour Windows aussi).
Par contre les indications pour OpenSuse et Fedora n'ont pas été mises à jour et ont donc disparu : ça pourrait être une petite touche facile à ajouter que d'indiquer comment installer les dépendances autrement qu'avec apt ?!
KDE aussi a de telles règles, exigeant notamment une documentation avant qu'une application puisse sortir de "review" vers "release"…
Le problème que souligne David Edmundson dans le AMA est que trop souvent la doc est écrite une fois au début et plus bien mise à jour ensuite :(
Autre souci : KDE offre 3 wikis : userbase, techbase et community, et les docs sont parfois rangées au mauvais endroit ou redondantes… Heureusement ce problème a été déjà bien élagué l'année dernière !
Bof. DCOP/DBus c'est de l'histoire très ancienne, qui concernent plutôt les développeurs… et de nos jours les membres actifs de KDE et Gnome qui se retrouvent côte à côte sur tous les salons et dans les tables rondes « bureau libre » sont plutôt copains, se filent des coups de main etc.
Je dirais que la guéguerre est plutôt chez les utilisateurs qui font parfois un choix radical. Quand ce sont des histoires de goût (ergonomie « puissante » ou « épurée »…) ça ne peut pas trop se discuter, mais invoquer la technologie à mon avis ça ne vaut plus quand la plupart des machines de bureau on plusieurs Go de RAM (etencore)
Ça fait plein de petits paquets à installer, justement parce que le gros ensemble KDElibs a été modularisé en KDE Frameworks dont on peut prendre le minimum.
Le délire de refuser d'installer 20Mo de librairies C++ alors que même un téléphone à 50 balles dispose de 8Go de "disque", c'est vraiment pas rationnel ! Alors qu'à côté de ça on installe des JDK et autres Electron qui pèsent 10 fois plus…
C'est renier le boulot d'une partie de la communauté libre pour des critères… sectaires ?
Désolé de m'énerver encore face à ce problème :-\
L'annonce de la 2.0 m'avait propulsé à écrire un filtre MLT appelant GMIC…
Malheureusement je n'y ai passé que 2 soirées fatigué, freiné par une segfault par-ci, une corruption d'image par là…
J'ai trouvé alors que votre documentation est encourageante (ça a l'air fastoche !), et finalement je suis resté rapidement avec des questions sans réponses (surtout sans connexion internet).
J'ai regardé du côté de ZArt, ça m'a un peu aidé aussi. J'avais entendu parler de Natron & OpenFX mais je ne m'y suis pas retrouvé.
Auriez-vous des conseils, déjà pour bricoler un prototype, et puis pour optimiser la vitesse de rendu (en limitant les interprétations redondantes de script, les allocations et copies de buffers, les conversions d'images…) ?
Bon, mais c'est surtout à moi de me cravacher un peu !
Merci merci pour ce beau travail, de matheux (pour les algos) et d'artiste (pour l'utilisation à bon escient) : David & David on vous aime !!
# Précisions
Posté par vpinon . En réponse au journal kdenlive 19.12.0 et accélération matérielle. Évalué à 10.
Bonjour,
D'abord merci de faire passer des nouvelles sur Kdenlive…
Et j'ai quelques réactions :)
Tout d'abord, je trouve injuste de dire que ça s'est empiré depuis 2013, que ce soit en stabilité ou en performances.
Nous avons basculé sur l'affichage OpenGL dès la branche Qt4, quand est apparue l'intégration de Movit (effets calculés sur le GPU) qui était très prometteuse et requérait ce changement. Malheureusement l'intégration GPU / Multithreading est compliquée (pour MLT, mais pas que), toujours instable depuis 5 ans, et nous avons donc dû désactiver cette option car trop d'utilisateurs se cassaient les dents là dessus. Nous cherchons toujours des contributeurs maîtrisant ces domaines : ce n'est pas vraiment à la portée du premier bricoleur venu (comme moi :-P)
Hormis les effets, l'affichage via OpenGL a visiblement causé des ralentissements chez certains utilisateurs, minoritaires et malheureusement sans qu'on trouve jamais l'explication. En tout cas chez les développeurs, les testeurs réguliers et d'après le bug tracker, rien n'a justifié un retour en arrière, qui serait compliqué maintenant. Moi-même j'ai un vieux i5 (3ème génération ?) avec 4Go de RAM, GPU Intel intégré : ça roule toujours !
Le passage à Qt5 en 2015 (indispensable car Qt4 en fin de vie) a engendré des régressions et instabilités, gommées au bout d'environ un an alors que le distributions opéraient la transition.
Un autre facteur qui a engendré des ralentissements est l'activation de la transparence sur les pistes par défaut (une requête d'un célèbre graphiste sur ce site je crois !). Dans certains cas (tailles de clips), la moteur s'est mis à appliquer des compositions continuellement. Ca a été corrigé progressivement… Par dessus le marché, nous sommes passés à des compositions plus fines (RGB vs YUV), ce qui implique des conversions qui ont un coût (surtout qu'on ne le fait toujours pas sur le GPU :-( )
De 2016 à 2019, presque tous les efforts étaient sur la réécriture sortie cette année (19.04) : depuis le début, la gestion du montage avait grossi dans quelques énormes classes, avec des imbrications indémêlables, au point que le debug et les évolutions étaient un affreux casse-tête. En repartant sur des modèles (avec tests) + vues (en qml), JB a reconstruit des bases propres, qui font que depuis on ne reçoit presque plus de rapport de crash sur cette partie, les petits bugs sont vite repérés et corrigé, et plein de nouvelles fonctions sont ajoutées pour permettre aux monteurs réguliers d'être plus rapides.
Il y avait encore quelques surcharges mémoires (avec les miniatures audio & vidéo), corrigées dans la 19.12, qui de l'avis de nombreux testeurs est plus réactive que jamais (Qt4 compris).
Concernant les effets disparus : comme MLT propose tous les plugins qu'il trouve, on se retrouvait avec une liste d'effets effrayante pour beaucoup, et la plupart mal gérés. Nous avons délégué la tâche de trier ces effets à nos utilisateurs (lors de plusieurs "cafés", nos discussions mensuelles sur IRC). Ils les ont testés un par un, et éliminé tous ceux qui étaient redondants ou qu'ils n'arrivaient pas à faire marcher. Ils ont aussi proposé une présélection des effets les plus attendus ; on affiche ceux-ci par défaut tout en laissant les liste plus étoffées dans les différentes catégories. Ce point est toujours en discussion !
Retour sur le point GPU : l'intégration de Movit (traitement d'image) est toujours aussi bugguée donc désactivée (l'option est même cachée), je crois que jouer ce jeu risque pour l'instant de vous exposer à quelques frustrations. Mais l'auteur de MLT l'a annoncé comme son chantier de 2020, espérons que ça change bientôt ! Après, certains ont suggéré que la technologie employée (GLSL) n'était peut-être pas très pertinente aujourd'hui, d'autres pistes pourraient être explorées.
Par contre, on constate souvent en profilant ce qui se passe pendant l'export que l'encodage (H264/5, VP8/9) reste la plupart du temps un contributeur majeur.
MLT peut tout à fait utiliser le GPU pour ça, rien à voir avec le traitement (c'est FFmpeg/libavcodec qui fait tout).
Des profils d'export via VAAPI (Intel, AMD) ou NVENC (Nvidia) sont disponibles à télécharger dans le magasin KDE ou même directement depuis le dialogue de rendu. Il faudrait les tester un peu mieux et les intégrer dans les releases…
Pour cela il faut que FFmpeg soit compilé avec les bonnes options, la plupart des distributions récentes proposent au moins VAAPI ; pour NVidia il faut voir, là peut-être qu'il faut chercher dans des dépôts tiers ou recompiler.
Ouf, ça en fait des choses à raconter !
Et dire que des nouveautés se préparent encore pour 2020…
Bon montage à tous !
[^] # Re: Réponse éclairée faite à 2h du mat
Posté par vpinon . En réponse au journal Écriture inclusive, féministes et Wikipédia. Évalué à 0.
Je vois l'intérêt d'en débattre : c'est à dire discuter de manière ouverte, en étant à l'écoute des besoins de l'autre, en exprimant clairement ses propres besoins, sans se poser en victime ni se moquer de l'autre.
Je les soutiens.
Elles écrivent des bios sur des inconnues… qui justement resteront inconnues tant qu'on ne les fera pas connaître, ça me semble logique.
Elles n'effacent pas l'encyclopédie, elles la complètent sur des sujets où elles pensent pouvoir apporter, c'est tout à fait le but de Wikipedia.
# Bravo !
Posté par vpinon . En réponse à la dépêche Plus d’excuse pour ne plus collaborer (avec Tracim 2.5) !. Évalué à 4.
Tracim progresse vraiment à une vitesse impressionnante.
Le partage public est bien pratique, et l'édition collaborative (CODE) va vraiment débloquer les choses pour que je puisse le proposer dans les cercles où j'évolue… Par contre niveau auto-hébergement ça doit commencer à devenir compliqué ?!
Je ne manquerais pas de suggérer l'option payante pour vous soutenir :)
Courage et à bientôt !
[^] # Re: Blagues du vendredi
Posté par vpinon . En réponse au journal Blagues Friday. Évalué à 10.
Pour les geeks (vu il y a peu au tableau d'une salle de réunion) :
« Un homme azerty en vaut é »
[^] # Re: cout logiciel
Posté par vpinon . En réponse à la dépêche Un ASIC conçu intégralement avec des logiciels libres. Évalué à 4.
Les fondeurs font des efforts depuis longtemps pour se rendre plus indépendants des éditeurs de CAO, en se basant sur des PDK a décliner automatiquement vers divers outils. Même l'industrie CAO essaye de mettre en place des formats "standards" je crois (genre UPF).
Par ailleurs, Tim Edwards travaille pour efabless (pendant des décennies il faisait ça sur son boulot de prof+consultant je crois), c'est son job de fournir cet environnement fonctionnel. La c'est la démo que tout est prêt.
efabless semble dépendre de Xfab comme unique fonderie, ils ont probablement des accords pour avoir accès aux DK et autres corelibs (a moins qu'il n'utilise des DK & corelibs "génériques", non optimisées, comme ils le proposent dans les bouquins)…
C'est gagnant-gagnant ? La CAO devient accessible, et Xfab enrichit son catalogue d'IPs compatibles…
mais cette libéra(lisa)tion ne va-t-elle pas aussi vers une "uberisation" de la conception ?
[^] # Re: Kdenlive?
Posté par vpinon . En réponse à la dépêche Cinéma, logiciels libres ou non : état des lieux. Évalué à 6. Dernière modification le 05 juillet 2019 à 12:28.
quelques "artisans" utilisant Kdenlive :
- Purism : avec toutes les explications sur la démarche et les outils !
- Gunga (Brésil)
- ma chérie
- et plein de contributions dans la rubrique "vitrine" du site Kdenlive
[^] # Re: Kdenlive?
Posté par vpinon . En réponse à la dépêche Cinéma, logiciels libres ou non : état des lieux. Évalué à 10.
Pas d'accord :)
Depuis 2012, plusieurs monteurs indépendants ont choisi Kdenlive comme outil de montage principal, et ont sorti des longs métrages : un en salles je crois, sur la POC21, mais assez confidentiel, et de nombreux en DVD/BlueRay (documentaires, captations de spectacles commercialisées).
Mais aussi de nombreux formats courts, diffusés sur des TV locales, en France (Rhône-Alpes, Bretagne) mais aussi au Brésil, en Estonie ; des lives sur des gros festivals…
En Inde et au Pakistan, 2 chaînes TV font (pré?-)monter leurs journalistes sous Kdenlive, mais ce ne sont pas vraiment des pros de la discipline et c'est probablement retravaillé derrière.
En 2015, Kdenlive a travaillé comme d'autres projets KDE à clarifier sa vision et ses missions (article sur l'ancien site… aux oubliettes :( ) ; résultat, il vise une utilisation pro (pour les petites structures c'est sûr, pas les gros studios).
Cette clarification a amené d'autres professionnels à s'investir dans le projet, justement pour informer les développeurs sur ce qu'il leur manque en priorité, ce qui les aiderait à améliorer l'efficacité du logiciel…
Ça commence juste à porter ses fruits, et les derniers retours sont très positifs !
Concernant MLT, c'est sûr que l'architecture est vieillotte et comporte de graves goulots d'étranglement concernant la performance (rendu multi-coeurs et sur puce graphique), des discussions sont en cours pour lui donner un bon coup de jeune, quitte à en faire un nouveau projet ?
Mais c'est aussi à la base un outil professionnel, qui a rapporté de l'argent à son auteur en prestation chez des diffuseurs.
[^] # Re: Avantages de l'ASIC
Posté par vpinon . En réponse à la dépêche Un ASIC conçu intégralement avec des logiciels libres. Évalué à 8.
Et un ASIC permet aussi de d'intégrer des fonctions analogiques, des périphériques et interfaces spécifiques (USB, lien RF ou NFC, contrôle de moteur…)
# Qt ça aide bien
Posté par vpinon . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 7.
Un jour en marge de mon boulot j'ai cherché à faire l'inverse de websockify (bridge TCP vers WebSocket), cet outil étant en python je suis d'abord parti de ce code… et je ne m'en suis pas sorti, car pour éviter les dépendances il recode le protocole, mais juste ce qu'il lui faut.
Alors j'ai cherché dans d'autres implémentations, j'ai même essayé du perl !
Et puis j'ai dégaîné Qt, auquel je suis un peu plus habitué, et en 15 lignes j'avais mon outil qui marche, et il tourne depuis plusieurs années maintenant.
Issu de la communauté KDE, si je cherche quelque chose qui n'est pas encore dans Qt & KF5, je fais un tour sur inqlude et normalement ça s'intègre bien.
Et comme gestionnaire de paquet, "fatalement" je suis passé à Craft, et même si j'ai dû participer à pas mal d'empaquetage je suis bien content !
[^] # Re: Slimbook
Posté par vpinon . En réponse au journal Sélection d'un PC libre. Évalué à 2.
Pas mal de membres de la communauté KDE ont opté pour les Slimbooks, car la boîte avait demandé les specs voulues avant de sortir un modèle avec le logo KDE sérigraphié ; elle est sponsors de divers événements, offre du matos en cadeau (exemple : concours de fond d'écran en cours)…
[^] # Re: userland
Posté par vpinon . En réponse au journal Mon retour sous KDE. Évalué à 1.
Il me semble que pas mal de gens surfent sur le web avec des configs similaires (quelques coeurs ARM à environ 1.5GHz, entre 2 et 4Go de RAM) : les tablettes et téléphones. Et Firefox et Chrome s'en sortent, surtout avec un bloqueur de pub.
[^] # Re: userland
Posté par vpinon . En réponse au journal Mon retour sous KDE. Évalué à 3.
L'effort se justifie sur les Single Board Computers (Pine64 etc), ChromeBooks, voire des téléphones (Librem5 etc) et tablettes pour Plasma Mobile: ils ne disposent pas de slot pour des barrettes de RAM, et quand tu n'as que 2 ou 4Go de soudés, tu es content que le système te laisse de la place pour quelques applis.
[^] # Re: l'opposé
Posté par vpinon . En réponse au journal Nvidia travaille sur le support d'EGLStreams pour KDE/Wayland. Évalué à 8. Dernière modification le 15 novembre 2018 à 21:17.
Désolé, mais quand je vois ça encore ressassé ça m'agace.
Plasma tourne de manière fluide sur des cartes ARM même sans driver GPU propre.
Les effets à la enlightenment 16 ne sont plus activés par défaut depuis des années (bien sûr tout est configurable).
Note : KDE est une communauté, qui travaille sur le bureau Plasma, mais aussi Krita, digiKam, Kdenlive, WikiToLearn, Atelier…
[^] # Re: Quel usage de Qt
Posté par vpinon . En réponse au journal Réduire la taille des exécutables générés avec PyInstaller. Évalué à 3.
Un personne "lambda" qui veut éditer du S37 n'aura peut-être pas peur du python (la réciproque n'étant pas vraie : quelqu'un qui veut éditer du python face au S37… ?)
[^] # Re: go
Posté par vpinon . En réponse au journal Réduire la taille des exécutables générés avec PyInstaller. Évalué à 6.
Pour un programme compilé (pas PyQt alors), il est aussi possible de "linker" Qt en statique, et alors s'opère le grand ménage dans les fonctions…
On peut arriver à des résultats très compacts (exemple en embarqué: 7Mo non compressé).
# les brevets logiciels ne sont pas que sur le serveur et le bureau
Posté par vpinon . En réponse au journal Vers une fin de la guerre des brevets logiciels ?. Évalué à 7.
Il me semble que la guerre des brevets se concentre plus sur les interfaces mobiles de nos jours, et dans la communauté OIN je ne retrouve pas nos chers amis de chez Apple, Samsung etc !
# Cutelyst
Posté par vpinon . En réponse au journal Des nouvelles d'Ulfius, framework web en C. Évalué à 6.
Hello,
Je n'y connais pas grand chose, mais dans le domaine des cadriciels web en C/C++, j'ai vu passer parfois des articles sur Cutelyst. Ça se base sur un Qt minimal (runtime pas bien lourd), c'est rapide, et assez élégant.
Et puis il y en a forcément en Rust & Go.
Enfin, bravo pour ton travail et merci pour l'info.
[^] # Re: Merci!
Posté par vpinon . En réponse au journal Discussion sur les objectifs de la communauté KDE. Évalué à 5.
Carrément !
Prendre la main sur la doc pour la rendre plus claire :
par exemple les instructions que nous avions écrites pour compiler Kdenlive commençaient à sentir le moisi (instructions pour ubuntu 15.04…), petit à petit les contributeurs qui voulaient s'y mettre les ont mises à jour en posant des questions sur la mailing list ou IRC (et pour Windows aussi).
Par contre les indications pour OpenSuse et Fedora n'ont pas été mises à jour et ont donc disparu : ça pourrait être une petite touche facile à ajouter que d'indiquer comment installer les dépendances autrement qu'avec apt ?!
[^] # Re: Merci!
Posté par vpinon . En réponse au journal Discussion sur les objectifs de la communauté KDE. Évalué à 5.
KDE aussi a de telles règles, exigeant notamment une documentation avant qu'une application puisse sortir de "review" vers "release"…
Le problème que souligne David Edmundson dans le AMA est que trop souvent la doc est écrite une fois au début et plus bien mise à jour ensuite :(
Autre souci : KDE offre 3 wikis : userbase, techbase et community, et les docs sont parfois rangées au mauvais endroit ou redondantes… Heureusement ce problème a été déjà bien élagué l'année dernière !
[^] # Re: KDE et Gnome
Posté par vpinon . En réponse au journal KDE Connect et GNOME. Évalué à -5.
Bof. DCOP/DBus c'est de l'histoire très ancienne, qui concernent plutôt les développeurs… et de nos jours les membres actifs de KDE et Gnome qui se retrouvent côte à côte sur tous les salons et dans les tables rondes « bureau libre » sont plutôt copains, se filent des coups de main etc.
Je dirais que la guéguerre est plutôt chez les utilisateurs qui font parfois un choix radical. Quand ce sont des histoires de goût (ergonomie « puissante » ou « épurée »…) ça ne peut pas trop se discuter, mais invoquer la technologie à mon avis ça ne vaut plus quand la plupart des machines de bureau on plusieurs Go de RAM (et encore)
Pardonnez moi, je me sens en plein 386
[^] # Re: KDE et Gnome
Posté par vpinon . En réponse au journal KDE Connect et GNOME. Évalué à 10.
Ça fait plein de petits paquets à installer, justement parce que le gros ensemble KDElibs a été modularisé en KDE Frameworks dont on peut prendre le minimum.
Le délire de refuser d'installer 20Mo de librairies C++ alors que même un téléphone à 50 balles dispose de 8Go de "disque", c'est vraiment pas rationnel ! Alors qu'à côté de ça on installe des JDK et autres Electron qui pèsent 10 fois plus…
C'est renier le boulot d'une partie de la communauté libre pour des critères… sectaires ?
Désolé de m'énerver encore face à ce problème :-\
[^] # Re: horaire décalé
Posté par vpinon . En réponse au journal Venez rencontrer l'équipe Kdenlive. Évalué à 2.
2h45pm = 14h45
Merci pour la remarque !
# Lien pour les dons
Posté par vpinon . En réponse au journal Venez rencontrer l'équipe Kdenlive. Évalué à 1.
héhé, j'ai recopié le lien du post qui n'est pas bien pertinent, voilà le bon
# Intégration dans Kdenlive
Posté par vpinon . En réponse à la dépêche G’MIC : 2.2, v’là les filtres !. Évalué à 8.
Hello,
L'annonce de la 2.0 m'avait propulsé à écrire un filtre MLT appelant GMIC…
Malheureusement je n'y ai passé que 2 soirées fatigué, freiné par une segfault par-ci, une corruption d'image par là…
J'ai trouvé alors que votre documentation est encourageante (ça a l'air fastoche !), et finalement je suis resté rapidement avec des questions sans réponses (surtout sans connexion internet).
J'ai regardé du côté de ZArt, ça m'a un peu aidé aussi. J'avais entendu parler de Natron & OpenFX mais je ne m'y suis pas retrouvé.
Auriez-vous des conseils, déjà pour bricoler un prototype, et puis pour optimiser la vitesse de rendu (en limitant les interprétations redondantes de script, les allocations et copies de buffers, les conversions d'images…) ?
Bon, mais c'est surtout à moi de me cravacher un peu !
Merci merci pour ce beau travail, de matheux (pour les algos) et d'artiste (pour l'utilisation à bon escient) : David & David on vous aime !!
# Tu oublies le NTSC
Posté par vpinon . En réponse au journal En évoquant Facebook. Évalué à 6.
Et le grandiose 29.97=30*1000/1001