Lablgtk3 on macOS with quartz gtk3: all grey toplevel

[ghost]

Since opam can trigger rebuild of macports package, my gtk3 ports has been rebuilt using quartz rather than X11. Good thing, powerful feature of opam.

Unfortunately, I’m getting an all grey top-level window, I mean initialization of the gtk3 widgets does not happen correctly. Here’s a screenshot: https://discuss.ocaml.org/t/lablgtk3-on-macos-with-quartz-gtk3-underneath/8454.

By clicking approximatively on the location of a drop down menu, it does appear, but the rest of the widgets are still grey/inactive/uninitialized.

I’ve uploaded the “main” .ml file on the following URL: https://www.strauss-engineering.ch/tmp/straightliner.ml Do I miss something about initialization or is it a bug?

Also, later on I've compiled the “examples” directory of the git lablgtk3 repos. and it’s even worse than my app: even a top-level window does not shows up with all those examples. The examples execute and terminate without showing anything, even not an error message on the console or syslog. I’ve compiled using:

for i in .ml; do ocamlfind c -thread -o “$i.run” -package lablgtk3 -linkpkg; done for i in .ml; do ocamlfind opt -thread -o “$i.opt” -package lablgtk3 -linkpkg; done

HELP!

[ghost]

Oops I made a booboo about my screenshots and .ml file URL, you got to copy/paste the text of the link and not follow the href.

[ghost]

Software version & environment: macOS (BigSur) 11.5.2, OCaml 4.12.0 using up-to-date opam installation, lablgtk3.1.1, macports up-to-date, gtk3 @3.24.23_0+quartz, cairo @1.16.0_2+quartz+x11;

philippe@air2:~/mysrc/straightliner$ cc -v Apple clang version 12.0.5 (clang-1205.0.22.11) Target: x86_64-apple-darwin20.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

philippe@air2:~/mysrc/straightliner$ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 Apple clang version 12.0.5 (clang-1205.0.22.11) Target: x86_64-apple-darwin20.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Hardware: MacBook Air 9,1 (w. Retina, 13.3", late 2020, intel iris plus 1536Mo)

[ghost]

Oh about the lablgtk examples, my (ultra) bad, I've forgot to tell ocamlfind about the source file: $i shame on me.

[ghost]

The two links: Screenshots and main gui .ml file

Regards.

[garrigue]

I see no call to GMain.init. You should probably put one before let gui = new gui_t. In LablGtk3 there is no GtkInit module, and one needs to call GMain.init explicitly.

[garrigue]

Looking at the code again, there is a call to GMain.init inside the constructor of gui_t. I would still suggest to move it outside, as it would be safer, but this does not explain your problem.

Did you try to run the examples that come with lablgtk3 ? (download the sources to get them)

[ghost]

Hello Jacques, first thank for your time on this issue and more generally on lablgtk!

If I move the call to GMain.init right above the « new gui_t », I get a segfault:

-- @.***:~/mysrc/straightliner$ ./straightliner.sh

(process:87255): Gtk-CRITICAL **: 09:45:38.578: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(process:87255): Gtk-CRITICAL **: 09:45:38.583: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(process:87255): Gtk-CRITICAL **: 09:45:38.583: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed ./straightliner.sh: line 2: 87255 Segmentation fault: 11 _build/default/src/straightliner.exe

@.***:~/mysrc/straightliner$ cat ./straightliner.sh

!/bin/sh

_build/default/src/straightliner.exe —

I remember having pulling my hairs about the placement of the GMain.init, but don’t remind much more :-(

Best regards.

Le 14 sept. 2021 à 03:20, Jacques Garrigue @.***> a écrit :

Looking at the code again, there is a call to GMain.init inside the constructor of gui_t. I would still suggest to move it outside, as it would be safer, but this does not explain your problem.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

-- i met a man he told me straight you gotta leave it's getting late too many cops too many guns all trying to do something no one else has done -- pj harvey, n.y., circa 2000

[ghost]

Pretty strange, I was thinking, in the meantime after your message, Jacques, of a race about the use of React, BUT:

• Placing the call to GMain.init on the top (first line) of the definition of class gui_t: it doesn't sigsegv, but shows the all greyed window with the active region of the combo box being sensitive and functional, not the rest.
• Placing GMain.init right before the "new gui_t", it sigsegv

strange!

[ghost]

Under Linux, having the GMain.init right above new gui_t also sigsegv. Having it inside gui_t let bindings preamble, the app works fine, no all grey window like on macOS & Quartz, it does fully works. Screenshot of the working GUI