MWP on MacOS Sonoma

[silicongarage]

I'm trying to build on MacOS and have gotten farther than #135 . I've hit a wall with libepoxy. I get the following error:

../src/mwp/meson.build:76:35: ERROR: C shared or static library 'epoxy' not found

Homebrew only installs a dynamic lib version of libepoxy, so I downloaded the source (v1.5.10) and managed to build and install static libepoxy.a using the --default-library=static switch. However I still get the above mwp meson message about the static library not being found. At this point I'm not sure how to proceed.

[stronnag]

I had wondered whether it would be possible to build the GTK4 version on MacOS. Congratulations on getting this far.

I would be interested to see the whole Meson output up to failure. That will give me some clue as how to proceed.

Meson will use pkg-config to determine if a dependency exists. What is the output of:

$ pkg-config  --print-provides epoxy

If there is none, or an error it is possible that the HomeBrew recipe either installed it elsewhere or not at all.
As libepoxy is not entirely essential, I could modify mwp to only optionally require it.

But please provide the above information (meson output up to failure and pkg-config for epoxy) before I go that route.

[stronnag]

On second thoughts, it's maybe more complex that than, as iirc, Homebrew uses /opt/<something> vice /usr/local/lib. So even if I remove libepoxy it will fail other pure C libraries.

[stronnag]

Indeed, I need to rework the way mwp evinces pure C libraries. I'll let you know then it's done.

[stronnag]

There is now a new development branch meson_libs which changes now meson handles C libraries.

git pull
git checkout meson-libs

Then I suggest you reconfigure with a new build directory, e.g.:

meson  setup _xbuild --prefix=~/.local --strip 
ninja -C _xbuild install

If it fails to find required dependencies, you can specify extra library paths (e.g. on my FreeBSD box);

rm -rf _xbuild
meson  setup _xbuild --prefix=~/.local --strip -Dextra-lib-paths=/usr/local/lib
# etc ...

The -Dextra-lib-paths= argument takes a comma separated list:
e.g

-Dextra-lib-paths=/usr/local/lib,/opt/homebrew/libs`

[silicongarage]

The output of $ pkg-config --print-provides epoxy returns epoxy = 1.5.10
I did a pull of meson_libs but now get a dependency for blueprint-compiler

Program blueprint-compiler found: NO
data/meson.build:38:12: ERROR: Program 'blueprint-compiler' not found or not executable

My searching shows Blueprint not available on Homebrew and couldn't find any info via Google on MacOS version

[stronnag]

It's a python program, so it probably runs everywhere. Certainly does on FreeBSD.

[stronnag]

https://gitlab.gnome.org/jwestman/blueprint-compiler

[stronnag]

In another project (which builds on macos), I added blueprint-compiler as a sub-project.
In the process of doing that ....

[stronnag]

If you pull meson-libs again, it will install its own blueprint-compiler as a sub-project.
You may then find you're missing some python dependencies ...

[stronnag]

Apropos the (now missing) message re arm64 symbols, potential workaround just pushed to meson-libs.

[stronnag]

And now a really ugly workaround for the compiler stuff ...

[silicongarage]

here's the latest output:
ninja.log

[stronnag]

That looks like it builds ...
did you install it ?
does it run ?

[silicongarage]

woo hoo!

[stronnag]

Well ... I'm shocked. Some problems with the panel scaling (which is meant to fit a mono-spaced "00:00:00.0N 000:00:00.0W", but amazing all the same.

[silicongarage]

Thanks for your persistence! I apologize about removing the "arm64" message. Was going to update with more info but you were too quick and saw the original. Other than the epoxy & blueprint issues, most of the build on my end was easy, just picking up missing deps with brew.

[stronnag]

So in summary and so I don't forget, I need to:

• pick out the C library dependencies (inc. removal of libepoxy).
• include the sub-project blueprint-compiler
• fix the extraction of the compiler metadata
• fix the 'weak' symbol in the speech wrapper
• add a setting for minimum panel size.

then anything else that doesn't work on MacOS ...

[silicongarage]

New question:
Is it possible to add support for BLE (like iNav) with fc-get & fc-set. I use Speedybee F405s (wing & mini) BLE for connectivity.

[stronnag]

New question: Is it possible to add support for BLE (like iNav) with fc-get & fc-set. I use Speedybee F405s (wing & mini) BLE for connectivity.

unfortunatly, BLE is completely OS specific, so no. However I expect there are macos BLE tools (that bridge ble into either a pseudo-terminal or IP connection.

[silicongarage]

Third Test
% export MWP_USE_PANED=1

sized by dragging the divider

[silicongarage]

mwp_stderr_2024-11-20.txt

[stronnag]

We have a winner. You can adjust the pane size (and the internal panes) to remove excess space.
I can then (TBD) save the pane width and reload it on next invocation.
Cool. It looks like we have a viable MacOS build.

So the next step will be to set the panel implementation depending on whether the OS is MacOS or other.

[silicongarage]

ha, didn't know you could adjust inner panes!

[stronnag]

Strangely, there is a (comprehensive) user guide and specifically for the panel.

[stronnag]

All the MacOS related changes are now merged into the development branch, including:

• Panel is automatically set to "Paned" on MacOS
• The pane size is saved / restored.

Looking forward to:

• (Seriously) issues for other things that may be broken on MacOS
• A PR (please, please) documenting how to build in MacOS. It could be as simple as "install this list of Hombrew packages, then follow the generic meson / ninja procedures. A PR would be cool, but even a simple text file I can merge into the docs would be much appreciated.

[silicongarage]

My github experience is low, never have done a PR.
Did so many pkg installs with mamba/conda and brew, need to figure out what a clean base is and then can document starting over. One of the biggest issues I had seems my env for homewbrew somehow kept get messed up. Lots of the meson issues with libraries would be resolved by redoing:
eval "$(/opt/homebrew/bin/brew shellenv)"

Given all that I will try to put something together. As for other issues, I don't have blackbox data, but use iNav->elrs->edgetx logs I've tried to replay. The menu for Replay OTX is grayed out. Starting with the csv file on the command line:
mwp flight-log.csv
will prompt as preparing to replay, but then nothing ever happens. Ha, probably just operator error.

[stronnag]

will prompt as preparing to replay, but then nothing ever happens. Ha, probably just operator error.

Check the log, it will most likely tell you the dependency that is not installed.

[silicongarage]

latest development branch errors at runtime:

[stronnag]

This typically happens if you install a version of mwp as a system (e.g. /usr/local) install, the do a later install (after the settings schema has changed) as a local install (~/.local).

As the system wide settings database (by default) has priority, the new binary finds the old schema and is fatally unhappy.

To fix this, you need to find any obsolete versions of org.stronnag.mwp.gschema.xml, delete them and rebuild the associated settings database.

So, if the obsolete version was /usr/local/share/glib-2.0/schemas/org.stronnag.mwp.gschema.xml,
then you would:

### AS ROOT if it's a system directory ###
MPREFIX=/usr/local
sudo rm $MPREFIX/share/glib-2.0/schemas/org.stronnag.mwp.gschema.xml
sudo glib-compile-schemas $MPREFIX/share/glib-2.0/schemas

Adjust MPREFIX as needed, sudo as necessary.

Which reminds me that the "Uninstall" section of INSTALL script refers to some obsolete files; I need to fix that.

[silicongarage]

At least on my mac, seems homebrew and conda/mamba don't play well together. I resolved a lot of the meson build issues by making sure in my .zshrc that the homebrew setup is last insuring that it then shows up first in the search PATH before the conda dirs.

Still chasing the gsettings problem:

Looking at the last output from ninja install shows that glib-compile-schemas is being run:

The schemas dir looks okay:
% ls -ld /opt/local/share/glib-2.0/schemas/*
-rw-r--r-- 1 buster wheel 5656 Nov 22 10:04 /opt/local/share/glib-2.0/schemas/gschemas.compiled
-rw-r--r-- 1 buster wheel 24320 Nov 21 21:10 /opt/local/share/glib-2.0/schemas/org.stronnag.mwp.gschema.xml

Syntax for gsettings on mac slightly different:
Usage:
gsettings --version
gsettings [--schemadir SCHEMADIR] COMMAND [ARGS…]

Running % gsettings list-schemas doesn't show org.stronnag.mwp as an installed schema.
However % gsettings --schemadir /opt/local/share/glib-2.0/schemas list-keys org.stronnag.mwp works.

Running as % sudo glib-compile-schemas /opt/local/share/glib-2.0/schemas doesn't make any difference.

[stronnag]

So you've somehow manged to install the setting schema in a place that the runtime doesn't know about (and for the record, gsettings is exactly the same on MacOS as it is anywhere else ...).

I have no visibility of what you've done, so where is mwp installed (i.e. the ninja line that installed it).?
And what does which mwp report?

[stronnag]

Also, what is the output of:

sudo find / -iname mwp
sudo find / -iname org.stronnag.mwp.gschema.xml

I'm interested to see if there are multiple examples outside of the build directory. If there are, which is the most recent?

[silicongarage]

I finally got it working.

Finder searching for both mwp and org.stronnag.mwp.gschema.xml showed no strays.
For completeness:
% which mwp
/opt/local/bin/mwp

% ls /opt/local/share/glib-2.0/schemas/*
/opt/local/share/glib-2.0/schemas/gschemas.compiled
/opt/local/share/glib-2.0/schemas/org.stronnag.mwp.gschema.xml

From its behavior, it appears mwp is using the default schemas path and not the installed script path of /opt/local/share/glib-2.0/schemas

How gsettings path defaults on macos changes depending on how it is installed - different for homebrew and conda/mamba.

For homebrew the default database:
/opt/homebrew/share/glib-2.0/schemas/gschemas.compiled

and for mamba/conda the default database:
/Users/buster/miniforge3/envs/default/share/glib-2.0/schemas/gschemas.compiled where "default" is the name of the active env

With my current PATH structure in .zshrc:
% which gsettings
/opt/homebrew/bin/gsettings

I softlinked /opt/local/share/glib-2.0/schemas/org.stronnag.mwp.gschema.xml into /opt/homebrew/share/glib-2.0/schemas and then ran % glib-compile-schemas /opt/homebrew/share/glib-2.0/schemas

Now org.stronnag.mwp shows up in the list when running % gsettings list-schemas and mwp starts up correctly

[silicongarage]

update: (mwptools 24.12.15)
Version builds and starts up.

steps:
(1) % meson setup build --wipe --buildtype=release --strip --prefix /opt/local
(2) % ninja -C build install
(3) % glib-compile-schemas /opt/homebrew/share/glib-2.0/schemas

There were some strange dylib warnings, don't know if that impacts anything:

objc[39264]: Class ResultReceiver is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgtk-3.0.dylib (0x1033f9e00) and /opt/homebrew/Cellar/gtk4/4.16.7/lib/libgtk-4.1.dylib (0x16fa2f270). One of the two will be used. Which one is undefined.
objc[39264]: Class GtkApplicationQuartzDelegate is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgtk-3.0.dylib (0x1033f9e28) and /opt/homebrew/Cellar/gtk4/4.16.7/lib/libgtk-4.1.dylib (0x16fa2f298). One of the two will be used. Which one is undefined.
objc[39264]: Class GNSMenuItem is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgtk-3.0.dylib (0x1033f9e78) and /opt/homebrew/Cellar/gtk4/4.16.7/lib/libgtk-4.1.dylib (0x16fa2f2e8). One of the two will be used. Which one is undefined.
objc[39264]: Class GNSMenu is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgtk-3.0.dylib (0x1033f9ea0) and /opt/homebrew/Cellar/gtk4/4.16.7/lib/libgtk-4.1.dylib (0x16fa2f310). One of the two will be used. Which one is undefined.
objc[39264]: Class FilterComboBox is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgtk-3.0.dylib (0x1033f9f18) and /opt/homebrew/Cellar/gtk4/4.16.7/lib/libgtk-4.1.dylib (0x16fa2f388). One of the two will be used. Which one is undefined.
objc[39264]: Class gdkCoreCursor is implemented in both /opt/homebrew/Cellar/gtk+3/3.24.43/lib/libgdk-3.0.dylib (0x102745628) and /opt/homebrew/Cellar/gtk4/4.16.7/lib/libgtk-4.1.dylib (0x16fa2f3d8). One of the two will be used. Which one is undefined.

[stronnag]

I've noticed that mwp is not remembering the pane position after I have moved them into position then quit and restarted

Vertically, horizontally or both ?

[silicongarage]

both horizontal

[stronnag]

I have probably broken that when I changed mwp to save its size of exit.

Can you please:

gsettings set org.stronnag.mwp  p-pane-width 0

restart mwp and see if the size is saner.
I still think there is a problem in that the new panel width is not saved if you resize it.

[silicongarage]

horizontal still not remembered

[stronnag]

I expected that. OK, I will look at it.

[stronnag]

Just pushed an update to development that should save the pane location. It will also 'spam' the mwp_stderr log with lines like

21:02:16.991453 :DBG: leave paned ww=1499 ppos=1155 pw=344

when you drag the pane divider.
Hopefully this will fix the MacOS pane behaviour.

[silicongarage]

I have pulled the latest dev branch, and did a wipe/rebuild

% git status
On branch development
Your branch is up to date with 'origin/development'.
nothing to commit, working tree clean

Still not saving the horizontal position
Here's the log file:
mwp_stderr_2024-12-17.txt

[silicongarage]

Maybe this is useful, I looked at the error in the log and tried to replicate on the CLI.

% dbus-launch --autolaunch=453906ec9a7d0a84418bd2d26472e7d5 --binary-syntax --close-stderr
Autolaunch requested, but X11 support not compiled in.
Cannot continue.
% which dbus-launch
/opt/homebrew/bin/dbus-launch

[stronnag]

There is definitely a problem on MacOS with Gtk's mechanism. It's on my to do list.

[stronnag]

I finally made a new "hackitosh" VM (running Ventura). It confirms multiple issues here that will require special handling in the code:

• gsettings from the shell and mwp use different gsettings stores, so changing mwp setings via gsettings is futile.
• MacOS /Gtk has a different idea of font size / string length in "pixels" compared to other platforms
• And some other issues.

[stronnag]

See #188