[Denemo-devel] Building for Windows

[Richard Shann]

The last build (19th Dec) was against Gtk 3.16.7
I tested the zip version, and running it under GDB I can see a whole new
raft of failures which look like further developments in the Gtk3
program. (I am building against Gtk 3.14.5 on Debian Jessie and I get a
whole slew of deprecations, but the program is reasonably functional).
Two of the failures with the current zip code are that the Denemo
Display fails to draw anything past the background color, (which seems
to be due to a failure to create a pixbuf), and the menus are all drawn
with pale grey lettering on a pale grey background (ie invisible) until
a menu item is selected (which I guess is due to the adwaita theme
shipped with this Gtk).

I think the way forward is to build against Gtk2. The only (*)
functionality we will lose is being able to make palettes that have more
than one row/column. That's not essential, and could be worked around if
we were going to stick with Gtk2. I can't see how we can continue to
follow Gtk3 without dropping Gtk2 as they are now getting too different.
If someone would like to develop a Gtk3 branch that would be good, it
will involve a lot of change in the code structure, a lot of it to the
good - getting rid of ancient stuff which has its origins in Gtk1).

What to do right now? I suggest reverting to the last successful windows
Gtk3 build - the one that failed only in loading the SVG for the
playback view, and trying different versions of the librsvg library. I
can try loading other svg images via gdb (I did this successfully on
Debian) and that may reveal what it is about the LilyPond SVG file that
is causing the failure to load. On Debian the LilyPond SVG file loaded
as gray music on a gray background and I had to insert LilyPond syntax
to re-color everything; something similar may be possible for windows. I
don't have a copy of the binary from earlier in the month that would let
me try this out though.

 I can also try asking on gtk-devel why the gtk_image_new_from_file() is
failing for svg on Windows - if we can get a fix for that then we
wouldn't need the rsvg calls (which are deprecated in Gtk3 anyway).

Any thoughts?

Richard
(*) I say the "only" functionality, but perhaps you know of other
problems with Gtk2, or at least with the Windows backend for Gtk2. Is it
conceivable that we could debug and fix Gtk2 - does the MATE project
maintain a repository of Gtk2 code with fixes that it develops?