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.