De retour de vacances et après une semaine chargée (le temps de tout remettre en ordre, c’était la jungle chez moi!!!), il est temps pour moi de faire un bilan de la 1ere campagne KickStarter du projet Openshot. J’en profite aussi pour faire un 1er point d’informations sur le début du travail qui a commencé entre temps. Mais avant de commencer cette campagne, nous n’imaginions pas du tout obtenir un tel succès, ce qui nous conforte aussi dans tout le travail effectué mais aussi dans l’espoir qu’apporte la nouvelle version de ce projet et dont les objectifs sont très attendues par la communauté des amoureux de la vidéo. Un grand merci aux 1463 donneurs qui ont permis de récolter la somme inattendue mais incroyable de 45 028 $US. Et un grand merci à toutes celles et tout ceux qui ont diffusé la nouvelle dans toutes les communautés. Merci à vous de croire en ce projet autant que nous y croyons nous-même.
Les donateurs
Les donateurs (pour un montant supérieur ou égal à 25$) vont recevoir un sondage qui collectera les informations de bases (email adresse, taille du T-Shirt, …..) nécessaires pour l’envoie de leur « cadeaux » (enfin bref, ceux qui ont droit). Ensuite des certificats de contributions signés par Jonathan seront ensuite envoyés. Plus vite, vous répondrez, plus vite nous pourrons commencer la nouvelle version.
Parmi tous ces donateurs, MediaCollege est le plus important avec une promesse de don de 1500 $US. Si comme moi, vous ne connaissiez pas ce site, il propose des centaines de tutoriels dans les domaines de l’audio, de la production vidéo et télévisuelle, la photographie, le graphisme, le design web, internet et plus……. Vraiment très intéressant ce site.
D’ailleurs voici un aperçu de ce qui est proposé sur OpenShot.
A ce jour, Jonathan attends encore le transfert des fonds de KickStarter afin de pouvoir commencer à acheter tous les « cadeaux »pour les contributeurs qui y ont droit.
Le plan de développement
Nous publierons prochainement sur le blog officiel (que je communiquerai aussi pour la communauté francophone) un plan de développement comprenant un calendrier pour les dates clés et les milestones envisagées. Bien que l’ajout des 5 nouveaux objectifs (et de leur succès!) a chamboulé notre plan initial, nous comptons toujours réaliser celle-ci pour Décembre. Pour les plus curieux d’entre vous, Jonathan essaiera, dans la mesure du possible, de publier un calendrier détaillé avec les MAJ quotidienne (dans la mesure du possible). Nous mettons un point d’honneur à tenir le plus informé notre communauté dans son ensemble (donateurs bien entendu mais aussi simple utilisateurs) des progrès et des difficultés que nous traverserons jusqu’à la réalisation de la version 2.0.0.
D’ailleurs, voici une nouvelle qui va en surprendre plus d’un, lié à des difficultés que nous avons avec GTK3. Nous avons pris l’une de nos plus grandes décisions à ce jour pour le projet : le passage de GTK à QT. Nous (l’équipe d’Openshot bien entendu!) avons étudié consciencieusement toutes les options s’offrant à nous et nous pensons qu’il s’agit de la meilleur solution. Vous vous doutez bien que nous avons mûrement réfléchi car cela entraîne avec le nouveau framework (i.e libopenshot) et la nouvelle timeline (utilisant HTML5, CSS3 et Javascript) et maintenant QT une refonte totale du projet. Un des facteurs majeur qui a entraîne ce choix est la très grande qualité de ses widgets pour l’utilisation avec HTLM et Javascript (pour notre timeline et le widget pour les courbes), pour son très bon support multi-plateforme (Linux, Mac OSX et Windows), pour une facilité d’utilisation d’OpenCL (qui affichera notre prévisualisateur de vidéo). Cela nous permettra aussi d’envisager et d’explorer des possibilités auquel nous ne pouvions répondre jusqu’à présent (exp: avoir des fenêtres détaches à volonté). Il est vrai que l’on y pense. Mais rien n’est moins sur pour l’instant et surtout pour la version en question (i.e la 2.0.0) avec un travail énorme et 7 mois pour y parvenir. Mais qui sait, plus tard………. au moins tout sera en place pour ……………..le bon moment. En faisant ces choix, nous mettons pas mal de choses en place pour maintenant et surtout pour plus tard.
Le passage à QT 5.0 va nous permettre aussi de simplifier le code. Nous enlèverons des centaines de lignes de codes lié à GTK désormais inutiles et qui seront remplacées soit par du Javascript soit par une API plus simple. Cela diminuera la complexité du code du projet et donc améliorera aussi à sa stabilité. Eh oui, même si nous faisons de grands bouleversements, les mots d’ordre du projet sont toujours les même, à savoir Stabilité, Simplicité d’installation et d’utilisation et Performance de tout ordre.
Une précision s’impose pour les non-initiés. Le fait de passer de GTK à QT est juste un changement de toolkit pour créer les interfaces (vous savez vos belles fenêtres) mais cela ne signifie pas que nous quittons des environnements GTK (Gnome3, Unity, XFCE, LXDE) à KDE. Il n’en n’est rien. Il n’y a pas de corrélation/d’obligation d’utiliser KDE pour utiliser QT. QT s’installe partout y compris sur vos téléphones. D’ailleurs, en parlant de QT, le développeur principal de l’environnement ultra léger LXDE Hong Jen Hey développé en GTK2 a exploré avec un certain succès le passage à QT comme le confirme ce post en français mais aussi sur le blog officiel. Les deux branches vont coexister pour l’instant.
D’ailleurs, une très belle vidéo démontrant les fonctionnalités de QT 5.0.
Et maintenant ?
Nous nous réunirons dans la semaine afin de discuter de tous ça entre nous et de prendre les décisions finales pour le plan de développement final. Bien entendu, nous vous tiendrons au courant dès que possible notament sur les plans au niveau de l’accélération Hardware, l’édition distribuée (avec le serveur), des prototypes et MAJ ainsi que des améliorations de notre interface. Stay tuned.
Cenwen's Blog 
Petit bug : dans ‘Le plan de développement’ §2 (première fois que j’utilise ce symbole ^^) ligne 3, vous avez marqué ‘le passage de QT à GTK’. C’est l’inverse, non ?
En effet. Merci et Rectification faite.
Je ne m’oppose aucunement à la migration de OpenShot de GTK vers Qt mais ça me titille un peu qu’on fasse mal paraître GTK avec des assertions un peu vagues, genre «oh mon dieu GTK est super compliqué, Qt est super simple» et «on va pouvoir virer des centaines et des centaines de lignes de code».
Déjà, sur la quantité de lignes de code, je pourrais dire que si vous avez beaucoup de code fait à la main pour l’interface graphique GTK (excepté les rares widgets générés à la volée), au lieu de maximiser l’utilisation des fichiers GtkBuilder (fabriqués avec Glade, donc zéro ligne de code à écrire), «You’re doing it Wrong™».
Pour ce qui est des widgets détachables… GTK le fait facilement.
J’ai vu diverses personnes me dire que Qt est tellement plus facile etc., mais quand je leur demande pourquoi spécifiquement, personne n’est capable de me donner des clarifications au-delà de «faire du drag & drop avec GTK, c’est tordu» (iconview, treeview, drag & drop sont les trois trucs les plus chiants de GTK, j’en conviens, mais une fois que c’est fait, c’est fait). Peut-être que tu peux m’apprendre quelque chose que je ne sais pas à ce sujet 🙂
Ceci étant dit, Qt ça a du sens si on veut un toolkit en meilleur état présentement pour l’intégration Mac OS et Windows. En passant, qui va coder le port de GTK à Qt pour Openshot (en plus de Jonathan)?
Bonne continuation!
Tu interprètes mes paroles à ta sauce (ex GTK super compliqué………..) mais peu importe, ce n’est le sens de ma réponse.
Si nous avons choisi QT pour les raisons que j’ai expliqué (meilleur support multiplate-forme (comme tu le dis à la fin), une meilleur utilisation d’OpenCL, c’est surtout pour la timeline que cela coince alors que Webkit fonctionne du tonnerre de dieu (comme à Scale 11X). Mais plutôt d’expliquer et vu que tu comprends l’anglais mieux que moi (chanceux), je vais mettre ce à quoi nous sommes confrontés après avoir testés ceux ci. A noté que c’est pareil pour les versions inférieur à QT 4.5. inclus, d’où le choix de QT 5.0. Je prends la liberté de mettre cette conversation privé ici.
« However, I’ve ran into 2 big problems:
GtkWebkit (a widget to embed a webkit browser) is too slow. It’s horribly slow. Unusable.
gtkmozembed (a widget to embed a gecko browser) is very fast, but is no longer available in Debian. It is also no longer being maintained by Mozilla. I did not expect that, as this was my preferred choice based on my early testing of this technology. Crap!
So, both techniques to embed browsers in GTK suck. Also in my mind, is porting OpenShot’s GTK code to Mac and Windows, both which have a few issues… mostly dealing with non-native widgets that look out of place, or X11 drawing issues. »
>>>Déjà, sur la quantité de lignes de code, je pourrais dire que si vous avez beaucoup de code fait à la main pour l’interface graphique GTK (excepté les rares widgets générés à la volée), au lieu de maximiser l’utilisation des fichiers GtkBuilder (fabriqués avec Glade, donc zéro ligne de code à écrire), «You’re doing it Wrong™
Je suis surpris que tu ne saches pas que nous utilisons Glade depuis le début. 😦
>>>Pour ce qui est des widgets détachables… GTK le fait facilement.
Je me suis probablement mal exprimé mais je parlai d’avoir la possibilité de détacher le lecteur vidéo et de le mettre en grand écran par exemple sur un autre bureau, à coté ou bien mieux sur un 2eme écran.
Vu que nous allons tout refaire, c’est l’occasion d’améliorer l’interface et de penser à cette fonctionnalité pour un futur proche (pas nécessairement pour la 2.0.0 mais après pourquoi pas).
>>>J’ai vu diverses personnes me dire que Qt est tellement plus facile etc., mais quand je leur demande pourquoi spécifiquement, personne n’est capable de me donner des clarifications au-delà de «faire du drag & drop avec GTK, c’est tordu» (iconview, treeview, drag & drop sont les trois trucs les plus chiants de GTK, j’en conviens, mais une fois que c’est fait, c’est fait). Peut-être que tu peux m’apprendre quelque chose que je ne sais pas à ce sujet 🙂
Pas encore car personnellement, je code en GTK avec Glade3. Mais qui c’est, cela viendra. 🙂 J’ai tout à apprendre à ce niveau là.
Mais effectivement ces trois points que tu évoques sont bien très chiant, je confirme.
>>>Ceci étant dit, Qt ça a du sens si on veut un toolkit en meilleur état présentement pour l’intégration Mac OS et Windows. En passant, qui va coder le port de GTK à Qt pour Openshot (en plus de Jonathan)?
Tout ceux qui voudrons et qui seront le bienvenue; bien entendu mais c’est surtout la Core (engine) Team cad outre Jonathan comme tu l’as dis, Andy, Mael et Moi.
>>>Bonne continuation!
Merci. 🙂
Au fait, du tant que je t’ai, il n’y a toujours pas de version de Pitivi à l’horizon ? La dernière (la 0.1.5) date du 28 septembre 2011 (à moi que j’en ai raté une entre temps).
Tu penseras à rajouter à ton graphique 2 nouvelle distributions basées sur MLT(si ce n’est pas déjà fait) : Flowblade et Shortcut de Dan Dennedy lui-même.
Tiens, j’avais pas entendu parler que WebkitGTK était lent d’une façon ou d’une autre. Après tout t’as des browsers comme Epiphany, Midori, et diverses autres applications qui l’utilisent et qui sont mille fois plus réactives que Firefox (pour ne nommer qu’un seul point de comparaison)… Je me réserve un doute sur ce point.
Openshot qui utilise glade: j’avais remarqué, mais comme je dis, à quel point? Et quand j’ai vu que ça utilisait encore des choses comme simplegladeapp (simplegtkbuilderapp.py) j’en ai eu des frissons 🙂
Prochaine version de Pitivi: là on en est à tabasser des bugs dans le coeur de GStreamer, côté interface et nouvelle timeline c’est fait (youppie!). Je commence à voir la lumière au bout du tunnel mais je ne sais pas exactement quand on va pouvoir releaser, parce que mes critères de qualité/stabilité sont très élevés et que le but est un peu de se débarrasser de tous les problèmes qui affligeaient les releases précédentes. Croisons les doigts pour cet été avant GUADEC je suppose.
Cladogramme/graphique d’histoire: yep, Shotcut et Flowblade y étaient déjà 😉 d’ailleurs je me dois de dire que Openshot est un cas spécial… je suis obligé de faire confiance à des ouï dires au lieu de pouvoir inspecter l’activité dans les dépôts de code (c’est d’ailleurs pourquoi le cladogramme n’a pas été mis à jour depuis des mois).
Honnêtement c’est chiant/énervant, Openshot semble développé derrière portes closes depuis plus d’un an (si on veut être très strict, depuis Septembre… mais je ne crois pas que les quelques commits en Septembre et Mai dernier ayant servi à la release bugfix 1.4.3 soient indicatifs du développement de la nouvelle mouture majeure basée sur OSL), je ne vois pas pourquoi ce n’est pas sur des dépôts publics – Pitivi a beau être en développement prolongé, tout est 100% public, tout est dans le dépôt officiel et n’importe qui peut aller tester le bestiau à tout moment pour voir l’état de la situation.
>>>Tiens, j’avais pas entendu parler que WebkitGTK était lent d’une façon ou d’une autre. Après tout t’as des browsers comme Epiphany, Midori, et diverses autres applications qui l’utilisent et qui sont mille fois plus réactives que Firefox (pour ne nommer qu’un seul point de comparaison)… Je me réserve un doute sur ce point.
Pas pour ce que nous faisons avec.
>>>Openshot qui utilise glade: j’avais remarqué, mais comme je dis, à quel point? Et quand j’ai vu que ça utilisait encore des choses comme simplegladeapp (simplegtkbuilderapp.py) j’en ai eu des frissons 🙂
Tiens je l’avais oublié celui-là. Un truc inutile en moins
>>>Prochaine version de Pitivi: là on en est à tabasser des bugs dans le coeur de GStreamer, côté interface et nouvelle timeline c’est fait (youppie!). Je commence à voir la lumière au bout du tunnel mais je ne sais pas exactement quand on va pouvoir releaser, parce que mes critères de qualité/stabilité sont très élevés et que le but est un peu de se débarrasser de tous les problèmes qui affligeaient les releases précédentes. Croisons les doigts pour cet été avant GUADEC je suppose.
Bon continuation et tabasser fort. 🙂
>>>Cladogramme/graphique d’histoire: yep, Shotcut et Flowblade y étaient déjà 😉 d’ailleurs je me dois de dire que Openshot est un cas spécial… je suis obligé de faire confiance à des ouï dires au lieu de pouvoir inspecter l’activité dans les dépôts de code (c’est d’ailleurs pourquoi le cladogramme n’a pas été mis à jour depuis des mois).
Franchement, je n’ai pas regardé ton graphique (Cladogramme ????). Marrant moi je me fis plus aux versions, car de l’agitation dans les depots de code ne veut pas tout dire prend par exemple Lumiera et toujours rien. Bon il est vrai que je n’ai plus le lien depuis un an mais ça bougeait beaucoup mais sans version.
>>>Honnêtement c’est chiant/énervant, Openshot semble développé derrière portes closes depuis plus d’un an (si on veut être très strict, depuis Septembre… mais je ne crois pas que les quelques commits en Septembre et Mai dernier ayant servi à la release bugfix 1.4.3 soient indicatifs du développement de la nouvelle mouture majeure basée sur OSL), je ne vois pas pourquoi ce n’est pas sur des dépôts publics – Pitivi a beau être en développement prolongé, tout est 100% public, tout est dans le dépôt officiel et n’importe qui peut aller tester le bestiau à tout moment pour voir l’état de la situation.
Ne t’en fais pas c’est sur 2 serveurs sécurisés et tout sera rapatrié sur Launchpad avec les commits faits quand cela sera le moment. Et cela le restera après.
Le dev est toujours en cours mais chacun fait ce qu’il a faire à son rythme sur ce qu’il veut et il y aura bcp d’agitation quand il le faudra.
C’est un acte de balance/jugement lors de l’analyse. D’ailleurs, Lumiera est bien indiqué comme mort sur mon graphique/cladogramme (et ça me rappelle qu’il faudrait que je mette à jour la ligne de Cinelerra CV qui est effectivement morte depuis 2007). Je ne regarde pas si un logiciel a eu un commit dans un mois donné, je regarde la quantité relative de commits… si on passe de 100-200 à 1-2 commits par mois où tout ce qui se produit c’est «oh j’ai mis à jour les traductions», «j’ai réparé un typo dans le build» ou «j’ai incrémenté le numéro de version», ça ne compte pas comme un projet actif.
Une bonne raison de ne pas simplement se fier au nombre de releases: parce que certains sont basés sur le temps (ex: Novacut qui «release» tous les mois… avec un ou deux commits de contenu, le reste c’est des commits qui… changent le numéro de version), d’autres sur des objectifs/seuils de qualité, etc. Au final, une release c’est juste un snapshot à un moment dans la ligne de temps du développement. Quand on y pense bien (et pour caricaturiser un peu), c’est juste une étiquette qu’on met sur un commit, des release notes et un rassemblement de fichiers dans un tarball.
Que ce soit «sur deux serveurs sécurisés» ne rassure personne et ne répond pas à la question: pourquoi derrière portes closes? Y’a aucune raison, d’autant plus que le machin va être sous GPLv3 de toutes façons. Ça ne donne pas une belle image du point de vue communauté et fait juste croire qu’il y a quelque chose qu’on nous cache. Enfin, en effet vous pouvez faire comme vous le voulez, mais je fais simplement soulever ce point: je n’y vois pas d’avantages pour Openshot, seulement des inconvénients.
J’avais pourtant cru comprendre que WebKitGTK+ 2.x était beaucoup plus rapide, qu’il y avait l’accélération matérielle pour le rendu… Dans tous les cas, vraiment déçu du passage à Qt
Oui mais dans ce cas, je parle de WebKitGTK+3, qui lui, est moins rapide pour ce que nous voulons en faire.