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? _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
