Open Spivoxity opened 3 years ago
I have fixed the issue on the development trunk by providing three options, activated by the configure flag -with-system-labltk=option
-with-system-lablgtk=no
; on Bullseye it can be used by manually installing a copy of the gtksourceview2.0 that still exists in Debian unstable. On Buster it works without change. I am keeping this option to help with building on other platforms including Windows and Mac, though some minor Mac customisations have been lost, temporarily I hope.-with-system-lablgtk=gtk2
to use installed copies of lablgtk2 and gtksourceview2.0.-with-system-lablgtk
or -with-system-lablgtk=gtk3
or yes
to use installed copies of lablgtk3 and gtksourceview3.0. Note that the lablgtk3 bindings available in Buster are not complete enough to be used, but they have improved sufficiently in Bullseye. This will now be the preferred build method for Debian packages, with the lablgtk stuff statically linked into the debugger, and a dependency on gtksourceview3.0.Depending on the installed version of ocaml
, adjustments have also been made to the interface between the internal copy of lablgtk and the garbage collector; they are selected automatically.
The plan for restoring Mac-like behaviour will be to install a local copy of the labgtk3 source, cut down appropriately (but not obsessively, Mike!), then add in the platform menu modifications I made in lablgtk2, affecting gtkMail.ml and ml_gtk.c.
The -with-system-lablgtk
flag can then be withdrawn.
Or, better, call gtk_platform_menubar
directly from the main program and put the primitive in debprims.c, allowing the use of an unmodified lablgtk.
The GUI for the debugger is currently built using gtksourceview2.0, using an internal, cut-down copy of the lablgtk bindings. In Debian Bullseye, gtksourceview2.0 has been withdrawn, and packages exist only for gtksourceview3.0 and -4.0. That makes it impossible to build the debugger on Bullseye, and presumably also on recent or forthcoming releases of other distros.