A summary of win32 issues

[qyot27]

Since it's mentioned as a possible TODO item, I wanted to see how well the current git master of wMAL works on win32 as-is. The following is pretty much what I've got so far:

In all cases, the biggest issue is that Python on Windows is all kinds of nasty to get modules into. You can have Python on your PATH, but trying to call easy_install to get stuff installed doesn't work without explicitly navigating to its directory first (which is probably safest since who knows if it would end up in the right spot if easy_install was on the PATH).

In some cases, this requires downloading the packages manually and installing them. In other cases (like readline) it requires getting Python-oriented substitutions for GNU tools that don't ship with MSys/MinGW or Cygwin.

wmal.py: works perfectly, albeit with a bit of a cosmetic problem with the command prompt. See screenshot. I've used it successfully to sync, update, score, and change status while I've been in Windows.

wmal-curses.py: probably has the bulk of the issues with external modules not being present or needing workarounds to get working. I still haven't got it working; it's currently sitting at missing fcntl - Google seems to turn up the result that this needs to be altered to either use Windows system calls or to use some sort of platform-agnostic form. curses itself is known to be problematic or nonexistent on Windows, but there seem to be some alternatives that can be used.

wmal-gtk.py: not working either, but in seemingly different ways. If there is no 'lock' file in .wmal/mal, there are no warnings output to the Prompt, the outline of the window shows up, but not any of the internal window elements (I vaguely seem to remember that it does show up sometimes, or did at one point...not really sure). If 'lock' is present, there are warnings about the file locking that get output to the Prompt (see below), but now the window and all its internal decorations/elements show up, although it gets stuck in a loop and never loads any of the MAL content. Clicking the close button doesn't do anything, requiring me to close the Prompt instead. As mentioned, I seem to remember that the first time I ever tried launching the GTK interface, it was without 'lock' present, but the window was still correctly drawn (none of the content appeared, though).

>python27 wmal-gtk.py Starting engine... Locking database... Exception in thread Thread-1: Traceback (most recent call last): File "C:\WINDOWS\Python27\lib\threading.py", line 551, in __bootstrap_inner self.run() File "C:\WINDOWS\Python27\lib\threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "wmal-gtk.py", line 412, in task_start_engine self.engine.start() File "C:\dap\vid\Incoming Files\wmal-python\modules\engine.py", line 113, in start (self.api_info, self.mediainfo) = self.data_handler.start() File "C:\dap\vid\Incoming Files\wmal-python\modules\data.py", line 97, in start self._lock() File "C:\dap\vid\Incoming Files\wmal-python\modules\data.py", line 329, in _lock raise utils.DataFatal("Database is locked by another process. " DataFatal: Database is locked by another process. If you're sure there's no other process is using it, remove the file ~/.wmal/lock

[z411]

Thank you for the feedback. While I'm planning to make a Win32 compatible interface in the future, I haven't tested if the existing interfaces work, so your testing helps very much.

wmal.py: If this is working then it means that the engine has no problem, so it's good to know. The cosmetic problem is caused by the color ANSI escape sequences so I'll try to fix that, or disable them completely for now.

wmal-curses.py: This is made using the urwid library, and well, it was made with *nix in mind. But I've read that it can also use the pdcurses (cross-platform) or wcurses (Win32) libraries so I'll test that. The current workaround is to run it under the Cygwin terminal but that's not really Win32 anymore...

wmal-gtk.py: This one surprises me, I'll really have to test this. I wonder if the problem is related to threading. And while you mention it, I will to improve the (now primitive) lock check, and at least have an option to disable it for debugging.

As for building a Windows interface, there doesn't seem to be a Python wrapper for the Win32 GUI API. I knew there was a "venster" library but it looks like it was abandoned. If you know of anything please tell me.

For now I'll probably make a wx interface, or (painfully) work directly with the Win32 API.

Another problem in Win32 is the episode tracker. It makes a call to "lsof" which obviously is unavailable in Windows, so I'll research if it can be done through the Win32 API.

[qyot27]

I'm not entirely sure if I had to go about manually resolving the dependencies (or use easy_install or pip) before wmal.py worked. I unfortunately didn't keep any notes while I was doing that. But even with that in mind, it does actually work in the stock Prompt, so it's not like there's a huge problem there.

The results with wmal-gtk.py are mainly because I knew I already had Py-GTK for Windows installed (as a dependency for Meld to work). Not sure if that really makes a difference in building an interface, though.

I do remember that some of my attempts involved using Cygwin to try and fetch/build things, which is part of why I said getting modules into Python on Windows is so nasty (it may have been when I was attempting to get urwid in there).

It makes me wonder if using ActiveState Python would be a better alternative on Windows, in case there's a more unified repository system there, but I just went with the official distribution from python.org since I figure it's probably better to assume the user has that one installed (and because that's the one I already did have installed). I'm just not sure if the official distro of Python for Windows and ActivePython can play nice together (and I'm not so sure I want to try and find out).

If it helps, this is the content of my site-packages directory:

 Volume in drive C has no label.
 Volume Serial Number is 00A1-FD09

 Directory of C:\WINDOWS\Python27\Lib\site-packages

10/31/2012  01:21 PM    <DIR>          .
10/31/2012  01:21 PM    <DIR>          ..
10/31/2012  01:19 PM    <DIR>          cairo
10/16/2012  09:32 PM               240 easy-install.pth
09/20/2006  01:05 PM               126 easy_install.py
10/14/2012  12:53 AM               320 easy_install.pyc
10/14/2012  12:53 AM               320 easy_install.pyo
10/31/2012  01:19 PM    <DIR>          gtk-2.0
10/13/2012  11:38 PM    <DIR>          PIL
05/15/2010  11:03 AM                 5 PIL.pth
10/16/2012  09:37 PM    <DIR>          pip
10/14/2012  12:53 AM    <DIR>          pip-1.2.1-py2.7.egg-info
10/19/2009  09:35 AM            85,435 pkg_resources.py
10/16/2012  09:26 PM            92,571 pkg_resources.pyc
10/14/2012  12:53 AM            92,571 pkg_resources.pyo
11/02/2010  08:35 PM               211 pycairo-1.8.10-py2.7.egg-info
02/08/2012  11:50 PM                24 pygtk.pth
04/04/2011  05:39 PM             2,966 pygtk.py
10/31/2012  01:21 PM             2,071 pygtk.pyc
10/16/2012  08:01 PM    <DIR>          pyreadline
10/06/2011  04:33 PM             2,240 pyreadline-1.7.1-py2.6.egg-info
10/16/2012  09:32 PM           141,226 pyserial-2.6-py2.7.egg
06/23/2011  06:25 AM             2,633 readline.py
10/16/2012  08:01 PM             1,878 readline.pyc
10/16/2012  08:01 PM             1,878 readline.pyo
03/08/2011  09:39 AM               121 README.txt
10/16/2012  09:26 PM    <DIR>          setuptools
10/14/2012  12:53 AM    <DIR>          setuptools-0.6c11-py2.7.egg-info
09/20/2006  01:05 PM             2,362 site.py
10/14/2012  12:53 AM             1,735 site.pyc
10/14/2012  12:53 AM             1,735 site.pyo
10/16/2012  09:26 PM    <DIR>          urwid-1.0.2-py2.7-win32.egg
              21 File(s)        432,668 bytes
              11 Dir(s)  13,069,455,360 bytes free

[z411]

Hello, I just tested the scripts in Windows. I used the official Python distribution.

In CLI wmal.py it asked for readline, but actually that module is optional as it just provides command history (up/down keys) and autocompletion (tab key). I made the changes so it starts anyway if the module is missing. No other external module was needed.

As for wmal-gtk hanging, you can try removing the line 418 as a workaround:

418        self.main.set_title('wMAL-gtk v0.1 [%s (%s)]' % (self.engine.api_info['name'], self.engine.api_info['mediatype'])) # remove this

Removing this line works for me, but it still hangs when trying to close it. My guess is that it's having problems communicating with the window manager while in a thread (which is probably something I shouldn't have done in the first place). I'll work on this.

If you get the "Database is locked" error it means that the script wasn't closed cleanly last time, so for now you'll have to delete the "lock" file manually.

Tell me how it goes.

[qyot27]

I can confirm that commenting out that line in wmal-gtk.py makes the content appear and allows me to actually work with it like I can on Ubuntu. Same with it still hanging on close, too. I've gotten into the habit of needing to delete the lock file manually anyway, so that's no trouble.

[z411]

Now that there is a Qt interface, it seems to work much better on Windows. I even tested with some primitive recognition on the Win32 branch, although I'll think of a better way to handle it. Nevertheless, Qt is quite a heavy dependency and it makes any attempt of freezing the application into a Windows installer not very lightweight. But I'll work on it if anyone wants to use it still.

[qyot27]

I wouldn't worry so much about the size of Qt, since it only requires the runtime - which according to PyQt's installer, only uses about 63 MBs of disk space. Compared to the 200+ MBs required to pull in Qt on a GTK-centric Linux distro, that's really not that bad.

EDIT: And ~63 MBs is just the raw size of the install; it can be cut down to 32 MBs if you pack the .dlls with UPX.

The only real issue I had when I tested the Qt interface was that the series info boxes took up like 80-90% of the window (not sure why, either, unless it has to do with the length of the titles somehow) and the series list was squeezed down rather awkwardly, so it didn't match the example picture of the Qt UI on the main page. I can expand the window out so the list isn't squashed, but the info area shouldn't be taking up that much space.

Example image: https://imageshack.com/i/nmxkrjp

[z411]

Thanks for testing. I wonder why that happened, widget/layout width seems utterly wrong but it works on my end.

Screenshot: http://postimg.org/image/tvhuep8jd/full/

Which version of Qt/PyQt are you using?

[qyot27]

PyQt4-4.11.1-gpl-Py2.7-Qt4.8.6-x32.exe

Ah, it seems to be related to the uxtheme. I tested with some others (Windows Classic and Cappuccino) and it appears correctly for those.

It is weird because this is like, the only time I've ever encountered a problem with the theme I was using (CleanGlass), and I've been using it for years.

[z411]

Maybe because I didn't set a fixed widget width. I'll try that theme and look into it. Thanks.

[qyot27]

I looked into the idea of fixed width being a solution for the uxtheme problem, and can confirm that yes, adding a fixed width for those widgets does solve the issue. I set the width to 100 to match the width for the series image, except for the progress and score spinboxes, which were set to 50. This makes the window appear as it should, even with the CleanGlass theme.

There is an issue with the progress bar in the series column as well as in the list column, and that's if the series is at 100%, it fills correctly. Anything less than 100%, and it doesn't fill at all*. Again, just with this theme - if I switch to Windows Classic, it does fill partially when under 100%, and does so with the right proportion in relation to the percentage.

*this acts differently between the series and list bars; the list bar never fills, the series bar depends on the value applied in the fixed-width fix (if the value is too small, like 100, it fails to fill), but displays the fill incorrectly, with the amount not being representative of the percentage.

A workaround is to invoke wmal-qt with a different style, which makes it ignore the uxtheme completely. PyQt comes with several built-in, but some of them don't seem to work under Windows - the ones that did work were Plastique, Clearlooks, Motif, CDE, Windows, and WindowsXP. The 'WindowsXP' style is the default one that honors the uxtheme (I would assume 'WindowsVista' does too, on Vista or higher, but since I'm not using one of those, it and any of the non-working styles fall back to 'Windows').

A feature request in regard to the above would be the ability for the user to switch what style they're using from within wmal-qt.

Also, clicking the close button doesn't exit the program in the Prompt, even though going through the menu and choosing to exit does. If I forget and click X, I have to kill the Prompt, since not even Ctrl+C will force it to exit (although it does exit on Ctrl+C if I launch it from mintty).

[z411]

A feature request in regard to the above would be the ability for the user to switch what style they're using from within wmal-qt.

Oh, this sounds good. I remember seeing some qt programs having this.

Also, clicking the close button doesn't exit the program in the Prompt, even though going through the menu and choosing to exit does. If I forget and click X, I have to kill the Prompt, since not even Ctrl+C will force it to exit (although it does exit on Ctrl+C if I launch it from mintty).

Are you sure wmal-qt isn't just getting minimized to tray when you click X?

[qyot27]

Are you sure wmal-qt isn't just getting minimized to tray when you click X?

Ah. Never mind then. I had 'Close to tray' checked.

[z411]

Heh. Well, some programs have a notification that appears once to remind people that it's in tray; maybe I could implement that bit.

[z411]

It's been a long time but the Qt & CLI interfaces, and the tracker are working nicely under Windows, so I'll be closing this. There are working alternatives in Windows to Taiga, but Windows support will still be provided for completeness support.