[nikz_spb]

Hello to everybody. I compiled a MyPaint for Windows XP 32 bit in this spring. It's version is shown as 1.0+ GIT. So I attached archive with this version here, hope somebody will find it usefyll. The only thing is that brushes here are a bit messy, most of them are in "lost and found" category:) The new in this version is mirror drawing

http://www.sendspace.com/file/ey563v

[achadwick]

Thanks for that. Looks great! Would you have time to write an up-to-date HOWTO document for Windows porters at all?

[nikz_spb]

Hello. Thank you for reply. Oh I just followed theese instruction (as far as i remember)
http://opensourcepack.blogspot.com/2009/08/building-mypaint-in-windows.html

I've tried to build it now (the last version), but after building it failed to start

[therahedwig]

Tumagonx mention that the build environment doesn't have all the libraries used in the new code, so the code is incomplete and doesn't work.

There was some mention of putting the enviroment onto google code? Mostly because then Tumagonx isn't solely responsible for the windows build.

[tumagonx]

Hi,

here is a version from yesterday as someone requested: http://osspack32.googlecode.com/files/MyPaint_140712git.7z
and i'd like to outline the current situation in case someone want to help

- mypaint require json-c from http://oss.metaparadigm.com/json-c this is new dependency
- it seems mypaint try to migrate to gegl canvas? this is new (optional?) dependency, current git canvas is very slow (the one that built above)
- there is mentioned gobject-introspection being optional, this AFAIK still _barely_ WIP for windows platform. What its used for? gir? pygi?
- it would be handy if git being bundled too in the build_env (git doesn't need msys anyway). So it can be fully automated "git pull"
- brushlib\mypaint-fixed-tiled-surface.c need #include <stdio.h>
- there is -z linkflags in brushlib\sconscript which AFAIK not valid for ld
- replacing the setup batch files with scons' setup.py would be appreciated, thus automated mypaint versioning
- workaropund for brushlib\brushsettings.py https://dl.dropbox.com/u/33728474/patches/brushsettings_path_py2exe.patch (should be better than this)

[achadwick]

- there is mentioned gobject-introspection being optional, this AFAIK still _barely_ WIP for windows platform. What its used for? gir? pygi?

AFAIK, this an optional thing for building GObject introspection data for mypaint-brushlib so that other apps can use it.

Just so you know, there'll be an initially unrelated GI-related dependency hitting master shortly when the gtk3 branch is merged back in. Note that despite the name you won't have to jump to GTK3-everything right away, but you will need to get pygtkcompat working (it's in PyGObject 3.1.92+) while the master tree is being ported over from PyGTK to PyGI+GTK3. See the gtk3 branch in master and README.gtk3 for a rough outline of the plan.

[tumagonx]

thanks for the confirmation andrew, then mypaint windows could have a longer breath

about the build_env, whether someone try from scratch or continue mine, I'd like to explain what it is

basically it contain:
- mingw (no msys) with gcc 32bit and gcc-cross64
- scons
- swig
- python 2.6 with py2exe and other python dependencies. in both 32bit and 64bit
  note: gcc compatible import library need to be created first and patched python.h also needed for python64 (already done)
           if you care about psyco, there is version 2.0.1 on the net that usable but only work with python 2.6 32bit
- GTK 2.24 runtime and devel. files in both 32 and 64 bit (If I recall the headers/pkgconfig versioning is screwed up)
  note: it has freetype disabled cause I think it's not needed for mypaint, the current state still require json-c (both 32 and 64 bit)
- nsis
  note: the current installer script for mypaint is quite lame

At first I try to mimic inkscape build environment but since mypaint is way simpler I also bundling pretty much everything. Bunch of batch files needed for initialization though most of it should be moved to scons whenever possible. I think reading the batch files will pretty much will figure out how it work

how to update dependency:
if official win32 binary available, copy the bin/lib/share hierarchy into GTK/GTK64 folder, if it was python dependencies it usually can be copied directly to python/python64's site-packages folder.

unfortunately if no binary available, the build_env itself might not able to build it (if require autotooled chain), therefor a complete set of msys+mingw will be needed. This is beyond the scope thereafter, I assume you know what to do

My plan is to have someone maintained it in googlecode, upgrade the build_env into buildbot (integrate git and googlecode_uploader) then voila mypaint snapshot everyday and everyone will be happy . Definitely I don't have the resource to do that.

[blurymind]

this is awesome. Big kudos for working on a build bot. The windows version has always lagged behind

[Bollebib]

awesome,thnx


though, I tried it out and it seems to lag enormously,causing broken strokes
any known issues?

[therahedwig]

awesome,thnx


though, I tried it out and it seems to lag enormously,causing broken strokes
any known issues?

If you look through tumagonx listing of libraries he mentions that the git canvas is very slow and that mypaint might be trying to move over to a gegl based canvas. (gegl is a library(reusable pieces of programing) which is more specialised in doing the graphical side of things. I believe in gimp the intergration of gegl will result into, amongst others, 64bit colourdepth(hdr), blender brush, and a ton of other fancy stuff.) However, as far as I know, gegl doesn't result in the fastest of programs, or is that just a result of incomplete implementation?

Anyway, I also threw it into the bug tracker, so either way, it's registered.

[achadwick]

What's different about this build from previous stable builds? They've always used the same canvas implementation, based on NumPy (which shouldn't be too slow, should it?)

Some comparative profiling information would be useful to figure out this slowdown. See tests/README.profiling in the current git master for a quick overview. It'd be a wonderful thing if either gui/drawwindow.py's start_profiling_cb() could be updated with something a bit more Windows-specific (patches welcome!) - but as it stands it will at least dump out a profile_fromgui.pstats before bombing out.

[achadwick]

Bug for slowness issues: https://gna.org/bugs/?19948 - please do subscribe to it. If you made an affected build, it would be really helpful if you could assign it to yourself and help us by fielding Windows bugs and submitting platform-specific patches.

I'm a little at sea when it comes to the many 3rd party builds for Windows. Whose is whose again, and where can they all be found? (I'm going to have to make a Windows VM, aren't I? Sigh :-) Maybe I can get a cheap copy through work.)

[therahedwig]

Yeah, I was thinking when I reported that bug:
Is it perhaps possible for Mypaint to somehow register how old the code it uses is in the about menu?
Like, maybe it can take the date at which the repository was downloaded and put that in the about menu. So that we know how old the sourcecode used is.
And maybe it would be an idea to do the same for the building env. Like, that it registers a version or date of downloading of the building env?

That way it would be a little easier to see which code comes from when instead of having to look at different builds. I think this is very important if we are going to look into people building their own versions.

I posted those gui profiles.

[tumagonx]

@achadwick
I think I'm a bit misinformed, it slowed down since mypaint use native code for brushlib (that brushlib.dll/.so). So maybe the brush engine not the canvas?

How it does in linux?

Note there is no change in build_env runtime files (if downloaded from my blog) since mypaint 1.0 (except added lcms)

[nikz_spb]

Hello:) I just want to ask if it will be any announcements for new builds on site (at least pre-pre-pre-alpha:)))? Cause many people go to "http://mypaint.intilinux.com/" and see last news were dated ~ 1 year ago and they can think "Oh it's too old" and get away from here:))