search

horizon-eda / horizon

Horizon is a free EDA package
https://horizon-eda.org/
GNU General Public License v3.0
1.11k stars 82 forks source link

macOS Support #271

Open phlmn opened 5 years ago

phlmn commented 5 years ago

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:

phlmn commented 5 years ago

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 commented 4 years ago

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

carrotIndustries commented 4 years ago

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 commented 3 years ago

@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: Screenshot 2020-10-12 at 12 27 03 Screenshot 2020-10-12 at 12 26 49

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

Disclaimers:

carrotIndustries commented 3 years ago

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: https://github.com/msys2/MINGW-packages/pull/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: https://github.com/horizon-eda/horizon/blob/c4b9f8f04819a55120e3c357139ce46c8c11a60c/Makefile#L734-L736

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

RIP

isometric commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

isometric commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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?

sparky4pro commented 2 years ago

Are there instructions for compiling Horizon on macOS (Apple Silicon)?

Used the makefile as is but it doesn't work.

Here the error message:

`Package libarchive was not found in the pkg-config search path. Perhaps you should add the directory containing 'libarchive.pc' to the PKG_CONFIG_PATH environment variable No package 'libarchive' found build/obj/src/util/uuid.o src/util/uuid.cpp:3:10: fatal error: 'glibmm/checksum.h' file not found

include <glibmm/checksum.h>

     ^~~~~~~~~~~~~~~~~~~

1 error generated. make: *** [build/obj/src/util/uuid.o] Error 1`

Home-brew could not find libarchive even though it was installed with 'brew install libarchive' but it's not pulled in.

Also, glibmm/checksum.h is not found even so I can manually compile gtkmm code with g++ just fine.

Installed all the other libs needed by Horizon...

EDIT: Yes, I found out that for libzmq I had to install zmq

carrotIndustries commented 2 years ago

For zeromq, zeromq and zmqpp seem to be the right packagesin homebrew.

sparky4pro commented 2 years ago

Yes, I found out that for libzmq I had to 'brew install zmq'.

However, libarchive is still not pulled in.

This is the info from homebrew:

`libarchive: stable 3.6.1 (bottled) [keg-only] Multi-format archive and compression library https://www.libarchive.org /opt/homebrew/Cellar/libarchive/3.6.1 (62 files, 3.7MB) Poured from bottle on 2022-05-23 at 13:01:01 From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/libarchive.rb License: BSD-2-Clause ==> Dependencies Required: libb2 ✔, lz4 ✔, xz ✔, zstd ✔ ==> Caveats libarchive is keg-only, which means it was not symlinked into /opt/homebrew, because macOS already provides this software and installing another version in parallel can cause all kinds of trouble.

If you need to have libarchive first in your PATH, run: echo 'export PATH="/opt/homebrew/opt/libarchive/bin:$PATH"' >> ~/.zshrc

For compilers to find libarchive you may need to set: export LDFLAGS="-L/opt/homebrew/opt/libarchive/lib" export CPPFLAGS="-I/opt/homebrew/opt/libarchive/include"

For pkg-config to find libarchive you may need to set: export PKG_CONFIG_PATH="/opt/homebrew/opt/libarchive/lib/pkgconfig"`

BTW: sorry, somehow I didn't see that you already answered, so I edited my former post. (I think I forgot to refresh the GitHub page before editing...)

sparky4pro commented 2 years ago

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 commented 2 years ago

but came to a halt at

you're missing boost

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

sparky4pro commented 2 years ago

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 commented 2 years ago

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:

Screenshot 2022-05-27 at 01 11 27 Screenshot 2022-05-27 at 01 13 45

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);
sparky4pro commented 2 years ago

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.

sparky4pro commented 2 years ago

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 commented 2 years ago

@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?

sparky4pro commented 2 years ago

@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

sparky4pro commented 2 years ago

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...

sparky4pro commented 2 years ago

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...

sparky4pro commented 2 years ago

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 commented 2 years ago

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:

Screenshot 2022-05-30 at 00 30 53 Screenshot 2022-05-30 at 00 30 57

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)

sparky4pro commented 2 years ago

@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 commented 2 years ago

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)

sparky4pro commented 2 years ago

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

Looking forward when horizon will use gtk4 :)

sparky4pro commented 2 years ago

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

carrotIndustries commented 2 years ago

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:

2022-05-30-200932_1920x1080_scrot

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.

sparky4pro commented 2 years ago

@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 :(

sparky4pro commented 2 years ago

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 commented 2 years ago

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.

sparky4pro commented 2 years ago

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 commented 2 years ago

Re: GTK4, FYI a handy way to track preparedness is here if you want to copy it: https://github.com/solvespace/solvespace/issues/853

carrotIndustries commented 2 years ago

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 https://github.com/horizon-eda/horizon/issues/271#issuecomment-1141390647

gitfoxi commented 1 year ago

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