Note: I actually sent this email to Chris a month ago but it didn’t go to the list, so I’m sending it there so that there’s a record of this conversation.
I’ve been quietly working on this for a few weeks now, and have got the various permutations working on OS X. Basically, there are 2 paths for GTK on OS X (now called macOS): X11, which is the classic approach, and Quartz, which is native, but newer and a little less fully baked. Homebrew, a very popular package manager on OS X, switched to Quartz mode at some point, which broke the pike builds. This sort of dual mode situation affected GL and GLUT as well. So, I’ve arrived at a solution where we prefer the native Quartz versions but will fall back if they’re not present (such as if you happen to be running the Darwin open source OS that macOS is based on. I think that’s the most reasonable approach because every macOS install will have Quartz, GL and GLUT (and using GTK doesn’t require you to install X11/XQuartz.
I’ve merged your change into 8.1 and 8.0 after testing, along with a bunch of other fixes to get things working. I have not been able to verify that the changes work properly on Windows because I am having trouble getting the windows build to compile successfully. Likely because I foolishly tried to upgrade to VC2015 from VS2008, which was working properly. There are also a number of problems with other bits of the 8.1 codebase that cause problems on Windows, though I see some commits lately that seem to suggest that may be a temporary thing.
Anyway, that’s the current update. And to answer your question about being able to run gtk apps on macOS without having to install X11, here’s a little taste :
x = GTK2Support.Alert("Hello world!");
On Wed, May 24, 2017 at 7:37 AM, H. William Welliver III
<[hidden email]> wrote:
> I’ve been quietly working on this for a few weeks now, and have got the
> various permutations working on OS X. Basically, there are 2 paths for GTK
> on OS X (now called macOS): X11, which is the classic approach, and Quartz,
> which is native, but newer and a little less fully baked. Homebrew, a very
> popular package manager on OS X, switched to Quartz mode at some point,
> which broke the pike builds. This sort of dual mode situation affected GL
> and GLUT as well. So, I’ve arrived at a solution where we prefer the native
> Quartz versions but will fall back if they’re not present (such as if you
> happen to be running the Darwin open source OS that macOS is based on. I
> think that’s the most reasonable approach because every macOS install will
> have Quartz, GL and GLUT (and using GTK doesn’t require you to install
Just managed to borrow someone to do some testing for me on a Mac, and
here's what we found:
1) Homebrew is pouring bottles of Pike 7.8.866. I would very much like
to change that at some point, but have no idea what that entails. How
do you bottle a formula?
2) Building Pike from source crashes out checking if rusage.c works in
3) rusage.h was not found. I don't know if that's significant.
Testing was done with the latest in the 8.1 branch, commit 3cc5d04.
I've successfully run a clean build of that same commit on my Linux
box, so it's not a critically broken commit or anything.
Sadly, I don't have a Mac to do any testing on, so I can't actually
probe this at all. What's the recommended way to install (a) a recent
stable Pike, and (b) the latest dev Pike, on a Mac?
I much appreciate the work being put into this. Pike + GTK2 should
mean we can do cross-platform GUIs easily... but it's not an easy
thing to accomplish.
They run a CI build that has been failing because of conflicts between native OS X GL and X11 GL. I’ve been trying to get 8.0 to compile properly under homebrew; I think I’ve got everything checked in now, so the next 8.0 release should be accepted into Homebrew. I suspect I did the last 7.8 release before they set that up, as the same problem exists there. Once the new 8.0 “formula” is checked into homebred-core, they will do a build and prepare a binary “bottle”.
Yes, I’ve got a few OS X clients running pike farm and there was a commit a few days ago that broke things on OS X and a bunch of other platforms. I think the problem is in the “POSIX source” commit.
I did a recent stable pike binary installer , but it doesn’t have GTK support. I put together detailed notes for doing this; most of that effort related to having static libs so that there are no external dependencies.
Aside from the recent commit that broke the dev build, pike builds without any real issues on OSX. You just have to install either Xcode or the Xcode command line tools, and any dependencies such as nettle, gmp, etc… if you’re not distributing the builds, homebrew works well for getting these without any effort.
Yes,I’m pleased to see that the GTK port on OS X finally works without X11. Another option perhaps worth considering is WX… there was a module for that a while back. The only problem is that cross platform UIs always seem a bit… wonky. The last cross platform app I built had a GTK ui on X11 and a native UI on OS X (via an objective-c bridge I built). A lot of work that may not have been worth the effort.
 Ask me for this, I haven’t had time to post them somewhere
|Free forum by Nabble||Edit this page|