Share this project

Done

Share this project

Done
OpenShot Video Editor for Windows, Mac, and Linux's video poster
Play

The time has come for a cross-platform version of OpenShot Video Editor, including its powerful new video editing & animation engine! Read more

Arlington, TX Software
Share this project
1,463
backers
$45,028
pledged of $20,000 goal
0
seconds to go

Funded!

This project was successfully funded on April 17, 2013.

The time has come for a cross-platform version of OpenShot Video Editor, including its powerful new video editing & animation engine!

Arlington, TX Software
Share this project

Epic OpenShot 2.0 Update! (Part 1 of 3)

37 likes

Greetings OpenShot Backers! I hope everyone had a great holiday season and a happy new year! This is the first of three updates over the next couple days! So, be sure to check back often and keep up with all our new developments.

Schedule Update

Before I go any further, I first want to address the current schedule. My original plan was to release a beta around Christmas time and a final release mid-January, but unfortunately things were not quite ready. The last thing I wanted to do was to release an unfinished, broken version for everyone to try out. So, I made the hard decision to delay the testing releases to be sure things are ready on all 3 platforms. The work required to bring OpenShot fully cross-platform has been very challenging, but the show-stopping bugs are being knocked out, one by one, and there is a ton of progress to report, so please read on!

Development Expanded

Over the past couple months, I've expanded the OpenShot team to include Cody Parker and Noah Figg, who have been a tremendous help! In fact, the word tremendous does not do them justice... just know they have been a key part of the team to make OpenShot 2.0 a reality. They have completed dozens and dozens of tasks, and worked closely with me to bring all the different pieces together. Noah has focused on the Qt interface, improving the core PyQt framework to simplify our coding, solving complicated issues (such as cross-platform icon systems, translation system, undo / redo system, Qt integration with HTML timeline, and more). Cody has focused on the HTML timeline, JQuery integration, Qt integration, as well as leveraging the amazing Angular.js framework (used to bind our interface elements to our JSON data structure).

Bringing It All Together

We have been building OpenShot 2.0 in three different modules: libopenshot (the library which does most of the hard stuff), Qt interface (the user-interface which contains the buttons, sliders, labels, tabs, etc...), and the HTML Timeline (which is where you arrange your clips and effects). Most of the functionality in OpenShot 2.0 has now been programmed, but these independent modules are now being brought together, tested, debugged, and packaged (i.e. creating installers).

Windows Development =(

Many years ago, I used to develop software almost 100% with Microsoft's development tools (i.e. Visual Studio). So, I'm very comfortable within this operating system and development environment, or so I thought. Although, while I'm no longer using Visual Studio for OpenShot 2.0 (I'm using MinGW for those who are interested), I have been fighting Windows bugs for most of December, and wow, I've seen the dark side of Windows development with regards to working outside Microsoft's preferred tool set. The good news is, I've conquered most of these crazy bugs (many caused by subtle changes in Windows support for C++, and linking issues with Windows DLLs). I have one final bug on Windows that still has me stumped, related to a heap corruption caused by msvcrt.dll. So... if any developer out there want so to help me troubleshoot this issue on Windows, I would be most appreciative! I know... I can already hear the crickets chirping. =)

Of course, Mac and Linux support has been super easy, and simply a pleasure to work in those development environment. In fact, my build instructions document contains about 3 pages for Mac, 2 pages for Linux, and 12 pages for Windows... if that gives you an idea of how difficult Windows is to develop in.

Qt4, Qt5, GTK, PyQt, and Python3

Okay, that is a lot of acronyms, so let me explain. Over the coarse of the Kickstarter campaign, you may recall that I mentioned OpenShot 2.0 would be switching to Qt (used to draw our interface to the screen), instead of porting our GTK (our existing interface) code base. Well, we started work using Qt4 initially, which is widely distributed on Mac and Linux and generally easy to work with. However, we later discovered that Python3 requires Qt5 (and not Qt4). So, we made a decision to move to Qt5, PyQt5, and Python3. 

Still makes no sense? Well, basically we are now using the latest version of Qt (for our interface), PyQt5 (a program to help us control Qt5 from Python), and Python3 (the latest version of Python... which is a programming language used by OpenShot). Unfortunately, this process of fine tuning our software stack slowed us down in October / November, but we now have this stack working great on Windows, Mac, and Linux. This stack represents the future of these frameworks and languages, and positions OpenShot in a good place for the future.

Want More Updates?!?

I hear you loud and clear! Stay tuned for part 2 of this update... scheduled for tomorrow (Saturday) evening! And part 3, scheduled for Sunday evening. And as I always like to reiterate, thank you so much for your support and patience!!! OpenShot 2.0 is not an easy application to build. Video editors are complex in many different ways. This Kickstarter represents important investments into many different and unique frameworks, such as libopenshot, and will pave the way for many wonderful open-source video editing platforms in the future.

Comments

    1. Creator Tom Pennycook on January 11, 2014

      Nice to hear from you, hope you had a nice holiday. Being an old codger I realise these things never come in on time. I would rather have a late but working beta than a buggy broken one. On the strange behaviour of Windows outside of their approved development framework, it would not surprise me in the least if this was deliberate move by them in an effort to force the use of their proprietary offering. Which was one of the reasons that I moved to Linux in the first place. Keep up the good work guys, it's done when it's done.

    2. Creator Nick Watts on January 11, 2014

      Sounding fantastic. I bought a GoPro over the holidays with some gift-cards I received, can't wait for the day I get to import all that great footage into OpenShot 2.0!

      Thanks for the dedication, we're all rooting for you :)

    3. Creator Dmitrie on January 11, 2014

      So glad to read this. :)
      Several people, including me, were worried about that 3-months silence, and I think, one update per month would be really good to keep us all in touch. By the way, I remember the concepts of UI in the beginning of your work on OpenShot 2.0 - and it would be really interesting to see the new interface concepts.

      Thanks for yours, Cody Parker's and Noah Figg's work - finally there's a team! =)

    4. Creator Dzianis Sheka on January 11, 2014

      Looking forward for the beta version and code release! It's quite interesting for me as js developer to see how you use the js inside openshot!

      Thank you for such big work!

    5. Creator Jonathan Thomas on January 11, 2014

      Thanks for the tip Peter. Strangely, the heap only gets corrupted when accessing my library via the SWIG Python3 wrapper. When I build a simple executable, link it to my library, everything works fine with no heap corruption issues. However, when I run those same commands through Python (which is still linked to my same library) I get heap errors with one of my dependency libraries trying to free memory on the heap.

      Anyway, I'm getting closer to solving it (I think). =)

    6. Creator Peter Dohm on January 11, 2014

      Jonathan, as I recall, there are some very curious rules about heap allocation on windows, namely individual libraries have their own heaps, so in some situations, allocating something in one library's heap, passing the pointer to it into another library, and freeing the pointer within the second causes exceptions, because the second library's heap knows nothing about the first library's pointer given separate heaps. This has stung me many times. I'm going to assume its not something this foundational, but in the hopes that maybe it helps, there you go. Sorry if this was something you're already way past... :)