[Pythonmac-SIG] Re: [Image-SIG] Quicktime port to Windows, join the project!

[Jack Jansen]

On 22-sep-03, at 22:03, Bob Ippolito wrote:

> On Monday, Sep 22, 2003, at 15:44 America/New_York, Jack Jansen wrote:
>
>>
>> On 22-sep-03, at 20:46, Bob Ippolito wrote:
>>> Jack Jansen's bgen will probably wrap the Windows QuickTime just as 
>>> well as it did for the Mac.  "just as well" being key here.  There 
>>> are some rather large issues with regard to the current state of the 
>>> Python support for QuickTime on the Mac, primarily due to situations 
>>> where Jack just chose not to wrap part of the API, or where a NULL 
>>> argument is sometimes necessary but the wrapper won't let it 
>>> through.  I've hacked around some of this, but one of a few things 
>>> need to happen:
>>> 1) do it without bgen
>>> 2) find all the missing/special cases and add those to the bgen 
>>> support file
>>
>> There's actually a much easier solution: allow for the various 
>> objects to wrap NULL pointers. In other words, add a couple of object 
>> Qt.NULLMovie and such that are movie-objects but wrapping a null 
>> pointer.
>>
>> It's on my todo list, but at the moment I have absolutely no time for 
>> Python work (as people have undoubtedly noticed).
>>
>> And the bit of information that Bob probably missed is that I've had 
>> the MacPython Quicktime module working on windows at some point in 
>> the past. So it is really a question of cleanup and polishing.
>
> I'll try and take care of it, then.  I'm already relatively familiar 
> with bgen, the QuickTime API and its bgen wrapper.  I have a modified 
> copy here that builds outside of the Python source tree with distutils 
> and uses the OS X style Apple headers (not Universal headers).. it's 
> also capable of making movies from scratch with compression (this is 
> why I modified the wrapper).

Ok, great! The mods to bgen (which I assume is what allows you to use 
the OSX-style headers, right?) I would like to see as a patch. The QT 
mods: read on.
>
> The next question is (and I'll copy this to pythonmac), how would this 
> get phased in?  It's not possible to replace a system module using 
> site-packages (without jacking sys.path), so in order to do a Package 
> Manager upgrade we would need to force admin privileges or just use a 
> different name.  The renaming route is probably optimal, since a 
> Carbon tree isn't going to make sense in win32, so what should I name 
> it?  Should it be a package or a py/extension pair?

Well, for this one case there's a simple solution: QuickTime shouldn't 
be in Carbon in the first place. So, we start by creating a QuickTime 
package (if we keep the current two-level structure it'll have 
QuickTime.QuickTime for the constants and QuickTime.Qt for the actual 
objects and functions) and an underlying C module that needs a new 
name, _QuickTime_Qt or something. This is distutils-installable, and 
will be included in 2.4 (with Carbon.Qt and Carbon.QuickTime importing 
them, after issuing a DeprecationWarning).

> I also have full access to Windows and Visual Studio.NET, so a win32 
> port shouldn't be a problem (other than motivation).

Help would be appreciated:-)

> Do you have your todo list public anywhere?  I might be able to help 
> knock some of them out.

One of the topmost points is "Catching up with all the stuff Bob 
Ippolito did and integrating it":-)
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman