I just thought about a wrinkle in providing script bindings for Windows. The build I make for Windows is relocatable (can be placed anywhere on the filesystem), but there are many things that need to be located at run-time: plugins and various text files like profiles and presets. It does this by figuring out the path of the executable and looking in directories relative to it. This makes it possible to use an exe without having to worry about current directory, which could be another way to do it, but does not work if you want to just double-click an exe or possibly support file associations. So, python.exe really needs and its runtime files would need to co-exist in the same dir tree. That is another thing that should be solved, and I am sure this problem has been already been solved by other projects, but I have no interest in finding that solution, sorry. That is a job left for someone interested.
On Thu, Feb 14, 2013 at 10:12 AM, Dan Dennedy <d...@dennedy.org> wrote: > On Wed, Feb 13, 2013 at 7:08 PM, Benjamin Bruheim <gro...@gmail.com> wrote: >> My worry is mainly windows builds. I have found a number of issues when I've >> been building on windows myself. If there's a way to patch your buildchain I >> would be happy to help out with that - even if I am not entirely sure how to > > The Shotcut Windows build is cross-compiled on an Ubuntu host. The > main difficulty with the Windows build (manually or automated > cross-compile) is dependencies. About half of them are pre-built, > usually by the upstream project, but I have manually cross-compiled a > few things. The other half are built by the script that comes with > shotcut source where I had to figure out the cross-compile > incantations required for each package it builds. > >> build that environment for myself. I did build MLT on windows and did manage >> to run flowblade after some generous removals of linux-specific elements. If >> _mlt.pyd is there, the rest is really damn simple. There's obviously tons of > > How good is the video embed working? I was not happy with some of the > quirks I observed with embedding the SDL video window on Windows when > I tried it in Shotcut. So, I switched to QGLWidget and never looked > back. Also, you really want OpenGL as a display method to best utilize > the GPU-based image processing in the next version of MLT. However, to > get the OpenGL display method working in Python requires some > enhancement to the SWIG definition to support Mlt::Event (see > RubyListener in src/swig/mlt.i). > >> subtleties, but the python-binding is already established on linux - it >> comes down to stuff that resembles build-errors (paths, stdlib variations >> etc). Personally I use mlt directly because the API is excellent. I've been >> writing a few wrappers for the dll's with varying degree of success. :) >> >> The windows build we already have is awesome. If it included the python >> binding it would be fantastic. If it is so that SWIG in crosscompilation is >> terrible then I don't blame yah. If it ain't, then i would be little effort >> for great payback. :) > > I am not interested in figuring out the build-time dependency for > python under mingw. If you want to try and help, then I can provide a > few things to help you prepare the linux mingw build environment > (packages to install and a few tarballs of pre-built dependencies). > > >> On Thu, Feb 14, 2013 at 12:18 AM, Dan Dennedy <d...@dennedy.org> wrote: >>> >>> On Wed, Feb 13, 2013 at 2:44 PM, Benjamin Bruheim <gro...@gmail.com> >>> wrote: >>> > Hey, >>> > >>> > I wonder if shotcut could package the bindings. It is famously hard to >>> > compile mlt so it could aid porting of software based on bindings. >>> >>> Did you pick Shotcut for its cross-platform-ness or binary convenience >>> or combination thereof? Getting multiple script language bindings for >>> multiple platforms working sounds like a good job for someone other >>> than me. :-) Wanting to let those scripts be able to embed MLT video >>> into each platform's GUI toolkit? Good luck with that! There is a >>> reason why I chose Qt over a scripting runtime for Shotcut. >>> >>> However, if you are just looking for binary downloads for Linux that >>> also includes the script bindings, I can easily accomodate because we >>> already have nightly builds for melt, melted, and Flowblade that >>> builds the python binding. However, the generated melt and melted >>> tarballs do not bundle the binding at this time; only Flowblade does. >>> Can you be a bit more specific about your goals? How about Linux only >>> builds of melt and melted that also includes python, ruby, php, lua, >>> and java bindings? Or is QML-scripting support for Shotcut more >>> interesting? >>> >>> -- >>> +-DRD-+ >> >> > > > > -- > +-DRD-+ -- +-DRD-+ ------------------------------------------------------------------------------ The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
