macOS Support

[phlmn]

I think it's a good idea to keep track the state of macOS support inside an issue.

I started to implement macOS support with #264, but are are quite some things missing. Things I currently have on my mind:

• make it compile (macOS Support (frist steps) #264)
• make it start (macOS Support (frist steps) #264)
• make the board viewer work (see OpenGL issue below)
• fix icons

[phlmn]

OpenGL Issue (from #264)

Unfortunately the board viewer does not work yet. glLineWidth(…) and glBlitFrameBuffer(…) are causing an error. By removing glLineWidth(…) and drawing directly to the screen instead of using glBlitFrameBuffer(…) the board viewer does start. Debugging OpenGL is not much fun, maybe someone has an idea.

Some potentially useful apitrace output:

$ ./apitrace replay horizon-imp.5.trace
/Users/phlmn/Coding/apitrace/build/../../horizon/horizon-imp
1 @0 CGLRetainPixelFormat(pix = 0x7ff682f98870) = 0x7ff682f98870
1: warning: unsupported CGLRetainPixelFormat call
2 @0 CGLReleasePixelFormat(pix = 0x7ff682f98870)
2: warning: unsupported CGLReleasePixelFormat call
4 @0 CGLRetainContext(ctx = 0x7ff68406a400) = 0x7ff68406a400
4: warning: unsupported CGLRetainContext call
5 @0 CGLReleaseContext(ctx = 0x7ff68406a400)
5: warning: unsupported CGLReleaseContext call
6 @0 CGLReleasePixelFormat(pix = 0x7ff682f98870)
6: warning: unsupported CGLReleasePixelFormat call
14 @0 CGLRetainPixelFormat(pix = 0x7ff682e7a510) = 0x7ff682e7a510
14: warning: unsupported CGLRetainPixelFormat call
15 @0 CGLReleasePixelFormat(pix = 0x7ff682e7a510)
15: warning: unsupported CGLReleasePixelFormat call
17 @0 CGLRetainContext(ctx = 0x7ff68492f800) = 0x7ff68492f800
17: warning: unsupported CGLRetainContext call
18 @0 CGLReleaseContext(ctx = 0x7ff68492f800)
18: warning: unsupported CGLReleaseContext call
19 @0 CGLReleasePixelFormat(pix = 0x7ff682e7a510)
19: warning: unsupported CGLReleasePixelFormat call
GL_RENDERER: Intel(R) Iris(TM) Graphics 550
GL_VENDOR: Intel Inc.
477 @0 glLinkProgram(program = 8)
477: warning: WARNING: Output of vertex shader 'oid_to_geom' not read by geometry shader
WARNING: Output of vertex shader 'lod_to_geom' not read by geometry shader

509 @0 glLinkProgram(program = 9)
509: warning: WARNING: Output of vertex shader 'oid_to_geom' not read by geometry shader

541 @0 glLinkProgram(program = 10)
541: warning: WARNING: Output of vertex shader 'oid_to_geom' not read by geometry shader
WARNING: Output of geometry shader 'flags_to_fragment' not read by fragment shader

573 @0 glLinkProgram(program = 11)
573: warning: WARNING: Output of vertex shader 'oid_to_geom' not read by geometry shader
WARNING: Output of geometry shader 'flags_to_fragment' not read by fragment shader

GL_RENDERER: Intel(R) Iris(TM) Graphics 550
GL_VENDOR: Intel Inc.
1299 @0 glLineWidth(width = 2)
1299: warning: glGetError(glLineWidth) = GL_INVALID_VALUE
1311 @0 glLineWidth(width = 2)
1311: warning: glGetError(glLineWidth) = GL_INVALID_VALUE
Rendered 0 frames in 0.241093 secs, average of 0 fps

[wraybowling]

Maybe move this to Milestones if it's a priority. https://github.com/horizon-eda/horizon/milestones

[carrotIndustries]

I'm still a bit undecided whether it's worth given the current state of OpenGL and Gtk on mac os. There still seem to be quite a lot of glitches in GtkGLArea's quartz backend and apple's move to only allow notarized apps to run doesn't make mac os an attractive platform to target.

[schneider-engineering]

@phlmn Icons are fixed by providing hicolor-icon-theme, e.g. through brew. The issue with glBlitFrameBuffer() is caused as the renderbuffer on the GLArea framebuffer ist GL_RGB8 instead of GL_RGBA8. set_has_alpha(true) somewhere in the constructor fixes this. I'm using GTK+3 stable (3.24.23), on the Master branch half of GLArea is rewritten, not entirely sure what problems will arise then.

This is how horizon on 10.15 currently looks for me:

Main problem so far is window resizing. This is completely broken. Moving between HiDPI (internal) and normal DPI (external monitor) is a problem as well, not entirely sure if this is related.

@carrotIndustries I get your point about notarizing, at least bundling an app package seems somewhat supported by the project itself: GTK OSX Bundling wiki page. In general I'm surprised how much actually works.

[schneider-engineering]

FWIW, the resizing issues seems to be an GTK issue. Happens with the glarea demo as well. Looks pretty much like this is the same issue: https://gitlab.gnome.org/GNOME/gtk/-/issues/1298

[carrotIndustries]

That's excellent news! To me that's enough to claim at least 'experimental' mac OS support. Please open a PR with the changes you did to make it build an run or tell me which of the existing mac OS-related PRs to merge. With that done we can also add CI to make sure it keeps building on mac OS.

[schneider-engineering]

This was built using master, I will have a look at #290, which I missed so far, thanks for pointing that out.

Things I would like to hear your opinion on before creating a PR:

• cppzmq is kind of hard to get on OSX. Would you consider to bundle it? I just threw it into 3rd_party for a first try.
• podofo doesn't play well with clang and c++17.
  /usr/local/include/podofo/base/PdfFilter.h:466:17: error: no template named 'auto_ptr' in namespace 'std'. I fixed this by adding -D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR to CXXFLAGS. Not a real c++ dev here, so no clue what side effects could be caused by this. Opinions?

Disclaimers:

• Grid rendering is only sloppy fixed so far, by forcing the line thickness to 1. Fixing this by actually using quads sounds easy enough but isn't done.
• As of now there is NO support for anything related to the menubar (The menu macOS has at the top of the screen)
• Keybindings are untouched, Command+Q works on some windows, but even minimizing a window with default system keybindings won't work right now. Not a GTK dev here.
• There is no app bundling done yet. build and run on osx #290 has something in that regards, but as this is developer grade anyhow right now, I can live without an app bundle just fine. Window resizing has to be fixed before thinking about distributing this in an easier fashion anyhow.
• As mentioned: resize the window and you can basically restart horizon.

[carrotIndustries]

As mentioned: resize the window and you can basically restart horizon.

Oh, didn't realize it's that bad. Claiming mac OS support with that level of buggyness will most likely cause more annoyances than not supporting it for the time being.

cppzmq is kind of hard to get on OSX. Would you consider to bundle it?

Isn't it available in homebrew? For msys2 for example, I added the c++ bindings to the zeromq package upstream: msys2/MINGW-packages#2193

podofo doesn't play well with clang and c++17

We've had the same issue on freebsd, so adding darwin to that if should to the trick:

horizon/Makefile

Lines 734 to 736 in c4b9f8f

	ifeq ($(UNAME), FreeBSD)
	CXXFLAGS += -D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR
	endif

Fixing this by actually using quads sounds easy enough but isn't done.

Another avenue could be to draw quads and turn them into grid marks in the fragment shader. My gut feeling tells me that his might be slightly faster.

As of now there is NO support for anything related to the menubar

I guess that this could alienate a lot of mac OS users, so we probably need to come up with one.

but even minimizing a window with default system keybindings won't work right now. Not a GTK dev here.

If that also happens with other Gtk apps, you should probably report in the gtk bugtracker.

[isometric]

Looks like GTK got a new OGL backend for macOS.

https://blogs.gnome.org/chergert/2020/12/15/gtk-4-got-a-new-macos-backend-now-with-opengl/

[carrotIndustries]

Looks like GTK got a new OGL backend for macOS.-

That's good news, but that's Gtk 4. It'll likely take quite some time till we use Gtk4 since it deprecated some features we need: https://discourse.gnome.org/t/using-gtkpopovermenu-as-a-gtkmenu-replacement/3786

We also need to make sure that a usable version of Gtk4 is available in all distros we want to support, i.e. Debian stable and Ubuntu LTS.

[isometric]

RIP

[isometric]

@schneider-engineering Can you share your changes? For zmq, relying on osrf/simulation/cppzmq seems fine.
@carrotIndustries How set against maintaining 3+4 are you? Never done GTK stuff but might take a shot at it over the holidays, a few pointers would be helpful.

[carrotIndustries]

How set against maintaining 3+4 are you?

As far as I can tell, that's not really feasible since there have been some significant API changes, such as gtk_box_pack_start being replaced by gtk_box_append. Also check out https://developer.gnome.org/gtk4/4.0/gtk-migrating-3-to-4.html Gtkmm4 also has just been released a day ago.

All in all, the earliest we can start thinking about Gtk4 is if it's available on all platforms as it's either gtk3 or gtk4.

[schneider-engineering]

@isometric somehow lost sight of this. will have a look tomorrow, ok?

[isometric]

It seems like longer term we should consider dropping from OGL to GLES and then maybe ANGLE if it comes to that. Seems like OGL all but dead as future support is concerned -- if not for macOS it then for the rPi 4 and successors.

[carrotIndustries]

It seems like longer term we should consider dropping from OGL to GLES

That idea has crossed my mind as well. The minimum GLES version required though would be 3.2 due to extensive (or excessive?) use of geometry shaders. We should keep support for OpenGL proper as that allows for more optimal rendering such as glDrawElementsInstancedBaseInstance to draw all instances of one model in the 3D preview in one call.

My main motivation for supporting GLES is bringing the app to non-x86 platforms since none(?) of the GPUs in ARM SoCs support non-ES OpenGL.

[isometric]

Hmm it seems like the rPi is already GLES 3.2 - it also supports OGL 2 and I think some of the nV Tegra stuff supports OGL 4.x but it's not exactly the most relevant platform these days.

[isometric]

So I was able to get horizon running by pull just the GL fixes in #290 without the memory violations. Also managed to get GTK built from source so might take a stab at resizing next week. Not sure why but I noticed that the black frame/halo around schematic/pcb doesn't appear in the gtk3-demo, any ideas @schneider-engineering?

It also looks like GTK4 just uses ANGLE for compat so we may as well just use that directly if this doesn't work. @carrotIndustries any idea how much work is needed for GLES?

[carrotIndustries]

any idea how much work is needed for GLES?

I don't have any experience at all with GLES, but apart from some functions as the mentioned glDrawElementsInstancedBaseInstance most of Horizon EDA's OGL usage is probably available in GLES 3.2. Anything below that would require some dramatic changes due to lack of geometry shaders. As far as I got the ANGLE docs, GLES 3.2 is stil WIP.

Not sure why but I noticed that the black frame/halo around schematic/pcb doesn't appear in the gtk3-demo, any ideas @schneider-engineering?

Might be related to client-side decorations and/or OpenGL.

[atoav]

I'd like to teach horizon as part of our university course, and the lack of macOS support is as of now the only thing blocking me from doing so, as many of our students have Macbooks. Sadly I don't have a mac myself so I can't really look into it, but I am definitly following this development : )

[bob-u]

Perhaps the best way forward would be to run Easy EDA on MacOS MoltenVK via Zink:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7383

Zink is OpenGL implementation running on top of Vulkan or in case of Mac MoltenVK.

[david12481632]

Perhaps the best way forward would be to run Easy EDA on MacOS MoltenVK via Zink:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7383

Zink is OpenGL implementation running on top of Vulkan or in case of Mac MoltenVK.

That looks promising

https://www.collabora.com/news-and-blog/blog/2021/06/14/zink-summer-2021-update/

[tkornack]

I would love to hear if anything has changed here. I came to say that I was able to compile without any trouble on Apple silicon with just a set of homebrew libraries. The GL view crashes, as described above.

There are a load of macOS Eagle users who need to bail out now that it's really dead and this really seems like the right place to land. Anyone interested in taking sponsored work on this topic?

[sparkylein]

I've added:

export PKG_CONFIG_PATH="/opt/homebrew/opt/libarchive/lib/pkgconfig"
export LDFLAGS="-L/opt/homebrew/opt/libarchive/lib"
export CPPFLAGS="-I/opt/homebrew/opt/libarchive/include"

into the terminal and now Horizon started compiling... but came to a halt at:

---

build/obj/3rd_party/router/router/pns_router.o
In file included from 3rd_party/router/router/pns_router.cpp:41:
In file included from 3rd_party/router/router/pns_node.h:31:
3rd_party/router/include/core/optional.h:4:10: fatal error: 'boost/optional.hpp' file not found
#include <boost/optional.hpp>
^~~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [build/obj/3rd_party/router/router/pns_router.o] Error 1

---

Boost 1.78.0_1 is installed and up-to-date.

[carrotIndustries]

but came to a halt at

you're missing boost

If boost is installed in homebrew, you might want to check the include paths.

[sparkylein]

EDIT:
I deleted my former post as I kept working on getting horizon to compile on macOS (Apple Silicon).

Got all former barriers out of the way (with changing the makefile) but it looks like one thing is still holding me up: lstdc++fs.

[schneider-engineering]

I just gave it another try. Like a few years ago, there are some OpenGL issues. Grid is not working, set_has_alpha is still required. The GTK / GL situation has not improved at all. Trying to move the window crashes everything. For whatever reason the icon theme was not loaded, didn't investigate. MacOS 12, arm64.

Screenshots:

Required brew packages:

boost
gtkmm3
zmq
libsigc++
libarchive
glm
libgit2
glib
opencascade
cppzmq
podofo
hicolor-icon-theme

Note: zmqpp is not the correct package, cppzmq is.

Build command:
CASROOT="/opt/homebrew/Cellar/opencascade/7.6.2/" PKG_CONFIG_PATH="/opt/homebrew/opt/libarchive/lib/pkgconfig" make -j

"necessary" patch (this is a little hacky, but I guess assuming to have homebrew is fine nowerdays):

diff --git a/Makefile b/Makefile
index f897c6d3..d3c5c47e 100644
--- a/Makefile
+++ b/Makefile
@@ -883,6 +883,10 @@ ifneq ($(OS),Windows_NT)
 endif
 LIBS_ALL = $(LIBS_COMMON) gtkmm-3.0 epoxy cairomm-pdf-1.0 librsvg-2.0 libzmq libgit2 libcurl glm libpng libarchive
 
+ifeq ($(shell uname), Darwin)
+	LIBS_ALL += gio-2.0
+endif
+
 OPTIMIZE = -fdata-sections -ffunction-sections -O3
 DEBUGFLAGS = -g3
 WARNFLAGS = -Wall -Wshadow
@@ -921,16 +925,19 @@ else
 	UNAME := $(shell uname)
 	ifeq ($(UNAME), FreeBSD)
 		CXXFLAGS += -D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR
-	else
-		LDFLAGS += -lstdc++fs
 	endif
 	ifeq ($(UNAME), Darwin)
-		# do nothing on mac os
+		CXXFLAGS += -D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR
+		CXXFLAGS += -I/opt/homebrew/include
+		LDFLAGS += -L/opt/homebrew/lib
 	else
 		# allow ld.gold to be overriden by command line
 		GOLD = -fuse-ld=gold
 		LDFLAGS += $(GOLD)
 	endif
+	ifeq ($(UNAME), Linux)
+		LDFLAGS += -lstdc++fs
+	endif
 endif
 
 SRC_SHARED_3D = \
@@ -964,7 +971,7 @@ OBJDIR           = $(BUILDDIR)/obj
 PICOBJDIR        = $(BUILDDIR)/picobj
 GENDIR           = $(BUILDDIR)/gen
 MKDIR            = mkdir -p
-QUIET            = @
+QUIET            = 
 ECHO             = @echo
 
 # Object files
diff --git a/src/canvas/canvas_gl.cpp b/src/canvas/canvas_gl.cpp
index 7dbb8905..dc09dee3 100644
--- a/src/canvas/canvas_gl.cpp
+++ b/src/canvas/canvas_gl.cpp
@@ -90,6 +90,8 @@ CanvasGL::CanvasGL()
                 }
                 return false;
             });
+
+    set_has_alpha(true);
 }
 
 void CanvasGL::set_grid_spacing(uint64_t x, uint64_t y)
@@ -261,8 +263,8 @@ bool CanvasGL::on_render(const Glib::RefPtr<Gdk::GLContext> &context)
     if (show_pictures)
         picture_renderer.render(false);
     GL_CHECK_ERROR
-    grid.render();
-    GL_CHECK_ERROR
+    // grid.render();
+    // GL_CHECK_ERROR
     triangle_renderer.render();
     GL_CHECK_ERROR
     if (show_pictures)
@@ -272,14 +274,20 @@ bool CanvasGL::on_render(const Glib::RefPtr<Gdk::GLContext> &context)
     GL_CHECK_ERROR
     drag_selection.render();
     GL_CHECK_ERROR
-    grid.render_cursor(cursor_pos_grid);
-    marker_renderer.render();
+    // grid.render_cursor(cursor_pos_grid);
+    // marker_renderer.render();
     glDisable(GL_BLEND);
+    GL_CHECK_ERROR
 
     glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fb);
+    GL_CHECK_ERROR
+
     glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo);
+    GL_CHECK_ERROR
+
     glBlitFramebuffer(0, 0, m_width * get_scale_factor(), m_height * get_scale_factor(), 0, 0,
                       m_width * get_scale_factor(), m_height * get_scale_factor(), GL_COLOR_BUFFER_BIT, GL_NEAREST);
+    GL_CHECK_ERROR
 
     glBindFramebuffer(GL_FRAMEBUFFER, fb);

[sparkylein]

Hi Schneider-engineering,
yes, found out about cppzmq before I edited my last post, which solved a lot of issues.
Still fighting lstdc++fs and opencascade (can't find the lib; there are only dylibs in the lib dir).

Anyway, tried to use your patch file but I get this error message:

patching file Makefile
can't find file to patch at input line 52
Perhaps you should have used the -p or --strip option?
The text leading up to this was:

|diff --git a/src/canvas/canvas_gl.cpp b/src/canvas/canvas_gl.cpp
|index 7dbb8905..dc09dee3 100644
|--- a/src/canvas/canvas_gl.cpp
|+++ b/src/canvas/canvas_gl.cpp

File to patch: ...

BTW: I used a clean Makefile from the repo.
Thank you for your input.

[sparkylein]

Started to compile on macOS-x86_64 and ran into the same problem as with macOS-arm64:
-lstdc++fs is holding up that the compilation goes through.

What am I missing?

EDIT:

Duh...

the makefile still had:

ifeq ($(UNAME), FreeBSD)
	CXXFLAGS += -D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR
else
	LDFLAGS += -lstdc++fs
endif

After commenting out
LDFLAGS += -lstdc++fs
It compiled all the way.

However, there are still bugs to iron out as schneider-engineering mentioned.
At least it's a start.
:D

[schneider-engineering]

@sparkylein sorry, for the late response. Not sure why the patch would not apply for you. Glad you got it compiled in the end. Clang/LLVM has <filesystem> support starting from 9.0, so the flag is not supported. When you read the patch, you can see I removed it as well.

Would you mind sharing your environment variables, that made the makefile patch minimal?

What machine do you have? Do you have a retina display? From what I remember, half of the issues in GTK are caused by DPI and screen/pixel coordinate conversion issues.

What patches to canvas_gl where necessary for you to get it to render?

[sparkylein]

@schneider-engineering, no worries. I used the master branch (got it through a zip file) and I suppose you pulled from git which gives you the latest incarnation of the repo.
My goal was to get it to compile first, and then worry about bugs in the app later.
Therefore, I did not apply any GTK, GL or other mods yet.

Compiled it on 2 macOS machines: one with intel-i5 and the other has the M1-Max.
Homebrew places the library files in different locations, so the makefile had to be adapted.

The makefile change for macOS-intel is:

---

ifeq ($(UNAME), Darwin)
	# add this on mac os (intel) to make it work
	CXXFLAGS += "-I/opt/homebrew/include"
	LDFLAGS +="-L/usr/local/opt/boost/lib"
        CXXFLAGS +="-I/usr/local/opt/boost/include"
	LDFLAGS +="-L/usr/local/opt/glm/lib"
        CXXFLAGS +="-I/usr/local/opt/glm/include"
	LDFLAGS +="-L/usr/local/opt/zmq/lib"
        CXXFLAGS +="-I/usr/local/opt/zmq/include"
        CXXFLAGS +="-I/usr/local/opt/cppzmq/include"
	LDFLAGS +="-L/usr/local/opt/libarchive/lib"
        CXXFLAGS +="-I/usr/local/opt/libarchive/include"
	LDFLAGS +="-L/usr/local/opt/podofo/lib"
        CXXFLAGS +="-I/usr/local/opt/podofo/include"
	LDFLAGS +="-L/usr/local/opt/librsvg/lib"
        CXXFLAGS +="-I/usr/local/opt/librsvg/include/librsvg-2.0"

---

The makefile change for macOS-Apple-Silicon is:

---

ifeq ($(UNAME), Darwin)
	# add this on mac os (Apple Silicon) to make it work
	CXXFLAGS += "-D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR"
	CXXFLAGS += "-I/opt/homebrew/include"
	LDFLAGS += "-L/opt/homebrew/lib"
	LDFLAGS +="-L/opt/homebrew/opt/boost/lib"
        CXXFLAGS +="-I/opt/homebrew/opt/boost/include"
	LDFLAGS +="-L/opt/homebrew/opt/glm/lib"
        CXXFLAGS +="-I/opt/homebrew/opt/glm/include"
        CXXFLAGS +="-I/opt/homebrew/opt/opencascade/include/opencascade"
	LDFLAGS +="-L/opt/homebrew/opt/zmq/lib"
        CXXFLAGS +="-I/opt/homebrew/opt/zmq/include"
        CXXFLAGS +="-I/opt/homebrew/opt/cppzmq/include"
	LDFLAGS +="-L/opt/homebrew/opt/libarchive/lib"
        CXXFLAGS +="-I/opt/homebrew/opt/libarchive/include"
	LDFLAGS +="-L/opt/homebrew/opt/podofo/lib"
        CXXFLAGS +="-I/opt/homebrew/opt/podofo/include"
	LDFLAGS +="-L/opt/homebrew/opt/librsvg/lib"
        CXXFLAGS +="-I/opt/homebrew/opt/librsvg/include/librsvg-2.0"

---

To make it easier I borrowed a python file from the KiCAD Mac-builder package and changed to (build_on_mac.py):

---

#!/usr/bin/env python

#Try not to use any packages that aren't included with Python, please.

import argparse
import errno
import os
import subprocess
import sys

def print_and_flush(s):
# sigh, in Python3 this is build in... :/
print(s)
sys.stdout.flush()

def get_number_of_cores():
return int(subprocess.check_output("sysctl -n hw.ncpu", shell=True).strip())

def get_local_macos_version():
return subprocess.check_output("sw_vers -productVersion | cut -d. -f1-2", shell=True).decode('utf-8').strip()

def main():
print("Local macOS version: " + get_local_macos_version())
print("Get number of available processor cores: " + str(get_number_of_cores()))

subprocess.run("export PKG_CONFIG_PATH=\"/opt/homebrew/opt/libarchive/lib/pkgconfig\" && CASROOT=\"/opt/homebrew/Cellar/opencascade/\" && make -j " + str(get_number_of_cores()), shell=True)

if name == "main":
main()

---

This python script is used to compile with max cores.

Before I forget, I also used a shell script to pull in all libraries with home-brew (again... borrowed it from the KiCAD Mac-builder package) and changed it accordingly (bootstrap.sh):

---

#!/bin/bash
set -x
set -e

#homebrew location (/usr/local for macOS Intel, /opt/homebrew for Apple Silicon and /home/linuxbrew/.linuxbrew for Linux)

#Easy hack to get a timeout command
function timeout() { perl -e 'alarm shift; exec @argv' "$@"; }

for _ in 1 2 3; do
if ! command -v brew >/dev/null; then
echo "Installing Homebrew ..."
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" < /dev/null
else
echo "Homebrew installed."
break
fi
done

PATH=$PATH:/usr/local/bin
export HOMEBREW_NO_ANALYTICS=1
echo "Updating SSH"
brew install openssh
echo "Installing some dependencies"
brew reinstall gtkmm3 cairomm librsvg util-linux sqlite boost glm glib libgit2 curl opencascade zmq zmqpp cppzmq podofo libarchive libspnav libsigc++ hicolor-icon-theme

---

Normally I don't like to use several different shell scripts and python helper code, but in this case I was eager to get it done. :P
I might try to consolidate all needed settings into one file.

The next steps are fixing all the bugs on macOS.
:D

[sparkylein]

Compile time:

macOS Monterey 12.4 on 2016 MacBook Pro with intel-i5: 9:50 minutes
(sysctl -n hw.ncpu counts 8 cores: 4 cpu cores and 4 threads)

macOS Monterey 12.4 on 2021 MacBook Pro with M1-Max: 2:10 minutes
(sysctl -n hw.ncpu counts 10 cores: 10 cpu cores)

DIdn't think the difference would be that big...

[sparkylein]

As schneider-engineering mentioned "set_has_alpha(true);" needs to be set otherwise the schematic and board windows will crash and not open.
I've placed it in canvas_gl.cpp line 45 just above "set_can_focus(true);"

What's really weird is that both windows (schematic and board windows) have a thick dark frame surrounding them.
If the window is resized, the black frame does not resize, but if the window is resized bigger than the black frame that window portion is hidden... weird.

Also in WIndows all shortcuts are Ctrl-Z, Ctrl-S, etc. on Mac it needs to move to Cmd-Z, Cmd-S respectively.

Edit: fixed typo...

[sparkylein]

The horizon imp window is acting weird on this platform.
When the window is resized, the whole window is resized, not only the GL canvas, but also the UI itself making everything (buttons, sliders, everything) distorted.
Spent many hours trying to understand how OpenGL is used in horizon, with no avail.
Looked at kicad's canvas code (as kicad doesn't have this resizing problem) but didn't find much similarities between the two to figure out why horizon's canvas distorts everything while resizing the window. )
Because the aspect ratio follows the window size and makes drawn circles ovals, horizon becomes unusable.
The buttons, sliders, etc. change their shape and location which makes the cursor unusable to click on any ui widget.
Having no comments in the source code is not helping...

[schneider-engineering]

hey @sparkylein,

gtkmm (3) on mac os does not seem to be too mature.

Very minimal Demo based on https://github.com/GNOME/gtkmm/blob/gtkmm-3-24/demos/gtk-demo/example_glarea.cc:

It has the exact same issues. This is not due to the lack of comments in Horizon ;) Interestingly enough the drop shadow around the window renders just fine, but all other issues are exactly the same (Even without the GLArea).

As I'm neither comfortable with GTK, nor with C++, this is where I gave up the last time (and just kept using KiCAD)

[sparkylein]

@schneider-engineering, you are correct, if a simple gtkmm app has the same issues, then it it likely impossible to fix this downstream…

Nevertheless, documenting code is a good habit to have, especially in a complicated software package like horizon. Looking through the code and see the different kind of technologies that were used to accomplish this and the fact that this is the work of one person amazes me. Just wonderful!
I can see so much potential in horizon, that IMHO it would be a bummer if in a few years from now @carrotIndustries is still the only one… and because of this is burned out. It becomes easier if the burden of fixing/enhancing the code base, and writing documentation, rests on more shoulders.

I spent over a decade on Linux, which is great, but wanted better hardware, than HP, Lenovo, etc. can offer, which made me move to a Mac. Therefore, I would love to see horizon work well on macOS :)

[tkornack]

As I'm neither comfortable with GTK, nor with C++, this is where I gave up the last time (and just kept using KiCAD)

I also gave up but I have had success running Horizon on virtualized linux in UTM on both amd64/intel and aarch64/M1.

It seems that a lot of these issues were recently addressed in the new macos gtk backend 4 [1], so I think we should wait until horizon is ported to version 4. That might have to wait until 2023 which is roughly when gtk4 [2] will appear in a stable Debian with the release of Debian Bookworm [3].

[1] https://blogs.gnome.org/chergert/2020/12/15/gtk-4-got-a-new-macos-backend-now-with-opengl/
[2] https://tracker.debian.org/pkg/gtk4
[3] https://en.wikipedia.org/wiki/Debian_version_history#Debian_12_(Bookworm)

[sparkylein]

@tkornack, thank you for the info.
Found even more: https://blogs.gnome.org/chergert/2022/02/

Looking forward when horizon will use gtk4 :)

[sparkylein]

BTW: homebrew has already gtkmm-4.6.
Just saying :P

[carrotIndustries]

Looking forward when horizon will use gtk4 :)

Don't hold your breath. Right now, gtk 4 makes it much harder to attain the user experience I want for Horizon EDA:

• https://gitlab.gnome.org/GNOME/gtk/-/issues/3502
• https://discourse.gnome.org/t/popup-menus-in-gtk4/6278
• https://discourse.gnome.org/t/pointer-warping-on-wayland/9197
• https://discourse.gnome.org/t/using-gtkpopovermenu-as-a-gtkmenu-replacement/3786
• On i3, without composting menus look like this:

Porting Horizon EDA to Gtk4 would be a multi-month effort and it'll most likely have worse user experience than the current Gtk3 implementation.

[sparkylein]

@carrotIndustries, thank you for the links.
It shows that you are way ahead of us, as you posted gtk4 issues already a year ago.
Oh well, this is quite sobering... so, no horizon-eda any time soon on macOS :(

[sparkylein]

Is this a different gtk beast?
https://gitlab.gnome.org/GNOME/gtk-osx/
https://gitlab.gnome.org/GNOME/gtk-mac-integration/
https://gitlab.gnome.org/GNOME/gtk-mac-bundler/
It works with gtk2 and gtk3.

Obviously this gnome/gtk project started life as:
https://sourceforge.net/projects/gtk-cocoa/
(which works with gtk1)

Not sure if it is worth looking into this...

[carrotIndustries]

Is this a different gtk beast?

From a cursory glance, they're all about improved integration or packaging. None of them will fix the issues the mac OS backend has.

[sparkylein]

And I though because (at least that's what I thought it is) it's a thin layer with gtk widget names but inside they use native cocoa widgets, it would eliminate any redrawing issues that exist with "normal" gtk widgets.

Thank you for your time and input in this.

[phkahler]

Re: GTK4, FYI a handy way to track preparedness is here if you want to copy it:
solvespace/solvespace#853

[carrotIndustries]

Re: GTK4, FYI a handy way to track preparedness is here if you want to copy it:

Solvespace is in a much better position for adapting to a new UI toolkit since it already supports three and doesn't contain that much UI and UI-specific code to begin with. See #271 (comment)

[gitfoxi]

While you're not holding your breath you can try it under Ubuntu, using Parallels on Apple Silicon. It mostly works and performance is great.

Build it from source.

3D viewer doesn't work :(

No provider of glDrawElementsInstancedBaseInstance found.  Requires one of:
    Desktop OpenGL 4.2
    GL_ARB_base_instance
    GL_EXT_base_instance

If you really want 3D viewer with terrible performance, run it like:

LIB_GL_ALWAYS_SOFTWARE=1 horizon-eda

[tkornack]

UTM also works well; 3D works and is tolerable.

[gitfoxi]

@tkornack I took your advice and gave UTM a try.

At first it had the same OpenGL problems I'd seen elsewhere.

I learned that UTM has recently implemented a new display driver virtio-gpu-gl-pci which uses the GPU and is very snappy but breaks Horizon. I was surprised that even the LIB_GL_ALWAYS_SOFTWARE workaround does not help like it does in parallels. You can configure UTM to use the old display driver, virtio-ramfb, and then Horizon works but the performance is only tolerable, not great.

[carrotIndustries]

No provider of glDrawElementsInstancedBaseInstance found. Requires one of:

Interesting, that's the first GL implementation I've come across that doesn't support this function. Implementing a workaround that uses one draw call per component should be possible. It's nothing that I plan on doing, but if someone wants to do it, I'm glad to help.

[gitfoxi]

VMWare Fusion claims to have OpenGL 4.3 so I gave it a shot. My 3rd trip through the Ubuntu installer in as many days.

Good news: 3D works perfectly!

Bad news: Nothing else works!

The schematic and layout tools just show the blue background with the light blue plusses. You can zoom in and out on the plusses, but nothing else displays.

I learned that getting OpenGL to work consistently across different GPUs and OSs is something people are very interested in, because of games. But it must be very hard to accomplish, though, and there's no easy solutions in the marketplace.

The internet recommends to use middleware instead, specifically Orge3d, https://www.ogre3d.org/about/features which does seem to have a story about integrating with GTK. https://wiki.ogre3d.org/GtkmmOgre

[gitfoxi]

@carrotIndustries, I gave it a try.

Parallels supports OpenGL 4.0. The function that requires OpenGL 4.2 is glDrawElementsInstancedBaseInstance. OpenGL 4.0 can support the similar-sounding function glDrawElementsInstanced. So,

glDrawElementsInstancedBaseInstance -- 👎
glDrawElementsInstanced -- 👍

The difference is the final parameter called baseinstance. What does baseinstance do? I read the documentation 5 times and I have no idea. It's a mystery to me.

https://registry.khronos.org/OpenGL-Refpages/gl4/html/glDrawElementsInstancedBaseInstance.xhtml

What's passed to baseinstance is something called, idxs.offset. I can't figure out what it's for. But I decided to see what happens without it.

-                    glDrawElementsInstancedBaseInstance(GL_TRIANGLES, it.count, GL_UNSIGNED_INT,
-                                                        (void *)(it.face_index_offset * sizeof(int)), idxs.n_packages,
-                                                        idxs.offset);
+                    glDrawElementsInstanced(GL_TRIANGLES, it.count, GL_UNSIGNED_INT,
+                                                        (void *)(it.face_index_offset * sizeof(int)), idxs.n_packages);

What happens is, some components appear in the wrong place.

If I could understand what idx.offset is doing as a baseinstance, maybe I could make progress.

But there's more problems. With this fix the 3D viewer does load and run under Parallels without error. However, it's a black screen except for the axis which animate perfectly.

I don't know how I can make progress against a black screen.

[tkornack]

Don't hold your breath. Right now, gtk 4 makes it much harder to attain the user experience I want for Horizon EDA

I'm curious if anything has changed about GTK4 support, given the time that's passed or your experience writing Dune 3D.