Homebrew Cask for mac?

[yuvilio]

Love Mypaint. It's great for taking notes, annotating designs, and plain doodling. I happen to mainly use it on my Ubuntu Linux laptop with the mypaint-testing ppa. Sometimes I'm on a Mac, though. I can use it thanks to Homebrew Cask. with brew cask install mypaint . But the version they have there is quite old (1.0.0). 1.1 and 1.2 alpha really add a lot of features/stability.

Any interest/technical comfort in setting up a more recent build for it there? Mypaint was originally added in Homebrew/homebrew-cask#9104, but not much happened since. I can probably compile it but it might be a tougher reach for others.

Happy to test or elaborate more.

[achadwick]

I'd love to help support MyPaint on the Mac. I just don't have a copy of Mac OS to build it with.

Check out README_OSX.md for a MacPorts-based solution for testing. I'd love it if that doc came in Homebrew or Flink flavours, and I'd be willing to accept PRs to make it awesome. The same goes for any code PRs needed for portability.

@ryandesign has worked on the MacPorts port before. Say hi!

As ever, I'm happy to help out with any porting issues from the MyPaint side. Just ask via the our issue tracker or on IRC/twitter. I'm just sorry that I can be of little use myself in actually fixing porting issues - but I do know the guts of MyPaint.

If anyone really wants to step up to the plate and act as a contactable maintainer for a port, I'd be happy to add them to @mypaint/collaborators or a new team. Let me know how far you want to go with this, and what you need from me.

[ryandesign]

Hi, I do keep the MacPorts MyPaint (stable version) and MyPaint-devel (development version) ports updated.

I have no experience with Homebrew, but you're welcome to crib from our work at MacPorts; we are permissively licensed (BSD). The port definitions are here.

The MyPaint project is overdue in releasing a new stable version. The current stable version, 1.1.0, does not build on OS X 10.9 and later.

[achadwick]

Got it. We're approaching 1.2.0-beta now, so now is a good time to get changes in to support OSX, and get some thorough testing done. The beta cycle precludes new features and new strings (in order to be fair to our translators), but fixes for the weirdnesses of individual ports will still be fine, probably.

[yuvilio]

Appreciate the quick reply and background info, guys! I can look into it but my Homebrew knowledge is pretty limited as well. We can leave the ticket open for now and gauge interest from others, if that works.

I'll take a look into this. My brother uses MyPaint on a daily basis, and I'm trying to migrate him over to OS X from Linux. I'll look into building under homebrew and making a cask for it.

Ok I've returned from my journey of building master on OS X 10.11 GM with homebrew! I took notes on the way, and I've got mostly good news. All the dependencies were installable using homebrew, although under slightly different names than macports. Pressure sensitivity is not working, although the wacom app detects it. I'm using a Wacom Intuos.

• libjcon-c -> json-c
• gtk3 -> gtk+3

You'll need to homebrew pygobject3 as well. in addition, I had to fiddle with PKG_CONFIG_PATH, CFLAGS, LDFLAGS, and CPPFLAGS. I also had to install python from homebrew as it made some things easier (but some harder). The (very raw) notes I took are:

Installation Troubles

- autotools (brew install automake autoconf) - json-c (brew install json-c) - gettext (brew install gettext) - libffi add to PKG_CONFIG_PATH - /usr/local/Cellar/libffi/… - libintl - http://stackoverflow.com/questions/11370684/what-is-libintl-h-and-where-can-i-get-it - Need to add include folder to CFLAGS, LDFLAGS - gettext binaries need to be added to path by brew link —force - need pyobjc (sudo pip install pyobjc)

Numpy and Scipy come with OS X stock it seems, but for my homebrewed version I had to

pip install scipy numpy

[achadwick]

Oh, nice to see that! Thanks for putting in the effort 😃

Speaking of libintl, I'd appreciate an OS X tester's eye on our init_gettext() function, and the routines in lib/i18n.py. I've not tested those myself, but the [EDIT: idea behind] them is that users should be able to configure the language on their system in some conventional way, then see MyPaint's UI in a different language (if it's supported).

@achadwick I'll take a closer look this Sunday once I have time. It would be great for Mac users if this was all easily installable as a .app or through homebrew cask, so I'll definitely give packaging for this platform a shot.

As for the translation, I'll try configuring my desktop in one of the supported languages, but it seems the ones I do understand are not supported. Perhaps I'll translate the app into Spanish at some point down the road as well.

[achadwick]

I don't understand Mac packaging much myself, but that does sound awesome. Thanks for looking into it!

MyPaint should be at 100% coverage in Spanish for both major components - you can dive in and review/change the strings if you'd like (https://hosted.weblate.org/engage/mypaint/ is the link we hand out to people).

If the translation isn't taking effect (either fully or partially), that's probably an issue with the code linked above - this stuff is incredibly fussy and highly sensitive to the point at which it gets called during startup. The OSX side is untested by me and probably needs close scrutiny I can't do myself, so I'm really hoping somebody can help out here.

If you're making binary packages, I can link to where you're uploading them or store them here. I try to arrange the Windows and Ubuntu beta releases to be built from the same signed source tarball.

---

BTW, I'd be absolutely delighted to accept packaging/build scripts for well-defined platform distributions like Homebrew/Fink/MacPorts on Mac, MSYS2/MSYS/Cygwin on Windows, or Fedora/Arch/FooDistrib on Linux. If it has a package manager and you can write a build script for it, I'm interested! Normally, if the build script can slot into the main MyPaint project without upsetting third-party downstream builds, I'm happy to have the code reside in the mypaint/mypaint repository under a subdirectory which also contains instructions for the build. If it has more complex requirements (like our mypaint/debian one for the PPA, where the folder name would clash with official Debian builds), a separate module may be more useful.

[0ion9]

@achadwick re: Arch Linux, Have you talked to ShadowKyogre, the current maintainer of mypaint-git PKGBUILD? I'd expect he would be amenable to including the PKGBUILD (which should easily be adaptable to building directly from a local clone rather than re-cloning), and the rather minimal set of instructions needed ('cd $dir_containing_pkgbuild;makepkg -i`) to compile and install it.

[ShadowKyogre]

@0ion9: Found your comment mentioning me in my email inbox and thought I'd pop into the conversation. I'm a bit confused by what you mean by "from a local clone rather than re-cloning". The result wouldn't be any different from a local clone and it only clones the repo if there's no existing copy of it.

Do you mean a PKGBUILD that can be run inside of the source directory? That's a bit finicky and is normally not how PKGBUILDs are written (and I believe it'd be a lot more complicated than how the current AUR PKGBUILD is written).

Also, while I'd be happy to submit the PKGBUILD here, there's a quirk that I wasn't sure how I should report it to mypaint: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mypaint-git#n48

What line 48 does is remove the references to where the package was built in the pkg-config files (which is needed to build things like Gimp's mypaint brush engine integration).

[0ion9]

@ShadowKyogre : Yes, being able to be run from the source directory was what I meant. Obviously if you just dropped it in as-is, it would see that there isn't a clone in the correct directory, and re-clone.
My imagined solution was actually just a symlink to the appropriate parent/grandparent directory, but I haven't tested it yet.

That other issue.. hmm. I'm not sure if that can be solved on the mypaint side, since you are explicitly requesting that directory it's not surprising that the .pc file references it.
But in any case that seems like a minor issue, since what you are doing is not at all complex or difficult to understand.