On Mon, Mar 4, 2013 at 10:23 AM, Richard Shann
<address@hidden> wrote:
On Mon, 2013-03-04 at 10:48 +0000, Richard Shann wrote:
> I'll now test on the XP boxes I can get to.
I think it is becoming clearer - there is one of the xp boxes which
crashes during the initial drawing of the windows, on all other machines
I have tested the only fault is with fonts. It seems that windows is
spectacularly unstable with regard to fonts. On one machine today the
Denemo font was not being found - it was present in C:\WINDOWS\Fonts so
I deleted it from there and the program started running correctly.
By contrast, on a Vista machine which was finding the fonts correctly I
tried deleting the font and Denemo could not find the fonts. I
re-installed the font, but it made no difference, Denemo still could not
find the font. I re-installed Denemo, still no font found. Finally I
re-booted the machine and the program ran normally.
On the internet there are plenty of threads about people being unable to
install .ttf fonts under windows, people try various things and mostly,
eventually the font is recognized.
So, I don't think we have to suspect a problem with Denemo - we can only
advise people to re-boot if the font is not found and to either
un-install or re-install it.
There is still the case of wine and one particular machine not running
Denemo -
I am almost 100% certain that Denemo is not working in wine because of portmidi. I think the only reason it worked with the early rc1-5ish is because portmidi was not actually working correctly. I disable portmidi in the mingw branch and it worked in wine. I am going to try another test against the master branch with --disable-portmidi to see if this is truly the case.
I guess the gdb.exe that our mxe build generated could be used
from wine to see if it is the same bug and perhaps find some origin from
within Denemo (or perhaps an origin in the gdk-pixbuf-loaders error
message we see on startup). But I don't propose delaying releasing a
windows executable for those problems.
I think we should make our release from the current master branch once
the translation updates have come in. Perhaps, Jeremiah, you could
create a candidate for this?
Ok. I will wait until the translations come in and then make a new candidate.
I attach the git diff of my gub repository
from yours - the changes in denemo.py that affect the linux build are
not tested, I was editing the wrong target.
Why did you set:
force_autoupdate = True
in portmidi.py. Did it actually do anything? I assumed that was for packages that use git as source
(Also, I don't know how you get the version name inside the installer,
so mine builds as denemo-0.0.0-0.mingw.exe).
This does this when using git as source. If a tarball is used then the version numbers will be there. I don't know if that is feature or bug.
Jeremiah
Richard
_______________________________________________
Denemo-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/denemo-devel