Hi, sorry for the late answer. I guess I need to say something about windows support for Freevo.
"Tyler W. Wilson" wrote:
> A few weeks ago for kicks I checked out the latest CVS code for Freevo,
> which I believe is 2.0 (it uses PyNotifier and not Twisted, so I assume
> this is correct).
Yes.
> I wanted to see what it might take to get it running on Windows. It took
> a couple days, but I have the main window showing up, with most of the
> menus displaying and working. Though the program doesn't really do
> anything at the moment, I think it does show promise.
It is. The only stuff missing are player plugins. You may want to use
windows specific player, but maybe mplayer also works for you.
> I would like to put out my comments about what changes I had to make to
> get things working, for the edification of the group. I know there are
> not too people actively working on the code, and Windows may not be a
> priority. But I figure if a few lines can be changed to make the code
> more cross-platform, it is a 'good' thing, yes?
It is. But at some points in the code I optimized it to be much faster
by breaking Windows support.
> This first email will only highlight the major areas where I ran into
> trouble, and possible ideas on how to fix them or work around them.
>
> So, here we go - in roughly discovered order:
>
> - Hard-coded *nix constants: there are many instances of using '/', ':',
> etc. instead of the available Python os constants.
>
> Suggest using os.pathsep (':',';'), os.sep ('/', '\'), etc.
This is one point. Let's see the function find_matches:
| def find_matches(files, suffix_list):
| return filter(lambda x: x[x.rfind('.')+1:].lower() in suffix_list, files)
That's ugly code, I know. But if you look at the comment by this
function:
| The correct implementation is
| filter(lambda x: os.path.splitext(x)[1].lower()[1:] in suffix_list, files)
| but this one should also work and is _much_ faster. On a Duron 800,
| Python 2.2 and 700 photos 0.01 secs instead of 0.2.
You see, there is a correct way working with windows and a fast one. I
prefer the fast one. So we need some checking like 'if windows: use
one function else use another'. I won't give up speed only because of
windows.
> - Hard-coded *nix paths: there are many instances of using '/var',
> '/proc', '/tmp', '/dev', etc. that seem to be related mostly to process
> execution, etc.
Yes. All this should be wrapped into sysconfig.py. So sysconfig.py may
give you a different path on windows. You are right, nothing in Freevo
should use /var or /tmp directly. As for /proc and /dev, we may need
it and you need to find a way how to do that in windows.
> Suggest creating some sort of platform-agnostic interface that will
> do the 'right thing' for each platform. For example, there is a
> getpid(name) in freevo/freevo which could be moved into
> platform_unix.py and a new platform_windows.py created to implement
> the same methods.
Agreed.
> Or how about sticking to the popen interface in Python? I have never
> used these routines, and am not sure about how Freevo is using the
> process features of Unix to know if this would work, but...
We use popen2 (a popen2 wrapper in src/util/popen.py)
> - Use of Python methods that are Unix-only, such as getuid(), getpwuid()
> and uname().
>
> Suggest writing wrappers to add these functions to the Windows Python.
> For example, I used:
>
> def windows_getuid():
> return os.getpid()
> os.getuid = windows_getuid
That should be part of the platform_windows.py file.
> in the src/main.py and that seemed to make Freevo happy. Though I know
> that the uid is used on Unix to look up process or user information, I
> wonder if there might be a way to change things slightly to work well on
> both platforms.
Maybe.
> - Using Imlib2 directly from the main Freevo source.
>
> It appears to me as if mevas was meant to wrap up all the image and
> display backends, though the main Freevo code seems to call directly to
> Imlib2. Suggest changing any of these instances to mevas methods which
> redirect to the active backend.
We need imlib2 for two reasons: inside mevas for drawing and inside a
thumbnail module for creating thumbnails. For the second, I guess we
can create a thumbnail lib that uses a different backend (PIL?) under
windows. Or even pygame, doesn't matter. Only that the thumbnails
created by that lib can't be traced back to the file. Inside the
thumbnail is a path to the original file. A helper could check that
and remove old thumbnails. Using pygame or PIL, we don't have that
feature.
The mevas stuff: we plan to drop mevas again and move to evas. So evas
needs to work with windows. There are two ways to make this
work. First, fix evas to work with windows (BTW, you can do the same
with imlib2) or create a lib that feels like pyevas but works in a
different way.
IMHO the best way to make it work with windows is to talk to the
enlightenment people and help them to create an output win32 canvas
for evas (it is on the todo list) and maybe also for imlib2.
> Another thing I think might be useful for people like me who are trying
> to port Freevo is some kind of overview doc describing how Freevo starts
> and the general code path it takes. I am still not sure how the CONF
> structure gets filled in, when the conf files are parsed, etc.
I guess I need to write some docs. Just ask specific questions like
"What is the path of an event?" and I will fill in the freevo 2.0
source doc wiki.
Dischi
--
Black holes are where God divided by zero.
pgpOVLrShbwrq.pgp
Description: PGP signature
